Subject: [Sip] Path header vs. pre-loaded route in Contact

From: Rohan Mahy <[email-masked]>
Date: Wed, 6 Mar 2002 09:14:58 -0800 (Pacific Standard Time)

Hi,

I think Juha is proposing something like this.  I haven't spent enough
time with loose-routing to figure it out on my own.  Does anyone have a
reason why this wouldn't work instead of using the Path header?

UA needs to find a proxy in the visited domain:

- DHCPv6 option for SIP servers
  or
- DHCPv6 option for domain name and then use DNS SRV or NAPTR
to find a suitable server (for example: nyc.visited.net)

Then the UA adopts this (visited) server as its outbound proxy, and
registers with the home network.  It adds a pre-loaded loose-route
(which points at the visited proxy) into its Contact.

REGISTER sip:home.net SIP/2.0
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Contact: <sip:user@12:34:56:78:9a:bc:de?Route=sip:nyc.visited.net;lr>
Route: sip:nyc.visited.net;lr           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Alternatively the visited server could add the pre-loaded Route to the
contact.  (Since, it's really a B2BUA anyway  ;-)

Since all the 3GPP entities support loose-routing, it seems at first
glance that this should work fine.  When the home proxy looks up the
Contact for [email-masked], it inserts a Route header and forwards the call
on as if the top-most Route URI was the request-URI.  You can still go
through as many border proxies as you want, before you arrive at the
visited network, which strips the Route header and forwards the request
onward.

thanks,
-rohan

_______________________________________________
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: [email-masked]
Date: Wed, 6 Mar 2002 20:03:02 +0200

looks like rohan's proposal to add the route parameter to the contact is
an alternative to the new record-register-route header that i
proposed.  either way would solve the problem for routing incoming
request to the ua via the proxy at the visited network.  i suggest that
we pick one and are done with this thread.

-- juha

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 6 Mar 2002 13:13:49 -0500

Strikes me that Rohan's proposal is more flexible and general, since it
can have any route the user wants for incoming calls as opposed to the
inverse of the route that the Register took.

If you actually want that behavior, though, how would you do the
discovery? Do a record-route on a REGISTER and then re-register with
what you want?

Dave.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, March 06, 2002 1:03 PM
> To: Rohan Mahy
> Cc: [email-masked]
> Subject: [Sip] Path header vs. pre-loaded route in Contact
> 
> 
> looks like rohan's proposal to add the route parameter to the 
> contact is an alternative to the new record-register-route 
> header that i proposed.  either way would solve the problem 
> for routing incoming request to the ua via the proxy at the 
> visited network.  i suggest that we pick one and are done 
> with this thread.
> 
> -- juha
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>

---

From: [email-masked]
Date: Wed, 6 Mar 2002 20:35:51 +0200

> discovery? Do a record-route on a REGISTER and then re-register with

this mechanism is only for register message in other to others to find a
route to me.  for outgoing non-requests, i would use the normal sip
means, i.e., i would query dns for the proxy of the user i want to reach
and then send the message there possibly via my outbound proxy (if any).

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 6 Mar 2002 13:43:52 -0600

Rohan wrote:
> Does anyone have a

This is a scaled-down version of my "compound contact" idea of about a year
ago, which I think was my first response to the original Path proposal I
heard from Bill Marshall.

The approach as suggested only works if there is only one proxy, identity
known to the roaming UA, in the path. If there are multiple proxies, for
example firewall controllers, which may be unknown to the roaming UA at the
time of registration, then it breaks.

One could get around this by allowing intermediate proxies to edit the
Contact, adding themselves to the compound-contact (I think I proposed
something like this once). This is nicer than the
synthesize-a-local-alias-and-remap-the-contact model, in that it doesn't
require added state in the listed intermediate proxies, but it does have the
same potential interaction with message integrity mechanisms that protect
the Contact field.

 --
Dean