Re: 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