Re: [codec] Speech Quality Aspects in emergency calls

Brian Rosen <br@brianrosen.net> Thu, 27 May 2010 13:15 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099EC3A6931; Thu, 27 May 2010 06:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.935
X-Spam-Level:
X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YyGjsGGMTxk; Thu, 27 May 2010 06:15:18 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id E0C1B3A68E4; Thu, 27 May 2010 06:15:15 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1OHcvK-0000A8-JP; Thu, 27 May 2010 08:14:58 -0500
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Thu, 27 May 2010 09:14:56 -0400
From: Brian Rosen <br@brianrosen.net>
To: Christian Hoene <hoene@uni-tuebingen.de>, Cullen Jennings <fluffy@cisco.com>, codec@ietf.org
Message-ID: <C823E890.35EB8%br@brianrosen.net>
Thread-Topic: Speech Quality Aspects in emergency calls
Thread-Index: Acr9TeFvwAIcoQvjTqijHtTrJC4yEQAON8cgAAX2Tq4=
In-Reply-To: <002a01cafd8a$3691f610$a3b5e230$@de>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
Cc: ecrit@ietf.org
Subject: Re: [codec] Speech Quality Aspects in emergency calls
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 13:15:25 -0000

Generally, high fidelity is a good thing for emergency calls.  This has to
be balanced against how many codecs each PSAP implements, but at least in
the evolving North American standards, which are currently believed to be
the most advanced, it is recommended that PSAPs implement one or two
wideband codecs.  Graceful fallback in cases of congestion would be nice,
but not a hard requirement.

Delay below 150ms is unlikely to be of much use.  Sometimes, an emergency
call can have audio+video and the delays must match (lip sync).  Frame time
really doesn't matter much independent of its effect on delay.  I personally
think delay over 150ms is not acceptable, but we've had this discussion and
there are some who persist in believing you can get good quality with 250
ms.  In an emergency call, stress is a big factor, and social skills are not
nuanced.  This means turn taking is an issue, and anything that gets in the
way of an interruption is bad.  All of my testing indicates that turn
taking, especially argument, is impaired above around 150 ms.

All of the above doesn't really rise to hard requirements other than the
soft requirement that delay doesn't impair turn taking.  The ability to
disable VAD is a hard requirement.

I believe that is it with respect to codec.  See ietf-ecrit-phonebcp for the
actual requirements.

Brian


On 5/27/10 6:48 AM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:

> Hello Cullen,
> dear ECRIT experts,
> 
>> I think that the bulk of the people that work on emergency calls in the ECRIT
>> WG and much of the IESG
>> are going to be very strong supporters of exactly what Brian is saying here.
> 
> I agree that the support of emergency call are important, also in the IETF WG
> Codec. However, at this point of time it is not clear
> to me what the service requirements of an emergency call are going to be.
> Which speech/audio quality requirements do the emergency
> agencies have?
> 
> Brian is suggesting a technical solution to become a requirement. But, don't
> we have to listen to the users, first? Only then, we
> can develop a technical solutions that might affect our work in the Codec WG.
> 
>> The implications aren't a
>> big deal for the CODEC WG, just that you need to be able to use SDP to signal
>> no VAD. 
> 
> Are you sure that this is the only requirement? I think that there are other
> important things in case of emergency calls. Do they
> need audio quality? Do they need ultra-low-delay or is any transmission delay
> fine? What shall happen, if the transmission quality
> is bad? Push-to-talk?
> 
>> No one thinks an
>> end user is going to go and change the configuration in their phone before
>> making an emergency call.
> 
> No, he does know VAD and he does not care about. Some part of the system must
> take care of. However, the user does know that he
> wants to make a emergency call and the phone might have a button called
> "emergency call".
> 
>> If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think this
>> is a requirement for an
>> internet codec, it's easy to make that happen but they are going to tell us
>> the same thing Brian is.
> 
> Good idea, I carbon-copied this email to the ECRIT mailing list, if you do not
> mind.
> 
> With best regards,
> 
>  Christian
> 
>> 
>> 
>> 
>> On May 24, 2010, at 12:20 PM, Brian Rosen wrote:
>> 
>>> Okay, you asked for it :)
>>> 
>>> In any country, the codes used in another country for emergency numbers are
>>> used as service invocations for other services.  You have to know what
>>> country you are in to know what emergency numbers are.  It is roughly
>>> impossible (today) to know that with sufficient reliability.
>>> 
>>> You can place an emergency call to an e.164 in many countries.  This may
>>> depend on which service.
>>> 
>>> The emergency call center (PSAP) can call you back.
>>> 
>>> A call placed to a call center can be transferred or upgraded to an
>>> emergency call.  This happens with relay centers used by disabled
>>> individuals.
>>> 
>>> In all of these circumstances, VAD must be disabled.  Emergency calling
>>> systems are filled with a lot of complexity that handle seldom occurring
>>> circumstances.  However, when it comes to saving lives, seldom occurring
>>> circumstances are important.
>>> 
>>> Brian
>>> 
>>> ps - I have been working in this field for a number of years.  You can learn
>>> a bit more about emergency calling from draft-ietf-ecrit-framework.  The
>>> inability to turn off VAD in VoIP systems believed to have caused actual
>>> harm according to some of my associates who work in PSAPs.
>>> 
>>> 
>>> 
>>> 
>>> On 5/24/10 1:37 PM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:
>>> 
>>>> Hi Brian,
>>>> 
>>>>> I'll be happy to go into the details, but phones may not know they are in
>>>>> an
>>>>> emergency call.  No phone knows this today.  There is some proposed
>>>>> signaling that would tell them, IF the phone, and the service provider
>>>>> implement it, but even then, there are circumstances where the phone won't
>>>>> know.
>>>> 
>>>> If(called.number==112 || called.number==911 || called.number=XYZ)
>>>> EmergencyCall();
>>>> 
>>>> See more at http://en.wikipedia.org/wiki/1-1-2
>>>> It is so easy to know... I do not get your arguments.
>>>> 
>>>> With best regards,
>>>> 
>>>> Christian
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> codec mailing list
>>> codec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/codec
>