Subject: Re: [codec] [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks

From: Henry Sinnreich <[email-masked]>
Date: Tue, 25 Aug 2009 09:31:57 -0700

FYI - just in case you may have missed it.
Such functions are distinct from codecs, but may be still of interest.
Thanks, Henry

On 8/25/09 9:15 AM, "John Atkinson" <[email-masked]> wrote:

Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks

ITU SG16 has developed a framework for coordination of voice quality signal processing in networks that have more than one network element capable of doing specific voice quality signal processing functions. This framework was developed to allow optimal placement of the VQSP functions within the network and avoid voice quality degradation due to undesirable side-effects of the interaction of the individual voice quality enhancement functions and to improve voice quality by only applying a given VQ function in one location in the network.

The five voice quality signal processing features commonly applied are

*         Echo Control (control of echo from a hybrid)
*         Acoustic Echo Control
*         Automatic Gain Control
*         Feedback Gain Control
*         Background Noise Reduction

A Node can potentially be capable of applying each of the above five VQSP functions in each of the two directions of a voice path. Doing both Echo control and Acoustic echo control on the same signal is not desirable or necessary nor is applying both automatic gain control and feedback gain control on the same signal desirable or necessary. In addition, it's usually optimal to do echo control as close to the echo source as possible.

This ITU work has not defined the actual method by which network elements can communicate which VQ functions are enabled or present in the network and in which direction they are capable of being applied. ITU has sent a Liason Statement to IETF requesting assistance defining how VoIP nodes communicate VQSP capability/state information to other nodes.

For Echo Control ,  VoIP implementors are currently aware of two existing methods of communicating between nodes that echo cancellation is being done. In ISUP, the Echo control device indicator in the Nature of Connection Indicators IE is used to indicate the presence of an echo control device in the forward direction and the Echo Control device Indicator in the Backwards Call Indicators IE is used to indcate the presence on an echo control device in the backwards direction. RFC 3108 defines a session description protocol attribute line for echo control.

a=ecan:<directionFlag><ecanEnable><ecanType>
which can be used to indicate the presence of G.165/G.168 echo cancellers in one or both directions.

In addition, RFC 3108 defines an attribute line for gain control

a=gc:<directionFlag><gcEnable><gcLvl>

which can be used to indicate the presence gain control in one or both directions

It would be beneficial for the Dispatch WG to review  the ITU Liason Statement  (which can be viewed at  https://datatracker.ietf.org/liaison/505/ ) and discuss the best method of communicating VQSP functions  between nodes .  Possible solutions include using SDP, SIP headers, RTP, RTCP, or some new on-path control protocol.

John Atkinson
[email-masked]

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 27 Aug 2009 10:42:10 +0400

Thanks.

best regards,

Slava Borilin

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Sinnreich
Sent: Tuesday, August 25, 2009 8:32 PM
To: John Atkinson; [email-masked]
Subject: Re: [codec] [dispatch] Optimal placement of Voice Quality
Signal Processing (VQSP) features within Networks

Optimal placement of Voice Quality Signal Processing (VQSP) features
within Networks

ITU SG16 has developed a framework for coordination of voice quality
signal processing in networks that have more than one network element
capable of doing specific voice quality signal processing functions.
This framework was developed to allow optimal placement of the VQSP
functions within the network and avoid voice quality degradation due to
undesirable side-effects of the interaction of the individual voice
quality enhancement functions and to improve voice quality by only
applying a given VQ function in one location in the network.  

 

A Node can potentially be capable of applying each of the above five
VQSP functions in each of the two directions of a voice path. Doing both
Echo control and Acoustic echo control on the same signal is not
desirable or necessary nor is applying both automatic gain control and
feedback gain control on the same signal desirable or necessary. In
addition, it's usually optimal to do echo control as close to the echo
source as possible. 
 
This ITU work has not defined the actual method by which network
elements can communicate which VQ functions are enabled or present in
the network and in which direction they are capable of being applied.
ITU has sent a Liason Statement to IETF requesting assistance defining
how VoIP nodes communicate VQSP capability/state information to other
nodes. 

For Echo Control ,  VoIP implementors are currently aware of two
existing methods of communicating between nodes that echo cancellation
is being done. In ISUP, the Echo control device indicator in the Nature
of Connection Indicators IE is used to indicate the presence of an echo
control device in the forward direction and the Echo Control device
Indicator in the Backwards Call Indicators IE is used to indcate the
presence on an echo control device in the backwards direction. RFC 3108
defines a session description protocol attribute line for echo control. 

a=ecan:<directionFlag><ecanEnable><ecanType>
which can be used to indicate the presence of G.165/G.168 echo
cancellers in one or both directions. 

which can be used to indicate the presence gain control in one or both
directions 

It would be beneficial for the Dispatch WG to review  the ITU Liason
Statement  (which can be viewed at
https://datatracker.ietf.org/liaison/505/ ) and discuss the best method
of communicating VQSP functions  between nodes .  Possible solutions
include using SDP, SIP headers, RTP, RTCP, or some new on-path control
protocol.

John Atkinson
[email-masked]