[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter
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
>-----Original Message-----
>From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>On Behalf Of ext Brian Rosen
>Sent: 30 December, 2008 18:40
>To: 'Hannes Tschofenig'; 'ext Henning Schulzrinne'; 'Milan Patel'
>Cc: 'ECRIT'
>Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter
>
>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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>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,
>
>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.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.
>(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
>
>_______________________________________________
>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