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

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Nov 2005 14:12:26 -0600

> 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).

However, if the proxy retargets for whatever reason, I agree with you
that
the expectation would be for the parameters to be lost. 

_______________________________________________
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: Sun, 06 Nov 2005 13:28:31 -0500

inline.

> If a proxy arbitrarily removes parameters, it will cause lots of

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

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 09 Nov 2005 15:11:20 -0500

> INVITE sip:Bs-registered-contact

Though this does mean the UA has to recognize that "sip:[email-masked]"
is one of its own names.  For an ordinary desk telephone, this doesn't
seem to be a problem, though for more complex situations, an agent might
not be able to recognize all addresses that "are forwarded to it".

Even the phone case might be messy...  Consider this:

In a typical sipX SIP PBX (http://www.sipfoundry.org) installation, each
extension forwards to first, any registered contacts (phones for the
extension), and second, the voicemail system.

So sip:[email-masked] is proxied to sip:[email-masked] and then to
sip:10.1.1.20;mailbox=123;action=deposit.

Currently, SIP phones do not recognize the AOL of one of their line
appearances as their own name.  So if you dial 123 (meaning
sip:[email-masked]) from phone 123:

1. The phone forwards it to the proxy for example.com.

2. The proxy forwards it first to sip:[email-masked].

3. The phone rejects that call with 486 Busy.

4. The proxy forwards it next to
sip:10.1.1.20;mailbox=123;action=deposit, which being the voicemail
system, accepts the call.

If the phone were to recognize sip:[email-masked] as being itself, the
process would be short-circuited.  The phone would not forward the call
at all, and terminate it itself.  But it would reject the call with 486
Busy and the call would never get to voicemail.

Of course, this is a pretty marginal example, but I suspect that there
might be more reasonable cases that would demonstrate problems as well.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 9 Nov 2005 22:42:23 +0100

Dale,

see inline

----- Original Message ----- 
From: "Dale R. Worley" <[email-masked]>
To: "Sipping" <[email-masked]>
Sent: Wednesday, November 09, 2005 9:11 PM
Subject: Re: [Sipping] Telling a proxy which service to execute

> is one of its own names.

Couldn't it have a local policy to accept all incoming calls regardless? 
(while checking that it was the intended destination, i.e. validating the 
Route)

> For an ordinary desk telephone, this doesn't

The phone would be able to detect that the Contact header in the INVITE 
points to itself. IMO dialing 123 should still create a call towards the 
proxy (since you never know what it's mapped to, there are valid cases like 
e.g. proxy-based call forwarding), but instead of 486 it could answer 603 
Decline (or some other 6xx code like Busy Everywhere), and stop the proxy 
from attempting other contacts.