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

["codec issue tracker" <[e-mail]>]

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

Comment(by hoene@…):

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

 There are no laws or regulations governing this, but it really is 'best
 practice'.
 ...
 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.

 [Hoene] 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.

 [Mike]: I agree that VAD (or DTX) needs to be negotiable.
 Not to mention any possibility of chopping off a portion of a syllable
 here or there...

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

 [Hoene]: 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?

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

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

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

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

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

 [Cullen] 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.

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