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.