Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt

From: Gunnar Hellström <[email-masked]>
Date: Sat, 6 Mar 2010 23:14:51 +0100

Hi,
In chapter 3 of this draft, there is a sentence about media saying: 

"Media:  Real-time text and video may be supported in devices some
      time in the future."

If this draft makes its way to be a published RFC, the expression "some time
in the future" will postpone the introduction of these media forever. That
is not wanted.

I suggest that you delete "some time in the future". The "may" carries
sufficient uncertainty to delay its introduction if it is not found feasible
from the outset to provide more media than audio.

The resulting sentence is proposed to be:

"Media:  Real-time text and video may be supported in devices."

/Gunnar  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, March 06, 2010 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-rosen-ecrit-ecall-03.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Best Current Practice for IP-based In-Vehicle
Emergency Calls
	Author(s)       : B. Rosen, et al.
	Filename        : draft-rosen-ecrit-ecall-03.txt
	Pages           : 17
	Date            : 2010-03-06

This document describes how to use a subset of the IETF-based emergency call
framework for accomplishing emergency calling support in vehicles.
Simplifications are possible due to the nature of the functionality that is
going to be provided in vehicles with the usage of GPS.  Additionally,
further profiling needs to be done regarding the encoding of location
information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosen-ecrit-ecall-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 07 Mar 2010 09:00:41 +0200

Hi Gunnar,

this document refers to emergency calls in vehicles. The standardization 
efforts I have seen in that space barely talk about voice support and I 
have not seen any video or real-time text being mentioned. I am 
specifically referring the work done in Europe (as part of the eCall 
effort -- hence the name of the draft).

While I agree with you in general I was trying to be closer to what is 
being standardized in other groups. Did I miss something or do you think 
we should be a bit more proactive here?

Ciao
Hannes

Gunnar Hellström wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 7 Mar 2010 20:28:08 +0100

Can I ask what this comment is attempting to achieve.

The eCall work based on 3GPP is primarily about getting data to a specialist call taker able to handle the data, and defining the format of that data. There is nothing that prevents that device making an ordinary emergency call, or indeed an emergency call requiring global text telephone. I believe that such capabilities are envisaged.

What is obviously not covered in 3GPP is the simultaneous use of that data with an ordinary emergency call, but that is because currently the data ultimately is sent as a modem based circuit switched call, which are not exactly multimedia. Switch that data to IP based media, and there is no reason why you cannot mix it with any multimedia emergency call, possibly with an extra service urn element to cover the requirement for a specialised call taker.

I would additionally raise the question of why people think IETF would be the better body to define this rather than 3GPP. Surely the delivery mechanisms are intended to be cellular based rather than any other access technology - unless you really want to crash your car into Starbucks so you can make use of the free WiFi.

regards

Keith

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Sent: Sunday, March 07, 2010 7:01 AM
> To: Gunnar Hellström
> Cc: Ecrit@Ietf. Org
> Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt
> 
> Hi Gunnar,
> 
> this document refers to emergency calls in vehicles. The 
> standardization efforts I have seen in that space barely talk 
> about voice support and I have not seen any video or 
> real-time text being mentioned. I am specifically referring 
> the work done in Europe (as part of the eCall effort -- hence 
> the name of the draft).
> 
> While I agree with you in general I was trying to be closer 
> to what is being standardized in other groups. Did I miss 
> something or do you think we should be a bit more proactive here?
> 
> Ciao
> Hannes
> 
> 
> Gunnar Hellström wrote:
> > Hi,
> > If this draft makes its way to be a published RFC, the expression 
> > "some time in the future" will postpone the introduction of these 
> > media forever. That is not wanted.
> >
> > sufficient uncertainty to delay its introduction if it is not found 
> > feasible from the outset to provide more media than audio.
> >
> > This document describes how to use a subset of the IETF-based 
> > emergency call framework for accomplishing emergency 
> calling support in vehicles.
> > Simplifications are possible due to the nature of the functionality 
> > that is going to be provided in vehicles with the usage of GPS.  
> > Additionally, further profiling needs to be done regarding the 
> > encoding of location information.
> >

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 7 Mar 2010 20:28:40 +0100

Hannes,

I want to split the question about the sentence about support of real-time
text and video in two: One about wording in a standard, and one about the
applicability of real-time text and video in the eCall environment.

1. Wording.
The current wording is:
"Media:  Real-time text and video may be supported in devices some time in
the future."
I expect a standard to be valid at the moment I read it. If this draft
becomes approved and published, the sentence will postpone all future
efforts to introduce support of real-time text and video to some unknown
moment when a new standard for the same purpose is approved without the
words about future support. It is against the purpose of a standard to talk
about what may be done in the future. The correct way to describe future
features is to just say that a feature MAY be supported, and let external
forces decide when the feature is made commonly implemented.

Therefore, please delete "some time in the future".

2. About applicability and feasibility of real-time text and video in eCall,
and being more proactive.
I get sad every time I see a feature standardized or implemented only for
audio. There are so many cases when severe problems of understanding appear
in a voice conversation that takes minutes to overcome, that would have been
solved in seconds by having a real-time text channel or a video channel
available in the call.  Such problems appear between people with different
languages, different dialects, in noisy environments, with bad connections,
or because they have items to exchange that requires exactness in spelling.
Such situations appear easily when travelling by car. 
And of course, from the accessibility side, it is even more easy to find
examples of situations where real-time text or video or both is essential
for the communication. 
There are plenty of strong and binding policy statements requiring all
communication products and services to be made accessible for people with
disabilities. Including real-time text and video in an interoperable way
everywhere where audio is supported is one good step to meet these
requirements, and it is also a good step towards better mainstream use of
the services. 
One such collection of binding accessibility requirements is the UN
convention on rights of people with disabilities.

Article 9 is about accessibility.
http://www.un.org/disabilities/default.asp?id=269
Article 11 is about emergency situations
http://www.un.org/disabilities/default.asp?id=271
   
However, it would be fruitless to just include accessibility features in a
standard without talking with the ones who proposed the standard.
So, for now, I suggest that the MAY is still left there, while you discuss
with the projects working on eCall about the feasibility of other media.

Gunnar 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, March 07, 2010 8:01 AM
To: Gunnar Hellström
Cc: Ecrit@Ietf. Org; Brian Rosen
Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt

Hi Gunnar,

Ciao
Hannes

> sufficient uncertainty to delay its introduction if it is not found
feasible
> implementation to automatically retrieve the ASCII version of the

__________ NOD32 4921 (20100306) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 8 Mar 2010 04:29:40 +0800

Hi Keith,

There is also the growing prevalence of MiFi in vehicles, where device connected to the MiFi point doesn't know about the 3G/4G backhaul. In this circumstance depending on 3GPP procedures is perhaps not quite so wise. 

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DRAGE, Keith (Keith) [[email-masked]]
Sent: Sunday, March 07, 2010 1:28 PM
To: Hannes Tschofenig; Gunnar Hellström
Cc: Ecrit@Ietf. Org
Subject: Re: [Ecrit] I-D Action:draft-rosen-ecrit-ecall-03.txt

regards

Keith

---

From: Arnoud van Wijk <[email-masked]>
Date: Mon, 08 Mar 2010 12:28:51 +0100

I want to jump in here.
I agree here with Gunnar.
What we see here is that still so many people still have everything 
voice centric. Not realizing how essential and important it is to allow 
real-time text and video to be added to the call.
This does sadden me a lot. We all as IETF and any other relevant 
standard organization should consider voice, video and real-time text 
the "real-time trinity".
Always make it possible, always implement it and always consider it part 
of the normal standardization process.
If there are limitations, it should never be the standard documents 
raising the barriers.
> Therefore, please delete "some time in the future".
Agree
> examples of situations where real-time text or video or both is essential

For example when you have video included in this call, the emergency 
agent can also see what is going on as well.
Video can add essential information of the situation.
> requirements, and it is also a good step towards better mainstream use of

Exactly.

> with the projects working on eCall about the feasibility of other media.
We could raise the bar and say:
"Media:  It is recommended to include Real-time text and video in devices."

After all, in emergency situations, it is essential that communication 
is optimal, since lives may be in unnecessary danger due by 
miscommunications and insufficient information of the situation.

Maybe being proactive here is a good thing. I do not want to die just 
because I am deaf and the only line of help is some voice line that I 
cannot use at all (only scream help maybe).

Arnoud
>> If this draft makes its way to be a published RFC, the expression "some
>>      
> time
>    
>> This document describes how to use a subset of the IETF-based emergency
>>      
> call
>    
>> Simplifications are possible due to the nature of the functionality that
>>      
> is
>