Re: [Ecrit] -ecall draft: steps to progress

["Drage, Keith (Nokia - GB)" <[e-mail]>]

Looks like I somehow failed to do a reply all on this one, so this is the reply I sent to this:

+1

Indeed many of these are points I have made previously.

On the URNs, as part of the URN definition, we need the draft the define the resources requested by the URN, which as indicated is a resource that supports both the mechanism in this draft (whatever it ends up being to align with the 3GPP discussions) and the existing in band modem type mechanism.

And as regards the INFO usage, if INFO is used, it must be a conforming INFO package. Relying on the upper layers is in my view a layer violation.

Keith

-----Original Message-----
From: Ecrit [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: 18 May 2016 13:15
To: Randall Gellens; Roger Marshall; [e-mail]
Subject: Re: [Ecrit] -ecall draft: steps to progress


Hi,

A few comments:

 

Q1: The reason people (at least those involved in the 3GPP work) haven¹t "provided any text" is because the work in 3GPP is still ongoing.

 

Q2: SA1 has agreed that it shall be possible to send cCall data using an eCall modem in the voice channel, e.g. in case the eCall ends up in CS-PSAP. URNs defined by the draft will need to support be needed for that too.
 

	3GPP TS 22.101 says:

	"An IVS that supports IMS emergency call based eCalls and is attached via LTE access with no CS access available shall support the transfer of MSD via IMS emergency call to a TS12 based PSAP using the eCall Modem end-to-end."

 

Q3: Randall said: 

	"I've said before that if we find we have new use cases that require very large data or high-frequency updates, we can
	do an extension to additional-data that adds a data channel mechanism that preserves the other aspects of additional-data
	(e.g., that data blocks are identified per a registry and the PSAP can choose to access the data or not)."

 
	First, the draft does not define ³frequent², nor does it give an explicit limit on the frequency and size of the INFO requests, which means different 
	people will have different views on whether the mechanism is appropriate for a specific use-case or not. As there is no limit, the frequency of SIP INFO 
	is dependent solely on PSAP policy (and PSAP may wish to trigger a lot of car actions). Such SIP INFO requests will generate unpredictable load on
	operator's SIP infrastructure and endanger success of handling of other IMS emergency calls.

 
	Second, the draft already talks about future use-cases (on-board cameras, PSAP requests for the car to take actions, etc etc), but it¹s unclear whether 
	the intention is to support those with INFO, or whether a "future mechanism" would be needed for those.

 
	

Q4:         Last week, in the SA1 meeting, it was pointed out that the CEN
specification actually specifies that the MSD shall be sent in binary form ­ not XML.

	"In order to enable interpretation by the PSAP, the MSD shall always be presented in an ASN.1 encoded module:
	either ASN.1 ŒUnaligned Packet Encoding Rules¹ (UPER) or ASN.1 ŒExtended XML Encoding Rules¹ (EXER) encoding shall be used.

	In the case of an MSD for pan-European eCall sent via GSM/UMTS (EN 16072/EN 16062), the MSD shall be encoded using ŒUnaligned Packed Encoding
	Rules¹ (UPER) as defined in ISO/IEC 8825-2. The length of this encoded MSD (including any Œoptional additional data¹) shall not exceed 140
	bytes (as specified in EN 16062). Any payload bytes received outside of the ASN.1 message length shall be ignored by the receiving entity.²


	Now, the CEN specification does contain the following note:

	"NOTE 3 If the MSD is transferred using another means of communication that has no, or less stringent, data limits, XML encoding rules
	may be used if preferred. Annex C contains the derived XSD for such encoding.²

	The eCall draft only covers the choice of encoding by saying: ³The XML encoding is better suited for use in SIP messages and is used in this document.². 
	If we want to go against the CEN recommendation when it comes to encoding, and use XML, we really need more justification for using XML.
Based on what do we claim
	that XML is better suited for SIP? Do we assume that SIP message have no data limits?

Q5:	I still claim that MSDs shall not be carried in INFO responses.


Regards,

Christer

 




On 17/05/16 04:06, "Ecrit on behalf of Randall Gellens"
<[e-mail] on behalf of [e-mail]> wrote:

>I think we need to keep in mind that the ecall draft makes use of the 
>mechanism established in additional-data.  I've said before that if we 
>find we have new use cases that require very large data or 
>high-frequency updates, we can do an extension to additional-data that 
>adds a data channel mechanism that preserves the other aspects of 
>additional-data (e.g., that data blocks are identified per a registry 
>and the PSAP can choose to access the data or not).
>
>At 3:17 PM +0000 5/16/16, Roger Marshall wrote:
>
>>>  We seem to be at somewhat of an impasse with regard to reaching an 
>>> agreement on the mechanism that ecall draft should use to transport 
>>> initial information.  There are differing opinions as to how data 
>>> could be, or even should be conveyed within a SIP Invite, but so far 
>>> we've not seen any proposed text that would change this in the 
>>> present draft.
>>>
>>
>>>  The chairs desire to progress this draft through the process as per 
>>> the agreement discussed in BA.  We would like to hear from the wg 
>>> members, namely, should we expect to get some proposed alternatives 
>>> in the next week so we can try to reach consensus on the list, or 
>>> alternatively, immediately schedule an interim meeting to get some 
>>> traction?
>>>
>>>
>>>  Roger & Marc
>>>
>>>  Ecrit Chairs
>>>
>>
>>  NOTICE TO RECIPIENT: This email, including attachments, may contain 
>> information which is confidential, proprietary, attorney-client 
>> privileged and/or controlled under U.S. export laws and regulations 
>> and may be restricted from disclosure by applicable State and Federal 
>> law. Nothing in this email shall create any legal binding agreement 
>> between the parties unless expressly stated herein and provided by an 
>> authorized representative of Comtech Telecommunications Corp. or its 
>> subsidiaries. If you are not the intended recipient of this message, 
>> be advised that any dissemination, distribution, or use of the 
>> contents of this message is strictly prohibited. If you received this 
>> message in error, please notify us immediately by return email and 
>> permanently delete all copies of the original email and any attached 
>> documentation from any computer or other media.
>>
>>
>>  _______________________________________________
>>  Ecrit mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/ecrit
>
>
>--
>Randall Gellens
>Opinions are personal;    facts are suspect;    I speak for myself only
>-------------- Randomly selected tag: --------------- So engineering 
>is, for all intents and purposes, magic, and who wouldn't
>want to be a magician?      --Elon Musk, founder SpaceX and Tesla Motors
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit

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