comment at end.
Dean Willis wrote:
On Oct 17, 2008, at 7:50 PM, Paul Kyzivat wrote:
Not helpful; section 7 refers to out-of-dialog request forwarding.
Why do you say that. That section of outbound doesn't even mention
dialogs.
It also doesn't mention multiple contacts per GRUU.
What happens to in-dialog requests?
The request references a gruu.
A pre-outbound gruu is bound to one and only one contact, so the
request-URI transformation rule is obvious; transform the request-URI
using the contact associated with the gruu. This behavior is
specified in 6.1 of the gruu draft. Oddly enough, that text in
gruu-6.1 replaces the request-URI with "the registered contacts"
(note the plural). Not sure that makes sense. Somebody tell me if
that's a bug in gruu.
An outbound-compliant gruu is bound to one and only instance, but an
instance can have multiple contacts.
I think what has to happen to make it work is fairly obvious, but it
isn't documented anywhere I can find.
There's some hinting at it in outbound-5.3.2, but inly from the
perspective of the edge proxy. What has to happen at the home proxy
to make this work?
I assume the same thing as for out of dialog requests. Out of dialog
requests that reference a gruu need just as much to get to the proper
instance as in-dialog requests do.
Not really; for out-of-dialog requests, any contact is equally valid.
But for in-dialog requests, I think there's a need to use the flow that
was used by the earlier requests in the dialog, if that's possible.
Why does it matter if both flows are functional? Presumably if one of
the flows has had problems the proxy ought to choose the other one first.
Are there any SIP devices that get confused when they see an unexpected
request URI on a request, for example, when the request URI
spontaneously changes mid-dialog without a reINVITE?
Are there other elements that might get confused by NOT seeing some
messages in a dialog?
For example: what happens if there is an off-the-shelf SBC squatting on
each flow?
Well, the multiple flows are there for redundancy, right?
If one of the flows failsl, the whole point is that things should
continue. If the UA gets upset receiving in-dialog messages on a
different flow, then things aren't working right.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
