3.2 Session Description Protocol (SDP) & Early Offer vs. Delayed Offer

3.2 Session Description Protocol (SDP) & Early Offer vs. Delayed Offer

While SIP handles the signaling, session establishment, and teardown of a communication channel, it does not transport the media itself. Instead, SIP relies on the Session Description Protocol (SDP), specified in RFC 4566, to describe multimedia session capabilities, media transport addresses, and codec parameters.

---

1. SDP Structure & Syntactic Hierarchy

An SDP message is a text-based payload formatted as <type>=<value>. SDP descriptions are split into two levels: the Session-Level description (global parameters applying to the entire session) and one or more Media-Level descriptions (parameters specific to individual audio, video, or data streams).

Annotated SDP Payload

v=0
o=CiscoSystemsCCM-SIP 16298371 1 IN IP4 10.1.1.10
s=SIP Call
c=IN IP4 10.1.1.10
t=0 0
m=audio 24580 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Breakdown of SDP Fields

Session-Level Fields

• v=0: Protocol version. Currently, only SDP version 0 is defined by RFC 4566.
• o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>: Owner/creator identity and session identifiers. In CUCM, this identifies the CallManager node, session sequence counter, and origin IP.
• s=SIP Call: Subject or session name (a single space or string required by standard).
• c=<nettype> <addrtype> <connection-address>: Connection data. IN stands for Internet, IP4 indicates IPv4 (or IP6), followed by the IP address where the endpoint expects to receive incoming RTP media.
• t=0 0: Time description. Start time and stop time. 0 0 signifies an unbounded, permanent interactive session.

Media-Level Fields

• m=<media> <port> <proto> <fmt ...>: Media announcements.
  • <media>: audio, video, image, or application.
  • <port>: The UDP port number on which the endpoint listens for incoming media packets (e.g., 24580). Port 0 indicates media stream rejection or teardown.
  • <proto>: Transport protocol, typically RTP/AVP (Real-Time Transport Protocol Audio/Video Profile) or RTP/SAVP (Secure RTP Audio/Video Profile).
  • <fmt ...>: Space-delimited list of RTP payload format types in order of preference. In the example above, 0 = G.711u, 8 = G.711a, 18 = G.729, and 101 = dynamic payload for RFC 2833/4733 telephony events.
• a=rtpmap:<payload_type> <encoding_name>/<clock_rate>[/<encoding_parameters>]: Maps dynamic or static payload numbers to specific codecs and sampling frequencies (e.g., a=rtpmap:18 G729/8000).
• a=fmtp:<format> <parameters>: Format-specific parameters. For instance, a=fmtp:18 annexb=no specifies G.729 without Annex B silence suppression; a=fmtp:101 0-15 declares support for DTMF digits 0 through 15.
• a=ptime:<integer>: Packetization time interval in milliseconds (default is 20 ms for VoIP).
• a=<direction>: Media stream directionality. Can be a=sendrecv (normal bidirectional conversation), a=sendonly (call hold / MOH playback), a=recvonly (held party listening), or a=inactive (session muted in both directions).

---

2. Early Offer (EO) vs. Delayed Offer (DO)

In SIP call processing, the exchange of SDP follows an Offer/Answer Model governed by RFC 3264. The negotiation determines where in the SIP transaction the SDP offer and the SDP answer reside.

Early Offer Sequence

1. Calling party (UAC) sends INVITE with SDP Offer listing supported codecs and its local RTP receiving IP and port.
2. Called party (UAS) processes the offer, selects a common codec, and returns an SDP Answer containing its local RTP IP and port in a 183 Session Progress (with early media) or 200 OK.
3. UAC confirms receipt with an ACK.
4. RTP media flows immediately. Early media cut-through ensures ringback tones, automated attendant prompts, and carrier intercept messages ("The number dialed has changed...") are heard without clipping.

Delayed Offer Sequence

1. UAC transmits an INVITE with no SDP body.
2. UAS receives the INVITE and must generate the SDP Offer in its 200 OK response, listing its own supported codecs and media ports.
3. UAC receives the 200 OK, analyzes the offered codecs, selects the preferred match, and returns the SDP Answer inside the ACK message.
4. RTP media cannot begin until the ACK arrives at the UAS. As a result, early media cannot be transmitted prior to call pickup without complex renegotiation.

---

3. Media Termination Point (MTP) Evolution & Best Effort Early Offer

The Legacy MTP Dilemma

Historically, Cisco IP Phones communicated with CUCM via Skinny Client Control Protocol (SCCP) or early SIP implementations that did not produce an SDP offer until the endpoint received media parameters from the switch. When routing calls out a SIP trunk requiring Early Offer, CUCM had no SDP to put in the initial outbound INVITE.

To bridge this gap, CUCM required the administrator to check Media Termination Point Required on the SIP trunk:

• CUCM pre-allocated an MTP from its media resource group list.
• The MTP's IP address and listening port were inserted into the outbound INVITE's SDP.
• When the trunk responded with the SDP answer, CUCM bound the MTP to the phone's media stream.

Severe Limitations of Forced MTP:

• Resource Exhaustion: Every call consumed DSP or software MTP channels on the gateway or CUCM node.
• Codec Restrictions: With MTP Required checked, the trunk offers only the single codec chosen in MTP Preferred Originating Codec (a G.711 or G.729 variant), so wideband audio and video were not possible on that trunk.
• Hairpinning: Media packets traversed the MTP server rather than flowing point-to-point between endpoints.

CUCM Early Offer Options in the SIP Profile

Modern CUCM versions replace the trunk-wide MTP checkbox with the SIP Profile setting Early Offer support for voice and video calls, which has three values:

1. Disabled (Default Value): The trunk sends Delayed Offer unless MTP Required is checked on the trunk.
2. Best Effort (no MTP inserted): If CUCM already knows the calling device's media capabilities (true for current Cisco SIP phones and for SIP trunks that sent an offer), it sends an Early Offer built from them. If it does not, it sends a Delayed Offer instead of inserting an MTP.
3. Mandatory (insert MTP if needed): CUCM always sends an Early Offer, using the calling device's own SDP when available and allocating an MTP only for the calls that need one.

Both newer options preserve end-to-end codec negotiation, wideband audio, and video for every call that does not need an MTP. Choose Mandatory when the provider rejects Delayed Offer; choose Best Effort when you would rather send a Delayed Offer than consume MTP resources.

---

4. Reliable Provisional Responses: PRACK & 100rel (RFC 3262)

Under basic SIP (RFC 3261), provisional responses (1xx series, like 180 Ringing and 183 Session Progress) are transmitted unreliably when UDP transport is used. If a 183 Session Progress packet carrying an SDP answer is lost over the WAN, the UAC never receives the media parameters, causing clipped speech or dead air.

To ensure reliable delivery, RFC 3262 defines the 100rel option tag (reliable provisional responses):

• The UAC indicates capability by inserting Supported: 100rel in the INVITE.
• If the UAS requires reliable provisional responses, it sends a 18x response with Require: 100rel and includes an RSeq (Response Sequence) header:

  SIP/2.0 183 Session Progress
  Via: SIP/2.0/UDP 10.1.1.10:5060;branch=z9hG4bK2b3c4d5e
  Require: 100rel
  RSeq: 31415
  Content-Type: application/sdp
  

• The UAC must acknowledge receipt by sending a PRACK (Provisional Response Acknowledgement) request containing an RAck header that references the RSeq number, CSeq number, and method:

  PRACK sip:2002@10.1.1.20:5060 SIP/2.0
  RAck: 31415 101 INVITE
  

• The UAS acknowledges the PRACK with a standard 200 OK.
• This mechanism guarantees that SDP carried within provisional responses is reliably negotiated, enabling consistent early media cut-through.