Subject: Re: [Sip] UA Loose Routing

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 23:11:35 -0400

Christer,

My concern with P-Called-Party-ID is similar to my concern on 
History-Info. On History-Info, the draft states:

    Firstly, it would cause the Request-URI to be relegated to nothing
    more than an indicator of the next hop for the request, identical
    exactly to the purpose of the Route header field.  This results in
    two things in the SIP specification which do exactly the same thing.
    Worse still, this is not just for some small feature of SIP (where
    such duplication might not be a big deal), but rather, it would be a
    duplication of SIP's primary function - routing of a call towards a
    target.

This concern applies exactly to P-Called-Party-ID. Indeed, its even 
worse, since now we would have, in a request:

Request-URI
To
P-Called-Party-ID
History-Info
Route

and I challenge you to explain to implementors what the differences are. 
What would happen when they are inconsistent?

My objective was to reduce this count. Indeed I was hopeful that 
UA-loose-route would allow us to deprecate P-Called-Party-ID, not the 
other way around. WIth UA-loose-route, we end up with:

Request-URI: identifies the target
Route: tells you how to get to the target
To: tells you the original target
History info: sequence of identities of targets

which is much cleaner.

So, functionally, P-Called-Party-ID could work. Any number of things 
*can* work.

-Jonathan R.

Christer Holmberg (JO/LMF) wrote:
> Hi,
> 
>> It is entirely appropriate at this stage to put forward 
>> alternatives. It is even more appropriate to do it now rather than
>> in 6 months time.
>> 
>> However please do not expect the editor to elaborate them. If the
>> WG has ideas, send text, either by individual author drafts, or by
>> the mailing list.
> 
> Regarding the P-Called-Party header, there already IS an RFC
> describing the header, and what it is used for. So, IF it already
> solves the problem (RFC3455 does say that the header is used to
> convey the AOR to the UAS), why would we need a separate draft? The
> only additional information that a draft could contain are the
> use-cases where receiving the AOR is important - but those use-cases
> are solution independent and already described in Jonathan's draft.
> 
> Of course, if we want to define a NEW header, or a NEW URI parameter,
> that may be done in a separate draft.
> 
> But, no matter how we do it, I think the author should at least
> indicate whether he has already thought about the alternatives that
> have been presented, and why he thinks that they don't work.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>>> -----Original Message----- From: Christer Holmberg (JO/LMF) 
>>> [mailto:[email-masked]] Sent: Thursday, June 14,
>>> 2007 10:51 AM To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF
>>> SIP List Subject: RE: [Sip] UA Loose Routing
>>> 
>>> 
>>> Hi Keith,
>>> 
>>> The text you sent says:
>>> 
>>> "Consensus noted that we do need some sort of solution for
>> the general
>>> problem of delivery of URI parameters across contact-routing 
>>> operations."
>>> 
>>> I have no problems with that.
>>> 
>>> I also have no problem with using Jonathan's draft as base line,
>>>  because the draft discusses the problem in a good way.
>>> 
>>> But, still: as the text says, the agreement was to come up
>> with SOME
>>> SORT OF SOLUTION, which to me does not mean that we have agreed
>>> to adopt the specific solution in Jonathan's draft. We should
>>> also be "allowed" to discuss alternative solutions, whether they
>>> 
>> are based on
>>> P-Called-Party, some other header, some URI parameter, or
>> whatever...
>>> Maybe those alternative solutions do not work, and then we should
>>>  describe that (as Jonathan has done for the To header- and
>>> History header alternatives).
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> 
>>> 
>>>> -----Original Message----- From: DRAGE, Keith (Keith)
>>>> [mailto:[email-masked]] Sent: 14. kesäkuuta 2007
>>>> 12:40 To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF
>>>> SIP List Subject: RE: [Sip] UA Loose Routing
>>>> 
>>>> You appear to be questioning whether the solution was
>> adopted. The
>>>> minutes state:
>>>> 
>>>> 
>> -------------------------------------------------------------------
>> 
>>>> Topic: GRUU and Supporting Drafts Led by Jonathan Rosenberg 
>>>> Slides included in proceedings Read:
>>>> draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00
>>>> 
>>>> Change since last version reviewed.
>>>> 
>>>> Issue: GRUU subtype names. The room demonstrated a slight
>>> preference
>>>> for the names used in -11 over known alternatives, but
>> nobody seems
>>>> particularly enamored with these names and the floor
>>> remains open to
>>>> suggestions.
>>>> 
>>>> Discussion on ua-loose-route draft deferred to next session.
>>>> 
>>>> 
>>>> Session 2: Friday 0900-1130 Grand Ballroom C
>>>> 
>>>> 
>>>> Topic: UA-loose-route, continued from previous session.
>>>> 
>>>> Consensus noted that we do need some sort of solution for
>>> the general
>>>> problem of delivery of URI parameters across contact-routing 
>>>> operations.
>>>> 
>>>> Issue: Concerns raised about backward compatibility. Noted that
>>>>  compliant P-CSCF should be OK.  Suggested that we have a
>>> design team
>>>> revisit call-flows and analyze for backward compatibility
>>>> issues.
>>>> 
>>>> Issue: Does GRUU normatively depend on this work? Resolved: 
>>>> GRUU does not reference this document. However, some
>>> participants feel
>>>> it should, as the benefit of GRUU cannot be fully
>> recognized in the
>>>> absence of this specification.  The chairs asked for a
>> hum, and the
>>>> consensus of the room is that GRUU and ua-loose-route can
>>>> proceed independently.
>>>> 
>>>> Question: Adopt this draft as baseline text for a WG
>> effort, should
>>>> the ADs approve the milestone? Consensus to adopt noted by
>>>> chairs. To-do: Chairs to work with AD to set new milestone.
>>>> 
>> ----------------------------------------------------------------------
>> 
>>>> The minutes quite clearly say "Adopt this draft as baseline
>>> text for a
>>>> WG effort" and given that the charter item now exists, then
>>> I believe
>>>> that we are entitled to call for the editor (Jonathan) to
>>> submit the
>>>> current text as draft-ietf-sip-ua-loose-route.
>>>> 
>>>> I agree the file name says loose-route, but I don'y think
>> we should
>>>> change that. After all, we lose that filename when it gets
>>> published
>>>> as an RFC anyway.
>>>> 
>>>> The charter item states
>>>> 
>>>> Dec 2007    Delivering request-URI and parameters to UAS via 
>>>> proxy to WGLC Feb 2008    Delivering request-URI and parameters
>>>> to UAS via proxy to IESG (PS)
>>>> 
>>>> I assume that you are OK with this.
>>>> 
>>>> What I would suggest is that you address specific comments to
>>>> the title of the deliverable:
>>>> 
>>>> Applying Loose Routing to Session Initiation Protocol (SIP)
>>>> User Agents (UA)
>>>> 
>>>> And to the abstract:
>>>> 
>>>> Abstract
>>>> 
>>>> A key part of the behavior of the Session Initiation
>>> Protocol (SIP)
>>>> is that SIP proxies rewrite the Request-URI as a request moves 
>>>> throughout the network.  Over the years, experience has
>>> shown this
>>>> to be problematic.  It makes it difficult to use Request URI
>>>> for service invocation, complicates emergency services, makes
>>>> it
>>> more complex
>>>> to support aliases, and so on.  Architecturally, it confounds
>>>> the concepts of address and route.  This document proposes
>> to change
>>>> this through a new mechanism called UA loose routing.
>>>> 
>>>> As you think appropriate to your concerns.
>>>> 
>>>> Alternatively, if you (or indeed any other SIP WG member)
>> do have a
>>>> completely different solution, then there is still time
>> to post an
>>>> individual draft or post a skeleton of a mechanism to the list.
>>>> 
>>>> 
>>>> Regards
>>>> 
>>>> Keith
>>>> 
>>>>> -----Original Message----- From: Christer Holmberg (JO/LMF) 
>>>>> [mailto:[email-masked]] Sent: Wednesday, June
>>>>> 13, 2007 8:52 PM To: DRAGE, Keith (Keith); Jonathan
>>>>> Rosenberg; IETF SIP List Subject: RE: [Sip] UA Loose Routing
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> We can call it loose route if we want, but I think the
>>>> initial focus
>>>>> should be the problem we are going to solve (I don't think
>>>> we agreed
>>>>> on a specific solution at #67), and we should look into
>>> alternative
>>>>> solutions (the draft does that in some extent, but
>> other possible
>>>>> alternatives have also been mentioned).
>>>>> 
>>>>> Or, do you prefer to have separate drafts describing
>> alternative
>>>>> solutions for the problem?
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Christer
>>>>> 
>>>>> 
>>>>> 
>>>>>> -----Original Message----- From: DRAGE, Keith (Keith)
>>>>>> [mailto:[email-masked]] Sent: 13. kesäkuuta 2007
>>>>>> 22:25 To: Jonathan Rosenberg; IETF SIP List Subject: RE:
>>>>>> [Sip] UA Loose Routing
>>>>>> 
>>>>>> (As WG chair)
>>>>>> 
>>>>>> As well as agreeing to charter the item, we actually agreed
>>>>>> 
>>>>> at IETF#67
>>>>>> that this draft was a suitable candidate to fulfil that
>>>>> charter item.
>>>>>> Therefore unless issues are raised with this, I would
>>> request the
>>>>>> editor (as Jonathan is editor) to submit the next
>>> version of this
>>>>>> document as draft-ietf-sip-ua-loose-route-00.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Keith
>>>>>> 
>>>>>>> -----Original Message----- From: Jonathan Rosenberg
>>>>>>> [mailto:[email-masked]] Sent: Wednesday, June 13, 2007
>>>>>>> 4:02 AM 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-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
>>>>>> 
>>>>>> _______________________________________________ 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
> 

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 23:14:42 -0400

Sorry, the draft is not clear on this. It also works in cases where the 
proxies translation logic is NOT based on registrations.

The basic idea is to apply the ;lr param in this case. So if the proxy 
looks up the request URI and find that the result is a SIP URI with the 
;lr param, it pushes that into the route set rather than rewriting the 
R-URI. Without the ;lr param, it rewrites the R-URI as it does today.
This is merely applying the exactly same logic we have for mid-dialog 
signaling, but for the initial dialog-forming request. I think there is 
some elegance in that.

So, if we consider this MGC case, the routing logic in the proxy that 
points to these old MGC would have entries which omit the ;lr parameter, 
and those pointing to ua-loose-route compliant ones would include it.

-Jonathan R.

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-masked]] 
>> 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:
>> 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. 
>> 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.
>>
>> 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.
>> -- 
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] for questions on current sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 23:21:35 -0400

inline.

Salvatore Loreto wrote:
> Hi Jonathan,
> 
> about the third redirection meaning:
> 
>    3.  The server is asking the client to route through an additional
>        proxy prior to visiting it, so that the recursed request
>        generated by the client pushes an additional Route onto the Route
>        set.
> 
> I was wondering if it should be possible insert more than only one contact 
> into the existing route set.

No.

> I'd like to know your opinion, because in my understanding it should not possible 
> due to the "alternative" meaning of different locations into the the Contact 
> header field; in fact the RFC3261 states:
> 
>    "When a redirect server returns a 3xx response to a request, it
>    populates the list of (one or more) alternative locations into the
>    Contact header field.  An "expires" parameter to the Contact header
>    field values may also be supplied to indicate the lifetime of the
>    Contact data."
> 
> 
> About the persistence of the redirection for a mid-dialog request,
> I am not sure it should persist just for the duration of the transaction, 
> instead the persistence should be managed by the "expires" parameter.

The problem is - under what conditions would the proxy utilize this? For 
all requests whose destination would otherwise be the redirecting UA? 
Only ones whose R-URI also matches?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 23:23:35 -0400

[email-masked] wrote:
>    From: Jonathan Rosenberg <[email-masked]>
> 
>    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.
> 
> Unfortunately, I have to say that I dislike this mechanism intensely,
> as it changes the whole philosophy of how SIP messages are routed.

Well, right now, it happens two ways. So I view it as trying to make it 
consistent.

> 
> On a more practical level, it only deals with one level of address
> mapping, and it's not usable by a UA that doesn't implement the change
> -- whereas I would expect that the optimal mechanism is one that
> tweaks the behavior of the proxy doing the mapping, and requires no
> change from any other system.

If the purpose of this is to communicate the targeted URI from the 
terminating proxy to the UA, I don't see how any mechanism can work 
unless it is supported by that proxy and that UA. Any of the mechanisms 
mentioned or discussed (P-Called-Party-ID, To, History-Info) have this 
property.

-Jonathan R.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 5 Jul 2007 22:59:31 +0200

Hi, 

> This concern applies exactly to P-Called-Party-ID. Indeed, 
> its even worse, since now we would have, in a request:
> 
> Request-URI
> To
> P-Called-Party-ID
> History-Info
> Route
> 
>My objective was to reduce this count. Indeed I was hopeful 
>that UA-loose-route would allow us to deprecate 
>P-Called-Party-ID, not the other way around. WIth 
>UA-loose-route, we end up with:
> 

If people can't explain to their implementors the meaning of different SIP headers maybe THAT is something we should concentrate on, and if needed write a draft about.

>which is much cleaner.

If we would re-do SIP I am sure lots of things could be done cleaner.

P-Called-Party-ID does not change the current routing mechanism, and it does not have the potential issue with proxies (and possible also SBCs) that you have mentioned. And the proxy re-writing the R-URI can use the mechanism no matter if the UA supports it or not. 

(And, naturally the mechanism would of course be backward compatible with entities and networks that already support P-Called-Party-ID.)

>So, functionally, P-Called-Party-ID could work. Any number of things *can* work.

Yes, but P-Called-Party-ID is a standardized mechanism, made for this purpose, which most likely does work.

Regards,

Christer

> alternatives. 
> >> It is even more appropriate to do it now rather than in 6 months 
> >> time.
> >> 
> >> However please do not expect the editor to elaborate them. 
> If the WG 
> >> has ideas, send text, either by individual author drafts, 
> or by the 
> >> mailing list.
> > 
> > solves the problem (RFC3455 does say that the header is 
> used to convey 
> > the AOR to the UAS), why would we need a separate draft? The only 
> > additional information that a draft could contain are the use-cases 
> > where receiving the AOR is important - but those use-cases are 
> > solution independent and already described in Jonathan's draft.
> > 
> >>> 2007 10:51 AM To: DRAGE, Keith (Keith); Jonathan 
> Rosenberg; IETF SIP 
> >>> SORT OF SOLUTION, which to me does not mean that we have 
> agreed to 
> >>> adopt the specific solution in Jonathan's draft. We 
> should also be 
> >>> "allowed" to discuss alternative solutions, whether they
> >>> 
> >> are based on
> >>> describe that (as Jonathan has done for the To header- 
> and History 
> >>> header alternatives).
> >>> 
> >>> Regards,
> >>> 
> >>> Christer
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> [mailto:[email-masked]] Sent: 14. kesäkuuta 2007 12:40 
> >>>> To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF 
> SIP List 
> >>>> Topic: GRUU and Supporting Drafts Led by Jonathan 
> Rosenberg Slides 
> >>>> included in proceedings Read:
> >>>> revisit call-flows and analyze for backward compatibility issues.
> >>>> 
> >>>> consensus of the room is that GRUU and ua-loose-route 
> can proceed 
> >>>> independently.
> >>>> 
> >>>> the ADs approve the milestone? Consensus to adopt noted 
> by chairs. 
> >>>> To-do: Chairs to work with AD to set new milestone.
> >>>> 
> >> 
> >>>> What I would suggest is that you address specific 
> comments to the 
> >>>> title of the deliverable:
> >>>> 
> >>>> Applying Loose Routing to Session Initiation Protocol (SIP) User 
> >>>> Agents (UA)
> >>>> 
> >>>> And to the abstract:
> >>>> 
> >>>> Abstract
> >>>> 
> >>>> to be problematic.  It makes it difficult to use Request URI for 
> >>>> service invocation, complicates emergency services, makes it
> >>> more complex
> >>>> to support aliases, and so on.  Architecturally, it 
> confounds the 
> >>>> concepts of address and route.  This document proposes
> >> to change
> >>>>> [mailto:[email-masked]] Sent: 
> Wednesday, June 13, 
> >>>>> 2007 8:52 PM To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF 
> >>>>>>> 4:02 AM To: IETF SIP List Subject: [Sip] UA Loose 
> Routing Issue 
> >>>>>>> #1: Backwards
> >>>> compatibility
> >>>>>>> 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,
> >>>>>>> between a UA and registrar easily. Now, the problem is with 
> >>>>>>> intermediate proxies. If there is an edge proxy between the
> >>>>>> UA and its
> >>>>>>> a Route header beyond itself, even though it thinks its the
> >>>>>> edge proxy
> mailing list  
> >>>>>>> https://www1.ietf.org/mailman/listinfo/sip
> mailing list  
> >>>>>> https://www1.ietf.org/mailman/listinfo/sip This list 
> is for NEW

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 18:08:53 -0400

inline.

Christer Holmberg (JO/LMF) wrote:
>> two things in the SIP specification which do exactly the same
>> thing. Worse still, this is not just for some small feature of SIP
>> (where such duplication might not be a big deal), but rather, it
>> would be a duplication of SIP's primary function - routing of a
>> call towards a target.
>> 
>> Request-URI To P-Called-Party-ID History-Info Route
>> 
>> and I challenge you to explain to implementors what the differences
>> are. What would happen when they are inconsistent?
>> 
>> UA-loose-route would allow us to deprecate P-Called-Party-ID, not
>> the other way around. WIth UA-loose-route, we end up with:
>> 
>> Request-URI: identifies the target Route: tells you how to get to
>> the target To: tells you the original target History info: sequence
>> of identities of targets
> 
> If people can't explain to their implementors the meaning of
> different SIP headers maybe THAT is something we should concentrate
> on, and if needed write a draft about.

Its not a question of documentation. Its that we would in fact have 
multiple headers which mean the same thing.

> P-Called-Party-ID does not change the current routing mechanism, and
> it does not have the potential issue with proxies (and possible also
> SBCs) that you have mentioned. And the proxy re-writing the R-URI can
> use the mechanism no matter if the UA supports it or not.

Sure, but its useless unless the UA supports it. So my point is, in all 
cases, we are talking about changes to UA and to proxy to do something 
useful here. The UA-loose-route mechanism doesn't require any changes 
beyond those two.

I do agree, that UA-loose-route requires a discovery mechanism, so the 
proxy knows whether to do this or not. But that is not difficult.

> 
> (And, naturally the mechanism would of course be backward compatible
> with entities and networks that already support P-Called-Party-ID.)
> 

We have lots of P-headers that already exist. That doesn't mean we 
shouldn't bother to provide an architecturally better solution.

-Jonathan R.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 10:25:53 +0200

Hi, 

>>>Request-URI: identifies the target Route: tells you how to get to the

>>>target To: tells you the original target History info: sequence of 
>>>identities of targets
>> 
>>If people can't explain to their implementors the meaning of different

>>SIP headers maybe THAT is something we should concentrate on, and if 
>>needed write a draft about.
> 
>Its not a question of documentation. Its that we would in 
>fact have multiple headers which mean the same thing.

So, for my clarification, which headers would mean the same thing using
P-Called-Party-ID?

>Sure, but its useless unless the UA supports it. So my point 
>is, in all cases, we are talking about changes to UA and to 
>proxy to do something useful here. The UA-loose-route 
>mechanism doesn't require any changes beyond those two.

The P-Called-Party-ID solution doesn't require any changes to proxies at
all.

And, even if a proxy wouldn't have a problem with the loose routing
solution as such, in some environments the proxies processes the
P-Called-Party-ID header. So, you would still need to update those
proxies, if you want to replace the P- header mechanism with something
else.
 
*can* work.
>We have lots of P-headers that already exist. That doesn't mean we
shouldn't bother to provide an architecturally better 
>solution.

I don't think a solution based on a P- header automatically is a "bad"
solution. In this case the main purpose is to provide a URI, and a
header (whether it's a P- header or not is not relevant) is perfectly ok
for that I think.

And, in general I think we give the market the wrong picture if we make
changes that may affect existing deployments and systems (the
P-Called-Party header has been part of IMS for a realtively long time) -
especailly when nothing is broken with the current systems.

Yes, maybe there are things we think could have been done cleaner, but
in some cases we just have to accept the fact that things have been
defined in a specific way.

Regards,

Christer