Re: [codec] #14: VAD and CNG?

Cullen Jennings <fluffy@cisco.com> Thu, 27 May 2010 03:37 UTC

Return-Path: <fluffy@cisco.com>
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 DDB1C3A659C for <codec@core3.amsl.com>; Wed, 26 May 2010 20:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.495
X-Spam-Level:
X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 K7UKTGLwsDB3 for <codec@core3.amsl.com>; Wed, 26 May 2010 20:37:02 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 39DF53A63C9 for <codec@ietf.org>; Wed, 26 May 2010 20:37:02 -0700 (PDT)
Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMGABGF/UurR7H+/2dsb2JhbACSGIwOcaZNmgKCYIIzBINC
X-IronPort-AV: E=Sophos;i="4.53,308,1272844800"; d="scan'208";a="258331335"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 May 2010 03:36:53 +0000
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4R3aqWR015332; Thu, 27 May 2010 03:36:52 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
Impp: xmpp:cullenfluffyjennings@jabber.org
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <C8203B90.358AB%br@brianrosen.net>
Date: Wed, 26 May 2010 21:36:51 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com>
References: <C8203B90.358AB%br@brianrosen.net>
To: codec@ietf.org
X-Mailer: Apple Mail (2.1078)
Subject: Re: [codec] #14: VAD and CNG?
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 03:37:04 -0000

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. 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. No one thinks an end user is going to go and change the configuration in their phone before making an 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. 



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