Session Description Protocol (SDP) Negotiation with Examples
Basic Offer/Answer Model for Media Session Setup
VoIP conversations use human speech audio encoded in a variety of different ways. The simplest is G.711 Pulse Code Modulation PCM 64kbit/second ranging up to sophisticated codecs such as SILK, Opus and EVS carrying high fidelity quality audio compressed, so they only require 10kbps to 20kbps of network bandwidth to transport the voice through the network. Within SIP, SDP (as defined in RFC 3264) provides a mechanism by which two or more entities intending to set up a call or conference can make use of Offer/Answer Session Description Protocol (SDP) model to arrive at a common view of a multimedia session.
Basically, one end says in SDP, “here, these are the codecs I support. Pick one”. the other end says “OK, let’s use this one”. So that’s the one they use.
Problems Relating to Codec Negotiation are Common when Setting Up SIP Calls, and it is Worth Knowing How to Troubleshoot Them
Take the case of an offer SDP which has one line of “m” containing payload types of 18 0 101:
m=audio 40024 RTP/AVP 18 0 101 c=IN IP4 184.108.40.206 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv
In case the answerer does not support any of these codes, the call would fail. The most common SIP response error code is 488 ‘Not Acceptable Here’ being sent back for the Offer.
To avoid this failure, the Offer should contain at least one common codec/payload type as shown in the example below – in which case the codec negotiation is successful, and the call is established. Note, the G.711 A-law psophometric filtering used in North America was absent in the failed call.
m=audio 40040 RTP/AVP 8 18 0 101 c=IN IP4 220.127.116.11 a=rtpmap:8 PCMA/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20
a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
Consider another example of offer SDP, which has one line of “m”, containing payload times of 8 and 101
m=audio 35904 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The above offer is answered by an SDP with one line of “m” containing codecs 8, but 120 for DTMF and similarly marked as sendrecv:
a=audio 25454 RTP/AVP 8 120 a=rtpmap:8 PCMA/8000 a=rtpmap:120 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv
The “a=fmtp:” attribute in the answer specifies 101 as payload type number instead of 120 which is an implementation error since the fmtp attribute is meant to apply to the telephone-events payload. The “events” description in SDP specifies DTMF events. So, to avoid DTMF issues, the a=fmtp should also use the payload type of 120 in this case.
In the subsequent RFC 3264, the Offer/Answer model was further extended to negotiate media description changes like the ability to change transport protocols (e.g., RTP Profiles) within a call, i.e. to change from SIP over TCP to SIP over UDP.
How Extensive is the Problem and how much effort is worth spending to fix it?
If customers are complaining of dropped calls or failed calls, such events may be extremely rare and intermittent. Alternatively, they may be common and affecting high-value blue ribbon customers. Teraquant uses big data analytics platforms to analyze call records and raw data from telephony systems with wide flexibility in order to present how frequently problems happen, when they occur and what events correlate with those failures, potentially revealing the root cause.
Is it worth contacting that customer to fix their Codec mismatch issue?
In the example below, 3% of all calls fail with “Not Acceptable Here” [SIP response code = 488] . This is a significant proportion of the calls and probably worth addressing the issue.
Low cost and flexible and easy to use tools exist today to eradicate all problems in your SIP network and get to the root cause.
Contact Teraquant for more help.