Subject: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

From: Roger Marshall <[email-masked]>
Date: Thu, 21 Apr 2016 04:13:08 +0000

During our meeting in BA, the posted notes reflect the agreement in the room & the chairs action to confirm consensus on the list to progress both ID's, draft-ietf-ecrit-car-crash-07 & draft-ietf-ecrit-ecall-07 for IESG submission in accordance with our work group milestones.

The agreement as documented was with a caveat of asking the AD for a sync with other SDO progress right before final approval.

Please confirm your support on moving these two forward/submission to IESG.

Roger Marshall
Marc Linsner
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: Christer Holmberg <[email-masked]>
Date: Thu, 21 Apr 2016 06:16:01 +0000

Hi,

I think we still have the issue with sending data in INFO responses (which is not related to the sync with other SDOs) in draft-ietf-ecrit-ecall.

Regards,

Christer

From: Ecrit <[email-masked]<mailto:[email-masked]>> on behalf of Roger Marshall <[email-masked]<mailto:[email-masked]>>
Date: Thursday 21 April 2016 at 07:13
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Ben Campbell <[email-masked]<mailto:[email-masked]>>
Subject: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

During our meeting in BA, the posted notes reflect the agreement in the room & the chairs action to confirm consensus on the list to progress both ID’s, draft-ietf-ecrit-car-crash-07 & draft-ietf-ecrit-ecall-07 for IESG submission in accordance with our work group milestones.

Roger Marshall
Marc Linsner
ECRIT chairs

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 21 Apr 2016 13:23:40 +0000

I'm afraid I cannot support ecall moving forward because of thetotal lack of synchronization with the other SDO. It is becoming more and more apparent that there are divergences with the current 3GPP thinking.

Further, I cannot support carcrash moving forward for the same reason unless it uses different subtypes to ecall. Please also note that if these different values are used in 3GPP support of emergency call, they will be routed to the default emergency PSAP in accordance with 3GPP specifications.

Keith

From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Roger Marshall
Sent: 21 April 2016 05:13
To: [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Roger Marshall
Marc Linsner
ECRIT chairs

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Apr 2016 06:42:32 -0700

At 6:16 AM +0000 4/21/16, Christer Holmberg wrote:

>  I think we still have the issue with sending data in INFO responses 
> (which is not related to the sync with other SDOs) in 
> draft-ietf-ecrit-ecall.

The argument seems silly to me.  If the draft uses re-INVITE, there 
would be no issue.  I suspect the problem may be that the draft 
registers an INFO package, which invites implication that the draft 
is using INFO as a pure tunnel mechanism, which is not the case.  The 
debate over INFO responses mixes up the context of protocols which 
use INFO as a tunnel/transport mechanism with the case here, which 
carries information intrinsic to the emergency call.

>  From: Ecrit <<mailto:[email-masked]>[email-masked]> 
> on behalf of Roger Marshall 
> <<mailto:[email-masked]>[email-masked]>
>  To: "<mailto:[email-masked]>[email-masked]" 
> <<mailto:[email-masked]>[email-masked]>
>  Cc: Ben Campbell <<mailto:[email-masked]>[email-masked]>
>  During our meeting in BA, the posted notes reflect the agreement in 
> the room & the chairs action to confirm consensus on the list to 
> progress both ID's, draft-ietf-ecrit-car-crash-07 & 
> draft-ietf-ecrit-ecall-07 for IESG submission in accordance with 
> our work group milestones.
>
>
>
>  The agreement as documented was with a caveat of asking the AD for 
> a sync with other SDO progress right before final approval.
>
>
>
>  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: ---------------
It wasn't as easy to get programs right as we had thought.
                                           --Wilkes, 1949

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Apr 2016 14:03:34 +0000

Hi,

Again, if you think the INFO package mechanism and the associated rules
are silly, bring the issue to SIPCORE.

Not sure I understand your comment about INFO not being used as a tunnel
mechanism. From a SIP protocol perspective the content is just some data
sent between two application endpoints.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Apr 2016 07:50:07 -0700

Hi Keith,

At 1:23 PM +0000 4/21/16, Keith (Nokia - GB) Drage wrote:

>  I'm afraid I cannot support ecall moving forward because of 
> thetotal lack of synchronization with the other SDO. It is becoming 
> more and more apparent that there are divergences with the current 
> 3GPP thinking.

Can you give more details and perhaps an example of these 
divergences?  I am not aware of any, and neither are our people in 
3GPP.

>   Further, I cannot support carcrash moving forward for the same 
> reason unless it uses different subtypes to ecall. Please also note 
> that if these different values are used in 3GPP support of 
> emergency call, they will be routed to the default emergency PSAP 
> in accordance with 3GPP specifications.

The two drafts use the same SOS child service URN at your insistence. 
Originally, these were two different child URNs, and you argued at 
that time that the call set-up must be identical in the two drafts. 
Your argument was accepted, so the drafts were modified so that 
car-crash inherits the call set-up and other technical aspects from 
ecall, with the only technical difference being the mandatory crash 
data set (MSD in ecall and VEDS in car-crash).

--Randy

-------------- Randomly selected tag: ---------------
    Freddie Laker
    May be at peace with his Maker.
    But he is persona non grata
    With IATA.
            --HRH Duke of Edinburgh

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Apr 2016 07:57:18 -0700

Hi Christer,

>  are silly, bring the issue to SIPCORE.

This is not what I am saying.  I am saying that the context of this 
draft is different from the general case where INFO is used as a 
tunnel mechanism for a protocol that just happens to use SIP as 
transport.  In the case here, we're using SIP as a way to establish 
emergency calls, and to transport small amounts of data that are 
intrinsic to the call.  Different contexts.

--Randy

-------------- Randomly selected tag: ---------------
Maybe Computer Science should be in the College of Theology.  -
                                              -R. S. Barton

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 21 Apr 2016 15:00:37 +0000

Hello,

3GPP SA2 (architecture) did not decide to endorse the draft-ietf-ecrit-ecall yet.
3GPP CT1 (protocol) decided to refer to section 14.1 of draft-ietf-ecrit-ecall for purpose of URNs referencing. Rest of the draft is FFS subject to 3GPP SA2 decisions.

So, IMO, Keith has a point on lack of synchronization of the solutions between 3GPP and ECRIT on draft-ietf-ecrit-ecall.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: Thursday, April 21, 2016 4:50 PM
To: Drage, Keith (Nokia - GB); EXT Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Keith,

At 1:23 PM +0000 4/21/16, Keith (Nokia - GB) Drage wrote:

>  I'm afraid I cannot support ecall moving forward because of thetotal 
> lack of synchronization with the other SDO. It is becoming more and 
> more apparent that there are divergences with the current 3GPP 
> thinking.

Can you give more details and perhaps an example of these divergences?  I am not aware of any, and neither are our people in 3GPP.

> that if these different values are used in 3GPP support of emergency 
> call, they will be routed to the default emergency PSAP in accordance 
> with 3GPP specifications.

The two drafts use the same SOS child service URN at your insistence. 
Originally, these were two different child URNs, and you argued at that time that the call set-up must be identical in the two drafts. 
Your argument was accepted, so the drafts were modified so that car-crash inherits the call set-up and other technical aspects from ecall, with the only technical difference being the mandatory crash data set (MSD in ecall and VEDS in car-crash).

--Randy

> draft-ietf-ecrit-ecall-07 for IESG submission in accordance with our 
> work group milestones.
>
>  The agreement as documented was with a caveat of asking the AD for a 
> sync with other SDO progress right before final approval.
>
> 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: ---------------
    Freddie Laker

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 21 Apr 2016 15:05:25 +0000

Hello,

1) IMO, either RFC6086 should be used as intended in RFC6086, or RFC6086 should not be used. Else, everyone trying to use RFC6086 can claim his context is different.

2) on "to transport small amounts of data that are intrinsic to the call" - how can we be sure that the amounts of data that are intrinsic to the call will stay "small" forever? The need on data transfers tend to grown, and the cars are getting more and more intelligent.

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Randall Gellens
Sent: Thursday, April 21, 2016 4:57 PM
To: Christer Holmberg; Randall Gellens; Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Christer,

At 2:03 PM +0000 4/21/16, Christer Holmberg wrote:

>  Again, if you think the INFO package mechanism and the associated 
> rules  are silly, bring the issue to SIPCORE.

This is not what I am saying.  I am saying that the context of this draft is different from the general case where INFO is used as a tunnel mechanism for a protocol that just happens to use SIP as transport.  In the case here, we're using SIP as a way to establish emergency calls, and to transport small amounts of data that are intrinsic to the call.  Different contexts.

--Randy

>
>  Not sure I understand your comment about INFO not being used as a 
> tunnel  mechanism. From a SIP protocol perspective the content is just 
> some data  sent between two application endpoints.
>
>  Regards,
>
>  Christer
>
>
>
>
>>>   I think we still have the issue with sending data in INFO 
>>> responses  (which is not related to the sync with other SDOs) in  
>>> draft-ietf-ecrit-ecall.
>>
>>registers an INFO package, which invites implication that the draft is 
>>using INFO as a pure tunnel mechanism, which is not the case.  The 
>>debate over INFO responses mixes up the context of protocols which use 
>>INFO as a tunnel/transport mechanism with the case here, which carries 
>>information intrinsic to the emergency call.
>>
>>
>>>   From: Ecrit 
>>> <<mailto:[email-masked]>[email-masked]>
>>>   Subject: [Ecrit] since BA, confirming 
>>> draft-ietf-ecrit-car-crash-07  and draft-ietf-ecrit-ecall-07
>>>
>>>
>>>   During our meeting in BA, the posted notes reflect the agreement 
>>> in  the room & the chairs action to confirm consensus on the list to  
>>>   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  
>>-------------- Randomly selected tag: --------------- It wasn't as 
>>easy to get programs right as we had thought.
>>                                            --Wilkes, 1949

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Maybe Computer Science should be in the College of Theology.  -
                                              -R. S. Barton

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Apr 2016 08:52:37 -0700

The fact that 3GPP SA2 and CT1 have not yet decided how to proceed is 
not evidence of divergences.

At 3:00 PM +0000 4/21/16, Ivo Sedlacek wrote:

>  3GPP CT1 (protocol) decided to refer to section 14.1 of 
> draft-ietf-ecrit-ecall for purpose of URNs referencing. Rest of the 
> draft is FFS subject to 3GPP SA2 decisions.
>
>  So, IMO, Keith has a point on lack of synchronization of the 
> solutions between 3GPP and ECRIT on draft-ietf-ecrit-ecall.
>
>  Kind regards
>
>  Ivo Sedlacek
>
>  Subject: Re: [Ecrit] since BA, confirming 

-------------- Randomly selected tag: ---------------
Walter Benjamin's concept of "aura" in simple terms means that
something assumes a particularly intense and melancholy power
to fascinate at the moment of its disappearance.
                --Joachim Kalka, from "Money As We Knew It."

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Apr 2016 08:56:31 -0700

Hi Ivo,

We are dealing with a very limited set of data now.  For this draft, 
that's all we are dealing with.  It is possible that in the future, 
new uses will appear that require transmitting larger sets of data, 
and if that happens, I'd be happy to develop an extension to the 
additional-data draft that provides a third mechanism for 
transmitting data, so that in addition to the current mechanisms of 
by-value in the SIP signaling and by-reference using HTTPS, we'd have 
a third mechanism using a separate media channel.

At 3:05 PM +0000 4/21/16, Ivo Sedlacek wrote:

>  Hello,
>
>  1) IMO, either RFC6086 should be used as intended in RFC6086, or 
> RFC6086 should not be used. Else, everyone trying to use RFC6086 
> can claim his context is different.
>
>  2) on "to transport small amounts of data that are intrinsic to the 
> call" - how can we be sure that the amounts of data that are 
> intrinsic to the call will stay "small" forever? The need on data 
> transfers tend to grown, and the cars are getting more and more 
> intelligent.
>
>  Kind regards
>
>  Ivo Sedlacek
>
>  -------------- Randomly selected tag: --------------- Maybe 
> Computer Science should be in the College of Theology.  -
>                                                -R. S. Barton
>

-------------- Randomly selected tag: ---------------
A successful tool is used to do something undreamed of by its author.
                                                           --Johnson

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Apr 2016 16:10:55 +0000

Hi,

>This is not what I am saying.  I am saying that the context of this draft is different from the general case where INFO is used as a tunnel mechanism for a protocol that just happens to use SIP as >transport.  In the case here, we're using SIP as a way to establish emergency calls, and to transport small amounts of data that are intrinsic to the call.  Different contexts.

It is still transparent data to the SIP session. The receiving SIP stack will receive the INFO, send 200, and send the content to the associated application without processing the content (the receiver will only make sure the receiver has indicated support of the associated Info Package).

And, even if you think the context is different, I don't see how that justifies anything. But, again, if you think it does, bring it to SIPCORE. RFC 6086 currently says nothing about different contexts.

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 21 Apr 2016 16:28:03 +0000

As far as I am aware, both SIP, now deceased, and SIPCORE, have made no general provision of the use of SIP as a transport, outside the use of INFO.

Specific mechanisms do exist such as MESSAGE, PUBLISH and SUBSCRIBE NOTIFY.

Moreover there is a long history of the use of SIP as a transport mechanism which is why I believe SIP/SIPCORE focused on INFO as being the correct means of providing this. That is INFO without miscellaneous extensions. There was IETF consensus on moving forward with INFO in the form that it is in, and one should stick within those rules.

Regards

Keith Drage

P.S. I need to go back an pick up on earlier mails for which I did not, and still do not, agree with your response.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Randall Gellens
Sent: 21 April 2016 15:57
To: Christer Holmberg; Randall Gellens; Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Christer,

--Randy

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 22 Apr 2016 00:30:20 +0000

The reason we are dealing with limited sets of data in CS domain ecall is because it is carried using modem type data transmission.

As the world evolves to and end-to-end IP connection I can well envisage a call for extension to the data in the form of for example:
a)	the last 30s of statistics downloaded from the engine management system
b)	the last 30s from the dashcam or any forward facing cameras

I am missing out additional real time streams here as I am assuming they could be added as additional media.

While 3GPP is not studying those as part of the release 14 work, and not proposing to increase that currently to maintain compatibility with the CS domain, I believe we need to build a mechanism to take account of the addition of large amounts of data in the future. I suspect for compatibility purposes there will remain the need for the limited block when interworking with the CS domain, but an enhanced block when we have end to end IP. I fail to see why we should have to have two different mechanisms because one block is bigger than the other.

The general principle in emergency calls as far as I can understand the more information that can be made available to the call taker, the better (assuming it is done in a controlled manner). That means that much of the additional data may well be subsequent data rather than included in the INVITE.

Regards

Keith 

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Randall Gellens
Sent: 21 April 2016 16:57
To: Ivo Sedlacek; Christer Holmberg; Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Ivo,

We are dealing with a very limited set of data now.  For this draft, that's all we are dealing with.  It is possible that in the future, new uses will appear that require transmitting larger sets of data, and if that happens, I'd be happy to develop an extension to the additional-data draft that provides a third mechanism for transmitting data, so that in addition to the current mechanisms of by-value in the SIP signaling and by-reference using HTTPS, we'd have a third mechanism using a separate media channel.

At 3:05 PM +0000 4/21/16, Ivo Sedlacek wrote:

> RFC6086 should not be used. Else, everyone trying to use RFC6086 can 
> claim his context is different.
>
> call" - how can we be sure that the amounts of data that are intrinsic 
> to the call will stay "small" forever? The need on data transfers tend 
> to grown, and the cars are getting more and more intelligent.
>
>  Kind regards
>
>  Ivo Sedlacek
>
>> tunnel  mechanism. From a SIP protocol perspective the content is 
>> just  some data  sent between two application endpoints.
>>
>>   Regards,
>>
>>   Christer
>>
>>
>>
>>
>>>> in  the room & the chairs action to confirm consensus on the list 
>>>> to  progress both ID's, draft-ietf-ecrit-car-crash-07 &
>>>>    The agreement as documented was with a caveat of asking the AD 
>>>> for  a sync with other SDO progress right before final approval.
>>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>>
>  -------------- Randomly selected tag: --------------- Maybe Computer 
> Science should be in the College of Theology.  -
>                                                -R. S. Barton
>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- A successful tool is used to do something undreamed of by its author.
                                                           --Johnson

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 22 Apr 2016 00:38:18 +0000

One thing I forgot to add to this message.

INFO was originally a specific mechanism for one use case.

When it was agreed to generalize it to the document we have now, there was a lot of resistance to any mechanism that allowed data to be carried in SIP. The argument was that SIP is a rendezvous protocol for a very specific purpose, and data transport should be met by other protocols, possibly with the support of SIP.

You seem to have evaded that discussion by writing it in ECRIT rather than involving SIPCORE.

Further I am not sure that ECRIT has the scope to invent new SIP protocol. Which part of the SIP charter justifies extending SIP in this manner?

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Drage, Keith (Nokia - GB)
Sent: 21 April 2016 17:28
To: EXT Randall Gellens; Christer Holmberg; Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Regards

Keith Drage

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Randall Gellens
Sent: 21 April 2016 15:57
To: Christer Holmberg; Randall Gellens; Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Christer,

--Randy

>>> all copies of the original email and any attached documentation from 
>>> any computer or other media.
>>>
>>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 22 Apr 2016 00:48:12 +0000

Assuming by "our people" you mean "Qualcomm" rather than "pensive" or some other organization.

I am aware that Qualcomm is trying to drive a specific solution forward in 3GPP.

That does not mean that the rest of 3GPP agree with that solution, and there still needs to be some serious discussion on the future extensibility, and interaction with other emergency call capabilities, of the Qualcomm solution, versus other proposals.

As regards the service URN usage, you dismissed the point I made about this usage in ecall in an earlier mail, in regard to the resource addressed. I am not happy with that response and need to come back on it. Until we have sorted the semantics of the URN used in ecall, it is impossible to say whether those are also applicable to carcrash, and vice versa.

Regards

Keith

-----Original Message-----
From: EXT Randall Gellens [mailto:[email-masked]] 
Sent: 21 April 2016 15:50
To: Drage, Keith (Nokia - GB); EXT Roger Marshall; [email-masked]
Cc: Ben Campbell ([email-masked])
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi Keith,

--Randy

-------------- Randomly selected tag: ---------------
    Freddie Laker

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Apr 2016 14:03:14 +0000

It seems to me that you would need a data path well beyond a SIP path for that kind of thing.  I’m not even sure a SUB/NOT is the right way to do that.
You might then pass the service point URI in Additional Data, but the negotiation of the transfer should be completely outside SIP.

Since it’s not real time, it’s not even an RTP thing, or, I suspect, even an SDP thing.  Just pass an HTTPS URI and define a new protocol.  If we have IP end to end, then use it.

Brian

> On Apr 21, 2016, at 8:30 PM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Apr 2016 14:36:26 +0000

Hi,

>Since it’s not real time, it’s not even an RTP thing, or, I suspect, even an SDP thing.  Just pass an HTTPS URI and define a new protocol.  If we have IP end to end, then use it.

You can negotiate other types of media/data channels than RTP/real-time with SDP.

I agree that SUB/NOT doesn't solve anything. And, as you need to send data in both directions, you'd have to create subscriptions (all of which have to be separate dialogs) in both directions, and then somehow associate them. 

Regards,

Christer

>> transfers tend to grown, and the cars are getting more and more intelligent.
>> 
>> Kind regards
>> 
>> Ivo Sedlacek
>> 
>>>> is using INFO as a pure tunnel mechanism, which is not the case.  
>>>> The debate over INFO responses mixes up the context of protocols 
>>>> which use INFO as a tunnel/transport mechanism with the case here, 
>>>> which carries information intrinsic to the emergency call.
>>>> 
>>>> 
>>>>>   From: Ecrit

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2016 11:14:54 -0400

> I agree that SUB/NOT doesn't solve anything. And, as you need to send data in both directions, you'd have to create subscriptions (all of which have to be separate dialogs) in both directions, and…

If there is video, then another RTP channel could be used to transfer 
it, or it could be transferred as a file.

For other stuff, MSRP and data channels are possibilities.

So there are lots of options.

But an INFO package seems ok to me for the little stuff that didn't go 
in the INVITE as additional data. But at that point I think it would be 
best to use INFO as intended, with INFO messages in both directions if 
needed.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Apr 2016 15:17:18 +0000

A data channel negotiated in SDP?  For this?

Please.  If we need a new protocol, because we’re bending SIP too much, let’s design a new protocol.  These are not some power sensitive, size sensitive devices.  It’s a fully connected vehicle.  We are quite capable of designing an appropriate protocol for this kind of data, and SDP negotiation isn’t appropriate.  If we’re past SIP, we’re past SIP.  And past SDP offer/answer.

I don’t think the possibility of needing a new protocol for data way beyond what we’ve considered so far for Additional Data is  bad idea, or obviates what Additional Data does now.  I’m happy to start discussion of such a thing, but please we need to get this simple stuff done now.

You are thinking camera video from a car.   Consider active building data, or security camera pan/tilt/zoom, or controlling an elevator, or medical sensor data.  All related to an emergency call, all beyond SIP, all bigger than passing in a body would be appropriate for.  

It’s not just vehicle telematics.

Very much in scope for ecrit.   Probably beyond 3GPP scope, but that’s not for me to say.

But a data channel negotiated in SDP over a SIP connection?  Really?  Look at it this way - establishing or taking down such a connection is not, at all related to establishing or taking down the SIP connection.  The two sessions are related, sure, but they don’t go up and down at the same time.  The SIP session is for the real time media to between the humans.  The stuff we’re talking about is machine to machine, possibly viewed real time or non-real time by one end (it’s streaming, RTSP stuff).

Brian

> On Apr 22, 2016, at 10:36 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2016 11:52:14 -0400

> But a data channel negotiated in SDP over a SIP connection?  Really?  Look at it this way - establishing or taking down such a connection is not, at all related to establishing or taking down the S…

I'm just a kibitzer here - I don't really understand the details of the 
use cases, and am just responding to the discussion.

But from what I have read, there are real differences of opinion about 
how this stuff should work. It seems the Europeans think it is important 
for there to be a real-time channel to the car, for use by the humans 
there. And all the other stuff is somehow associated with that.

OTOH, I gather from what you have said, that the US considers those to 
be separate things. So the car (or whatever) might want to report stuff 
without establishing a real-time channel.

Those differences either need to be reconciled, or else they may well 
lead to different mechanisms.

	Thanks,
	Paul

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Apr 2016 16:36:29 +0000

Well, yes, we thing the “Additional Data” might come with a real time media session and it might not.

Consider a medical device worn all the time.  It COULD have a media channel available, but many would not.

Regardless of whether there is media or not., there is an emergency “call”, which has to be routed by LoST and has all the usual sippish things.

The data (“Additional Data”) applies to both “calls” with media and without media.  In most cases, it’s pretty small, and can reasonably be carried in a body.  In other cases, it’s large, but it’s pretty static or has no back channel (it’s read-only), so you can pass a URI in the SIP signaling and then retrieve the data by reference to the URI.

What we’re talking about here is something even more complex, where we might need something more interactive between the device making the emergency call and the PSAP or responder.  This isn’t simple static data retrieved with a body or a URI dereference.  It actually needs some two way interaction.  I think that’s a new protocol.

Sometimes, we get some claims that even though we have a pretty beefy vehicle mounted system, and an IP end to end, we can’t handle the vehicle end being a server.  So some argue that you can’t just pass an RTSP URI that points to the vehicle system.  I think that is going to rapidly become an unsustainable argument, but today, the existing cell networks pretty much won’t let the UE be any kind of server.  The question that gives us is how many work arounds will we need to engineer to allow server like functionality where they just won’t let the UE be a server?

I do think that we have a range of devices that will have this kind of two way interaction, and a new protocol might be appropriate.  We’d need some scope discussions.

I’ve participated in a similar effort several years ago around smart buildings, which had a lot of similarities to the issues being raised here. 

Brian

> On Apr 22, 2016, at 11:52 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> I'm just a kibitzer here - I don't really understand the details of the use cases, and am just responding to the discussion.
> 
> But from what I have read, there are real differences of opinion about how this stuff should work. It seems the Europeans think it is important for there to be a real-time channel to the car, for use by the humans there. And all the other stuff is somehow associated with that.
> 
> OTOH, I gather from what you have said, that the US considers those to be separate things. So the car (or whatever) might want to report stuff without establishing a real-time channel.
> 
> Those differences either need to be reconciled, or else they may well lead to different mechanisms.
> 
> 	Thanks,
> 	Paul
> 
>> Brian
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Apr 2016 20:21:58 +0000

Hi,

>Please.  If we need a new protocol, because we’re bending SIP too much, let’s design a new protocol. 

As Paul mentioned, you could e.g. use MSRP. No need to define a new protocol, only the structure carrying the information (which you have to do no matter what mechanism you use).

>These are not some power sensitive, size sensitive devices.  It’s a fully connected vehicle. 

It's not only about the devices (read: endpoints). There is also a network.

>We are quite capable of designing an appropriate protocol for this kind of data, and SDP negotiation isn’t appropriate.  If we’re past SIP, we’re past SIP.  And past SDP offer/answer.

I thought the draft defines eCall for SIP.

>I don’t think the possibility of needing a new protocol for data way beyond what we’ve considered so far for Additional Data is  bad idea, or obviates what Additional Data does now.  I’m happy to start >discussion of such a thing, but please we need to get this simple stuff done now.

There are ready mechanisms that can be used.

>You are thinking camera video from a car.   Consider active building data, or security camera pan/tilt/zoom, or controlling 
>an elevator, or medical sensor data.  All related to an emergency call, all beyond SIP, all bigger than passing in a body would be appropriate for.  
>
>But a data channel negotiated in SDP over a SIP connection?  Really?  Look at it this way - establishing or taking down such a connection is not, at all related to establishing or taking down the SIP >connection.  The two sessions are related, sure, but they don’t go up and down at the same time.  The SIP session is for the real time media to between the humans.  The stuff we’re talking about is >machine to machine, possibly viewed real time or non-real time by one end (it’s streaming, RTSP stuff).

I don't follow. You need a SIP session to send INFOs too, and those INFOs will me mid-dialog/session SIP messages.

And, e.g. MSRP, which is negotiated using SDP, is not considered real-time, AFAIK.

Regards,

Christer

>>>>> The argument seems silly to me.  If the draft uses re-INVITE, 
>>>>> there would be no issue.  I suspect the problem may be that the 
>>>>> draft registers an INFO package, which invites implication that 
>>>>> the draft is using INFO as a pure tunnel mechanism, which is not the case.

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 23 Apr 2016 17:06:08 +0000

I don’t think MSRP is at all appropriate to send large quantity of data between a device and a PSAP.  

I think that if a session has media, then SIP is an appropriate protocol to establish the session, and if there is data related to the call, then it’s appropriate to pass small quantity of such data in the SIP headers or bodies.

Once you get beyond a small amount of data, I think SIP is not appropriate.  You can pass some data, like a URI, that could be used to establish some other kind of data connection in SIP, again, assuming the data is related to the call.  Here it really is related, not directly tied to the call. 

AFAIK, we don’t consider networks, even mobile networks, to be power sensitive or size sensitive.  We’re often asked to bend common sense to accommodate small battery operated mobile devices because of their limitations.  Those are usually not network limitations, they are end device limitations.  I don’t think we have those issues here.  You could imagine other devices, like a small medical sensor, that could have such limitations, so I think some consideration of those issues is appropriate, but they don’t apply to vehicle telematics.

The draft does define eCall for SIP, and provides ways to transfer a small amount of data in SIP headers or bodies.  I think that is fine.  When we start suggesting we use these mechanisms for one way streaming video, then I think we’re probably beyond what this draft attempts to do.  I think accommodating large quantities of data related to an emergency call is useful, and I’d like a solution, but I don’t think this draft should do that, and I think such data transfer isn’t something you do in SIP.  I don’t mind passing info that could be used to establish some other session for such data, as long as the data is related to the emergency call,using the mechanisms described in the draft.  

I don’t think establishing an MSRP session is useful unless there is text being exchanged between the caller and the PSAP.  I certainly would object to using MSRP as a generic data transport mechanism.

Brian

> On Apr 22, 2016, at 4:21 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Apr 2016 17:34:49 +0000

Hi,

> I don’t think MSRP is at all appropriate to send large quantity of data between a device and a PSAP.  

It is more appropriate than using INFO - or any other SIP method.

> I think that if a session has media, then SIP is an appropriate protocol to establish the session, 

The scope is SIP, so you are going to establish a SIP session no matter if there is media or not.

>and if there is data related to the call, then it’s appropriate to pass small quantity of such data in the SIP headers or bodies.

In general I agree.

However, if we know that such small quantity one day may become large quantity, we should take that into consideration when defining the mechanism for transporting the data.

> Once you get beyond a small amount of data, I think SIP is not appropriate.
> You can pass some data, like a URI, that could be used to establish some other kind of data connection in SIP, again, assuming 
> the data is related to the call.  Here it really is related, not directly tied to the call. 
>
> AFAIK, we don’t consider networks, even mobile networks, to be power sensitive or size sensitive.  We’re often asked to 
> bend common sense to accommodate small battery operated mobile devices because of their limitations.  Those are 
> usually not network limitations, they are end device limitations.  I don’t think we have those issues here.  You could 
> imagine other devices, like a small medical sensor, that could have such limitations, so I think some consideration of 
> those issues is appropriate, but they don’t apply to vehicle telematics.
>
> The draft does define eCall for SIP, and provides ways to transfer a small amount of data in SIP headers or bodies. 
> I think that is fine.  When we start suggesting we use these mechanisms for one way streaming video, then I think 
> we’re probably beyond what this draft attempts to do.  I think accommodating large quantities of data related to 
> an emergency call is useful, and I’d like a solution, but I don’t think this draft should do that, and I think such data 
> transfer isn’t something you do in SIP.  I don’t mind passing info that could be used to establish some other session 
> for such data, as long as the data is related to the emergency call,using the mechanisms described in the draft.  

While I agree with you, the draft does not limit the amount of data that can be transported, and does not define how much data is "too much".

> I don’t think establishing an MSRP session is useful unless there is text being exchanged between the caller and 
> the PSAP.  I certainly would object to using MSRP as a generic data transport mechanism.

I don't think anyone has suggested to use MSRP for media (read: audio and video).

Regards,

Christer

>>>>>> which use INFO as a tunnel/transport mechanism with the case 
>>>>>> here, which carries information intrinsic to the emergency call.
>>>>>> 
>>>>>> 
>>>>>>> From: Ecrit
>>>>>>> in  the room & the chairs action to confirm consensus on the 
>>>>>>> list to  progress both ID's, draft-ietf-ecrit-car-crash-07 &
>>>>>>> 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: --------------- It wasn't 
>>>>>> as easy to get programs right as we had thought.
>>>>>>                                          --Wilkes, 1949
>>>> 
>>>> 
>>>> --
>>>> Randall Gellens

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Apr 2016 14:00:10 -0400

> I don’t think establishing an MSRP session is useful unless there is text being exchanged between the caller and the PSAP.  I certainly would object to using MSRP as a generic data transport mechan…

What about RFC5547: file transfer over MSRP?

	Thanks,
	Paul

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 25 Apr 2016 06:59:58 +0000

> AFAIK, we don’t consider networks, even mobile networks, to be power sensitive or >>>size sensitive<<<.  

Be aware that RFC3261 defines 513 response:
------------------------------------
21.5.7 513 Message Too Large

   The server was unable to process the request since the message length
   exceeded its capabilities.
------------------------------------

This response can also be sent by a SIP network entity if a SIP request (e.g. SIP INFO with an additional data) is too large for it. Such rejection is particularly likely if the SIP network entity is optimized for regular sizes of SIP signalling for sesson setup, modification and release.

Kind regards

Ivo Sedlacek

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 25 Apr 2016 13:09:52 +0000

Yes, that is helpful, and I would not object to a statement in both drafts that the mechanisms are intended for small amounts of data and the server can reject whatever it considers too big using 513.

Brian

> On Apr 25, 2016, at 2:59 AM, Ivo Sedlacek <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Apr 2016 13:16:28 +0000

Hi,

>Yes, that is helpful, and I would not object to a statement in both
>drafts that the mechanisms are intended for small amounts of data and the
>server can reject whatever it considers too big using 513.

That¹s why we should have a solution from day one that can also handle big
amounts of data - whatever the definition of "big amount" is.

Regards,

Christer

>>> AFAIK, we don¹t consider networks, even mobile networks, to be power
>>>sensitive or >>>size sensitive<<<.
>> 
>> This response can also be sent by a SIP network entity if a SIP request
>>(e.g. SIP INFO with an additional data) is too large for it. Such
>>rejection is particularly likely if the SIP network entity is optimized
>>for regular sizes of SIP signalling for sesson setup, modification and
>>release.
>> 
>> Kind regards
>> 
>> Ivo Sedlacek
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 25 Apr 2016 09:59:10 -0700

The ecall draft says:

    Note that if additional data sets are defined and registered (e.g.,
    in the future or in other regions) and transmitted using the same
    mechanisms, the size and frequency of transmission during a session
    needs to be evaluated to be sure it is appropriate to use the
    signaling channel.

The additional-data drafts says:

    Transmitting data by value is especially useful in certain cases,
    such as when the data exists in or is generated by the originating
    device, but is not intended for very large data blocks.

At 1:09 PM +0000 4/25/16, Brian Rosen wrote:

> drafts that the mechanisms are intended for small amounts of data 
> and the server can reject whatever it considers too big using 513.
>
>  Brian
>
>>>  AFAIK, we don't consider networks, even mobile networks, to be 
>>> power sensitive or >>>size sensitive<<<. 
>>
>>  This response can also be sent by a SIP network entity if a SIP 
>> request (e.g. SIP INFO with an additional data) is too large for 
>> it. Such rejection is particularly likely if the SIP network 
>> entity is optimized for regular sizes of SIP signalling for sesson 
>> setup, modification and release.
>>
>>  Kind regards
>>
>>  Ivo Sedlacek
>

-------------- Randomly selected tag: ---------------
But, something that only exists in thought is even better, as
you can read for yourself in my favorite book of (English)
verse and drawings, "The Space-Child's Mother Goose" (Verses
by Frederick Winsor, Illustrations by Marian Parry, Simon and
Schuster, 1958, unfortunately out of print):
    I have a pet hen whose name is Probable. She lays eggs in
    concept, being a sophist bird.  But not in reality at all;
    those would be inferior eggs; for thought is superior to
    reality.
--unknown

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 26 Apr 2016 13:22:37 +0000

Essentially we have 3 mechanism we could look at:

1)	Carried in SIP signaling message, such as for example using INFO.

2)	Making use of SIP as the rendezvous protocol and using SDP to indicate some media that can carry the information.

3)	Using some fields within SIP to carry information that might be used by another protocol, independent of the SIP rendezvous capabilities.

All of these have specific characteristics which have been discussed by IETF in the past, such as for example the appropriateness for carrying data, the impact of firewalls, etc. 

Moreover when we talk ecall (as a 3GPP emergency call) being carried over a 3GPP access, they have additional specific characteristics.

In 3GPP both 2) and 3) are used for file transfer in normal calls, eg. When specified by RCS. Preference or permission for one or the other seems to be based on charging models applied by the mobile operators concerned, and has a geographic divide as well.

SIP signaling is carried using a specific QoS (QCI=5), and when made as an emergency call, gets a special quality bearer on the radio access. That specific QoS is tailored to signaling packets, specifically the SIP signaling ones used in IMS.

Using media negotiated by SDP, means that internal control of PCC applies, which means that an emergency bearer can be used for the media, and an appropriate QCI value can be applied by the network, which for non-real-time data might well be QCI=6 or QCI=8.

Using media not negotiated by SDP means there is no link between the emergency call and the required media in IMS. Therefore no emergency bearer, and probably internet quality QCI, something like QCI=3.

See table 6.1.7 of 3GPP Specification 23.203 for details of these QCI values.

http://www.3gpp.org/DynaReport/23203.htm

regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Christer Holmberg
Sent: 23 April 2016 18:35
To: Rosen, Brian
Cc: Ben Campbell ([email-masked]); [email-masked]
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Hi,

In general I agree.

> You can pass some data, like a URI, that could be used to establish 
> some other kind of data connection in SIP, again, assuming the data is related to the call.  Here it really is related, not directly tied to the call.
>
> AFAIK, we don’t consider networks, even mobile networks, to be power 
> sensitive or size sensitive.  We’re often asked to bend common sense 
> to accommodate small battery operated mobile devices because of their 
> limitations.  Those are usually not network limitations, they are end 
> device limitations.  I don’t think we have those issues here.  You could imagine other devices, like a small medical sensor, that could have such limitations, so I think some consideration of those issues is appropriate, but they don’t apply to vehicle telematics.
>
> I think that is fine.  When we start suggesting we use these 
> mechanisms for one way streaming video, then I think we’re probably 
> beyond what this draft attempts to do.  I think accommodating large 
> quantities of data related to an emergency call is useful, and I’d 
> like a solution, but I don’t think this draft should do that, and I think such data transfer isn’t something you do in SIP.  I don’t mind passing info that could be used to establish some other session for such data, as long as the data is related to the emergency call,using the mechanisms described in the draft.

> I don’t think establishing an MSRP session is useful unless there is 
> text being exchanged between the caller and the PSAP.  I certainly would object to using MSRP as a generic data transport mechanism.

Regards,

Christer

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 26 Apr 2016 13:22:44 +0000

Just to be very clear, for ecall, it is an emergency call in IMS and as such, there is always a conversational media channel present. For automatically generated ecall, the calling user might not be in a position to use it, but it is there.

(In the current CS implementation it can automatically swap between modem type data transmission and voice)

Regards

Keith

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of EXT Rosen, Brian
Sent: 22 April 2016 17:36
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

Brian

>>>>> 2) on "to transport small amounts of data that are intrinsic to 
>>>>> the call" - how can we be sure that the amounts of data that are 
>>>>> This is not what I am saying.  I am saying that the context of 
>>>>> this draft is different from the general case where INFO is used 
>>>>> as a tunnel mechanism for a protocol that just happens to use SIP 
>>>>> as transport.  In the case here, we're using SIP as a way to 
>>>>> establish emergency calls, and to transport small amounts of data 
>>>>> that are intrinsic to the call.  Different contexts.
>>>>> 
>>>>> --Randy
>>>>> 
>>>>>> 
>>>>>>>> responses  (which is not related to the sync with other SDOs) 
>>>>>>>> in draft-ietf-ecrit-ecall.
>>>>>>> 
>>>>>>>>  During our meeting in BA, the posted notes reflect the 
>>>>>>>> agreement in  the room & the chairs action to confirm consensus 
>>>>>>>> on the list to  progress both ID's, 
>>>>>>>> draft-ietf-ecrit-car-crash-07 &