You have an MGC that registers?
If so, it can avoid this problem by not using the new option when
registering. This is *optional* behavior.
Paul
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
_______________________________________________
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
_______________________________________________
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
