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

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

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:[e-mail]] On Behalf Of EXT Rosen, Brian
Sent: 22 April 2016 17:36
To: Paul Kyzivat
Cc: [e-mail]
Subject: Re: [Ecrit] since BA, confirming draft-ietf-ecrit-car-crash-07 and draft-ietf-ecrit-ecall-07

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 <[e-mail]> wrote:
> 
> On 4/22/16 11:17 AM, Rosen, Brian wrote:
>> 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).
> 
> 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
>> 
>>> On Apr 22, 2016, at 10:36 AM, Christer Holmberg <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>>> 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.
>>> 
>>> 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
>>> 
>>> 
>>> 
>>>> On Apr 21, 2016, at 8:30 PM, Drage, Keith (Nokia - GB) <[e-mail]> wrote:
>>>> 
>>>> 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:[e-mail]] On Behalf Of EXT 
>>>> Randall Gellens
>>>> Sent: 21 April 2016 16:57
>>>> To: Ivo Sedlacek; Christer Holmberg; Roger Marshall; [e-mail]
>>>> Cc: Ben Campbell ([e-mail])
>>>> 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:
>>>> 
>>>>> 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:[e-mail]] On Behalf Of Randall 
>>>>> Gellens
>>>>> Sent: Thursday, April 21, 2016 4:57 PM
>>>>> To: Christer Holmberg; Randall Gellens; Roger Marshall; 
>>>>> [e-mail]
>>>>> Cc: Ben Campbell ([e-mail])
>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 21/04/16 16:42, "Randall Gellens" <[e-mail]> wrote:
>>>>>> 
>>>>>>> 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:[e-mail]>[e-mail]>
>>>>>>>> on behalf of Roger Marshall
>>>>>>>> <<mailto:[e-mail]>Roger.Marshall@comtechte
>>>>>>>> l.com>
>>>>>>>>  Date: Thursday 21 April 2016 at 07:13
>>>>>>>>  To: "<mailto:[e-mail]>[e-mail]"
>>>>>>>> <<mailto:[e-mail]>[e-mail]>
>>>>>>>>  Cc: Ben Campbell <<mailto:[e-mail]>[e-mail]>
>>>>>>>>  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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  _______________________________________________
>>>>>>>>  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: --------------- 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
>>>>> 
>>>>> _______________________________________________
>>>>> 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: --------------- A successful tool is used to do something undreamed of by its author.
>>>>                                                          --Johnson
>>>> 
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>> 
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>> 
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> 
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit

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