Teraquant 'No Fluff' Blog

Are You Struggling with Failed Negotiations or One-Way Audio?

There are many SIP networks where either calls fail entirely or issues arise when a conference bridge offering a diversity of codecs (some unsupported) cause failed negotiations or one-way audio. In addition, the increased use of VPN especially from current traditional SD-WAN implementations cause incorrect mapping of IP addresses and longer latencies. Video and voice codec negotiations fail due to no match or common ground between codecs offered by each endpoint. There might also be a problem with SIP implementation between the two vendors.

This post aims to give a high-level understanding of how Session Description Protocol, a protocol used within a SIP message, presents various media capabilities of the VoIP phones and networks to negotiate smooth and successful multimedia communications and a better user experience. When SDP in SIP is implemented correctly, it can support voice calls, video conferences, fax over IP and instant messages, as well as the distribution of multimedia. When it’s not, however, successful communication is impossible. For SIP SDP to work, both endpoints must agree on which codec will be used for the call or conference in question.

What is Codec Negotiation?

The codec encodes and compresses the analog audio containing our speech or video and compresses it into the bandwidth available on the IP network. A measure of a codec’s sophistication is its ability to carry high-definition Voice or high-fidelity VoIP audio in a small amount of bandwidth required from the network to transport the voice. For example, Opus and SILK codecs provide hi-fi quality speech up to the limit of the human ear (20kHz) or a bit lower than that for older folks like me using low digital bandwidth (down to as low as 30Kbps).

Both endpoints involved in the phone conversation must agree which codec is going to be used for a particular call in order to ensure interoperability and correct decoding of the audio sent. This process is called Codec Negotiation and occurs while the SIP signaling is setting up the call. The specific media descriptions are specified and offered in the codec list within the Session Description Protocol (SDP) part of the SIP INVITE message. It is then counter offered by the terminating endpoint during this negotiation.

If the negotiation fails, the switch or Session Border Controllers (SBC) will notice the mismatch between the parties and the fact that there is no common codec to be used, offered, or agreed upon. The SBC will then generate a SIP response message 488 “not acceptable media” or “not acceptable here”. In this case the call fails and setup never completes.

Understanding and Troubleshooting – SDP in SIP

RFC 4566 (obsoletes RFC 2327) defines the details of SDP in complete detail intended for describing multimedia sessions for purposes of session announcement, session invitation, and other forms of multimedia session initiation such as conference calls.

The SDP session description consists of several lines of text in the form <type>=<value>. The session description starts with v= line (version number, always zero) and each media level section starts with an m= line. We will focus on the media section and media attributes in more detail.

m=<media> <port> <proto> <fmt> ...

Where is the transport protocol dependent on the connection type, and is the media format description.

For subfields, the common types for RTP media are RTP/AVP or RTP/SAVP. RTP/AVP is the Audio/Video profile carried over UDP, whereas RTP/SAVP indicates Secure RTP (encrypted SRTP audio) running over UDP.

The C Field <c=> indicates the IP address where the media RTP should be sent to by the other end.

The <fmt> field indicates the payload type. The details of common payload types is shown in the table 1.1 below. For non-RTP media, the proto field could be set as UDP as indicated in the example below, transport of whiteboard (wb) media type over UDP.

m=application 32416 udp wb

The <m> field shown above, is used to indicate that audio is the payload and also the UDP port number used by the RTP.

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

This attribute provides more details such as encoding, clock rate and encoding parameters of the payload type used in the m= line. Up to one rtpmap attribute can be defined for each media format specified. Thus, we might well have the following:

a=fmtp:<format><format specific parameters>

Codec specific parameters can be included through the fmtp attribute.

m=audio 49230 RTP/AVP 18 96 97 98
a=rtpmap:18 G729/8000/1
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
a=fmtp:18 annexb=yes

During the early stages of RTP development, statically assigned payload types (0–34) were used to bind encodings to payload types. Since the payload type number space is limited and relatively small, it cannot accommodate static assignments for all existing and future encodings. So payload type numbers in the range 96–127 are used exclusively for dynamic assignment of a codec to be used for that particular call. Payload types 35–95 are unassigned and reserved for future use.

So the m= line gives a summary of all codecs to be used. The <a=> lines go into detail and provide specific codec definitions dynamically allocating a number for the payload type from 96-127 is used for that call.

For static payload types, the a=rtpmap attribute, may be omitted in case the payload details to be used are completely as per the RTP audio/video static profile for that payload type. For example: 16-bit linear encoded stereo audio sampled at 16 kHz using dynamic RTP/AVP payload type 98 for this stream:

m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2

Table 1.1  – Common payload types defined in RFC 3551

Frequently Asked Questions

Not sure what solution is right for you? Ready to chat?