Sorry, the draft is not clear on this. It also works in cases where the
proxies translation logic is NOT based on registrations.
The basic idea is to apply the ;lr param in this case. So if the proxy
looks up the request URI and find that the result is a SIP URI with the
;lr param, it pushes that into the route set rather than rewriting the
R-URI. Without the ;lr param, it rewrites the R-URI as it does today.
This is merely applying the exactly same logic we have for mid-dialog
signaling, but for the initial dialog-forming request. I think there is
some elegance in that.
So, if we consider this MGC case, the routing logic in the proxy that
points to these old MGC would have entries which omit the ;lr parameter,
and those pointing to ua-loose-route compliant ones would include it.
-Jonathan R.
Christer Holmberg (JO/LMF) wrote:
Hi,
At least with existing MGCs you will have backward compability issues.
MGCs normally route SIP-to-ISUP calls based on the Request-URI, and if the
Request-URI contains e.g. a sos servicetype URN, or a 800 service number, the
MGC will not be able to route on those.
Regards,
Christer
-----Original Message-----
From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED]
Sent: 13. kesäkuuta 2007 6:02
To: IETF SIP List
Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility
I've recently revised my draft on UA loose routing. You can
pick it up here:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
se-route-01.txt
This draft is meant to fulfill one of our charter items:
Feb 2008 Delivering request-URI and parameters
to UAS via proxy to
IESG (PS)
As folks may recall, the GRUU spec used to have these things
called grids, which allowed a UA to add its own parameters to
the GRUU before handing it out. Several GRUU revisions back,
this function got yanked because it was recognized that the
problem was more general than GRUU, and would be useful for
AOR as well.
Two IETFs back I presented this draft briefly during a SIP session.
There was a lot of interest and people liked it
architecturally, however there were two open issues that
needed to get resolved. This mail is meant to start
discussion on one of them - backwards compatibility.
THe mechanism basically changes the way proxies handle
requests. Instead of rewriting the request URI for
out-of-dialog requests, they'll push a route header and leave
the r-uri alone. This allows the original R-URI and any
parameters it contains to get delivered to the UAS.
So, the main issue is, what kinds of backwards compatibility
problems will this cause. The draft provides a basic
mechanism whereby a UA includes an option tag in the
REGISTER, and the registrar indicates that it is using this
mechanism or not. So we can negotiate this between a UA and
registrar easily. Now, the problem is with intermediate
proxies. If there is an edge proxy between the UA and its
registrar, it will now see requests targeted to the UA, which
contain a Route header beyond itself, even though it thinks
its the edge proxy and the last point of contact before the
UA. Technically, if this edge proxy is compliant to rfc3261
it would work. However, the question is whether proxies in
the wild would properly work in this case.
If folks can comment based on their own products, or their
experiences, on whether they think this would work, or
concerns they have, that would be great. THere are solutions
that would allow us to disable the mechanism when
intermediate proxies don't support it, but they are more
complex and I'd rather avoid it.
THanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ
07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Cisco Fellow Parsippany, NJ 07054-2711
Cisco Systems
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
