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

From: "George Foti (LMC)" <[email-masked]>
Date: Wed, 6 Mar 2002 14:05:00 -0500

Comments inline
> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 12:15 PM
> To: [email-masked]
> Subject: [Sip] Path header vs. pre-loaded route in Contact
> 
> 
> 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  ;-)

The only way that the visited server can know the route to pre-load is
through response coming back to it from the registration process in the PATH
header,  as the home proxy assigned  to the subscriber takes place only at
registration, and that proxy name is returned in the response ( as described
previously) 
In conclusion the proposal cannot work

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

_______________________________________________
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 21:40:19 +0200

> In conclusion the proposal cannot work

george,

you are spreading complete disinformation.  either the ua or the visited
proxy can find out the ip address of the home proxy of the visiting user
by making a dns query for the sip srv record of the home domain of the
visiting user.  this has been mentioned at least a half of dozen times
on this mailing list.

i keep on copying the process until also you get it.

-- juha
-------------------------------------------------------------------
by the way, no one in your tag team has yet been able to provide a
convincing reason why even a 3gpp ua ua would need the path information.
as we know, the ua can always get its requests to its home proxy by
using the outbound proxy of the visited network and optionally a loose
source route to the home proxy that it can find from the dns.  then the
entry proxy of the home network can (based on local subscriber
information) forward the request to whatever internal proxy is needed to
handle it.  the entry proxy, by the way, doesn't need to record route
itself, which means that only the initial message of each dialog would
need to go via it.

so my second suggestion is that unless you can show some fundamental
flaw in the above process, you stop crying after the path response on
this mailing list.