Subject: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests?

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 11:37:34 +0000

Hi,

draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a vehicle to the PSAP (or in the other direction), is considered "additional data" carried in SIP requests. I think there may be issues with such approach.

For example, the vehicle may be requested to send picture(s). Sending those on the signaling plane could create very large SIP requests.

Also, the vehicle may be requested to provide lots of sensor data etc. Sending that on the signaling plane could create a very large number of SIP requests.

Finally, the draft seems to assume that data can be sent also in INFO responses - which is not correct. Data can only be carried in INFO requests, and because of that the number of SIP messages could double in the worst case scenario.

So, I don't think we can consider everything sent from the vehicle to the PSAP as "additional data" carried in SIP requests, as it would very likely cause issues in the network.

(Yes, I know data can also be provided e.g. by providing a URL, but I am not sure whether that will actually work - enabling the UA to send IP packets to the PSAP could open an opportunity for attacks on the PSAP).

Regards,

Christer

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Dec 2014 14:24:07 +0000

I do agree that when there is a lot of data, we want to send URIs, and let the PSAP pull the data over HTTP.  I believe we can do that with this mechanism.

The same problem occurs in data related to a location.  One might have surveillance video available, for example.  The answer is the same, send it via URI.

The document does not provide guidance on this point, and maybe it should.

Brian

> On Dec 11, 2014, at 6:37 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Dec 2014 09:19:32 -0800

Hi Christer,

The document builds on existing emergency calling, and hence does not 
specify non-eCall aspects, such as media, since those are already 
addressed in the underlying documents.  As you know, those existing 
emergency calling documents currently cover streaming media, but not 
non-streaming media such as pictures or video clips.  There is work 
going on is some SDOs to address how non-streaming media will be 
carried in an emergency call.  I think everyone involved can easily 
see that such media will be carried using existing mechanisms, most 
likely as file attachments using MSRP.  There is no intent for the 
eCall document to specify its own mechanism for transferring 
non-streaming media (and it would be quite silly dor it to do so).

At 11:37 AM +0000 12/11/14, Christer Holmberg wrote:

>  Hi,
>
>  draft-ietf-ecrit-ecall seems to assume that, whatever is sent from 
> a vehicle to the PSAP (or in the other direction), is considered 
> "additional data" carried in SIP requests. I think there may be 
> issues with such approach.
>
>  For example, the vehicle may be requested to send picture(s). 
> Sending those on the signaling plane could create very large SIP 
> requests.
>
>  Also, the vehicle may be requested to provide lots of sensor data 
> etc. Sending that on the signaling plane could create a very large 
> number of SIP requests.
>
>  Finally, the draft seems to assume that data can be sent also in 
> INFO responses - which is not correct. Data can only be carried in 
> INFO requests, and because of that the number of SIP messages could 
> double in the worst case scenario.
>
>  So, I don't think we can consider everything sent from the vehicle 
> to the PSAP as "additional data" carried in SIP requests, as it 
> would very likely cause issues in the network.
>
>  (Yes, I know data can also be provided e.g. by providing a URL, but 
> I am not sure whether that will actually work - enabling the UA to 
> send IP packets to the PSAP could open an opportunity for attacks 
> on the PSAP).
>
>  Regards,
>
>  Christer
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Nearly all men can stand adversity, but if you want to test a
man's character, give him power.            --Abraham Lincoln

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 17:51:55 +0000

Hi Randall,

>The document builds on existing emergency calling, and hence does not specify non-eCall aspects, such as media, since those are already addressed in the underlying >documents.  As you know, those existing emergency calling documents currently cover streaming media, but not non-streaming media such as pictures or video clips.  >There is work going on is some SDOs to address how non-streaming media will be carried in an emergency call.  I think everyone involved can easily see that such media will >be carried using existing mechanisms, most likely as file attachments using MSRP.  There is no intent for the eCall document to specify its own mechanism for transferring >non-streaming media (and it would be quite silly dor it to do so).

My thinking has been that other SDOs should be able to reference this document, and that it would include a mechanism on how to transport non-streaming media.

Currently the draft gives a picture that everything is carried in SIP - so it should at least state that media plane mechanisms can also be used.

Regards,

Christer

At 11:37 AM +0000 12/11/14, Christer Holmberg wrote:

>  Hi,
>
>  draft-ietf-ecrit-ecall seems to assume that, whatever is sent from a 
> vehicle to the PSAP (or in the other direction), is considered 
> "additional data" carried in SIP requests. I think there may be issues 
> with such approach.
>
>  Finally, the draft seems to assume that data can be sent also in INFO 
> responses - which is not correct. Data can only be carried in INFO 
> requests, and because of that the number of SIP messages could double 
> in the worst case scenario.
>
>  So, I don't think we can consider everything sent from the vehicle to 
> the PSAP as "additional data" carried in SIP requests, as it would 
> very likely cause issues in the network.
>
>  (Yes, I know data can also be provided e.g. by providing a URL, but I 
> am not sure whether that will actually work - enabling the UA to send 
> IP packets to the PSAP could open an opportunity for attacks on the 
> PSAP).
>
>  Regards,
>
>  Christer
>

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Nearly all men can stand adversity, but if you want to test a
man's character, give him power.            --Abraham Lincoln

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 17:56:10 +0000

Hi Brian,

> The document does not provide guidance on this point, and maybe it should.

I think there are issues with providing a URI, and sending data over HTTP.

- If the PSAP provides a URI to the UA for fetching data, the URI could open possibilities for attacks on the PSAP.
- If the UA provides a URI to the PSAP for fetching data, the URI could result in privacy issues. Also, there may be NAT related issues when the PSAP tries to connect to the UA.

I think a media plane mechanism should be considered for transporting big- and/or frequent data (pictures, sensor data, etc).

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Thu, 11 Dec 2014 10:03:55 -0800

Hi Christer,

At 5:51 PM +0000 12/11/14, Christer Holmberg wrote:

>>   >The document builds on existing emergency calling, and hence 
>> does not specify non-eCall aspects, such as media, since those are 
>> already addressed in the underlying >documents.  As you know, 
>> those existing emergency calling documents currently cover 
>> streaming media, but not non-streaming media such as pictures or 
>> video clips.  >There is work going on is some SDOs to address how 
>> non-streaming media will be carried in an emergency call.  I think 
>> everyone involved can easily see that such media will >be carried 
>> using existing mechanisms, most likely as file attachments using 
>> MSRP.  There is no intent for the eCall document to specify its 
>> own mechanism for transferring >non-streaming media (and it would 
>> be quite silly dor it to do so).

>  My thinking has been that other SDOs should be able to reference 
> this document, and that it would include a mechanism on how to 
> transport non-streaming media.

Of course other SDOs should be able to reference this document, but 
common mechanisms (that are usable in all forms of emergency calls) 
should be in their respective documents and included by reference 
here.  This goes for both streaming and non-streaming media, since 
those are or will be common to all emergency calls.

>  Currently the draft gives a picture that everything is carried in 
> SIP - so it should at least state that media plane mechanisms can 
> also be used.

I'm happy to include some explanatory text to this effect.  I 
certainly don't want the document to give the wrong impression that 
media will be carried in the signaling plane!

>  -------------- Randomly selected tag: --------------- Nearly all 
> men can stand adversity, but if you want to test a

-------------- Randomly selected tag: ---------------
C++ is pronounced "C cross cross."  Not one but two crosses to bear: C
and a broken interpretation of object-orientation.

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 11 Dec 2014 18:07:25 +0000

>
>- If the PSAP provides a URI to the UA for fetching data, the URI could
>open possibilities for attacks on the PSAP.
That is correct, but the possibilities for pushing huge data to the PSAP
without the PSAP being able to throttle it effectively are worse.  In
fact, I think we could reasonably put an upper bound on the size of data
and tell the PSAP they can ignore it if it¹s bigger than that.

Now, for well known service providers, the SP can make this reasonable
itself.  But then, for well known service providers, there is no security
problem with a fetch.

All-in-all, I¹d prefer an HTTP fetch to a data or control plane push for
large content with respect to security issues

>- If the UA provides a URI to the PSAP for fetching data, the URI could
>result in privacy issues. Also, there may be NAT related issues when the
>PSAP tries to connect to the UA.
I do not see any privacy issues.  For one thing, privacy expectations are
significantly lower in emergency calls (by statute in many jurisdictions).
 PSAPs will need credentials for any form of security.  In North America,
we have a reasonable PKI worked out and we have some commitments to start
deployment of it.  The credentials can be used to make sure only
authorized entities have access to the data.  The URI should be some
ephemeral id, so an attacker would need to observe the signaling to get
it.  But then, if the attacker can observe the signaling, it can observe a
push.

Doing something in the data plane would be something along the lines of
MSRP file.  Not really opposed to that.

Brian

---

From: Andrew Allen <[email-masked]>
Date: Thu, 11 Dec 2014 18:28:52 +0000

Isn't this the media plane negotiation and setup mechanism for transferring a file when using SIP?

http://www.rfc-editor.org/rfc/rfc5547.txt

Or am I missing something?

Andrew

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, December 11, 2014 12:56 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests?

Hi Brian,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Dec 2014 18:34:52 +0000

Hi,

>Or am I missing something?

I didn't suggest that we would need to define a new mechanism for transferring data.

My issue was that, the way I read the ecall draft, it only "allows" data transfer using SIP. But, Randall has indicated that is not the intention.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, December 11, 2014 12:56 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ecall: considering everything "additional data" carried in SIP requests?

Hi Brian,

Regards,

Christer

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 12 Dec 2014 07:31:27 +0000

Hello,

> >result in privacy issues. Also, there may be NAT related issues when 
> >the PSAP tries to connect to the UA.
>
>  PSAPs will need credentials for any form of security.  In North America, we 
> have a reasonable PKI worked out and we have some commitments to start 
> deployment of it.  The credentials can be used to make sure only authorized 
> entities have access to the data.  The URI should be some ephemeral id, so an 
> attacker would need to observe the signaling to get it.  But then, if the 
> attacker can observe the signaling, it can observe a push.

The identified privacy issue:
- a  famous person is hurt in car accident.
- the car provides a URI at which photo of the hurt person can be fetched.

It is perfectly OK for PSAP personnel to fetch the photo at the URI.

However, non-PSAP personnel, if they happen to get the URI, should not be able to fetch the photo at the URI.

Kind regards

Ivo Sedlacek

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 12 Dec 2014 07:50:58 +0000

Hello,

> The document builds on existing emergency calling, and hence does not specify 
> non-eCall aspects, such as media, since those are already addressed in the 
> underlying documents.  As you know, those existing emergency calling 
> documents currently cover streaming media, but not non-streaming media such 
> as pictures or video clips.  There is work going on is some SDOs to address 
> how non-streaming media will be carried in an emergency call.  I think 
> everyone involved can easily see that such media will be carried using 
> existing mechanisms, most likely as file attachments using MSRP.  There is no 
> intent for the eCall document to specify its own mechanism for transferring 

Let's assume PSAP sends a request for a photo to be taken by a car camera (e.g. in SIP INFO as in I-D-ietf-ecrit-ecall-01).

Let's assume the car sends the actual photo to PSAP using a media stream (e.g. MSRP media stream as suggested above).

The PSAP knows that an MSRP media stream is negotiated in the emergency call and that the MSRP message carrying the actual photo is sent within that MSRP media stream. 

However, there needs to be a mechanism enabling the PSAP personnel to associate the actual photo (sent via the MSRP media stream) with the request for the photo (sent via the SIP INFO). This does not seem to be possible today.

Kind regards

Ivo Sedlacek

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 09:17:18 +0100

Ivo,

I don't know whether it matters but I have doubts that a photo will be
sent as a media stream. When you talk about a photo I guess you actually
don't mean a photo but rather to enable a webcam.

Ciao
Hannes

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 12 Dec 2014 08:46:32 +0000

Hello,

> sent as a media stream. When you talk about a photo I guess you 
> actually don't mean a photo but rather to enable a webcam.

draft-ietf-ecrit-ecall-01 states:
------------------
   NG-eCall is expected to offer:
...
   o  The ability for the PSAP to access vehicle components (e.g., an
      onboard camera (such as rear facing or blind-spot cameras) for a
      visual assessment of the crash site situation)
....
------------------

I can imagine that PSAP will be interested in both photos and video media stream. 

Photos normally have higher resolution than video media stream.

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 08:53:37 +0000

Hi,

>Doing something in the data plane would be something along the lines of MSRP file.  Not really opposed to that.

MSRP seems to be what most people have been talking about, and assumed that will be used.

However, now we also have the data channel, defined in rtcweb. I am not saying that would be a better solution, but perhaps something to look into :)

Regards.

Christer

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 09:57:37 +0100

Hi Ivo,

I fully agree that it is useful to send pictures and videos around but
the mechanisms for doing so might be different.

For the video I could imagine that the PSAP sends updates the existing
session using an INVITE while a file transfer is most likely done
differently.

Ciao
Hannes

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 10:12:51 +0000

Hi,

>I fully agree that it is useful to send pictures and videos around but the mechanisms for doing so might be different.
>
>For the video I could imagine that the PSAP sends updates the existing session using an INVITE while a file transfer is most likely done differently.

That is true. I assume "traditional" real-time audio/video very likely be sent using RTP.

But, the issue has not been on the specific protocols, but more about not having to send big data on the signaling plane, and to be able to use *some* media plane mechanism instead.

Regards,

Christer

On 12/12/2014 09:46 AM, Ivo Sedlacek wrote:
> Hello,
> 
>> I don't know whether it matters but I have doubts that a photo will 
>> be sent as a media stream. When you talk about a photo I guess you 
>       visual assessment of the crash site situation) ....
> ------------------
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 11:16:40 +0100

Hi Christer,

the use of the additional data draft in the context of the ecall draft
does not mean that everything has to be sent in the signaling plane.
Nothing prevents the PSAP from using the ordinary SIP mechanisms.

Maybe I am just failing to see the problem.

Ciao
Hannes

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 10:30:37 +0000

Hi,

> the use of the additional data draft in the context of the ecall draft does not mean that everything has to be sent in the signaling plane.

And that has been clarified now :)

But, that is not how I read the draft, and I think Randall has also said that some clarification text will be added.

Regards,

Christer

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 12 Dec 2014 11:33:34 +0100

> But, that is not how I read the draft, and I think Randall has also said that some clarification text will be added.

Perfect. Issue solved!

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 17:31:41 +0000

Hi,

>> clarification text will be added.

So, while the draft can use SIP INFO as an example, it need to make it clear that the MSD, eCall-Specific Control/Metadata etc can also be transported using another mechanisms (media plane mechanisms).

If we don't want to define such mechanism(s) in the draft, it should be clear that it's up to other SDOs to define them.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Dec 2014 10:02:01 -0800

At 5:31 PM +0000 12/12/14, Christer Holmberg wrote:

>   >> But, that is not how I read the draft, and I think Randall has 
> also said that some
>>>  clarification text will be added.
>>
>>  Perfect. Issue solved!
>
>  So, while the draft can use SIP INFO as an example, it need to make 
> it clear that the MSD, eCall-Specific Control/Metadata etc can also 
> be transported using another mechanisms (media plane mechanisms).

We're all agreed that media should be transmitted via a media plane, 
not the signaling plane.  I can add a caution that excessively large 
sensor data should not be sent by value in the signaling plane.

-------------- Randomly selected tag: ---------------
Vous etes ici

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Dec 2014 10:15:36 -0800

At 7:50 AM +0000 12/12/14, Ivo Sedlacek wrote:

>  Let's assume PSAP sends a request for a photo to be taken by a car 
> camera (e.g. in SIP INFO as in I-D-ietf-ecrit-ecall-01).
>
>  Let's assume the car sends the actual photo to PSAP using a media 
> stream (e.g. MSRP media stream as suggested above).
>
>  The PSAP knows that an MSRP media stream is negotiated in the 
> emergency call and that the MSRP message carrying the actual photo 
> is sent within that MSRP media stream.
>
>  However, there needs to be a mechanism enabling the PSAP personnel 
> to associate the actual photo (sent via the MSRP media stream) with 
> the request for the photo (sent via the SIP INFO). This does not 
> seem to be possible today.

Why is this an IETF protocol issue rather than a client-side issue 
for the PSAP equipment?  PSAP equipment must log everything and 
associate information with an incident.  If the call taker requests a 
still image or a video stream, presumably the media must be 
associated with the call (the incident ID) and archived with other 
media and other data.

-------------- Randomly selected tag: ---------------
Lansing Residents Can Drop Off Trees
--Newspaper headline

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Dec 2014 18:16:52 +0000

Hi,

>>> also said that some clarification text will be added.
>>>
>>>  Perfect. Issue solved!
>>
>> it clear that the MSD, eCall-Specific Control/Metadata etc can also be 
>> transported using another mechanisms (media plane mechanisms).
>
> We're all agreed that media should be transmitted via a media plane, not the signaling plane.  
> I can add a caution that excessively large sensor data should not be sent by value in the signaling plane.

I don't think we need to go into specifics, and it's not only about media. And, it's not only about size, but also frequency.

I think we should simply say that the the MSD, eCall-Specific Control/Metadata, media and data can also be sent using a media plane mechanism, and that each SDO needs to make a decision which mechanism to use, based on network characteristics, expected data/frequency, etc etc.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Dec 2014 10:20:08 -0800

>  draft-ietf-ecrit-ecall-01 states:

It's increasingly common that videos and still images have the same 
resolution (although in some cases the frames per second might be 
lower for higher resolution).  However, this is all besides the 
point.  The point of the discussion has since yesterday been agreed: 
I will add clarifying text to the eCall document to say that media is 
sent using a media plane and not the signaling plane.

-------------- Randomly selected tag: ---------------
Computers are useless.  They can only give you answers.
                            --Pablo Picasso (1881-1973)

---

From: Randall Gellens <[email-masked]>
Date: Fri, 12 Dec 2014 11:43:44 -0800

At 6:16 PM +0000 12/12/14, Christer Holmberg wrote:

>  I don't think we need to go into specifics, and it's not only about 
> media. And, it's not only about size, but also frequency.

The frequency shouldn't be an issue.  The eCall draft says that the 
IVS sends the MSD in the initial INVITE, and then on request of the 
PSAP.

>  I think we should simply say that the the MSD, eCall-Specific 
> Control/Metadata, media and data can also be sent using a media 
> plane mechanism, and that each SDO needs to make a decision which 
> mechanism to use, based on network characteristics, expected 
> data/frequency, etc etc.

I don't see a need to get into hypotheticals.  The eCall draft says 
how the MSD is sent using the ECRIT additional-data mechanism, which 
is the direction of ECRIT.  If in the future there is a need to 
define a mechanism to send emergency call related data using a media 
stream, let's work on the problem at that time.

-------------- Randomly selected tag: ---------------
Democracy is a government where you can say what you think even if you
don't think.                                       --Winston Churchill

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Dec 2014 10:21:18 +0000

Hi,

>>>>   So, while the draft can use SIP INFO as an example, it need to 
>>>> make  it clear that the MSD, eCall-Specific Control/Metadata etc can 
>>>> also be  transported using another mechanisms (media plane mechanisms).
>>>
>>> not the signaling plane.
> The frequency shouldn't be an issue.  The eCall draft says that the IVS sends the MSD in the initial INVITE, and then on request of the PSAP.

And, how often can those "request of the PSAP" occur?

Also, as the draft also indicates, the PSAP can request other kind of data ("an enhanced MSD or an MSD plus additional sets of data") from the UA. And, the more data that is available, the more often those requests may be sent by the PSAP.

So, it should be possible to send those requests, and the associated data, e.g. using a media plane mechanism.

Obviously, any data that is needed in order to route the INVITE to the correct PSAP in the first place needs to be sent in the INVITE.

>> Control/Metadata, media and data can also be sent using a media plane 
>> mechanism, and that each SDO needs to make a decision which mechanism 
>> to use, based on network characteristics, expected data/frequency, etc 
>> etc.
>
> I don't see a need to get into hypotheticals.  The eCall draft says how the MSD is sent using the ECRIT 
> additional-data mechanism, which is the direction of ECRIT.  If in the future there is a need to define a 
> mechanism to send emergency call related data using a media stream, let's work on the problem at that time.

Well, my comments are against the ecall draft, and are based on the potential problems I see in the future, in the type of networks that the draft targets.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sat, 13 Dec 2014 11:24:15 -0800

Hi Christer,

At 10:21 AM +0000 12/13/14, Christer Holmberg wrote:

>>  The frequency shouldn't be an issue.  The eCall draft says that 
>> the IVS sends the MSD in the initial INVITE, and then on request 
>> of the PSAP.
>

The frequency of request is obviously up to the PSAP, but the 
expectation is that these requests will be infrequent, especially 
over the duration of a call.

>  Also, as the draft also indicates, the PSAP can request other kind 
> of data ("an enhanced MSD or an MSD plus additional sets of data") 
> from the UA. And, the more data that is available, the more often 
> those requests may be sent by the PSAP.

It's unlikely that PSAPs will be requesting multiple data objects or 
doing so frequently.  More likely is that PSAPs may request an 
updated MSD if the call-taker thinks the vehicle state may have 
changed.  If in the future a more comprehensive set of data is 
standardized and used in Europe, PSAPs may request that form, but 
again the expectation is that this might occur once at the start of 
the call, and possibly again if the call-taker thinks the vehicle 
state may have changed.

>  So, it should be possible to send those requests, and the 
> associated data, e.g. using a media plane mechanism.

I don't see how this follows.

>
>  Obviously, any data that is needed in order to route the INVITE to 
> the correct PSAP in the first place needs to be sent in the INVITE.
>
>>  mechanism to send emergency call related data using a media 
>  Well, my comments are against the ecall draft, and are based on the 
> potential problems I see in the future, in the type of networks 
> that the draft targets.

If we identify a need to transmit data associated with an emergency 
call over a media plane, this should be done as an extension to the 
additional-data draft and then incorporated by reference into all 
documents that use additional-data.  Otherwise we risk creating 
multiple incompatible mechanisms.  However, I don't see any such need 
at this time.

-------------- Randomly selected tag: ---------------
yoin (yoh-EEN; Japanese; noun): experiential reverberation that
continues to move one long after the initial external stimulus
has ceased.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Dec 2014 20:26:32 +0000

Hi,

>>>>>>  make  it clear that the MSD, eCall-Specific Control/Metadata etc 
>>>>>> can  also be  transported using another mechanisms (media plane 
>>>>>> mechanisms).
>>>>>
>>>>   I don't think we need to go into specifics, and it's not only 
>>>> about  media. And, it's not only about size, but also frequency.
>>>
> The frequency of request is obviously up to the PSAP, but the expectation is that 
> these requests will be infrequent, especially over the duration of a call.

I think we should try to get some numbers, because it will make is easier to choose the appropriate mechanism.

>>  Also, as the draft also indicates, the PSAP can request other kind of 
>> data ("an enhanced MSD or an MSD plus additional sets of data") from 
>> the UA. And, the more data that is available, the more often those 
>> requests may be sent by the PSAP.
>
> It's unlikely that PSAPs will be requesting multiple data objects or doing so 
> frequently.  More likely is that PSAPs may request an updated MSD if the call-taker 
> thinks the vehicle state may have changed.
>
> If in the future a more comprehensive set of data is standardized and used in 
> Europe, PSAPs may request that form, but again the expectation is that this might 
> occur once at the start of the call, and possibly again if the call-taker thinks the 
> vehicle state may have changed.

I think it would be very useful to document those kind of things in the draft. Because, we should choose the mechanism based on technical grounds.

However, I assume eCall control blocks, which afaik are separate from the MSD, could be sent more often (depending on how fancy the system is)?

>> potential problems I see in the future, in the type of networks that 
>> the draft targets.
>
> If we identify a need to transmit data associated with an emergency call over a 
> media plane, this should be done as an extension to the additional-data draft and 
> then incorporated by reference into all documents that use additional-data.  
> Otherwise we risk creating multiple incompatible mechanisms.  However, I don't see > any such need at this time.

I thought we already agreed that there is data (pictures, sensor data etc) for which a media plane mechanism is more appropriate, but that we may not define such mechanism (as different SDOs may already have mechanisms they want to re-use).

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sat, 13 Dec 2014 15:34:40 -0800

At 8:26 PM +0000 12/13/14, Christer Holmberg wrote:

>> expectation is that
>  I think we should try to get some numbers, because it will make is 
> easier to choose the appropriate mechanism.

We can't get real-world numbers until we have deployed systems.  But 
we can make reasonable assumptions based on typical PSAP operational 
procedures.  As an example, U.S. PSAPs can request updated location 
information whenever desired by the call-taker.  In practice, this is 
not done often, and for many calls not at all.

>  I think it would be very useful to document those kind of things in 
> the draft. Because, we should choose the mechanism based on 
> technical grounds.
>
>  However, I assume eCall control blocks, which afaik are separate 
> from the MSD, could be sent more often (depending on how fancy the 
> system is)?

What sort of documentation would you like to see?

eCall control blocks are primarily for the PSAP to request the 
vehicle to do something.  The only mandatory action that the vehicle 
MUST support is to send an MSD.  So it is not likely to be sent 
frequently.

>>  Otherwise we risk creating multiple incompatible mechanisms. 
>> However, I don't see > any such need at this time.
>
>  I thought we already agreed that there is data (pictures, sensor 
> data etc) for which a media plane mechanism is more appropriate, 
> but that we may not define such mechanism (as different SDOs may 
> already have mechanisms they want to re-use).

Pictures (or video clips) are media and should be sent as media.

It would be better to have a common mechanism for transmitting static 
media, just as we have a common mechanism for streaming media, but 
the eCall draft is not the place to define such a mechanism.

-------------- Randomly selected tag: ---------------
Majority: That quality that distinguishes a crime from a law.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 14 Dec 2014 20:24:17 +0000

Hi,

>>>>>>>>   make  it clear that the MSD, eCall-Specific Control/Metadata 
>>>>>>>> etc  can  also be  transported using another mechanisms (media 
>>>>>>>> plane  mechanisms).
>>>>>>>
>>>>>>>    I can add a caution that excessively large sensor data should 
>>>>>>> not  be  sent by value in the signaling plane.
>>>>>>
> We can't get real-world numbers until we have deployed systems.  But we can make reasonable 
> assumptions based on typical PSAP operational procedures.  As an example, U.S. PSAPs can request 
> updated location information whenever desired by the call-taker.  In practice, this is not done often, 
> and for many calls not at all.

Well, that is good background information.

The questions are:

1) Can we expect similar behaviour for eCall?

2) Can we expect future enhancements of MSD to trigger more frequent MSD requests, and/or the size of the MSD to grow?

>>> changed.
>>>  If in the future a more comprehensive set of data is standardized 
>>> and used in  Europe, PSAPs may request that form, but again the 
>>> expectation is that this might  occur once at the start of the call, 
>>> and possibly again if the call-taker thinks the  vehicle state may 
>>> have changed.
>>
>> the draft. Because, we should choose the mechanism based on technical 
>> grounds.
>>
>>  However, I assume eCall control blocks, which afaik are separate from 
>>  the MSD, could be sent more often (depending on how fancy the system 
>> is)?
>

Anything which can help in choosing (and justifying the choice of) transport mechanisms.

> eCall control blocks are primarily for the PSAP to request the vehicle to do something.  
> The only mandatory action that the vehicle MUST support is to send an MSD.  So it is not likely to be sent frequently.

The "capabilities" element is sent from the IVS to the PSAP.

And, looking forward, the more fancy systems get, the more frequent they might be. 

So, the control blocks can be a candidate for a media plane mechanism. I don't really think it's "additional data" anyway, it's more of a two-way protocol.

>>>>>  Obviously, any data that is needed in order to route the INVITE 
>>>>> to  the correct PSAP in the first place needs to be sent in the INVITE.
>>>>
>>>>>   I don't see a need to get into hypotheticals.  The eCall draft 
>>>>> says  how the MSD is sent using the ECRIT  additional-data 
>>>>> mechanism, which  is the direction of ECRIT.  If in the future 
>>>>> there is a need to  define a  mechanism to send emergency call 
>>>>> related data using a media  stream, let's work on the problem at that time.
>>>>
>>>>   Well, my comments are against the ecall draft, and are based on 
>>>> the  potential problems I see in the future, in the type of networks 
>>>> that the draft targets.
>>>>
>>> documents that use additional-data.
>>  I thought we already agreed that there is data (pictures, sensor data 
>> etc) for which a media plane mechanism is more appropriate, but that 
>> we may not define such mechanism (as different SDOs may already have 
>> mechanisms they want to re-use).
>
> It would be better to have a common mechanism for transmitting static media, just as we have a 
> common mechanism for streaming media, but the eCall draft is not the place to define such a mechanism.

As long as we clearly describe that such mechanisms can be used.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sun, 14 Dec 2014 15:51:41 -0800

>  1) Can we expect similar behaviour for eCall?

I believe so.

>
>  2) Can we expect future enhancements of MSD to trigger more 
> frequent MSD requests, and/or the size of the MSD to grow?

For the short and medium term, probably not.  I think that longer 
term, a larger MSD is more likely, but still should be comparatively 
small, not even close to the size of a phone image.

>> vehicle to do something. 
>>  The only mandatory action that the vehicle MUST support is to send 
>> an MSD.  So it is not likely to be sent frequently.
>

Yes, but only once at the start, and the size should remain quite 
small, since only the supported capabilities are included.

>  So, the control blocks can be a candidate for a media plane 
> mechanism. I don't really think it's "additional data" anyway, it's 
> more of a two-way protocol.

I think we are still very much in the additional data realm.  Sending 
crash data once or twice even thrice, and sending a request for crash 
data once or twice doesn't change the scale enough to warrant 
treatment as media.

>  As long as we clearly describe that such mechanisms can be used.

I'm happy to add text to clarify that the draft relies on more 
general mechanisms for media transmission, and I can also clarify 
that the MSD and the metadata are small, expected to be sent 
infrequently, and expected to remain small, and that if a large 
amount of data or high frequency updates are desired in the future, 
alternative transport, such as media transport mechanisms, should be 
considered.

-------------- Randomly selected tag: ---------------
Time is nature's way of making sure that everything doesn't
happen on schedule.

---

From: Ivo Sedlacek <[email-masked]>
Date: Mon, 15 Dec 2014 12:29:04 +0000

Hello,

> data once or twice doesn't change the scale enough to warrant 

the draft states:
--------------

   o  The ability to carry more data (e.g., an enhanced MSD or an MSD
      plus additional sets of data)
   o  The ability to handle video
   o  The ability to handle text
   o  The ability for the PSAP to access vehicle components (e.g., an
      onboard camera (such as rear facing or blind-spot cameras) for a
      visual assessment of the crash site situation)
   o  The ability for the PSAP to request the vehicle to take actions
      (e.g., sound the horn, disable the ignition, lock/unlock doors)
   o  The ability to avoid audio muting of the voice channel (because
      the MSD is not transferred using an in-band modem)
--------------

If PSAP uses each of the above in a call, then it will be at least 2x 6 INFO requests in the call.

Moreover, PSAP may wish to use some of those several times (e.g. switching the video from rear facing camera to blind-spot camera and back).

So, INFOs can cause a significant load on the SIP proxies handling the emergency call.

Kind regards

Ivo Sedlacek

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Dec 2014 15:43:59 +0000

Hi,

> I think we are still very much in the additional data realm.  
> Sending crash data once or twice even thrice, and sending a request for crash 

See below.

...

> alternative transport, such as media transport mechanisms, should be 

But, if someone want to deploy a "future proof" solution, why not allow everything to be sent on the media plane from start? 

There may be information that have to be sent on the media plane from "day one", so it seems weird that one would have to use two different mechanisms just because they haven't reached the future yet.

As we have discussed before, we may not define the exact media plane transport mechanism within this draft, but we should allow others to do so.

Regards,

Christer