[codec] #34: Speech Quality Aspects in emergency calls

"codec issue tracker" <trac@tools.ietf.org> Thu, 24 June 2010 15:18 UTC

Return-Path: <trac@tools.ietf.org>
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 D04E83A6951 for <codec@core3.amsl.com>; Thu, 24 Jun 2010 08:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.858
X-Spam-Level:
X-Spam-Status: No, score=-100.858 tagged_above=-999 required=5 tests=[AWL=-1.458, BAYES_50=0.001, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001, 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 W0CMTZjdGXsW for <codec@core3.amsl.com>; Thu, 24 Jun 2010 08:18:13 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B34F83A6802 for <codec@ietf.org>; Thu, 24 Jun 2010 08:18:13 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1ORoC6-00053Z-D8; Thu, 24 Jun 2010 08:18:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: hoene@uni-tuebingen.de
X-Trac-Project: codec
Date: Thu, 24 Jun 2010 15:18:22 -0000
X-URL: http://tools.ietf.org/codec/
X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/codec/trac/ticket/34
Message-ID: <062.8337dddc40b2c9c88b04caa75d6825e7@tools.ietf.org>
X-Trac-Ticket-ID: 34
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: codec@ietf.org
Subject: [codec] #34: Speech Quality Aspects in emergency calls
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: codec@ietf.org
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, 24 Jun 2010 15:18:15 -0000

#34: Speech Quality Aspects in emergency calls
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------
 [Hoene]: 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".

 [Brian]: 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.

 [Gregor Jänin]:
 I have to come back on a comment chistian made : What about Push-to-talk??
 I have found out that in Europe and Australia they are looking into
 "eurocae wg67", als solution to transfer PTT!
 It is already used in fight safety control and some of the PSAP equipment
 vendors doing both , flight and public safety!
 What is your position on that, we gonna neet it! Especial when we talk
 about autority to autority, or even just nextel..

 [Brian]: PTT is not currently a requirement for citizen to authority.  It
 is a requirement for authority to authority.  It is not a requirement for
 authority to citizen.

 I don’t think PTT has any effect on codec.

 ...

 We do support text (and video) with ecrit standards.  Of particular
 interest is the “real time text” codec work, but just using SIP MESSAGE
 works.  There is also some work on sending ‘data only’, i.e. sensor alerts
 using the same mechanisms.

 It has occurred to me that while in the normal case, we do want to disable
 VAD, it does help when the network is highly congested.  Since what I
 asked for was that it should be negotiable, the PSAP could control when it
 was or wasn’t used.

 The problem with PTT in general is that the emergency service isn’t in a
 “talk group”, and what you would be establishing is an on the fly two
 party talk group which has to be routed using the same mechanisms as the
 emergency calls are routed.   That’s not impossible, but it is unusual.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/codec/trac/ticket/34>
codec <http://tools.ietf.org/codec/>