A codec is a device or software capable of encoding or decoding a digital data stream or signal. Audio codecs can encode or decode a digital data stream of audio. Video codecs encode or decode digital video streams.

This chapter describes the basics of encoding digital voice samples using codecs and how to configure them.

Cisco Unified Border Element (CUBE) uses codecs to compress digital voice samples to reduce bandwidth usage per call.

Configuring codecs allows the CUBE to act as a demarcation point on a VoIP network and allows calls on a specific dial peer to be established only if the desired codec criteria are satisfied. Also, preferences can be used to determine which codecs are selected over others.

If codec filtering is not required, CUBE also supports transparent codec negotiations. The codec filtering enables negotiations between endpoints with CUBE leaving the codec information untouched.

The following illustrations show how codec negotiation is performed on CUBE. Two VoIP clouds must be interconnected. In this scenario, both VoIP 1 and VoIP 2 networks have G.711 a-law that is configured as the preferred codec.

In the first example, the CUBE router is configured to use the G.729a codec. This can be done by using the appropriate codec command on both VoIP dial peers. When a call is set up, CUBE accepts only G.729a calls, thus influencing the codec negotiation.

In the second example, the CUBE dial peers are configured with a transparent codec and this leaves the codec information that is contained within the call signaling untouched. Because both VoIP 1 and VoIP 2 have G.711 a-law as their first choice, the resulting call is a G.711 a-law call.

Note	H.323 protocol is no longer supported from Cisco IOS XE Bengaluru 17.6.1a onwards. Consider using SIP for multimedia applications.

While using the voice-class codec transparent, only the offer is passed transparently (without filtering). Codec filtering is carried out on SDP content in ANSWER messages. Only the first codec in the offer list is included in the outbound message.

Note	You can use 'pass-thru content sdp,' if you do not want to involve CUBE in the codec negotiation.

When a VoIP call is established, the digitized audio and video samples must be transmitted. These samples are often called the media payload. The following media protocols specify the standards related to transmission of media payload in VoIP networks:

• Real-Time Transport Protocol (RTP)—RTP is a Layer 4 protocol that is encapsulated inside UDP segments. RTP carries the actual media voice samples in a call.

• Real-Time Control Protocol (RTCP)—RTCP is a companion protocol to RTP. Both RTP and RTCP operate at Layer 4 and are encapsulated in UDP. RTP and RTCP typically use UDP ports 16384 to 32767, though these ranges may vary according to hardware platform. RTP uses the even port numbers in that range, whereas RTCP uses the odd port numbers. While RTP is responsible for carrying the media payload, RTcP carries information about the RTP stream such as latency, jitter, packets, and octets sent and received.

• Compressed RTP (CRTP)—One of the challenges with RTP is its overhead. Specifically, the combined IP, UDP, and RTP headers are approximately 40 bytes in size, whereas a common voice payload size on a VoIP network is only 20 bytes, which includes 20 ms of voice by default. In that case, the header is twice the size of the payload. cRTP is used for RTP header compression and can reduce the 40-byte header to 2 or 4 bytes in size (depending on whether UDP checksums are in use), as shown in the figure below.

  

• Secure RTP (SRTP)—To help prevent an attacker from intercepting and decoding or possibly manipulating media packets, SRTP encrypts RTP packets. In addition, SRTP provides message authentication, integrity checking, and protection against replay attacks.

  VPN technology is used to protect traffic between sites. Sending SRTP via a VPN tunnel results in the encryption of traffic that is already secure, adding significant overhead and bandwidth needs. It is recommended that SRTP is used for media traffic, and that is excluded from VPN tunnels. By encrypting media directly on communicating endpoints, it is possible to realise a more secure solution, that requires less bandwidth and infrastructure investment.

Voice Activity Detection (VAD) is a technology that works with the human nature of voice conversations, mainly that one person listens while the other talks. VAD classifies traffic as speech, unknown, and silence. Speech and unknown payloads are transported, but silence is dropped. This accounts for approximately 30 percent savings in bandwidth over time.

VAD can significantly reduce the amount of bandwidth that is required by a media stream. However, VAD has a few negative attributes that must be considered. Because no packets are sent during silence, the listener can get the impression that the talker has been disconnected. Another characteristic is that it takes a moment for VAD to recognize the speech as having started again, and as a result, the first part of the sentence can be clipped. This can be annoying to the listening party. Music on Hold (MoH) and fax can also cause VAD to become ineffective because the media stream is constant.

VAD is enabled by default in CUBE dial peers as long as the codec selected supports it. VAD can be disabled at the VoIP dial peer using the no vad command. Some codecs, such as G.729b and G.729ab, support Comfort Noise Generation (CNG). When VAD is enabled, white noise is played to the listener during times when no packets are received. This leads the listener to believe that call is still connected. Cisco IP Phones and most gateways support CNG.

G.729 Annex-B and G.723.1 Annex-A include an integrated VAD function, but otherwise performs the same as G.729 and G.723.1, respectively.

Note	VAD to NO-VAD calls is not supported by Cisco Unified Border Element (CUBE). This confirms that CUBE cannot generate comfort noise to fill periods of silence.

The amount of bandwidth that is required varies by the codec and the transmission media. Two events require bandwidth. The media stream itself requires bandwidth between 17–106 kbps depending on codec, header compression, and Layer 2 and 3 headers. In addition, call signaling must be taken into account. While bandwidth required by call signaling is much smaller, problems occur when this traffic is dropped in congested networks.

The table below gives calculations for the default voice payload sizes in Cisco Unified Communications Manager or CUBE. For additional calculations, including different voice payload sizes and other protocols, use the TAC Voice Bandwidth Codec Calculator (registered customers only). For an explanation of each of the column headings, see the table below.

CUBE is required to support the codec used between endpoints. g729r8 is supported by default. All other codecs have to be configured. The following codecs are supported: