Subject: [Ecrit] Request URI in Phone BCP

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 03 Sep 2007 21:58:26 +0200

There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is 
the text:

"
1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 
6.3). If the device cannot access a LoST server, the To: SHOULD be a 
service URN in the "sos" tree.
"

Instead of talking about the To in the second sentence it should say 
Request URI. Here is the changed text:

"
1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 
6.3). If the device cannot access a LoST server, the Request URI SHOULD 
be a service URN in the "sos" tree.
"

I believe that item (5) should be removed:

"
5. A Route header SHOULD be present with the service URN in the "sos" 
tree, and the loose route parameter.
"

The 3GPP IMS emergency service spec, TS  24.229, does not use it either.

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 3 Sep 2007 22:30:38 -0400

I don't think that is right, and I think the loose route draft is correct.
If you put the PSAP URI in the Request URI then you don't know it's an
emergency call, and you don't know what service was requested.  The service
URN is the marker that the call is an emergency call.

If you put the service URN in the Request URI, and the PSAP URI in a Route
header, then the call will be routed to the PSAP correctly, and the Request
URI will remain as the service URN.

You can't depend on To:, although if the UA recognizes the dial string, then
the To: would also have the service URN.  If it did not detect the
dialstring, the To: would have the dial string.

If the UA did not do the LoST dip, then there would not be a Route header.
This allows the first hop proxy to determine what it needs to do.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, September 03, 2007 3:58 PM
> To: ECRIT
> Subject: [Ecrit] Request URI in Phone BCP
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Sep 2007 22:52:01 -0500

Hannes

I agree with Brian.  We need to have an 'emergency' indication in all 
SIP requests.  Since the To cannot be relied upon not to have been 
changed along the way, the indication needs to be somewhere other 
than the To header.  The Route header is intended to be untouched by 
any entity until the request gets to the device at that (the Route 
header's) URI, so integrity is at least intended.  We can't even say 
this for the To header.

Leaving the R-URI as the service URN leaves the emergency indication 
in the request.

If the next destination hop is not in the R-URI position in the 
request, it needs to be in the Route header (with an "lr" (for 'loose 
route' URI parameter).

This accomplishes what we all want:
- the request to have a service indication (in the R-URI placement)
- the request to be routed at the PSAP URI (the URI in the Route 
header, with the lr parameter)
- no trust required from the To header (i.e., not extending the 
integrity of the To header, like the pains PAI did - which has 
limited applicability anywhere it's used)

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 08:39:38 +0200

Hi Brian,

> I don't think that is right, and I think the loose route draft is correct.
I my mail I mentioned 2 issues.

The loose route draft talks about the Request URI and in my opinion 
that's a good approach.
This would require a bugfix for the first sentence that talks about 
"To:" instead of "Request URI".

> emergency call, and you don't know what service was requested.
I fully agree with you.

>   The service
Correct.

> URI will remain as the service URN.
I agree that the service URN needs to be put into the Request URI. 
That's fine.
I am not sure why you need to put the PSAP URI into the Route header 
instead of putting it into the To header if you run LoST at the end host.

> the To: would also have the service URN.
Correct.
>   If it did not detect the
Correct.

> If the UA did not do the LoST dip, then there would not be a Route header.
Correct.

> This allows the first hop proxy to determine what it needs to do.
To be a bit more systematic, we have the following cases:

* UA does not recognize the emergency call.

To: would have the dial string.

* UA runs LoST and determines the PSAP URI:

Request URI: Service URN
My suggestion: To: would have the PSAP URI.

* UA does not run LoST but recognizes the emergency call.

Request URI: Service URN

To: Service URN

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 08:43:59 +0200

Hi James,

James M. Polk wrote:
> SIP requests.  
I agree.

> Since the To cannot be relied upon not to have been changed along the 
> way, the indication needs to be somewhere other than the To header.
I agree as well. This was the motivation for the "UA Loose Routing" draft.

>   The Route header is intended to be untouched by any entity until the 
> request gets to the device at that (the Route header's) URI, so 
> integrity is at least intended.

True. If I understood the Loose Routing draft correctly then this would 
be an alternative solution. Jonathan, however, proposed the usage of the 
Request URI instead of using the Route header.

>   We can't even say this for the To header.
I know. Retargeting would change it.

> Leaving the R-URI as the service URN leaves the emergency indication 
Correct. This was my assumption until I learned about the lack of 
excitement for the UA Loose Routing draft in the SIP WG.
Hence, I have asked them for clarification in my mail.

> request, it needs to be in the Route header (with an "lr" (for 'loose 
I don't understand that sentence.

Correct.
> header, with the lr parameter)
Why doesn't the PSAP URI belong into the To header?

> integrity of the To header, like the pains PAI did - which has limited 
> applicability anywhere it's used)
I don't understand that sentence

I am not sure this solution is inline with what the SIP guys are 
discussing.

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 4 Sep 2007 08:59:16 -0400

Hannes

The To: header is not used to route.  Request-URI and Route are used to
route.  How can we put the actual destination of the call in a To: field
alone and expect the call to be routed there?

Brian

> Sent: Tuesday, September 04, 2007 2:40 AM
> To: Brian Rosen
> Cc: 'ECRIT'
> Subject: Re: [Ecrit] Request URI in Phone BCP
> 
> Hi Brian,
> 
> Brian Rosen wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Sep 2007 10:23:08 -0500

Hannes

comments in-line

At 01:43 AM 9/4/2007, Hannes Tschofenig wrote:
>Hi James,
>
>James M. Polk wrote:
>>Hannes
>>
>>I agree with Brian.  We need to have an 'emergency' indication in 
>>all SIP requests.
>I agree.
>
>>Since the To cannot be relied upon not to have been changed along 
>>the way, the indication needs to be somewhere other than the To header.
>>   The Route header is intended to be untouched by any entity until 
>> the request gets to the device at that (the Route header's) URI, 
>> so integrity is at least intended.
>
>True. If I understood the Loose Routing draft correctly then this 
>would be an alternative solution. Jonathan, however, proposed the 
>usage of the Request URI instead of using the Route header.
>
>>Leaving the R-URI as the service URN leaves the emergency 
>>indication in the request.
>>request, it needs to be in the Route header (with an "lr" (for 
>>'loose route' URI parameter).

This is classic SIP, per RFC 3261.  A request is targeted at the URI 
in the status line (the first line of a SIP request) unless there is 
a Route header field with an "lr" URI parameter - which takes over as 
where (to the URI in the Route header) the request is targeted at 
until the message reaches this SIP element

>Why doesn't the PSAP URI belong into the To header?

it can be, but there is no trust in what's in the To header, that's the point

>I don't understand that sentence

because there is no integrity in the To header, P-Asserted-Identity 
(RFC3325) created a difficult solution that only works in a single 
domain. This limitation makes it not usable, and proves using the To 
header is not recommended.

>I am not sure this solution is inline with what the SIP guys are discussing.

huh?  This is "the SIP solution"... I didn't originate it

---

From: Richard Barnes <[email-masked]>
Date: Tue, 04 Sep 2007 11:42:24 -0400

Maybe I'm being simplistic, but why are we conflating emergency 
indication with routing?  I realize that there's a need for emergency 
call marking, but it seems abusive to use the Route header for that.  I 
think we need to find a header with a more appropriate semantic (even To 
seems better, since that's the logical destination).  If there's not a 
header available that's has appropriate semantics and isn't modifiable, 
then we should define a new header field for emergency indication that 
MUST NOT be modified by any entity other than the UAC.

--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Sep 2007 11:06:14 -0500

Richard

We're not conflating the two (at least I don't believe I am). I was 
stating that the emergency indication is needed.  Routing to the 
correct PSAP is necessary. SIP requests are routed based on the URI 
in the R-URI in the status line *unless* there is a URI in a Route 
header.  With the _PSAP_URI in the Route header, the R-URI can be the 
emergency indication (the sos service URN) with an implication that 
this value not change in transit.  The To header cannot be trusted to 
be the same , whether this is a URI or emergency indication. SIP does 
not (lowercase 'r') route on the contents of the To header - 
therefore it should not be used at all for emergency calling for any 
field that needs to be relied upon.

see below for the final answer

At 10:42 AM 9/4/2007, Richard Barnes wrote:
>indication with routing?  I realize that there's a need for 
>emergency call marking, but it seems abusive to use the Route header 
>for that.  I think we need to find a header with a more appropriate 
>semantic (even To seems better, since that's the logical destination).

>If there's not a header available that's has appropriate semantics 
>and isn't modifiable, then we should define a new header field for 
>emergency indication that MUST NOT be modified by any entity other 
>than the UAC.

The R-URI shouldn't change if there is a Route header with a URI of the PSAP.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 20:34:32 +0200

Have you look at this document? 
draft-polk-ecrit-local-emergency-rph-namespace-01.txt

Richard Barnes wrote:
> call marking, but it seems abusive to use the Route header for that.  
> I think we need to find a header with a more appropriate semantic 
> (even To seems better, since that's the logical destination).  If 
> there's not a header available that's has appropriate semantics and 
> isn't modifiable, then we should define a new header field for