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

From: Ben Evans <[email-masked]>
Date: Thu, 18 May 2006 16:55:03 +1200

Hi, I am trying to figure out what should be a simple proxying scenario using draft-ietf-sip-outbound-03. Consider the following scenario:

   UA1 -------> proxy ------- UA2
        flow

1. UA1 forms a flow to a proxy/registrar (no edge proxies involved) and registers successfully.

2. UA2 makes a call to UA1 (UA2 may or may not have a flow to the proxy, it does not matter here). 

3. The proxy receives the INVITE, looks up UA1's AOR (the Request-URI) in its location service, and finds the contact URI and the flow information. The proxy then uses the flow to send the request to UA1. The proxy also adds itself to the Record-Route header.

4. UA1 responds with 200 OK, which is forwarded to UA2.

5. UA2 now has to send the ACK. It forms the ACK request using UA1's contact URI as the Request-URI, and the route set from the dialog.

6. The proxy receives the ACK from UA2...

My problem is: how does the proxy know to send the ACK out on the correct flow to UA1??

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?

Thanks
Ben
-- 
Ben Evans / Software Engineer / Open Cloud / [email-masked]
Tel: +6421636182 / PO Box 19210, Wellington, NZ / www.opencloud.com

_______________________________________________
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: Thu, 18 May 2006 10:44:57 -0500

On May 17, 2006, at 11:55 PM, Ben Evans wrote:

> Hi, I am trying to figure out what should be a simple proxying  
> scenario using draft-ietf-sip-outbound-03. Consider the following  
> scenario:
>
> 3. The proxy receives the INVITE, looks up UA1's AOR (the Request- 
> URI) in its location service, and finds the contact URI and the  
> flow information. The proxy then uses the flow to send the request  
> to UA1. The proxy also adds itself to the Record-Route header.
>
> 5. UA2 now has to send the ACK. It forms the ACK request using  
> UA1's contact URI as the Request-URI, and the route set from the  
> dialog.
>
> 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.

--
Dean

---

From: Ben Evans <[email-masked]>
Date: Fri, 19 May 2006 15:41:18 +1200

Dean Willis wrote:
>> [...]
>> 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?
> 
> 
> 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!

Cheers
Ben

---

From: Dean Willis <[email-masked]>
Date: Fri, 19 May 2006 18:52:45 -0500

On May 18, 2006, at 10:41 PM, Ben Evans wrote:

>> more
> 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 . . .

--
Dean