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

From: "codec issue tracker" <[email-masked]>
Date: Sun, 02 May 2010 16:03:03 -0000

#14: VAD and CNG?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Comment(by hoene@…):

 [Hoene]: Comfort noise used to be use to indicate that a transmission is
 ongoing. However, if high quality transmission shall be supported,
 artifical noise worsen the audio quality. Thus, the generation of idle
 channel noise should not be used to indicate that the call is still
 active. Instead, in case of transmission problems an acoustic or visual
 notification can be given.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/14#comment:1>
codec <http://tools.ietf.org/codec/>

---

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Mon, 10 May 2010 18:16:26 -0700

Hi Christian,

I think comfort noise is more than just to let the telephone user know that the connection is not dead.  If voice packets are sent only during active voice regions of the signal (in DTX) and not during silence/background noise regions, and if there is audible background noise and comfort noise is not added during background noise regions, at the receiving end the background noise will be "on" only during active voice and "off" otherwise.  This frequent on-off switching will make the background noise sound unnatural and will bother many users.  Adding comfort noise during background noise regions will make such background noise sound more natural.

Of course, this works well only if the background noise is relatively stationary.  If the background noise is dynamically changing, then comfort noise can't really sound like the true background noise.  Today I was put on hold in a phone call with music playing.  Apparently the system treated some parts of the music as background noise and replaced them with comfort noise. The result is pretty annoying, or amusing, depending on which way you look at it.

Therefore, I think comfort noise has its value if DTX is used and the background noise is fairly stationary, but if the background noise or music is changing dynamically and high audio quality is desired, then the DTX and comfort noise should be turned off and all parts of the signal need to be transmitted.

Raymond  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of codec issue tracker
Sent: Sunday, May 02, 2010 9:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [codec] #14: VAD and CNG?

#14: VAD and CNG?

Comment(by hoene@…):

_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: "codec issue tracker" <[email-masked]>
Date: Mon, 24 May 2010 14:22:15 -0000

#14: VAD and CNG?

Comment(by hoene@…):

 [Raymond]: I think comfort noise is more than just to let the telephone
 user know that the connection is not dead.  If voice packets are sent only
 during active voice regions of the signal (in DTX) and not during
 silence/background noise regions, and if there is audible background noise
 and comfort noise is not added during background noise regions, at the
 receiving end the background noise will be "on" only during active voice
 and "off" otherwise.  This frequent on-off switching will make the
 background noise sound unnatural and will bother many users.  Adding
 comfort noise during background noise regions will make such background
 noise sound more natural.

 [Benjamin]:  The cheapest solution, of course, is transmit-side activity
 detection.
 Maybe we need to specify a way for a receiver to request that the
 transmitter employ (or not employ) VAD.

 [Benjamin]:
 I know that CELT makes decoder VAD very efficient, but how is decoder VAD
 better than encoder VAD?  Encoder VAD saves even more CPU, saves
 bandwidth, and enables easier jitter buffering.
 Are you thinking about some sort of adaptive thresholding that requires
 knowing all streams' volume levels?
 Anyway, VAD can run on both encode and decode sides at the same time.

 [Stephen]: It might be valuable to be able to obtain the VAD without
 having to decrypt the bitstream, since that also can become a problem as
 the number of streams grows.
 There is a security consideration (traffic analysis), however, it still
 might be worth thinking about.

 [JM]:
 > I know that CELT makes decoder VAD very efficient,
 Not only CELT. You can do that with an LPC-based codec too.

 > but how is decoder VAD
 > better than encoder VAD?  Encoder VAD saves even more CPU, saves
 > bandwidth, and enables easier jitter buffering.

 There's a few reasons why I think decoder-side is better:
 - The decision for an encoder-size VAD would take some amount of space in
 the bit-stream
 - If we make an encode-size VAD mandatory, then all encoders will have to
 spend the CPU cycles, even when it's not needed. If it's not mandatory,
 then the decoder cannot rely on it, so it still needs to implement a VAD
 - A decoder VAD does not need to be specified in an exact way, so
 implementers can choose different implementations depending on that
 information they need.
 - You cannot "game" a decode-size VAD.

 > Are you thinking about some sort of adaptive thresholding that
 > requires knowing all streams' volume levels?

 Well, knowing the relative amplitudes of each stream can allow you to take
 more intelligent decisions, e.g. when you have to choose the "most active
 speaker". That's something you can't really get from an encoder VAD.

 > Anyway, VAD can run on both encode and decode sides at the same time.

 That would just mean nobody would bother implementing the encode side.

 [Benjamin]:

 I think I failed to communicate that by VAD I mean _not sending packets_
 during inactivity.  For the packets that are sent, the overhead should
 average much less than 1 bit per frame.

 I'm not suggesting sending 200 packets a second containing a flag
 indicating no voice activity, followed by carefully coded background
 noise.  That would be silly.

 > - If we make an encode-size VAD mandatory, then all encoders will have
 > to spend the CPU cycles, even when it's not needed. If it's not
 > mandatory, then the decoder cannot rely on it, so it still needs to
 > implement a VAD

 I don't see this as "mandatory".  The encoder can turn off VAD, and
 probably should for full-quality applications.

 > - A decoder VAD does not need to be specified in an exact way, so
 > implementers can choose different implementations depending on that
 > information they need.

 The only thing that needs exact specification is the signalling.  The
 encoder may use it or not use it as it pleases.

 > - You cannot "game" a decode-size VAD.

 I don't know what this means.

 >> Are you thinking about some sort of adaptive thresholding that
 >> requires knowing all streams' volume levels?
 >
 > Well, knowing the relative amplitudes of each stream can allow you to
 > take more intelligent decisions, e.g. when you have to choose the
 > "most active speaker". That's something you can't really get from an
 encoder VAD.
 >
 >> Anyway, VAD can run on both encode and decode sides at the same time.
 >
 > That would just mean nobody would bother implementing the encode side.

 I expect encode-side VAD on a conference call to save more than a factor
 of 2 in bandwidth, which makes it very desirable, especially for large
 deployments.  People will use it to save bandwidth (especially if it's on
 by default in the reference implementation).  The decode-side CPU savings
 are just a minor bonus side-effect.

 [JM]:
 What you're describing is called DTX (discontinuous transmission). This
 can be useful feature, but it's very different from what we were
 originally talking about in terms of conference mixing.

 [Ben]: Oops. Right.  What I'm trying to say is that DTX, based on encoder-
 side VAD, also greatly reduces the (average) computational burden on a
 conference mixer.  Of course, if everyone's really talking at once then
 VAD can't help.

 [Roman]: There is one more application to efficiently combining pre-
 encoded
 audio: playing announcements or recorded audio. Standard network or IVR
 announcements can be encoded once and efficiently inserted or combined
 into audio stream. If pre-encoded audio is supported and the client
 supports AVT tones, it is trivial to develop a very efficient IVR server
 which does not require any CODEC encoding or decoding.

 Efficient decoder side VAD is also very helpful in case of speech
 recognition, where it allows to save cycles in end-pointer. This way audio
 only needs to be decoded and passed to the speech recognition system only
 when voice is present.

 Bottom line, if we have both efficient decoder side VAD and combining pre-
 encoded audio we can develop some very efficient VXML servers, voice mail
 and IVR system, not just conferencing servers.

 Of course, this works well only if the background noise is relatively
 stationary.  If the background noise is dynamically changing, then comfort
 noise can't really sound like the true background noise.  Today I was put
 on hold in a phone call with music playing.  Apparently the system treated
 some parts of the music as background noise and replaced them with comfort
 noise. The result is pretty annoying, or amusing, depending on which way
 you look at it.

 Therefore, I think comfort noise has its value if DTX is used and the
 background noise is fairly stationary, but if the background noise or
 music is changing dynamically and high audio quality is desired, then the
 DTX and comfort noise should be turned off and all parts of the signal
 need to be transmitted.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/14#comment:2>
codec <http://tools.ietf.org/codec/>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 24 May 2010 10:48:18 -0400

I hope we are assuming VAD (or DTX) is negotiable.  It is essential (for
emergency calls) that VAD is disabled.  While in many cases the endpoint
will know that it is in an emergency call, and disable VAD, it is not always
possible to know.

Brian

On 5/24/10 10:22 AM, "codec issue tracker" <[email-masked]> wrote:

> #14: VAD and 
> CNG?
------------------------------------+------------------------------------
> ---
 Reporter:  hoene@Š                 |       Owner:     
     Type:  defect
> |      Status:  new
 Priority:  major                   |   Milestone:
 Severity:  -
> |    Keywords:   

Comment(by hoene@Š):

 [Raymond]: I think comfort noise is more than just to
> let the telephone
 user know that the connection is not dead.  If voice
> packets are sent only
 during active voice regions of the signal (in DTX) and
> not during
 silence/background noise regions, and if there is audible
> background noise
 and comfort noise is not added during background noise
> regions, at the
 receiving end the background noise will be "on" only during
> active voice
 and "off" otherwise.  This frequent on-off switching will make
> the

> comfort noise during background noise regions will make such background
 noise
> sound more natural.

 [Benjamin]:  The cheapest solution, of course, is
> transmit-side activity
 detection.
 Maybe we need to specify a way for a
> receiver to request that the

> [Benjamin]:
 I know that CELT makes decoder VAD very efficient, but how is
> decoder VAD

> bandwidth, and enables easier jitter buffering.
 Are you thinking about some
> sort of adaptive thresholding that requires
 knowing all streams' volume
> levels?
 Anyway, VAD can run on both encode and decode sides at the same
> time.

> having to decrypt the bitstream, since that also can become a problem as
 the
> number of streams grows.
 There is a security consideration (traffic
> analysis), however, it still

 [JM]:
 > I know
> that CELT makes decoder VAD very efficient,
 Not only CELT. You can do that
> with an LPC-based codec too.

 > but how is decoder VAD
 > better than encoder
> VAD?  Encoder VAD saves even more CPU, saves

 There's a few reasons why I think decoder-side is better:

> - The decision for an encoder-size VAD would take some amount of space in the
> bit-stream
 - If we make an encode-size VAD mandatory, then all encoders will
> have to
 spend the CPU cycles, even when it's not needed. If it's not
> mandatory,
 then the decoder cannot rely on it, so it still needs to implement
> a VAD

 > Are you
> thinking about some sort of adaptive thresholding that
 > requires knowing all
> streams' volume levels?

 Well, knowing the relative amplitudes of each stream
> can allow you to take
 more intelligent decisions, e.g. when you have to
> choose the "most active
 speaker". That's something you can't really get from
> an encoder VAD.

 > Anyway, VAD can run on both encode and decode sides at the

 That would just mean nobody would bother implementing the encode
> side.

 [Benjamin]:

 I think I failed to communicate that by VAD I mean _not
> sending packets_
 during inactivity.  For the packets that are sent, the
> overhead should

 I'm not suggesting
> sending 200 packets a second containing a flag
 indicating no voice activity,
> followed by carefully coded background

 > - If
> we make an encode-size VAD mandatory, then all encoders will have
 > to spend
> the CPU cycles, even when it's not needed. If it's not
 > mandatory, then the
> decoder cannot rely on it, so it still needs to
 > implement a VAD

 I don't
> see this as "mandatory".  The encoder can turn off VAD, and
 probably should
> for full-quality applications.

> implementations depending on that

 The only thing
> that needs exact specification is the signalling.  The
 encoder may use it or
> not use it as it pleases.

 > - You cannot "game" a decode-size VAD.

 I don't
> know what this means.

 > Well,
> knowing the relative amplitudes of each stream can allow you to
 > take more
> intelligent decisions, e.g. when you have to choose the
 > "most active

 I
> expect encode-side VAD on a conference call to save more than a factor
 of 2
> in bandwidth, which makes it very desirable, especially for large

> deployments.  People will use it to save bandwidth (especially if it's on by
> default in the reference implementation).  The decode-side CPU savings
 are
> just a minor bonus side-effect.

 [JM]:
 What you're describing is called DTX
> (discontinuous transmission). This
 can be useful feature, but it's very
> different from what we were
 originally talking about in terms of conference
> mixing.

 [Ben]: Oops. Right.  What I'm trying to say is that DTX, based on
> encoder-
 side VAD, also greatly reduces the (average) computational burden on
> a

> VAD can't help.

 [Roman]: There is one more application to efficiently
> combining pre-
 encoded
 audio: playing announcements or recorded audio.
> Standard network or IVR
 announcements can be encoded once and efficiently
> inserted or combined
 into audio stream. If pre-encoded audio is supported and
> the client
 supports AVT tones, it is trivial to develop a very efficient IVR
> server

 Efficient
> decoder side VAD is also very helpful in case of speech
 recognition, where it
> allows to save cycles in end-pointer. This way audio
 only needs to be decoded
> and passed to the speech recognition system only
 when voice is present.

> encoded audio we can develop some very efficient VXML servers, voice mail and
> IVR system, not just conferencing servers.

 Of course, this works well only
> if the background noise is relatively
 stationary.  If the background noise is
> dynamically changing, then comfort
 noise can't really sound like the true
> background noise.  Today I was put
 on hold in a phone call with music
> playing.  Apparently the system treated
 some parts of the music as background
> noise and replaced them with comfort
 noise. The result is pretty annoying, or
> amusing, depending on which way
 you look at it.

 Therefore, I think comfort
> noise has its value if DTX is used and the
 background noise is fairly
> stationary, but if the background noise or
 music is changing dynamically and
> high audio quality is desired, then the
 DTX and comfort noise should be
> turned off and all parts of the signal
 need to be transmitted.

-- 
Ticket
> URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/14#comment:2>
codec
> <http://tools.ietf.org/codec/>

______________________________________________
> _
codec mailing 
> list
[email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 24 May 2010 17:30:28 +0200

> will know that it is in an emergency call, and disable VAD, it is not always

Just for curiosity, Brian. Why is it essential for emergency calls to disable VAD?

/O

---

From: Brian Rosen <[email-masked]>
Date: Mon, 24 May 2010 11:53:08 -0400

When you make an emergency call, background is a very important source of
information.  For example, if the call taker hears someone threaten the
caller, that will inform the response.  Often the caller is in distress, and
may put the phone down, or speak faintly.  VAD will "zero out" the
background sounds.

Brian

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 24 May 2010 18:00:13 +0200

Hi Brian,

I would say: This is a task of the phone to amplify the signal during an emergency call. Of course, the phone knows that a emergency
has been called and that any vague signal can be of importance. It should then switch over to a emergency mode (disabling
background-noise removals, changed automatic gain control, etc).

This requirement needs not be covered by signaling nor codec. The phone can take care of it much better.

Christian

>From: Brian Rosen [mailto:[email-masked]]
>Sent: Monday, May 24, 2010 5:53 PM
>To: Olle E. Johansson
>Cc: [email-masked]; [email-masked]

---

From: Michael Knappe <[email-masked]>
Date: Mon, 24 May 2010 09:05:59 -0700

I agree that VAD (or DTX) needs to be negotiable.

Mike

---

From: Michael Knappe <[email-masked]>
Date: Mon, 24 May 2010 09:09:43 -0700

Not to mention any possibility of chopping off a portion of a syllable here
or there...

Mike

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 24 May 2010 12:54:12 -0400

> I agree that VAD (or DTX) needs to be negotiable.

Me too.  Specifically, I think that DTX should always be allowed within
any stream.  The decoder always MUST correctly decode a stream with or
without DTX, and the encoder SHOULD obey the decoder's preference for or
against DTX, as expressed in SDP, unless there is a reason not to obey
this preference.  Decoders MAY express no preference.

In particular, decoders must handle adaptive jitter buffering properly
with or without DTX.

Examples:
An encoder operating with push-to-talk hardware (microphone active only
when a button is depressed) should always use DTX, regardless of decoder
preference.

A decoder that cares about average bandwidth should probably request DTX
enabled, whereas a decoder that cares only about peak bandwidth should
request DTX disabled.

A decoder that cares about non-voice background sounds should request DTX
disabled.

--Ben

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 24 May 2010 18:55:28 +0200

Hello,

I do not like the idea that a user should decide on parameters that he does not understand.
Can't we develop some intelligent, automatic decision on when to use DTX? For example, switch VAD on if
a) if bandwidth is limited (dynamically controlled)
b) if transmission energy needs to be saved on mobile devices (controlled/negotiated for both sender and receiver)
c) if a lot of background noise is present (sender initiated, no negotiation required)
d) if the background noise is important (sender initiated, e.g. emergency call, but then again, the sender can amplify the
background noise instead)
Shall the controlling/negotiation take place in-band or using SDP?

With best regards,

 Christian

---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
http://www.net.uni-tuebingen.de/

>From: Michael Knappe [mailto:[email-masked]]
>Sent: Monday, May 24, 2010 6:06 PM
>To: Brian Rosen; [email-masked]; [email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Mon, 24 May 2010 13:01:04 -0400

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.

Brian

On 5/24/10 12:00 PM, "Christian Hoene" <[email-masked]> wrote:

> Hi Brian,
> 
> I would say: This is a task of the phone to amplify the signal during an
> emergency call. Of course, the phone knows that a emergency
> has been called and that any vague signal can be of importance. It should then
> switch over to a emergency mode (disabling
>>> Just for curiosity, Brian. Why is it essential for emergency calls to
>>> disable
>>> VAD?
>>> 
>>> /O
>>> 
>>> 
> 
>

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Mon, 24 May 2010 13:24:14 -0400

> I do not like the idea that a user should decide on parameters that he does not understand.

In general, parameters for bitrate, jitter buffer, sample rate, filtering,
and AEC are not exposed to the user.  They are typically managed according
to some customized algorithm designed for the hardware, network, and
application.  DTX is just one more of these settings, and would be no more
likely to be exposed to the user.  We don't need to worry about the user
interface, because in most cases there won't be one.

I think it's a good idea for the reference implementation to provide some
intelligent heuristics for use of DTX, but these heuristics should not be
a requirement of any RFC.

--Ben

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 24 May 2010 19:37:11 +0200

Hi Brian,

>implement it, but even then, there are circumstances where the phone won't

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

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 24 May 2010 19:43:04 +0200

Hi Benjamin,

>In general, parameters for bitrate, jitter buffer, sample rate, filtering, and AEC are not exposed to
>the user.  They are typically managed according to some customized algorithm designed for the
>hardware, network, and application.  DTX is just one more of these settings, and would be no more
>likely to be exposed to the user.  We don't need to worry about the user interface, because in most
>cases there won't be one.

Actually, I meant two kind of users: Those of the phone and those of the codec.
>
>I think it's a good idea for the reference implementation to provide some intelligent heuristics for
>use of DTX, but these heuristics should not be a requirement of any RFC.

Yes, you are true. But we must be precise. The requirement for some heuristics on how to set those parameters MUST be part of the
requirements document. However, the heuristics NEED NOT to be implemented in every phone but the implementer CAN choose any superior
algorithm to optimize particular application needs. Thus, a heuristic on how to select DTX should only ensure some minimal system
quality.

Christian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 24 May 2010 14:20:00 -0400

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.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 May 2010 21:36:51 -0600

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.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 27 May 2010 12:48:58 +0200

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 27 May 2010 09:14:56 -0400

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" <[email-masked]> wrote:

> 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
> 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
> 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