Hi Dean, Thank you for your response. In the text below, I am not referring to GRUU, i.e. I am referring to outbound. IMHO there are two cases, i.e.:
1. The initial dialog-forming request, destined to the UA. When this request arrives at the authorative proxy, the outbound mechanism works OK (i.e. there are two-or-more alternative routes to the target UA which will be tried sequentially); and 2. The case when the dialog has been established. In this case the far-end UA builds the Route header that it will include in its subsequent in-dialog requests. Unfortunately, this Route header includes the edge-proxy#1 and flow#1 (flow-token#1). The failure of the flow#1 can not be tried again via flow#2. For the the authorative proxy, to re-write the Route header (to replace the edge-proxy#1 with edge-proxy#2) for this request and all subsequent in-dialog requests (destined for the UA) violate the SIP proxy function. Hence, I have my doubts that the outbound "alternative flow mechanism" will work for the in-dialog requests - as I have stated in my email. Cheers, Milo ======================================================================== ===== -----Original Message----- From: Dean Willis [mailto:[EMAIL PROTECTED] Sent: Sunday, October 19, 2008 12:47 PM To: Orsic, Milo (Milo) Cc: Paul Kyzivat; SIP IETF Subject: Re: [Sip] Outbound and mid-dialog requests with GRUU On Oct 18, 2008, at 12:17 PM, Orsic, Milo (Milo) wrote: > 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). > Flow 1 goes from contact 1 through edge proxy 1, flow 2 goes from contact 2 through edge proxy 2. Both flows are attached to a single instance-id. The home proxy/registrar keeps track of the keepalive status of each flow, and the keepalives keep the NAT binding open for each flow. Presume flow 1 is in-use for a dialog, and the flow fails. The home proxy must then re-route the dialog to flow 2. This requires a fair bit of mechanism in the proxy, mechanism that is not completely defined in the outbound draft, but that can be readily inferred. Another way to look at it is that Outbound routes to the "instance", not to the "contact". I think there is a little bit of confusion about gruu. Without Outbound, the gruu is an alias for the conact. With Outbound, Is the gruu an alias for the contact or the instance ? From a semantic- clarity model, I think gruu needs to be an alias for the instance. This however, is not completely clear to me in the current spec set. -- 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
