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?
--
Dean
_______________________________________________
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
