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

From: "George Foti (LMC)" <[email-masked]>
Date: Wed, 6 Mar 2002 16:18:31 -0500

Hi Rohan,

For incoming calls, that should work,.

I am concerned about outgoing calls, which have  to be handled by the home
proxy of the originating sub. The request will get to the I-CSCF for the
home, but after that,  the I-CSCF has no way of routing it any further and
it would have to interrogate a data base to find out the proxy assigned to
the sub. for further routing.

We would have to do that for every originating request, since the I-CSCF is
stateless. Now that will lengthen the call set up time and is inefficient.

By being able to return the proxy assigned to the mobile in a resgistration
response, it can be pre-loaded by the P-CSCF for originating calls and we
would save the step of I-CSCF interrogating the database for the proxy
assigned  to the sub.

Dont know if that clarifies this case.

Rgds/gf

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 4:07 PM
> To: George Foti (LMC)
> Cc: 'Rohan Mahy'; [email-masked]
> Subject: RE: [Sip] Path header vs. pre-loaded route in Contact
> 
> 
> Hi George,
> 
> I think you misunderstood me.
> 
> ---- Original message ----
> >Date: Wed, 6 Mar 2002 14:05:00 -0500 
> >From: "George Foti (LMC)" <[email-masked]>  
> >Subject: RE: [Sip] Path header vs. pre-loaded route in 
> Contact  
> >To: "'Rohan Mahy'" <[email-masked]>, [email-masked]
> >
> >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
> 
> George, this is a Route header in the Contact which gets used 
> for incoming calls only.  The visited proxy only needs to 
> know its own address, or as Dean pointed out, any border 
> proxies in the visited network that need to be in the path, 
> but that wouldn't be reached if the home network was trying 
> to use ordinary SIP loose-routing to get to nyc.visited.net
> 
> The visited network doesn't need to know anything about 
> proxies in the home network for example because loose-routing 
> would cause them to be reached based on local policy in the 
> home network.
> 
> In the 3GPP case, it seems likely the P-CSCF would know the 
> sip URI of any I-CSCF in the visited network, and could add 
> this to the Contact header.  Like Dean said, this could run 
> afoul of end-to-end message integrity, but that's not likely 
> to affect the 3GPP case.
> 
> Can you think of anything else about this that would not work 
> in the 3G case.
> 
> thanks,
> -rohan
> 
> 
> >
> >
> >> 
> >> 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
> 

_______________________________________________
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: Wed, 6 Mar 2002 15:44:09 -0600

> would save the step of I-CSCF interrogating the database for the proxy

One could use some other mechanism than REGISTER for discovering the
dynamically assigned home proxy, and that mechanism could provide the entire
home-side service route if needed.

For example, a system I'm currently working with has the phone doing an HTTP
GET for a configuration file that contains the name of the home-proxy
cluster, and we send the phone a control message telling it to reload if
there is a change. One could extend this to download a "Service route" that
would include both the I-proxy and the S-proxy.

This does use a couple more messages than REGISTER, so is by some measure
less efficient, but it can be shown to work adequately. Whether one likes it
or not, the REGISTER/PATH approach is reasonably efficient.

--
Dean

---

From: [email-masked]
Date: Thu, 7 Mar 2002 08:47:59 +0200

> or not, the REGISTER/PATH approach is reasonably efficient.

if you really want to pin down a proxy for the user (which as i have
explained many times) is a bad idea, then you would need invent a new
sip request for that purpose, because register message is not a general
solution to the problem.  the reason is that if i don't want to register
at all and if for some very strange reason, i would still need the
pinned down home proxy, i would have no way of getting it.

but i haven't yet heard any convincing reason why such pining down of a
home proxy would be needed.  i start to suspect that the real reason is
that the 3gpp ims folks have already decided to use the path message and
can't change that decision.  if that is the case, then do your own
proprietary extension.

-- juha

---

From: [email-masked]
Date: Thu, 7 Mar 2002 08:42:30 +0200

> the sub. for further routing.

it is good that you now admit that your previous email about this topic
was bogus and that in fact we don't need to do anything to the sip
protocol in order to make the 3gpp ims service work.  it is just a
question of implementation efficiency and i simply don't believe that a
single database query can be any issue at all.

currently when my proxy gets an invite message, it needs to make lots of
database queries, for example, to check if caller belongs to one of my
home domains, if so, to check that the from address belongs to the user,
to check that the user has the right to place a call to the to address,
to check what long distance or international carrier the caller want to
use, if it is emergency number, to check where the user is located,
etc., etc.

there are several possibilities to speed up the simple query that the
3gpp ims entry proxy needs to do.  first is of course load balancing to
keep the load of a single entry proxy low.  then you could, for example,
cash the next hop proxy in the memory of the entry proxy when the user
registers and then make the query in a few milliseconds.  i just bought
512 mb of ram for my computer and it costed me about usd 75.

 > stateless. Now that will lengthen the call set up time and is inefficient.

see above.  this is all bogus.

 > would save the step of I-CSCF interrogating the database for the proxy

and what happens if the preloaded proxy dies?  this kind of pinning down
a particular proxy is a very bad idea in general.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Mar 2002 02:08:07 -0600

> pinned down home proxy, i would have no way of getting it.

Actually, I think we have demonstrated that it's a reasonable solution to
get this information from REGISTER as long as you're registering anyhow.
There might be a requirement for another way to get it, if one wants to not
register, but that's a seperate problem probably solvable a different way.

> can't change that decision.  if that is the case, then do your own

Then you aren't listening, because there have been ample reasons given to
use a home service proxy, and I will want such an extension in my personal
home phone so it's not just IMS.

1) We have rough consensus on providing an optional extension header to use
REGISTER to discover service routes in each direction. I know, Juha
disagrees, but that's the "rough part" . . . we can always consider other
techniques for accomplishing similar goals.

2) We've had it proven that, even though it works like RecordRoute, we can't
call this extension RecordRoute due to backward compatibility problems (as
Jonathan Lennox reminded us), so Path's as good a name as any.

3) We have a draft on the table that provides baseline text for the
extension. Somebody please volunteer to edit it the rest of the way home . .
 .

4) We've debated the heck out of it and haven't come up with an idea that's
demonstrably cleaner, more efficient, or better enough to convince a quorum.

So, unless somebody who's a) got a good argument otherwise, and b) isn't
repeating Juha's argument, (because we've heard his argument, and while
credible and argued with admirable tenacity, we have rough consensus to do
otherwise) presents said argument to the contrary REALLY quickly, then I
think we have to proceed with Path.

So I strongly suggest we close this topic and get on with other work. Unless
there is a striking new contribution, I plan to ignore any continuance of
this thread, and request you all do the same.

Good Day!

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Mar 2002 16:57:03 +0200

> home phone so it's not just IMS.

you send your invite to the proxy of your domain and that proxy can
forward the invite to your personal proxy that handles the speed dial or
whatever personal services you have.

we can't have a function tht has nothing to do with registration and
that only is available if someone registers. the same solution must be
also available if someone doesn't want to register.

finally, if you are going to push this through then please also edit the
bis so that it is not inconsistent with your path.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Mar 2002 23:55:02 -0500

> bis so that it is not inconsistent with your path.

I find nothing in the Path proposal inconsistent with bis. I also think
I have fair shakes at claiming a pretty darn good sense of what is and
is not consistent with bis.

I will tell you what is NOT consistent. It is NOT consistent to use
Record-Route in register, as has been pointed out by many. It is also
NOT consistent to add ?Route header values to the Contact in the
REGISTER to indicate an incoming path. The reason is, the biggest
breakthrough we made in bis was to realize that the ultimate
destination, and the hops for getting there, are really, really
different things. All our attempts of glomming them together with the
old routing stuff was ugly and error-prone. By putting the hops
(conveyed in ?Route elements) back into the same header you use to
convey the destination (Contact in the REGISTER), we are brought right
back there once more. No way. For incoming calls, the best way, and most
consistent way, for the registrar to learn about intermediate hops is a
new header with semantics much like record-route, but scoped to a
registration. I can also assure you there is nothing it can't do that
appending a ?Route to the Contact can do. (I realize you did not propose
this, so do not take it personally).

Now, for outgoing requests. I sympathize with you, Juha, that the
reasons for needing it in the IMS are not that compelling (avoiding the
DB dip at the I-CSCF for mobile originated calls). However, I think it
is well within the scope of bis to allow route discovery in any message
that traverses some kind of path of proxies, so long as the scope is
well defined. I had even thought about allowing Path (or something with
a different name) in OPTIONS, to discover routes of even broader scope.
Thus, I think it is perfectly within the bounds of SIP to discover an
outbound path, scoped to a registration, through a register response. I
agree its not terribly useful, but its not unreasonable, and definitely
not counter to the very fabric of the sip architecture, as you have been
claiming.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 8 Mar 2002 14:14:18 +0200

> is not consistent with bis.

i quess it depends on what someone means by inconsistency.  for example,
path changes the bis defined purpose of sending a register request and
it changes the ua behavior when it sends a non-register requests.

 > Record-Route in register, as has been pointed out by many. 

that is why i proposed that the header is called Record-Register-Route.
i don't dispute the need for that for inbound requests.

 > not counter to the very fabric of the sip architecture, as you have been

i could accept that if i could do the discovery without registering
although as i have said and that you too admit, there is no real need
for it in the 3gpp application and noone has not been describe any other
application either where this the discovery would be needed for outbound
calls. 

-- juha