Subject: RE: [Sipping] Telling a proxy which service to execute

From: "Elwell, John" <[email-masked]>
Date: Tue, 08 Nov 2005 01:44:59 +0000

Jonathan,

Interesting, and in some ways more logical. But is it feasible to make the
change now? How many existing UASs would tolerate receiving the AoR rather
than the Contact URI in the Request-URI?

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 06 November 2005 18:29
> To: Francois Audet
> Cc: Gonzalo Camarillo; sipping; Elwell, John
> Subject: Re: [Sipping] Telling a proxy which service to execute
> 
> inline.
> 
> Francois Audet wrote:
> 
> >>It has been proposed (in 
> >>draft-elwell-sipping-service-retargeting-00.txt) to use URI 
> >>parameters 
> >>for that. This approach has been compared by some in the 
> list to the 
> >>approach followed by netann (draft-burger-sipping-netann-11.txt).
> >>
> >>It is worthwhile noting that using URI parameters to convey service 
> >>information (on any type of information) has an important 
> problem. If 
> >>the request traverses a proxy that does not understand the URI 
> >>parameter, the URI parameter may be removed. That is the 
> >>reason why we 
> >>moved away from URI parameters to implement URI-list 
> services (a.k.a. 
> >>exploders).
> > 
> > 
> > If a proxy arbitrarily removes parameters, it will cause lots of
> > problems
> > (including with Netann).
> 
> I've been thinking about this a bunch, and it seems that much of the 
> problems stem from a fundamental confusion in sip about the 
> purpose of 
> URI translation.
> 
> Today, we use translation of the request URI to do what I think are 
> fundamentally two different things. One of them is a 
> translation for the 
> purposes of routing the request to the intended target. In 
> such a case, 
> the intended target is indeed legitimately identified by the 
> value that 
> was previously in the request URI; we just modified it 
> because we want 
> the request to get to that target. The classic example of this is 
> standard registration processing, where the request URI is 
> replaced by 
> the registered contact.
> 
> The other usage is where the target of the request is modified (aka 
> retargetting). In such a case, the new URI is not identified 
> by the new 
> URI, we are truly directing the request elsewhere. Call forwarding, 
> forwarding to voicemail all are in this category.
> 
> Many of our problems with loss of URI parameters stem from 
> the fact that 
> URI re-writing is done to reach the actual target (i.e., the 
> first case 
> above). These would all go away if we made a somewhat radical 
> change in 
> SIP processing, which I throw out for thought purposes (may 
> very well be 
> too late for something like this).
> 
> The proposal is that request URI rewriting never occur in the first 
> case. Rather, loose routing be used. That means that normal contact 
> routing in sip would happen by pushing the registered contact 
> into the 
> route set, rather than rewriting the request URI. So, if A calls B in 
> the standard trapezoid configuration, proxy B would forward to the 
> called party a request that looks like this:
> 
> INVITE sip:[email-masked]
> Route: sip:Bs-registered-contact
> 
> rather than what happens today:
> 
> INVITE sip:Bs-registered-contact
> 
> and if a Path was used in the registration, the registered 
> contact would 
> be the last value in the Route set. This would mean that route 
> processing would get applied to UAs also, but that bridge was crossed 
> long ago and I think it brings benefits.
> 
> Other types of inter-proxy routing would work the same way; the 
> request-URI remains unmodified unless the actual request 
> target changes.
> 
> Now, if you did this, using URI parameters to identify a 
> service works 
> exactly as you want. If the request is truly 
> retargeted/forwarded away 
> from that service, the URI parameters are lost, as they 
> should be. Any 
> message munging to get the request routed to the service that can 
> understand the URI parameters would occur through Route header pushes 
> and pops, and thus the request URI parameters would be retained.
> 
> The problem with this, historically, has been that, when a client 
> performs a REGISTER, there is no way to know whether the Contacts 
> represent a way to reach a UA representing a user that can 
> authenticate 
> themselves with the given AOR (in which case, by my proposal 
> above, the 
> request-URI would be unchanged), or whether they represent a 
> different 
> user entirely (in which case the request URI would change). At this 
> point, I would go so far as to declare this a bug in 
> REGISTER, and that 
> security problems, NAT traversal problems, and other things 
> have more or 
> less pushed us in the direction of draft-ietf-sip-outbound, 
> which says 
> that registrations register a route to the specific UA. As 
> such, if you 
> use sip-outbound exclusively a proxy would always know that 
> it would not 
> rewrite the request URI when doing contact routing.
> 
> Fire away....
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 21:37:35 -0500

Ah, good question.

My idea on this was to tie it to sip-outbound. The idea is that, when a 
home proxy does the registration lookup, it checks to see whether the 
registered contact was one created via sip-outbound. If so, the proxy 
KNOWS that this contact is a route to the entity with the given AOR 
(since sip-outbound provides that property). As a consequence, the R-URI 
would remain the same. If the contact didn't arrive via sip-outbound, it 
does what it does today - rewrite the r-uri - because it can't know 
definitively one way or the other whether its a retarget.

So, sip-outbound itself could specify that compliant implementations 
must be prepared to receive their AOR in the r-uri of incoming requests, 
and that there would also be a Route header there containing the URI 
they registered in the contact.

Another problem we'd have to face is, when receiving a redirect, how 
does a proxy know whether the redirect is a retarget vs. just a 
forwarding hop towards the existing target? I have proposed a solution 
to that in the route-construct draft:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-00.txt

The idea is that a 305 means adding a forwarding hop, all other 
responses are retargets. As such, a proxy or UA recursing on a 305 would 
take the Contact header field URI in that 305, and populate that into 
the topmost Route header field value of the outgoing request, rather 
than rewriting the request-URI.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com