Subject: [Sip] New I-D on UA loose routing

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Oct 2006 12:37:11 -0400

I've submitted a new I-D which describes this concept of UA loose 
routing that we've been discussing on the list. This fell out of the 
GRUU discussions as an alternative solution for grid. As the draft 
explains, the mechanism also solves many other problems, like 
sub-addressing, limited use adresses, 8xx number usage, and is even 
required for proper 911/emergency services operation with ecrit.

Until the draft appears in the archives, you can pick it up at:
http://www.jdrosen.net/papers/draft-rosenberg-sip-ua-loose-route-00.txt

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 24 Oct 2006 15:26:49 -0700

Hi,

I have read this draft and I think it is a terrible idea in SIP/2.0 to
send a UA an incoming request with a Route header.  If we were working
on SIP/2.1 or SIP/3.0, I think this approach would be a fruitful idea
to consider as baseline behavior, but I think this is too major of a
change from the current spec and state of implementation.

Lets analyze the requirements described in the document.  The unkown
gruu, limited-use gruu, subaddressing, and service invocation
requirements can all be met just by restoring the grid parameter to
its rightful place in GRUU. The emergency services requirement is a
tautology; if a proxy wants to rewrite the Request-URI from an SOS
URN, don't do that, insert a loose-route instead; no additional
mechanism or specification is necessary. The freephone requirement
deals with mixed SIP and PSTN networks, where the existing
History-Info (or dare I say Diversion) mechanism is perfectly adequate
and more likely to be implemented in this environment. The alias
requirement can be addresses in a variety of ways including
configuration, or simply restoring the To header to usefulness.  My
conclusion is that this mechanism does not solve any requirements we
are not already addressing.  (If we were starting from scratch, we
might do things differently).

As for the implications of handling loose-routing on the UA, I do not
believe the expected behavior is easily containable. The only entities
that should receive requests with additional Route headers are proxy
servers.  Embedding a proxy server in/on a UA then requires the UA to
implement TLS, strict route fix ups, loop detection, and a host of
other things. I don't think we want to go there. The alternative is
for us to break the rules and define a "sort of a proxy" role.  I
expect picking apart what parts of RFC3261 need to be implemented as a
proxy would be a nightmare.  I can also imagine the impact on the
outbound draft if each outbound UA needs to route through an embeded
edge proxy.  How will the first "real" edge proxy decide if outbound
processing has been done correctly?

The concept of logical roles such as proxy, registrar, identity
server, etc. is already confusing to many implementors. If we start
redefining or breaking the rules which describe existing roles, I
believe we are going to have a real mess on our hands.

thanks,
-rohan

---

From: EKR <[email-masked]>
Date: Tue, 24 Oct 2006 17:24:53 -0700

Rohan Mahy <[email-masked]> wrote:
> its rightful place in GRUU. 

Not really, no. You'd like to be able to generate limited-use addresses
that point to the AOR, not the GRUU. This is reflective of the basic
problem: attaching disambiguators to a SIP URI is something that
should be done generically, not confined to GRUU.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Oct 2006 14:01:14 -0700

"Rohan Mahy" <[email-masked]> writes:

> On 10/24/06, EKR <[email-masked]> wrote:
> If you are proposing a new parameter that proxies should copy through
> to a user agent, that would be fine with me, but doing that would be a
> new extension and would require proxies to implement it.  You could
> call it grid or you could call it something else.  The general
> property you describe however would not require UAs to handle incoming
> requests with Route headers.

Right, that's just one way of implementing. My point in responding to your
message was that a parameter that is GRUU-only to do a task that is
applicable outside of GRUU is a Bad Thing.

-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 25 Oct 2006 17:07:20 -0700

> applicable outside of GRUU is a Bad Thing.

Postponing this *agreed-upon* functionality for GRUU to depend on a
brand-new untested mechanism is a MUCH WORSE Thing.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 25 Oct 2006 12:57:37 -0700

thanks,
-rohan

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Oct 2006 18:01:24 -0700

> brand-new untested mechanism is a MUCH WORSE Thing.

I don't agree, but I think we're talking past each other here.

Prior to this change GRUU defined a mechanism whereby the UAC could
add a disambiguator to a GRUU. My point is that whatever mechanism
we choose should have applicability outside of GRUU. 
Are you objecting to this? If so, why?

I appreciate that you think the particular proposed mechanism to attack
this problem is bad, but that's not what I'm arguing for here...

-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Oct 2006 11:37:17 -0700

Ekr,

As I said in an earlier mail (perhaps not as clearly as necessary), if
you want to propose a general grid-like mechanism that satisfies the
requirements of grid and also extends this "pass-along" property of a
parameter to AORs *without resorting to UAs handling Route headers*, I
am generally supportive. I would want to include this mechanism either
in the GRUU draft itself or in a small document that GRUU normatively
references and that any GRUU-supporting device MUST implement.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 18:18:37 -0400

You are equating processing a Route header, with being a proxy. Nothing 
in RFC 3261 says that if you process a Route header, you are a proxy. 
Indeed, RFC 3261 is silent on the applicability of Route headers to UA. 
Certainly I agree we don't want to require a UA to do thigns like mutual 
TLS.

Indeed, I would like to understand what concrete problems you see. Your 
note points out that there could be other solutions, and then complains 
that this is making things confusing. Yes, there could be other 
solutions - I look forward to your draft. I don't think it makes things 
more confusing.

I think this mechanism is quite elegant in that extends the idea of 
loose routing to UA, and is arguably what we should have done in SIP in 
the first place.

-Jonathan R.

---

From: Shida Schubert <[email-masked]>
Date: Thu, 26 Oct 2006 21:07:03 -0700

Interesting draft...

I generally like the idea although having a spec such as
p-called-party-id already
may raise an argument about some of the motives behind this draft(Yes I
know,
p-header is for restricted environment and I know we don't want to
define too
many vehicles to carry an identities...).

Anyhow, I don't know how well this is going to work for Service
URN(911/emergency).

AFAIK idea behind putting the service URN in either To or R-URI is not
to address a
specific AoR or name but it is to mark a call so intermediaries can
prioritize the call
and treat it as an emergency call.

And because it does not address a target, call may be retargeted before
it gets to
any ESC and may lose the marker(Service URN). I guess we can probably write
something in phonebcp to prevent this but it is something to keep in mind.

Regards
Shida

---

From: "Rohan Mahy" <[email-masked]>
Date: Sun, 29 Oct 2006 08:00:21 -0800

Jonathan,

I don't understand what you mean by "much later".  The grid parameter
appears in draft-ietf-sip-gruu-00, dated January 2004.  I do not
consider it a "nice-to-have".  I think it is essential to make several
features work, including local conferencing. It merely restores the
ability of the UA to manufacture a large number of distinct Contact
URIs.

I am somewhat mystified that the very old problem of passing
qualifiers through from an AOR to a UA has suddenly come to such
prominence that it was able to disrupt stable working functionality in
a high-priority WG draft. What suddenly changed in the priorities
of... oh, look a shiny penny!

thanks,
-rohan

On 10/26/06, Jonathan Rosenberg <[email-masked]> wrote:
> To summarize, I think you are saying:
>
> 1. I dont like the mechanism, and
> 2. whatever the mechanism is, has to be a normative ref from GRUU as
> MUST implement, or part of GRUU
>
> I responded to your concern (1) in another note.
>
> I'd like to understand your motivation on (2). The grid feature of GRUU
> was considered nice-to-have (it came only much later in the GRUU
> evolution), and all of the things people wanted to do with it are
> equally applicable to the AOR (as ekr pointed out), and so have very
> little to do with the problem GRUU was intending to solve - addressing a
> UA directly. Why do you see a solution for these two as being coupled?
>
> -Jonathan R.
>
> Rohan Mahy wrote:
>
> > Ekr,
> >

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 30 Oct 2006 08:13:27 -0600

Another idea to add to this topic...

Why not do something like this:

Contact: <sip:user@domain?Opaque-Params=blah>

...when handing out a URI, so that when someone creates an INVITE based
off of that contact they wind up generating:

INVITE sip:user@domain SIP/2.0
Opaque-Params: blah

Etc.

That should survive all the way to the other side.

Regards,
Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 11:37 AM
> To: IETF SIP List
> Subject: [Sip] New I-D on UA loose routing
> 
> I've submitted a new I-D which describes this concept of UA 
> loose routing that we've been discussing on the list. This 
> fell out of the GRUU discussions as an alternative solution 
> for grid. As the draft explains, the mechanism also solves 
> many other problems, like sub-addressing, limited use 
> adresses, 8xx number usage, and is even required for proper 
> 911/emergency services operation with ecrit.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 30 Oct 2006 07:21:58 -0800

Hi,

First I'd like to propose a concrete counter proposal.  Dean would
call this an additional "band-aid" but I feel like the patient has
painfully managed to recover pretty well from 2nd degree burns over
60% of the body and now just has a persistent paper cut.

We define a new URI parameter called 'ua-opaque'.  When an
authoritative proxy receives a request with this parameter in the
request URI (in an AOR or a GRUU), it copies the value of this
parameter into any URI it retargets to. This functionality is
mandatory for URIs which are GRUU.  This parameter effectively
replaces the 'grid' parameter by providing a simple superset of the
functionality.

I believe that this approach has significantly better backwards
compatility and maturity than the UA loose-route approach. Below I
will list the technical problems I see with the UA loose route
approach.

1) Outbound. the current outbound draft has language about what the
first edge proxy needs to do.  One of the ways to tell if the first
proxy did its job is to check the first element in the Path vector for
the 'ob' parameter.  I don't believe this would work anymore.  Maybe I
am not smart enough, but I can't think of a way to make detection that
outbound will work in a UA loose-route environment, short of a
first-hop Proxy-Require, which a number of folks where adamantly
against.

2) Forking / HERFP.  There are some UAs which reject requests to them
with Route headers left with a 400 and some with a 403.  To be safe, a
proxy will need to forward in the traditional manner to
non-loose-route UAs, or risk exacerbating HERFP. A proxy forking to
both UA loose-route and non-UA loose UAs therefore needs to keep track
of both and effectively run two separate code paths for different
branches for the same target set.

3) Marid-style assumptions.  Like the problem with outbound, a proxy
that wants to check that requests are either for its domain or from
its domain and that it is receiving requests for its domain directly
(not through an intervening proxy) may have a harder time figuring out
if it is the first proxy.

thanks,
-rohan

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 30 Oct 2006 11:16:07 -0600

Ok, so revising my earlier response, what about embedding a SIP header
called "UA-Opaque" in the URI so that we can (I think) continue to use
baseline UA behavior.

Regards,
Brian

> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 9:22 AM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] New I-D on UA loose routing
> 
> Hi,
> 
> First I'd like to propose a concrete counter proposal.  Dean 
> would call this an additional "band-aid" but I feel like the 
> patient has painfully managed to recover pretty well from 2nd 
> degree burns over 60% of the body and now just has a 
> persistent paper cut.
> 
> authoritative proxy receives a request with this parameter in 
> the request URI (in an AOR or a GRUU), it copies the value of 
> this parameter into any URI it retargets to. This 
> functionality is mandatory for URIs which are GRUU.  This 
> parameter effectively replaces the 'grid' parameter by 
> providing a simple superset of the functionality.
> 
> I believe that this approach has significantly better 
> backwards compatility and maturity than the UA loose-route 
> approach. Below I will list the technical problems I see with 
> the UA loose route approach.
> 
> 1) Outbound. the current outbound draft has language about 
> what the first edge proxy needs to do.  One of the ways to 
> tell if the first proxy did its job is to check the first 
> element in the Path vector for the 'ob' parameter.  I don't 
> believe this would work anymore.  Maybe I am not smart 
> enough, but I can't think of a way to make detection that 
> outbound will work in a UA loose-route environment, short of 
> a first-hop Proxy-Require, which a number of folks where 
> adamantly against.
> 
> 2) Forking / HERFP.  There are some UAs which reject requests 
> to them with Route headers left with a 400 and some with a 
> 403.  To be safe, a proxy will need to forward in the 
> traditional manner to non-loose-route UAs, or risk 
> exacerbating HERFP. A proxy forking to both UA loose-route 
> and non-UA loose UAs therefore needs to keep track of both 
> and effectively run two separate code paths for different 
> 3) Marid-style assumptions.  Like the problem with outbound, 
> a proxy that wants to check that requests are either for its 
> domain or from its domain and that it is receiving requests 
> for its domain directly (not through an intervening proxy) 
> may have a harder time figuring out if it is the first proxy.
> 
> thanks,
> -rohan
> 
> 
> > You are equating processing a Route header, with being a proxy. 
> > Nothing in RFC 3261 says that if you process a Route 
> header, you are a proxy.
> > Certainly I agree we don't want to require a UA to do thigns like 
> > mutual TLS.
> >
> > Indeed, I would like to understand what concrete problems you see. 
> > Your note points out that there could be other solutions, and then 
> > complains that this is making things confusing. Yes, there could be 
> > other solutions - I look forward to your draft. I don't 
> think it makes 
> > things more confusing.
> >
> > loose routing to UA, and is arguably what we should have 
> done in SIP 
> > in the first place.
> >
> > -Jonathan R.
> >
> >
> >
> >
> >
> > Rohan Mahy wrote:
> >
> > > Hi,
> > >
> > > I have read this draft and I think it is a terrible idea 
> in SIP/2.0 
> > > to send a UA an incoming request with a Route header.  If we were 
> > > working on SIP/2.1 or SIP/3.0, I think this approach would be a 
> > > fruitful idea to consider as baseline behavior, but I 
> think this is 
> > > too major of a change from the current spec and state of 
> implementation.
> > >
> > > History-Info (or dare I say Diversion) mechanism is perfectly 
> > > adequate and more likely to be implemented in this 
> environment. The 
> > > alias requirement can be addresses in a variety of ways including 
> > > As for the implications of handling loose-routing on the UA, I do 
> > > not believe the expected behavior is easily containable. The only 
> > > entities that should receive requests with additional 
> Route headers 
> > > are proxy servers.  Embedding a proxy server in/on a UA then 
> > > requires the UA to implement TLS, strict route fix ups, loop 
> > > detection, and a host of other things. I don't think we 
> want to go 
> > > there. The alternative is for us to break the rules and define a 
> > > "sort of a proxy" role.  I expect picking apart what parts of 
> > > RFC3261 need to be implemented as a proxy would be a 
> nightmare.  I 
> > > can also imagine the impact on the outbound draft if each 
> outbound 
> > > UA needs to route through an embeded edge proxy.  How 
> will the first 
> > > "real" edge proxy decide if outbound processing has been 
> done correctly?
> > >
> > >> routing that we've been discussing on the list. This fell out of 
> > >> the GRUU discussions as an alternative solution for grid. As the 
> > >> draft explains, the mechanism also solves many other 
> problems, like 
> > >> [email-masked] for questions on 
> current sip Use 
> > >> [email-masked] for new developments on the application of sip
> > >>
> > >
> >
> > --