Demystifying SIP Early Offer vs. Late Offer: Architecture and Signaling Workflows

Overview

This guide explains the fundamental differences between Early Offer (EO) and Late Offer (LO) media negotiation in Session Initiation Protocol (SIP). You will learn how the RFC 3264 Offer/Answer model functions under both approaches, how message flows differ during call setup, and how Session Border Controllers (SBCs) handle interworking between the two models.

Key takeaways

• Early Offer includes the SDP offer in the initial SIP INVITE message, establishing media capabilities immediately.
• Late Offer delays sending the SDP offer until the 200 OK (or 183 Session Progress) from the called party, requiring the calling party to return the SDP answer in the ACK.
• Late Offer avoids codec mismatches on the calling side by letting the called endpoint present its supported media capabilities first.
• Session Border Controllers (SBCs) are commonly deployed to convert between Early Offer and Late Offer when interconnecting disparate enterprise systems and ITSP trunks.

Prerequisites

• Understanding of basic SIP signaling sequences (INVITE, 18x, 200 OK, ACK)
• Familiarity with Session Description Protocol (SDP) syntax and media attributes

Guide

1. section #1

   1. The SIP Offer/Answer Model (RFC 3264) The Session Initiation Protocol relies on the SDP Offer/Answer model defined in RFC 3264 to establish audio, video, or data sessions between endpoints. One peer constructs an SDP 'Offer' listing supported media types, transport protocols, IP addresses, ports, and preferred codecs. The receiving peer evaluates the offer against its local capabilities and generates an SDP 'Answer' indicating the accepted media parameters. RFC 3261 permits two distinct sequences for exchanging these descriptions during initial call setup: Early Offer and Late Offer (delayed offer). The primary distinction lies in which SIP message carries the initial SDP offer and which peer acts as the offering party.

2. section #2

   2. Early Offer (EO) Architecture and Message Flow In an Early Offer scenario, the calling endpoint (UAC) includes its SDP offer directly inside the initial SIP INVITE message. The called endpoint (UAS) receives the INVITE, inspects the proposed media capabilities, selects mutually supported parameters (such as codec and sampling rate), and returns its SDP answer in a reliable provisional response (183 Session Progress) or the final 200 OK response. Because media capabilities are known immediately upon receiving the INVITE, the called endpoint can allocate DSP resources and prepare early media (e.g., custom ringback tones) without delay. Early Offer is the standard operational mode for most SIP trunks, WebRTC gateways, and carrier networks.

   UAC (Caller)                 UAS (Callee)
        |                            |
        |--- INVITE (SDP Offer) ---->|
        |<-- 100 Trying -------------|
        |<-- 180 Ringing (no SDP) ---|
        |<-- 200 OK (SDP Answer) ----|
        |--- ACK ------------------->|
        |                            |
        |<====== RTP Stream ========>|

3. section #3

   3. Late Offer (LO) Architecture and Message Flow In a Late Offer (also known as Delayed Offer) scenario, the calling endpoint sends an initial SIP INVITE without an SDP body. This signals to the called party that it must formulate the SDP offer. Upon answering or progressing the call, the UAS includes its full list of media capabilities (SDP Offer) in the 200 OK response (or optionally in a 183 Session Progress message if PRACK/100rel is supported). The calling party (UAC) processes this offer, selects compatible media attributes, and embeds its SDP Answer inside the SIP ACK request. Late Offer is historically common in legacy PBX integrations and Cisco Unified Communications Manager (CUCM) deployments where the originating endpoint's media capabilties are unknown prior to call routing.

   UAC (Caller)                 UAS (Callee)
        |                            |
        |--- INVITE (No SDP) ------->|
        |<-- 100 Trying -------------|
        |<-- 180 Ringing ------------|
        |<-- 200 OK (SDP Offer) -----|
        |--- ACK (SDP Answer) ------>|
        |                            |
        |<====== RTP Stream ========>|

4. section #4

   4. Early Media and 183 Session Progress Nuances Handling early media (such as carrier announcements or network ringback) varies significantly between Early Offer and Late Offer. Under Early Offer, early media is straightforward: the UAS returns a 183 Session Progress containing the SDP Answer, establishing a one-way or two-way RTP path before the call is answered. Under Late Offer, early media requires the UAS to send its SDP Offer in a 183 Session Progress message using provisional response acknowledgement (PRACK, RFC 3262). The UAC then returns its SDP Answer in the PRACK request or subsequent 200 OK to the PRACK. If PRACK is not supported by both endpoints, Late Offer cannot reliably establish early media audio paths before the final 200 OK.

5. section #5

   5. SBC Conversion and Interworking Strategies Interoperability issues frequently arise when an enterprise system utilizing Late Offer attempts to communicate directly with an Internet Telephony Service Provider (ITSP) that strictly enforces Early Offer. Session Border Controllers (SBCs)—such as Cisco CUBE, Oracle Enterprise SBC, or Kamailio—resolve this by performing Early Offer to Late Offer interworking. When receiving a Late Offer INVITE from an internal PBX, the SBC can delay forwarding the INVITE to the carrier until it negotiates media internally, or it can insert a local media profile to construct an Early Offer INVITE toward the carrier on behalf of the caller.

   [CUCM / PBX]                 [SBC]                   [ITSP Carrier]
     (Late Offer)                                         (Early Offer)
          |
          |--- INVITE (No SDP) ---->|
          |                         |-- INVITE (Allocated SDP Offer) -->
          |                         |<-- 200 OK (SDP Answer) -----------
          |<-- 200 OK (SDP Offer) --|
          |--- ACK (SDP Answer) --->|
          |                         |--- ACK -------------------------->
          |                         |

6. section #6

   6. Summary of Engineering Trade-offs Choosing or configuring Early Offer versus Late Offer depends on topology requirements. Early Offer simplifies media setup, reduces signaling round-trips for early media, and is required by most public SIP trunks. However, it requires the originating system to know its media parameters (IP, port, codec list) before routing the call. Late Offer offers maximum flexibility for dynamic media termination (such as IVRs or hunt groups) and avoids premature codec commitment, but introduces complexity around ACK-based SDP answers and PRACK requirements for early media. Best practice in modern VoIP architecture is to enforce Early Offer at the peering boundary using SBC interworking functions.

Further reading

• RFC 3261: SIP: Session Initiation Protocol
• RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)
• RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP)
• Cisco CUBE Configuration Guide: Understanding Early Offer and Delayed Offer