Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2007 23:01:58 -0400

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-loose-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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 10:58:29 +0200

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jun 2007 08:03:55 -0400

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.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 13 Jun 2007 15:11:58 +0300

Jonathan Rosenberg writes:

 > be great.

jonathan,

[open]ser proxies have a large number of functions to examine and
manipulate request uri.  it would mean lots of coding work to make all
same functions apply to an uri in the route header.  so i don't like
this change at all.

why can't you say that when proxies rewrite request uri, they need to
leave parameters (or at least some parameters) alone?

or, why can't you say that if a proxy rewrites request uri, it needs to
push the original request uri into some new header unless this new
header already exists?

-- juha

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 14:10:11 +0200

Hi, 

>If so, it can avoid this problem by not using the new option 
>when registering. This is *optional* behavior.

Correct. My misstake.

Regards,

Christer

> > 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
> > 
> > 
> > 
> >  
> > 
> >> I've recently revised my draft on UA loose routing. You 
> can pick it 
> >> up here:
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> 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.
> >> -- 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >>
> > 
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 14:45:12 +0200

Hi,

Another thing to keep in mind is that when the Path header is used, the generated Route (used from the home proxy towards the UE) will not be identical to the Path.

Route = Path + pushed Route

Now, I don't know whether RFC3327 says that the Route MUST be identical to the Path it's based on, or whether it's allowed to add Route(s) in addition to those based on the Path, but there could be intermediates that do some kind of checking.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 14:48:06 +0200

Hi, 

>>concerns they have, that would  > be great.
> 
>jonathan,
> 
>[open]ser proxies have a large number of functions to examine 
>and manipulate request uri.  it would mean lots of coding 
>work to make all same functions apply to an uri in the route 
>header.  so i don't like this change at all.
> 
>why can't you say that when proxies rewrite request uri, they 
>need to leave parameters (or at least some parameters) alone?
> 
>or, why can't you say that if a proxy rewrites request uri, 
>it needs to push the original request uri into some new 
>header unless this new header already exists?

Something like P-Called-Party.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 14:53:18 +0200

Hi,

This is not very relevant to the loose route solution as such, but just
a small comment on the emergency service use-case.

I am not sure whether the emergency service centers will always
register, and if they don't loose route of course does not solve the
problem.

Regards,

Christer

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 13 Jun 2007 21:24:50 +0200

(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

> Sent: Wednesday, June 13, 2007 4:02 AM
> To: IETF SIP List

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 21:52:02 +0200

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

> 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
> 
> > I've recently revised my draft on UA loose routing. You can 
> pick it up 
> > here:
> > 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.
> > 
> > includes an option tag in the REGISTER, and the registrar indicates 
> > 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.
> >

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Jun 2007 12:57:26 -0700

>register, and if they don't loose route of course does not solve the

Hi Christer,
	Can you expand on the issue here?  I'm afraid I didn't understand
it from this message.
			thanks,
				Ted

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 22:02:50 +0200

Hi, 

>Can you expand on the issue here?  I'm afraid I didn't understand it
from this message.

As said in the draft, the loose route mechanism can only be used if the
UA has registered and indicated support of the loose route mechanism.

So, entities that do not register will not be able to use the mechanism.
And, to my understanding the ESCs will not always register, which mean
it's not possible to use the loose route mechanism to forward the
initial request to them.

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 14 Jun 2007 10:54:11 +0300

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

regards
Sal

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 14 Jun 2007 11:39:44 +0200

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

> 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
> 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).
> 
> at IETF#67 
> > 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
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 11:51:08 +0200

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

> Sent: 14. kesäkuuta 2007 12:40
> To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF SIP List
> 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.
> 
> 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
> 
> 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
> 
> 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).
> > 
> architecturally, 
> requests.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 14 Jun 2007 11:55:44 +0200

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. 

Regards

Keith

> Sent: Thursday, June 14, 2007 10:51 AM
> "Consensus noted that we do need some sort of solution for 
> the general problem of delivery of URI parameters across 
> contact-routing operations."
> 
> 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
> 
> 
>  
> 
> preference 
> participants feel 
> > it should, as the benefit of GRUU cannot be fully recognized in the 
> > the ADs approve the milestone? Consensus to adopt noted by chairs. 
> > To-do: Chairs to work with AD to set new milestone.
> > 
> 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
> > 
> >    throughout the network.  Over the years, experience has 
> shown this 
> > to
> >    invocation, complicates emergency services, makes it 
> more complex 
> > to
> > 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
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 13:02:36 +0200

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

> the general 
> > operations."
> > I also have no problem with using Jonathan's draft as base line, 
> > because the draft discusses the problem in a good way.
> > 
> 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
> > 
> > 
> >  
> > 
> > > You appear to be questioning whether the solution was 
> adopted. The 
> > > minutes state:
> > > 
> > > 
> > >    concepts of address and route.  This document proposes 
> to change 
> > > this
> > > > Or, do you prefer to have separate drafts describing 
> alternative 
> > > > solutions for the problem?
> > > > 
> > > > Regards,
> > > > 
> > > > Christer
> > > > 
> > > >  
> > > > 
> > > > > > Cisco Fellow                                   
> Parsippany, NJ 
> > > > > > 07054-2711

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jun 2007 13:48:40 +0100

Christer,

For clarification, does the P-Called-party header field URI get overwritten when retargeting (as opposed to routing) occurs? If not, I fear it suffers from the same problem as the To header field URI, as described in Jonathan's draft.

John 

> Sent: 14 June 2007 12:03
> 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
> 
> 
> 
> 
> > > > Read: 
> draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00
> > > > 
> > > > What I would suggest is that you address specific 
> comments to the 
> > > > title of the deliverable:
> > > > 
> > > >    be problematic.  It makes it difficult to use 
> Request URI for 
> > > > service
> > > > > > > because it was recognized that the problem was 
> more general
> > > > > > than GRUU,
> > > > > > > Sip mailing list  
> https://www1.ietf.org/mailman/listinfo/sip

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 14:59:36 +0200

Hi John, 

>For clarification, does the P-Called-party header field URI 
>get overwritten when retargeting (as opposed to routing) 
>occurs? If not, I fear it suffers from the same problem as 
>the To header field URI, as described in Jonathan's draft.

I believe it does work with retargeting.

In fact, chapter 4.2 of RFC3455 pretty much describes the same retargeting problem when using the To header as Jonathan does in his draft.

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.
> > 
> > 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.
> > 
> > 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
> > 
> > 
> > 
> > 
> > > > > > > > Feb 2008	  	Delivering request-URI 
> and parameters 
> > > > > > > > to UAS via proxy to
> > > > > > > > IESG (PS)
> > > > > > > > 
> > > > > > > > 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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 16:57:25 -0400

Why would you think Emergency communications systems would not register?

I think we have cross domain issues, but a UA in an ECS registers with a
registrar in that ECS domain.  The caller registers with a registrar in its
domain.

I don't see a problem with the proposed solution.  I think it will work.

Brian

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Wednesday, June 13, 2007 4:03 PM
> To: Ted Hardie; Jonathan Rosenberg; IETF SIP List
> Subject: RE: [Sip] UA Loose Routing: Emergency example
> 
> 
> Hi,
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 09:18:43 +0200

Hi, 

>Why would you think Emergency communications systems would not
register?

My understanding is that in many countries they are connected more like
network equipment than user equipment, so in those cases they may not
always register.

(And, of course, if the ECS is in the PSTN it won't register, since the
MGC does not register.)

But, I am not an expert on this, so maybe I'm wrong. But, it's not
really relevant for the problem we are trying to solve, so we don't need
to discuss it futher within that context.

Regards,

Christer

> 
> I think we have cross domain issues, but a UA in an ECS 
> registers with a registrar in that ECS domain.  The caller 
> registers with a registrar in its domain.
> 
> > As said in the draft, the loose route mechanism can only be used if 
> > the UA has registered and indicated support of the loose 
> route mechanism.
> >

---

From: [email-masked]
Date: Sun, 17 Jun 2007 22:29:52 -0400

From: Jonathan Rosenberg <[email-masked]>

Unfortunately, I have to say that I dislike this mechanism intensely,
as it changes the whole philosophy of how SIP messages are routed.

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.

Dale