Hi, >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.
Correct. My misstake. Regards, Christer > 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
