[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter
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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>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
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit