Subject: Re: [Sip] draft-ietf-sip-outbound-03: proxy routing question

From: Cullen Jennings <[email-masked]>
Date: Sun, 11 Jun 2006 15:32:14 -0700

Ahhg --- when using GRUU this may just happen without the double R-R.  
I've no objections to putting some clarifying hints in but I'm really  
not sure exactly what to add. Anyone want to send text?

On May 19, 2006, at 4:52 PM, Dean Willis wrote:

> On May 18, 2006, at 10:41 PM, Ben Evans wrote:
>
>> Dean Willis wrote:
>>>
>>> On May 17, 2006, at 11:55 PM, Ben Evans wrote:
>>>> [...]
>>>> Because the ACK's Request-URI contains UA1's contact URI, not the
>>>> AOR, the proxy would normally not do a location service lookup (the
>>>> contact URI is a physical IP address/port). So how does the proxy
>>>> obtain the flow information  from the location service so that  
>>>> it  can
>>>> send the ACK (and any future mid-dialog requests) on the  correct
>>>> flow? What am I missing?
>>>
>>>
>>> My theory is that the proxy should use the "double record routing
>>> trick". As such, it inserts two R-R values. The first identifies the
>>> interface and flow binding for UA1, and the second identifies the
>>> interface as seen by UA2.
>>>
>>> When the proxy receives the ACK at step 6, it pops the first  
>>> route  (its
>>> interface facing UA2). It then inspects the next route to figure   
>>> out
>>> where to send. Since this next route is also "local", it pops  this
>>> route field, picks the flow from the information in that route   
>>> field,
>>> and puts the ACK onto the flow towards UA1.
>>>
>>> We originally developed this trick to work with proxies that  
>>> have  more
>>> than one interface, but since the flow identifier is sort of a   
>>> "virtual
>>> interface", the technique should work here.
>>
>> Thanks Dean, this worked really well. Should this technique should  
>> be mentioned in the draft? Or maybe it is already obvious to those  
>> in the know!
>
> Good point. Probably wouldn't hurt to mention it. Lots of people  
> just assume people understand this, so it may not get the needed  
> coverage.
>
> Oh Mr. Outbound Editor . . .

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 12 Jun 2006 12:58:01 -0500

Why would GRUU keep the proxy from being able to double-R-R? It might  
change what would go INTO the R-R, which shouldn't be a problem.

--
Dean

On Jun 11, 2006, at 5:32 PM, Cullen Jennings wrote:

>
> Ahhg --- when using GRUU this may just happen without the double R- 
> R. I've no objections to putting some clarifying hints in but I'm  
> really not sure exactly what to add. Anyone want to send text?
>
>>>> interface facing UA2). It then inspects the next route to  
>>>> figure  out
>>> Thanks Dean, this worked really well. Should this technique  
>>> should be mentioned in the draft? Or maybe it is already obvious  
>>> to those in the know!
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Jun 2006 21:23:52 -0400

The double record-routing is neccesary if one of two conditions are true 
(or both):

1. a proxy is reachable at different IP addresses/hostnames/ports on 
each side of the dialog,

OR

2. the next hop where a mid-dialog request should go is a function not 
just of where its going, but where it came from

We've traditionally used double-RR in case 1. Its still pretty much 
undocumented I think. SIP outbound introduces (not sure if its the first 
time) case number 2.

Consider a mid-dialog request from UA1 towards UA2. Such a request would 
look like:

INVITE sip:ua2-contact
Route: sip:ua1-rr

and from UA2, towards UA1:

INVITE sip:ua1-contact
Route: sip:ua2-rr

The issue that Ben is raising, I think, is that, prior to sip-outbound, 
the proxy would receive the request, pop the top route (being its own), 
and then find no more Route headers, thus use RFC 3263 on the r-uri to 
send it on its way. With sip-outbound, thats not really true.  The next 
hop decision made by the proxy depends on the *direction* the request is 
coming from. For the request from UA1 towards UA2, its standard DNS SRV. 
For the request from UA2 towards UA1. However, even though the domain in 
the r-uri doesn't match that of the proxy, its NOT standard DNS SRV. 
Rather, the proxy needs to know to place the request on the existing 
connection towards UA1. How does it know to do that? Should it rely on 
the value of the R-URI? Turns out thats a bad idea (a bit more on that 
below). Rather, the value in the Route header field is what would tell 
it to do that. But, if ua1-rr == ua2-rr, it doesn't work.

GRUU, if anything makes this problem even more amplified. Mid-dialog 
requests towards the client, per gruu-07, will have the registered 
contact in the Request-URI, as in the examples above. However, that 
contact got there because the home proxy translated the GRUU that was in 
the r-uri into that contact. Turns out, there is a decent chance that, 
if a client has multiple flows registered, the home proxy might get it 
wrong. This means that the r-uri for mid-dialog requests becomes even 
less reliable for telling the proxy where to send the mid-dialog request 
(but ONLY for requests towards the client). This means that the Route 
header is really the only way to know the algorithm to apply for 
forwarding (DNS SRV vs. connection mapping).

Thus, to make a long story short, I think sip-outbound does in fact push 
heavily towards double-RR, and GRUU only amplifies this need further. I 
do think its worth documenting this in sip-outbound. Indeed, while 
revising gruu today, I more or less convinced myself that sip-outbound 
needs to almost mandate that a proxy NOT look at the r-uri to determine 
which connection on which to send a request.

Thanks,
Jonathan R.

Dean Willis wrote:

>> Ahhg --- when using GRUU this may just happen without the double R- R. 
>>>>> interface facing UA2). It then inspects the next route to  figure  out
>>>>> We originally developed this trick to work with proxies that  have  
>>>>> more

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com