Hi Dean, Pertaining to Paul's posting below: ------------------------------ Well, the multiple flows are there for redundancy, right? If one of the flows fails, 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 ====================== The UA will not get upset, since it may not receive the message. Assume: 1. First registration between (UA's address) IP#1 via edge proxy#1 establishes the binding in the NAT/reflexive-firewall (and flow#1) - as required by the draft. 2. Second registration between (UA's address) IP#2 via edge proxy#2 is used for redundancy, establishes the binding in the NAT/reflexive-firewall (and flow#2) - as required by the draft. 3. Dialog is established using this flow#1 (and Route for this dialog includes the edge proxy#1). There was never a registration between IP#2 via proxy#1. Hence, any in-dialog request (destined for the UA) sent from edge proxy#1 (since it is in the Route) to IP#2 will be filtered by the NAT/reflexive-firewall. As you can see by this example, the second registration - as required by the draft - doesn't really creates a redundant flow. IMHO, the draft should restrict the "redundancy" to a single contact address (reached via different edge proxies). Cheers, Milo ======================================================================== ==== ======================================================================== === -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Saturday, October 18, 2008 9:51 AM To: Dean Willis Cc: SIP IETF Subject: Re: [Sip] Outbound and mid-dialog requests with GRUU 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
_______________________________________________ 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
