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

From: Roger Marshall <[email-masked]>
Date: Mon, 16 May 2016 15:17:54 +0000

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.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 16 May 2016 18:06:07 -0700

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
>  [email-masked]
>  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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2016 12:14:38 +0000

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

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 18 May 2016 14:08:23 +0000

Hello,

I suggest to split the eCall URNs definition (section 14.1 of draft-ietf-ecrit-ecall) into a separate draft and progress this separate draft.

This should be possible as 'sos' service type URNs describes emergency services provided by PSAP (rather than a particular SIP signalling used to obtain the emergency service).

See RFC5031, section 4.2 - there are also no details on how SIP signalling is constructed.

The rest of the draft-ietf-ecrit-ecall needs more discussion (see mail from Christer).

Kind regards

Ivo Sedlacek

From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Monday, May 16, 2016 5:18 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Ecrit] -ecall draft: steps to progress

Roger & Marc
Ecrit Chairs

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 19 May 2016 12:17:46 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 18 May 2016 13:15
To: Randall Gellens; Roger Marshall; [email-masked]
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.²

	"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?

Regards,

Christer

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

>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).
>
>>> 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
>>>
>>
>> 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.
>>
>>
>-------------- Randomly selected tag: --------------- So engineering 
>is, for all intents and purposes, magic, and who wouldn't