Subject: Re: [Ecrit] draft-ietf-ecall-07

From: Randall Gellens <[email-masked]>
Date: Tue, 7 Jun 2016 18:34:19 -0700

Hi Keith,

At 12:48 PM +0000 5/19/16, Keith (Nokia - GB) Drage wrote:

>  I did another read through of this document last night, and had the 
> following comments. I have not reviewed the entire document.
>
>  Note that this does not supercede any of the comments made in the 
> last few days:
>
>  1)	s. 2, 1st para: ecall in 3GPP is a 3GPP emergency call, and 
> while there are some similarities, 3GPP emergency call does not 
> fully comply with either RFC 6443 or RFC 6881. I am also not sure 
> the references are relevant to the purpose of the draft in any case.

In my understanding, 3GPP IMS emergency calls are conformant with 
these RFCs because the RFCs permit the 3GPP model of a proxy (in the 
3GPP case, the E-CSCF) inserting location.  3GPP does not require 
that the proxy insert location, but does permit it, so in my view 
there isn't a conflict.

>
>  2)	s. 2, 3rd and 4th para: These paragraphs seem to be going 
> beyond document scope, and into a wish list. I suggest both these 
> paragraphs are deleted.

The 4th paragraph was added last year at your request.  The 3d 
paragraph permits the document to be used in non-ecall situations 
(such as the car-crash document for North America), and is identified 
a permitted but out of scope use.

>
>  3)	s. 3, 4th paragraph:
>
>     An eCall can be either user-initiated or automatically triggered.
>     Automatically triggered eCalls indicate a car crash or some other
>     serious incident and carry a greater presumption of risk of injury.
>     Manually triggered eCalls might be reports of serious hazards and are
>     likely to require a different response than an automatically
>     triggered eCall.  Manually triggered eCalls are also more likely to
>     be false (e.g., accidental) calls and so might be subject to
>     different operational handling by the PSAP.
>
>  The distinction between seriousness and impact of manual versus 
> automatic is highly subjective, and will depend on the underlying 
> philosophy of the administration in how it handles what it regards 
> as false alerts, which differs substantially from administration to 
> administration.

Good point, I will reword this text.

>
>  4)	s. 3, 5th para:
>
>     As part of this work, the European Telecommunications
>     Standards Institute (ETSI) [SDO-ETSI] has published a Technical
>     Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR]
>     that presents findings and recommendations regarding support for
>     eCall in an all-IP environment.
>
>  This somehow implies that the contents of this document are valid 
> for the interpretation of the draft. Vewry little of the work has 
> migrated into the stage 1 in 3GPP, and the other groups in 3GPP are 
> working directly from the stage 1 description, not from the ETSI 
> work.

I'll adjust the wording to make it more clear that the ETSI work is 
background and informative, and not being used to direct the draft.

>
>  5)	s. 3 last para:
>
>     A transition period will exist during which time the various entities
>     involved in initiating and handling an eCall might support next-
>     generation eCall, legacy eCall, or both.  This transition period
>     might last several years or longer.  The issue of migration/co-
>     existence during the transition period is very important but is
>     outside the scope of this document.  The ETSI TR "Mobile Standards
>     Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in
>     Clause 7.
>
>  I have not found any statements that support the concept of a 
> transition in any of the documents I have read. The 3GPP stage 1 
> requires both UEs and PSAPs to support both data transfer 
> mechanisms.

By definition there is a transition period, and various 3GPP CRs and 
DPs and the like mention this concept (e.g., at some point 2G/3G 
networks will be turned off).  The text says that transition issues 
are out of scope.

>
>  6)	s. 3 general
>
>  Some statement should be made in this section about the need for 
> the UE and the PSAP to support both mechanisms within SIP, as 
> required by the stage 1, as the 3GPP emergency network does not 
> provide any data interworking, only signalling interworking. 
> Interworking SIP to CS domain, any attached body to a SIP message 
> will be discarded.

That's out of scope of the draft.  3GPP will cover it, as you say above.

>
>  7)	s. 4 reference to 22.101, and s. 18.1. This document carries 
> no provisions needed to implement this document, and therefore it 
> should not be a normative reference. Further the reference should 
> be to release 14 and later. The latest version of all releases of 
> 3GPP documents are still valid documents for that release.

I can make this an informative reference.

>
>  8)	s. 4. Is considerably out of data in regard to the current 
> version of 22.101. This appears to be a summary of the CS 
> requirements before the IMS changes were made.

In light of the recently approved changes for eCall over IMS, perhaps 
these can be deleted from this document or less formally summarized.

>
>  9)	s. 6 last para.
>
>     This document registers new service URN children within the "sos"
>     subservice.  These URNs provide the mechanism by which an eCall is
>     identified, and differentiate between manually and automatically
>     triggered eCalls (which can be subject to different treatment,
>     depending on policy).  The two service URNs are:
>     urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual
>
>  The URN does not identify an ecall. It identifies the resource to 
> which the ecall needs to be directed. To explain further, the sos 
> URN does not identify an emergency call, it identifies the resource 
> needed to answer the emergency call, which is why we have a 
> separate Resource-Priority namespace "esnet".

Thanks for the clarification regarding the wording, I'll revise it.

>
>  10)	s.7
>
>  Europe does not use the term ESInet. That term is North America, 
> and possibly USA, specific. It might be more appropriate to use 
> terminology from the ETSI M483 group if this text is needed at all.

EENA uses the term, which is why it's mentioned.  However, perhaps 
this section can be replaced with a statement that call routing is 
out of scope of the draft.

>
>  11)	s.8
>
>  In regard to test calls, I think some statement should be made 
> about what they actually test. Using this URN would certainly not 
> test the emergency call handling capabilities of either the network 
> or the UE. Does it test all data transfer capabilities (including 
> the CS). Why do we need a URN rather than just the same number as 
> is used in the CS domain?

The document does not try to mandate the behavior of test calls. 
I'll make this more clear.

>
>  12)	s.9
>
>     Future enhancements are desired to enable the PSAP to send other
>     requests to the vehicle, such as locking or unlocking doors, sounding
>     the horn, flashing the lights, starting a video stream from on-board
>     cameras (such as rear focus or blind-spot), etc.
>
>  Do you have a reference for this, or is it speculative thinking?
>
>  I do not think the mechanisms proposed in this draft are suitable 
> for transferring a video stream, so even if provided, are they part 
> of ecall, or just part of the standard emergency call. Maybe the 
> only ecall responsibility is to indicate the existence of these?
>
>  I'd note that extending beyond the existing CS domain capability is 
> not required at the moment by the 3GPP stage 1. I think we all 
> acknowledge that all and any data available in the car might be 
> candidates for transfer to the PSAP, but it is not clear whether 
> this is part of ecall, or whether it is part of the additional 
> media beyond voice already available as part of 3GPP emergency 
> call. Certainly there is a limit on the amount of data that can be 
> transferred using the mechanisms currently in this draft, beyond 
> which the QoS of the signalling channel will become inappropriate.

No additional data beyond the MSD is currently required nor 
supported, but there has been discussion in various European 
eCall-related forums regarding such capabilities.  I will look into 
adding references.  Video feeds and other such streaming data would 
be carried using SIP media streams, not the additional-data 
mechanisms.

>
>  13)	s.9 & s.13
>
>  It is not clear to me which elements correspond to the existing MSD 
> defined by CEN, and which have been defined over the top. Firstly I 
> think all data that is defined by CEN should carry an appropriate 
> CEN reference, because the UE needs to support both, and it should 
> be the same data that is transferred in this. That should occur 
> either in one of these sections, or in a new separate section.
>
>  Further, if information does go over the top of the existing CEN 
> definition, this needs additional review and possibly postponement 
> to a later version, as this is not required by the current 3GPP 
> stage 1.
>
>  14)	s.14.3
>
>           A call-back from a PSAP incurs additional risk,
>           since the current mechanisms are not ideal for verifying that
>           such a call is indeed a call-back from a PSAP in response to an
>           emergency call placed by the IVS.  See the discussion in
>           Section 11 and the PSAP Callback document [RFC7090].
>
>  I do not understand why call-back is being referred to here. Can you explain?

A call back from a PSAP could request that the vehicle send an updated MSD.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Majority: That quality that distinguishes a crime from a law.