Subject: RE: [Sip] The right solution to sip routing

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 30 Jan 2002 10:18:15 -0000

> Folks -
[...]
> Voila! Everything works very nicely.

Wow.

Very good.

I'm 'pressed that you managed to weave such magic given
the long legacy of specifications/implementations/
recommendations in a backwardly-compatible way, and still
get near as damnit ideal behaviour.

Certainly gets my vote.

 - Jo.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:10:23 -0500

Thanks for the support, Jo.

I'd also like to say a few words on this. After years of changes and
fixes and patches and modifications, I *finally* feel like we have it
right. I am certain that the ideal behavior in the note Robert sent is
the right one. The only ugliness around the mechanism surrounds the
requirement for mucking with the route set in order to handle downstream
strict routers; this actually will go away as proxies and UAs get
upgraded to bis. It is my hope and expectation that this aspect of the
specification would be removed when we rev to draft, and it was part of
our goals to define a mechanism which would not "leave a mess forever",
allowing the interim mechanisms to only get invoked when needed. 

An important benefit of the mechanism, which Robert mentions, is the
ability to finally discard the maddr parameter in the URI. maddr is
really the earliest legacy of our attempts at source routing. I think it
is clear that it should be discarded when you think about things in
terms of names, addresses, and routes. The URI is a name/address, but
definitely NOT a route. However, maddr is clearly a parameter for
routing, and thus does not belong in the URI. We needed it because
initially, we needed a way for a proxy to create a URL that BOTH
indicated the final destination AND the hop to get there. By formally
separating these now, as it should be, the need for maddr disappears.
This provides a nice resolution of the various problems we have found in
the interpretation of transport and port in the URI when maddr was
present, in addition to proxy processing logic in the presence of maddr
in the r-uri. THis causes confusion since it effectively presents two
independent routing guidelines - the URI, and the Route headers, and
there are precedence issues which are hard to resolve. The proposal
helps resolve them by making sure there is one mechanism for routing.

The mechanism also makes the way much easier for a formal definition of
the Path header. Now, it becomes just like record-route - it represents
a hop. The difference is only one of scope. The UA uses it to learn of
pre-loaded routes to a particular domain, and the registrar uses it to
learn of pre-loaded routes to a client. A proxy inserts one when it
wishes to be on a pre-loaded route to that domain, or in the path of
calls from that domain back to the UA. The scope of it depends on the
message its carried in; for REGISTER, its scoped to the lifetime of the
registration. But, it seems like it would even be useful to allow Path
in something like OPTIONS, which would allow a UA to learn of preloaded
routes to a domain without having to register to that domain. 3gpp can
elect not to use it, but it would allow for a more general "pre-loaded
route discovery" tool which could be used without binding outgoing calls
to a registration.

I'll send a separate note with an example flow of how I think it should
work based on this new mechanism. 

Much thanks to Robert for doing a tremendous amount of working in
getting us from where we were to where we are now. Arguably the hardest
and most important problem in SIP is now licked!

-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