Subject: [Sip] Changing To in service-marked calls

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Nov 2005 12:28:44 -0500

Picking up on a slightly-related discussion at the SIP meeting. An 
emerging consensus for marking emergency calls is to use the urn:service 
URN (see related draft). However, for backward-compatibility, we need to 
deal with phones that will issue requests such as

INVITE sip:[email-masked];user=phone
To: sip:[email-masked];user=phone

which the outbound proxy should then translate to

INVITE urn:service:sos
To: urn:service:sos

or

INVITE sip:[email-masked]
To: urn:service:sos

if that outbound proxy also does a PSAP look up. Any comments on this 
approach? (I find it somewhat distasteful.)

In general, the goals are to be able to
- distinguish emergency calls
- and detect if a location-to-URL translation has already taken place 
(we don't want to do this several times)

As a side note, this is also applicable to other services beyond 
emergency calling.

One alternative is to use a pre-loaded Route to urn:service:sos added by 
the outbound proxy.

Advice appreciated.

Henning

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Nov 2005 13:13:48 -0500

> INVITE sip:[email-masked]

I know we started to open the door to changing To and From, but did we 
really agree to allow *proxies* to change them???

> approach? (I find it somewhat distasteful.)

Why is it important to have the value in To?

> One alternative is to use a pre-loaded Route to urn:service:sos added by 

On that theme, how about:

INVITE urn:service:sos

and then eventually to:

INVITE urn:service:sos
To: sip:[email-masked];user=phone
Route: sip:[email-masked];lr

This way, once the 911 is recognized as a local representation of an 
emergency call it is replaced with a global representation of an 
emergency call and remains unchanged from then on. The Route headers 
then get it there.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Nov 2005 12:18:40 -0600

On Nov 9, 2005, at 11:28 AM, Henning Schulzrinne wrote:
> emerging consensus for marking emergency calls is to use the  
> urn:service URN (see related draft). However, for backward- 
> compatibility, we need to deal with phones that will issue requests  
> such as
>

Is this the same question as "Should the To: change on a retargeting  
operation"?

Or is it "Is 911 service determination  a retargeting operation or is  
it a routing operation"?

--
Dean

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Nov 2005 14:03:41 -0500

> really agree to allow *proxies* to change them???

That's where my discomfort arises. I checked RFC 3261 and To is proxy 
'r', i.e., this is not an option.

> Why is it important to have the value in To?

Parties in the call path should be able to tell that this was an 
emergency call. It does appear to be a (logical) destination identifier.

The original motivation was to make sure that calls marked as emergency 
might bypass authorization, but you want to make sure that you can't do

INVITE urn:service:sos
Route: sip:[email-masked];lr

where Alice is a friend not providing (officially recognized) emergency 
services. I don't think this is possible, so the only entities that can 
make such authorization bypass decisions would be the one inserting the 
Route (which is probably what you would do in any event).

> emergency call and remains unchanged from then on. The Route headers 

Works for me. Is there any estimate how existing proxies would deal with 
a service URN + Route combination?