1. ACLI Configuration Guide
  2. Transcoding
  3. Comfort Noise Transcoding

Comfort Noise Transcoding

The Comfort Noise (CN) codec provides a means of encoding periods of silence that occur in an audio stream into a low-level sound that confirms to the listener that the call remains active. In a scenario where the endpoint does not support CN packets during periods of silence, the listener might think that the phone call disconnected. To avoid such a scenario, you can enable the Oracle® Enterprise Session Border Controller (E-SBC) to transcode the CN packet into in-band RTP packets of the voice codec resulting in low-level sound during silences in the audio stream.

Without CN transcoding enabled, the E-SBC forwards all of the CN packets through to the endpoint on ingress and back out again on egress. Also, without CN transcoding enabled, the E-SBC passes through all of the thousands of in-band RTP packets that make up the silences when the endpoint does not support CN. Passing thousands of RTP packets can use a large amount of bandwidth. To save bandwidth in scenarios where one endpoint supports CN and the other endpoint does not, you can set the codec policy to transcode a CN packet into in-band audio RTP packets containing silence. Such transcoding results in a lower transmission rate of RTP packets because the system sends only one CN packet on egress rather than the thousands of RTP packets that would otherwise pass through between ingress and egress.

To configure the E-SBC to transcode the CN codec, you must add "CN" to the add-codecs-on-egress list in the codec-policy configuration.

For transcoding comfort noise:

  • The side of the call that does not support CN, must use an audio codec that the SBC supports for transcoding. See "Transcodable Codecs."
  • The side of the call that supports CN, must use an audio codec that the SBC supports as interoperable with CN. Interoperable codecs: (non-signalling codecs) PCMA, PCMU, and G.726.

Be aware that enabling CN transcoding can generate periods when no RTP packets flow on the side of the call that sends and receives CN packets. Depending on the values set in the following guard timer parameters, the system might detect no flow and drop the call.

  • flow-time-limit
  • initial-guard-timer
  • subsq-guard-timer
  • tcp-flow-time-limit
  • tcp-initial-guard-timer
  • tcp-subsq-guard-timer
Setting the value for a guard timer parameter to zero disables the parameter. When you set the parameters to zero, the system does not terminate any calls due to lack of RTP packets. Set the guard timers in the media-manager-config object. 
ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#

Supported and Unsupported Platforms and Behavior

Comfort Noise transcoding supports:
  • the Acme Packet 1100, Acme Packet 3900, Acme Packet 4600, and the Acme Packet 6300.
  • simultaneous transcoding of comfort noise and telephone event (RFC 2833) to and from in-band DTMF.
  • using either the comfort-noise-generate SPL or comfort noise transcoding. The system cannot support both methods at the same time.
  • High Availability (HA) as currently implemented, regarding the configuration and media flows.
Comfort Noise transcoding does not support:
  • the Acme Packet 6100, Server Edition, and VMWare.
  • scenarios involving H.323 call signaling and IWF (SIP<->H.323).
  • hairpin scenarios.
  • dynamically defined payload types.

Troubleshooting

  • Inspect the SDP m= and a= lines for correct modifications as a result of the codec policy.
  • When you enable SIP debug, the sipmsg.log shows "CN-XCODE-GEN-Enabled" for the flow that you enabled to generate CN.

System Behavior Without Comfort Noise Transcoding

The following scenarios describe how the Oracle® Enterprise Session Border Controller (E-SBC) handles Comfort Noise (CN) packets without transcoding enabled.

Both sides offer and answer support for CN

CN packets pass through the E-SBC from the Offerer to the Answerer and from the Answerer to the Offerer.

Neither side offers or answers support for CN

Any silence in the audio stream passes through the E-SBC in the RTP audio packets.

One side supports CN, and the other side does not

The Offerer does not send CN packets because the Answerer advertises no support for CN. Any silence in the audio stream passes through the E-SBC in the RTP audio packets.

System Behavior With Comfort Noise Transcoding

The following scenarios show how the Oracle® Enterprise Session Border Controller (E-SBC) handles Comfort Noise (CN) packets with transcoding enabled.

General Behavior in the Scenarios

When the SDP produced by the ingress codec-policy O¹ contains an audio codec that interoperates with CN (PCMA, PCMU, and G.726), and the egress codec-policy allows the interoperable codec and is configured to add CN, the E-SBC adds the default payload type of 13 to the SDP m= line.

When the SDP produced by the ingress codec-policy O¹ does not contain a codec that interoperates with CN, and the egress codec-policy is configured to add an interoperable audio codec plus the CN codec, the E-SBC adds the default payload type of 13 to the SDP m= line.

When the E-SBC adds the CN codec, the system adds the following default a= line to the SDP:

a=rtpmap:13 CN/8000

For more information about the concepts and terms used in the scenarios, see "Transcoding Processing Overview."

Comfort Noise Transcoded Scenario

In a typical scenario with CN transcoding enabled, the E-SBC transcodes the ingress audio codec for the media stream to PCMA. The DSP detects silence in the media stream from the Offerer, translates the silence into a CN packet, and sends the packet to the Answerer. The Answerer sends a CN packet to the DSP, which translates the packet into silence in the media stream and sends the packet to the Offerer. The result is silence on egress.

Ingress codec policy Setting Egress codec policy Setting
allow codecs * allow codecs *
add codecs on egress N/A add codecs on egress PCMA CN
order codecs N/A order codecs N/A

The side of the call that does not support CN, must use an audio codec that the E-SBC supports as transcodable, represented by "x" in the call flow.

The side of the call that supports CN, must use an audio codec that the E-SBC supports as interoperable with CN, represented by PCMA in the call flow.

Audio Codec Not Transcoded - Comfort Noise Codec Transcoded Scenario

In the following scenario, the ingress codec policy and the egress codec policy both allow all offered codecs. The setting for add-codecs-on-egress is CN.

  1. The Offerer sends an offer O° to the E-SBC with an SDP m-line for an audio codec PCMU, but with no CN signaling codec
  2. The codec-policy for the ingress realm allows the audio codec, PCMU, and outputs O¹ which contains PCMU.
  3. The E-SBC egress codec-policy takes O¹ as input and adds CN after checking that at least one of the audio codecs in O¹ interoperates with CN, resulting in PCMU and CN in output O².
  4. The Answerer responds with the answer in Aº containing the PCMU audio codec and the signaling codec CN, indicating the Answerer supports comfort noise. The egress codec-policy produces answer A¹ with no changes.
  5. The E-SBC removes CN from A¹ because it was not offered by the Offerer. The result contains only the audio codec PCMU.

Even with CN transcoding enabled, the E-SBC does not transcode the audio codec (PCMU). The E-SBC transcodes silence detection and generation, as well as CN packet detection and generation.

Ingress codec policy Setting Egress codec policy Setting
allow codecs * allow codecs *
add codecs on egress N/A add codecs on egress CN
order codecs N/A order codecs N/A

Comfort Noise and Telephone Event Codecs Both Transcoded Scenario

In the following scenario, the E-SBC transcodes both Comfort Noise (CN) and telephone event codecs.

  1. The Offerer sends an offer (O°) with an SDP m-line for an audio codec PCMU to the E-SBC, and includes both CN and telephone-event signaling codecs.
  2. The codec-policy for the ingress realm allows all codecs and outputs O¹. The E-SBC egress codec-policy takes O¹ as input, allows all codecs, and produces output O².
  3. The Answerer responds with the answer in A° containing the PCMU audio codec. The egress codec-policy produces answer A¹ with no changes.
  4. The E-SBC applies the add-codecs-on-egress parameter from the ingress codec-policy to add CN and telephone-event to A¹. The result contains the audio codec PCMU and the CN and telephone-event signaling codecs because the E-SBC excepts signalling codecs from the rule that the system can apply the add-codecs-on-egress parameter only by the egress codec policy.

Even with CN transcoding enabled, the E-SBC does not transcode the audio codec (PCMU). The E-SBC transcodes silence detection and generation, as well as CN packet detection and generation. The E-SBC transcodes telephone-events to in-band DTMF audio.

Ingress codec policy Settings Egress codec policy Settings
allow codecs * allow codecs *
add codecs on egress CN telephone event add codecs on egress N/A
order codecs N/A order codecs N/A
dtmf-in-audio preferred dtmf-in-audio preferred