Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 30 Dec 2008 15:50:16 +0200

Hi Henning,

I understand your concern. 

It is true that we do not have anything in the IETF emergency services
architecture where the mechanism of
http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02.txt, i.e. sos
SIP REGISTER, plays a role. Maybe we have not yet thought about that problem
hard enough. May it is a pure 3GPP IMS problem. 

There is obviously the question about why the 3GPP IMS emergency services
architecture is different than the one developed in the IETF (despite all
the talks we had in various meetings and workshops). The reason for this can
most likely be found in the desire of those players working in the 3GPP (and
related organizations) to have P-CSCF (a SIP proxy) in the visited network
so that it more closely reessembles a PSTN model. Is that a good
communication model? Does not really matter that much. What matters is that
almost all of the companies we see participating in the discussion here on
the mailing list regarding all our documents and that are also strong
advocates of the IETF emergency services model react very different in the
3GPP and just recently decided to vote against a further alignment between
these two emergency services architectures. The companies that supported
this misalignment include Ericsson, Alcatel-Lucent, Cisco, Qualcomm, etc.
(as far as I was told; I am not traveling to 3GPP meetings myself).
There is certainly no consistent thinking within larger companies regarding
the desired communication models and hence it is not suprising that this
aspect again surfaces when it comes to emergency services. 

Hence, we have to deal with this disconnect between the 3GPP and the IETF
emergency services architecture. 

So, why does the 3GPP comes to us and asks for a document to be worked on
even if we in the IETF cannot make use of it? Why cannot they just do it
alone without us? 

Well. In this case it is the fault of the IETF: the SIP process (see
http://www.rfc-editor.org/bcp/bcp67.txt) prevents them from doing something
useful within the 3GPP (without coming to the IETF). This process was
established many years ago and probably has not worked as well as some of us
would have liked it. This document might get updated based on the fact that
many folks aren't too happy with it. But this takes time. 

I hope that this makes more sense now. 

Ciao
Hannes
 
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Henning Schulzrinne
>Sent: 18 November, 2008 21:42
>To: Milan Patel
>Cc: ECRIT
>Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter
>
>Milan,
>
>thanks for your explanation. I think it raises a larger issue: 
>You seem to treat this as a 3GPP-specific issue, i.e., 
>something that only should be used in the 3GPP case. For 
>example, the P-Associated-URI facility is not something 
>available outside that context. In general, I consider it a 
>bad idea to have deployment-specific SIP variants, even more 
>so in the emergency calling case. The goal should be that any 
>SIP terminal can place emergency calls, rather than creating 
>non- compatible versions of SIP based on access networks. 
>Maybe we should have this larger-issue first before worrying 
>about parameter syntax.
>
>Henning
>
>On Nov 18, 2008, at 12:38 PM, Milan Patel wrote:
>
>> Hi Henning,
>>
>> Firstly, your previous email you asked:
>> Why not just have the normal registration be accepted for emergency 
>> calls only, without the parameter?
>> This is perfectly OK when the user is not roaming.
>>
>> At least in 3GPP, the addition of "sos" in the INVITE's 
>contact header 
>> can be associated with the sos URN in the Request-URI. But let's 
>> concentrate on the REGISTER request for now in this email.
>>
>> I'll deal with the restricted case first: if you do not have 
>> sufficient credentials to register with the network, you can't 
>> register, so yes, this is similar to the unauthenticated access. In 
>> this case, we are using Equipment identity to identify the user, but 
>> doesn't help in the call-back case. Since the user is not registered 
>> at an S-CSCF, there is no way the call can be routed back to 
>the user.
>>
>> Normal user: if the user isn't roaming, and registered as 
>one normally 
>> does. The UE registers with a SIP URI. In the 
>P-Associated-URI in the 
>> 200 (OK) to the REGISTER, the UE receives all the identities 
>> implicitly registered by the UE, including a tel-URI. In the 
>event of 
>> an emergency, the user may use any of these identities when 
>initiating 
>> an emergency call.
>>
>> Now in the case when the user wasn't registered, or was roaming 
>> (regardless of being registered or not), and has sufficient 
>> credentials to be authenticated by the network, the user makes an 
>> emergency call - the UE registers with the network. It needs to tell 
>> the registrar this registration is due to an emergency call, please 
>> don't barr my identities, or restrict me from roaming.
>>
>> Do I need to provide further explanation in the draft on the 
>> conditions for emergency registration? Isn't it sufficient to refer 
>> out to 3GPP TS 23.167?
>>
>> Cheers,
>> Milan
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit
>

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 Dec 2008 11:40:15 -0500

Nice argument, and true.

However, in this case, I think we have a simpler problem. 

In some countries, it's a regulatory requirement that devices be able to
place emergency calls in circumstances where other calls may not be
permitted.  This may be because there is no subscription for services, or
because of some kind of failure (perhaps a home network is not reachable,
but the visited network is, and is subject to regulation that it must enable
emergency calls).

In other circumstances, the notion of "home" and "visited" is defined such
that the visited network always handles emergency calls, regardless of
regulation or failure.

It seems to me that the notion of a special registration for emergency calls
makes sense in those circumstances.  Such a registration ought to be
explicitly marked as an emergency registration, and not the normal one, I
think.

Therefore, I think this makes sense.

I've never been completely sold on a parameter, but I agree that it's a
reasonable way to solve what I think is a reasonable problem worth solving.

So this is not directly tied to 3GPP; they are simply an example of the
"visited network handles emergency calls".

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, December 30, 2008 8:50 AM
To: 'ext Henning Schulzrinne'; Milan Patel
Cc: ECRIT
Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

Hi Henning,

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 31 Dec 2008 11:29:34 +0200

Thanks Brian for your response. 

Maybe we can even craft some text to be added to the document to capture
your reasoning. This would make me feel better. 

Ciao
Hannes
 
>On Behalf Of ext Brian Rosen
>Sent: 30 December, 2008 18:40
>To: 'Hannes Tschofenig'; 'ext Henning Schulzrinne'; 'Milan Patel'
>Cc: 'ECRIT'
>In some countries, it's a regulatory requirement that devices 
>be able to place emergency calls in circumstances where other 
>calls may not be permitted.  This may be because there is no 
>subscription for services, or because of some kind of failure 
>(perhaps a home network is not reachable, but the visited 
>network is, and is subject to regulation that it must enable 
>emergency calls).
>
>In other circumstances, the notion of "home" and "visited" is 
>defined such that the visited network always handles emergency 
>calls, regardless of regulation or failure.
>
>It seems to me that the notion of a special registration for 
>emergency calls makes sense in those circumstances.  Such a 
>registration ought to be explicitly marked as an emergency 
>registration, and not the normal one, I think.
>
>I've never been completely sold on a parameter, but I agree 
>that it's a reasonable way to solve what I think is a 
>reasonable problem worth solving.
>
>So this is not directly tied to 3GPP; they are simply an 
>example of the "visited network handles emergency calls".
>
>Brian
>
>On Behalf Of Hannes Tschofenig
>It is true that we do not have anything in the IETF emergency 
>services architecture where the mechanism of 
>http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter-02.t
>xt, i.e. sos SIP REGISTER, plays a role. Maybe we have not yet 
>thought about that problem hard enough. May it is a pure 3GPP 
>IMS problem. 
>
>There is obviously the question about why the 3GPP IMS 
>emergency services architecture is different than the one 
>developed in the IETF (despite all the talks we had in various 
>meetings and workshops). The reason for this can most likely 
>be found in the desire of those players working in the 3GPP 
>(and related organizations) to have P-CSCF (a SIP proxy) in 
>the visited network so that it more closely reessembles a PSTN 
>model. Is that a good communication model? Does not really 
>matter that much. What matters is that almost all of the 
>companies we see participating in the discussion here on the 
>mailing list regarding all our documents and that are also 
>strong advocates of the IETF emergency services model react 
>very different in the 3GPP and just recently decided to vote 
>against a further alignment between these two emergency 
>services architectures. The companies that supported this 
>misalignment include Ericsson, Alcatel-Lucent, Cisco, Qualcomm, etc.
>There is certainly no consistent thinking within larger 
>companies regarding the desired communication models and hence 
>it is not suprising that this aspect again surfaces when it 
>comes to emergency services. 
>
>Hence, we have to deal with this disconnect between the 3GPP 
>and the IETF emergency services architecture. 
>
>So, why does the 3GPP comes to us and asks for a document to 
>be worked on even if we in the IETF cannot make use of it? Why 
>cannot they just do it alone without us? 
>
>http://www.rfc-editor.org/bcp/bcp67.txt) prevents them from 
>doing something useful within the 3GPP (without coming to the 
>IETF). This process was established many years ago and 
>probably has not worked as well as some of us would have liked 
>it. This document might get updated based on the fact that 
>>You seem to treat this as a 3GPP-specific issue, i.e., something that 
>>only should be used in the 3GPP case. For example, the 
>P-Associated-URI 
>>facility is not something available outside that context. In 
>general, I 
>>consider it a bad idea to have deployment-specific SIP variants, even 
>>more so in the emergency calling case. The goal should be 
>that any SIP 
>>terminal can place emergency calls, rather than creating
>>Maybe we should have this larger-issue first before worrying about 
>>parameter syntax.
>>
>>Henning
>>