SIP Media Management: Early Offer vs. Late Offer

I hate being late. Just ask my wife. She has grown used to the fact that I like being in our seats at least 20 minutes prior to the start of a movie, but she never fails to point out that we are the only ones in the theater at that time.  Thankfully, she has learned to bring a book or her knitting and make the best of it.

She, on other hand, has no problem with being late. In fact, she will start getting dressed to go out sometime around the time I want to leave. This has led to me naming a departure time that’s even too early for me.

It’s an endless cycle, yet somehow we continue to stay married.

The creators of SIP must have been thinking about people like my wife and me when they developed the protocol. They realized that some folks absolutely need to be early and others are better suited to being late. Thus, they came up with early offer and late offer.

Note:  Some people refer to late offer as delayed offer, but I prefer the former.

If you are a regular reader of this blog, you already know that SIP is a signaling protocol and Session Description Protocol (SDP) describes a session’s media. That separation allows SIP to create sessions for any number of media types. It’s not just voice, video, or instant message.   It’s any real-time data you wish to use.


For a deeper understanding of SDP, please refer to Understanding Session Description Protocol (SDP).


You should also be very familiar with the idea of putting SDP in the message body of an INVITE request. The headers of the INVITE describe the kind of session you want to establish and the SDP describes the media you are willing to send and receive. For instance, an Avaya telephone will typically send SDP that contains entries for G.711, G.729, G.723, and G.722 codec types.

The recipient of that INVITE will parse the SDP, decide which codec it will use, and send its own SDP back in the 200 Ok response. Note that the called party gets to see the caller’s SDP before showing his. In other words, the caller lays his cards out on the table and allows the called party to decide which hand to play.

This is called early offer. Early offer means SDP in the INVITE. Early offer gives the power of choosing the ultimate media for a session over to the recipient.

However, what if you didn’t want the called party to have all that power? What if you wanted the caller to hold his cards close to the vest and wait until the called party shows his?

This is where late offer comes in.

With late offer, there is no SDP in the INVITE request. The messages exchanged between the caller (user agent client) and the called party (user agent server) are identical, but responsibility for choosing the media shifts from one to the other.

In late offer, the called party receives an INVITE with no message body. He does all the usual stuff to process the INVITE (e.g. send a 180 Ringing), but is unaware of what codec might be involved in the session. When the call is answered, a 200 Ok with SDP is sent and the caller responds back with an ACK. However, the ACK will now contain the SDP that would have been sent in the INVITE. With this change in SDP placement, the caller gets to decide which codec will be used for this session.

Early offer = SDP in INVITE

Late offer   = SDP in ACK

When I first started working with SIP, early offer was the norm. Of course, back then we were working with either basic SIP proxies or point-to-point SIP clients. A lot has changed since then and we now have very sophisticated session management and call processing. These smarter network components want to implement call admission control and bandwidth management. To do so, they need to seize control from the endpoints and make centralized decisions for the greater good of all. So, even though a client may want to use G.722, it may not be the best choice at the time. Late offer allows the core communications system to play the traffic cop and make the codec decisions.

I hope this makes sense. If it helps, you can think of me as early offer and my wife as late offer. I am all gung-ho about getting to the theater early, but she has the final say. For better or worse, isn’t that the case with most aspects of married life?

In a future article I will tackle early media vs. late media.  Stay tuned for more fun and games!

49 comments

  1. Hi Andrew,

    Thanks for another good article. I wrote something similar here: http://www.jitterjabber.com/session-description-protocol-delayed-offer/

    It would be good to get your feedback on configurable late offer within Avaya platforms (CM, SM etc) and whether or not this is possible. I’ve seen the ability to change this on Cisco UC platforms.

    1. Jonathan Els · · Reply

      Cisco does DO by default, and has some issues with EO. Most revolve around media terminate and midcall events.

  2. Thanks, Iain. I am really not sure if this is configurable on an Avaya system, but I will poke around. They may tie it to direct media on the SIP signaling group, but I can’t quite tell and I am not currently in a position to make changes and look at SIP traces. If I find something, I will share it here.

  3. Hi there. Great article as usual.

    I have a question though.

    Given that late offer now relies on the ACK to send the SDP answer, how does the protocol make sure that the ACK is not lost (assuming we’re working over UDP, which is pretty usual still for SIP).

    During early offer, the SDP offer is done in the INVITE (and INVITEs are re-transmitted if no response is received), then the SDP answer is sent in the 183 and/or 200 OK, and the 200 OK is also retransmitted until an ACK is received from what I remember. However, what about late offer? what if the ACK is lost with the SDP answer? what triggers retransmission since there is no ACK for the ACK 🙂

    1. Pappala Yayati Sai Kalyan · · Reply

      Hi,
      Can you explain me what happens when the ACK does not contain SDP? Will the call be disconnected?

  4. Moises, ACKs are retransmitted if the UAS doesn’t receive one after sending a 200 OK. The UAS will continue to send the final response until an ACK is received. This will prevent the problem of a lost ACK.

    From 3261:

    This is because the UAC core handles retransmissions of the ACK, not the transaction layer. The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives.

  5. Andrew, I have a question concerning re-transmitted 200 ok’s and their re-transmitted responses – ACK’s. Can a UAS, who has received two 200 ok’s due to the UAC re-transmitting, send an ACK for that CSEQ followed by a new invite for a later cseq with new sdp paramaters and THEN send a second ACK for the previous CSEQ. The confirmed state and timer I suggests the UAC should absorb this 2nd ack but i’m looking for clarity if a new invite received between them. Would sincerely appreciate your feedback.

    1. I think you mean a UAC receiving two 200 Oks from a UAS.

      I expect that this should be fine since the second INVITE is a new transaction. The SIP stacks should be able to handle keeping them straight.

  6. Thank you Andrew, stuck in an RFC battle with vendors and I appreciate your quick feedback.

  7. Hi Andrew,

    This article is really useful, crisp and clear in a way to understand. A quick doubt how do i decide in which deployments should I use EO or LO, a case study will be helpful.

  8. Hi Andrew, Good Article!!!

    I have a query. Suppose the scenario, where the SIP end points used the Late Offer (in 200 Ok and Ack), then what if receiver of SDP (Offer) end point does not match any Codec. So in that case what will be the next messages in call flow? and when the session between endpoints will be started?

    1. Thanks!

      The client needs to ACK the 200 OK, but it will set the SDP media port to 0. It will then send a BYE to end the call.

  9. Thanks Andrew for quick response.

  10. Dave Brown · · Reply

    So, the flip side of Nitesh’s question above… I send an Early Offer and the SDP has just one codec in it. The far end cannot use that codec, so we have no matching codec to use for this call. I should expect to get an error message like a 488 or some sort of denial back from the far end, correct?

    I had this situation, but I was getting no error messages in the trace and could not figure out what the issue was until we spoke to the tech at the far end and he informed us they don’t support that particular codec.

    1. Yes, in that case you should receive a 4xx error response. Were you not seeing any response?

      1. Dave Brown · ·

        We would get the Trying and Ringing responses back, but that was it until the call ultimately just failed to establish or the caller from our side hung up. We didn’t receive anything with SDP in it from the far end.

  11. Nice explanation 🙂

  12. for Offer answer scenario , if the offer comes from INVITE in not accepted by Called party , then how calling party know which codec it supported .
    please let me know the answer

    1. If it’s not accepted then the called party will return a 415 Unsupported Media Type. In that case there is no session.

  13. Hi Andrew, From our application we have received sdp in the ACk response the codec Media attribute(a) value as: ‘X-cisco-media:umoh’ received but our application tried to process the sdp answer and received ‘javax.media.mscontrol.networkconnection.SdpPortManagerException.’ Can you please help me on this to resolve this issue. We are using sip and jsr309 standard.

    1. Because of this issue, we are not able to hear the each voices(silent) from the two legs.

      1. I don’t understand what you are saying about ports. You have ports for media and ports for signaling. The 200 Ok will go to the SIP signaling port (most likely 5060). The media port is defined by the SDP. It may change with the re-INVITE.

      2. Andrew, I’m talking about the RTP Connection have the ports. Wireshark RTP: ‘Media Description, name and address (m): audio 5124 RTP/AVP 0 101’ (Here 5124 is the RTP Port). Please go through the with the example you get the better idea on my issue. For ex: 1. If we calling Alice – Sends the Invite request with the different RTP Port(12000) and received 200 Ok with different RTP Ports(15445). 2. If Alice calling the Bob – Sends the invite request with the differrent RTP(12344) Port and received 200 Ok with different RTP Port(13647). 3. Both Connections are established and able to here the each voices. 4. Five mins later sip stack received Re-invite request from the Alice phone with the different port(16542). 5. Our Sip stack will sends the 200 Ok response with the different RTP Port(12005). In this case the Alice and Bob voices are went to silent. When ever we have received the Re-Invite request the ongoing voices are break. So, that only i asked you to get the help which rtp port to be sent in the Re-invite 200 Ok sdp? either Alice 200 Ok rtp port or Bob 200 Ok rtp port or any other ports to be add?

    2. X-cisco-media is a proprietary Cisco attribute. My guess is your SIP stack chokes on it.

      1. Thanks Andrew.. Alice(Agent) and Bob(Customer) calls are connected. received Re-invite request from the Cisco CM. Can you tell me the Re-Invite request have different RTP port and we have 200 Ok with the different port. Which is cause the mute audio case? What would be the correct port send in the Re-Invite 200 Ok?

  14. Venkat · · Reply

    What if after completion of offer/answer if i put SDP in ACK again??

    1. I’ve never seen that, but I expect it will be ignored by the recipient. It might shut the call down, but I couldn’t say for sure.

  15. xuxiong · · Reply

    Hi Andrew,

    I encountered a situation that the late offer failed, would you please have a look.

    Here’s log:
    2015-08-24 15:39:08,871|app.voip|280|DEBUG|received[617] from
    (‘172.22.42.150’, 5060)
    INVITE sip:+8676985288031@10.17.41.163:5060 SIP/2.0
    Via: SIP/2.0/UDP
    172.22.42.150:5060;branch=z9hG4bK6vo9k76al6b9amm84m0l9hm70T39215
    Record-Route:
    Call-ID: asbc3fla9n82li2xl98nz8elyxeioll99a98@ATS.ats02.gd.ctcims.cn.1
    From: “Anonymous”;tag=sbc0510ra899ow3-CC-1
    To:
    CSeq: 1 INVITE
    Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
    Contact: ;isfocus
    Max-Forwards: 65
    Supported: 100rel,timer
    Session-Expires: 1800
    Min-SE: 600
    Content-Length: 0

    2015-08-24 15:39:08,887|app.voip|527|DEBUG|createServer
    2015-08-24 15:39:08,887|app.voip|622|DEBUG|sending[316] to
    (‘172.22.42.150’, 5060)
    SIP/2.0 100 Trying
    Content-Length: 0
    Via: SIP/2.0/UDP
    172.22.42.150:5060;branch=z9hG4bK6vo9k76al6b9amm84m0l9hm70T39215
    From: “Anonymous” ;tag=sbc0510ra899ow3-CC-1
    To:
    CSeq: 1 INVITE
    Call-ID: asbc3fla9n82li2xl98nz8elyxeioll99a98@ATS.ats02.gd.ctcims.cn.1

    2015-08-24 15:39:08,887|app.voip|548|DEBUG|receivedRequest
    method=INVITE ua=
    for ua without queue
    2015-08-24 15:39:08,887|root|74|INFO|incoming call from (‘”Anonymous”
    ‘, )
    2015-08-24 15:39:08,887|app.voip|688|DEBUG|request does not have SDP body
    2015-08-24 15:39:08,887|std.rfc3261|1352|DEBUG|request contact
    ;isfocus
    2015-08-24 15:39:08,887|app.voip|606|DEBUG|dialogCreated from

    to
    1440401948.89
    2015-08-24 15:39:08,887|app.voip|622|DEBUG|sending[686] to
    (‘172.22.42.150’, 5060)
    SIP/2.0 200 OK
    Content-Length: 219
    Via: SIP/2.0/UDP
    172.22.42.150:5060;branch=z9hG4bK6vo9k76al6b9amm84m0l9hm70T39215
    From: “Anonymous” ;tag=sbc0510ra899ow3-CC-1
    To: ;tag=79341366520
    Contact:
    CSeq: 1 INVITE
    Call-ID: asbc3fla9n82li2xl98nz8elyxeioll99a98@ATS.ats02.gd.ctcims.cn.1
    Record-Route:
    Content-Type: application/sdp

    v=0
    o=- 1439521303 1439521303 IN IP4 10.17.41.163
    s=-
    c=IN IP4 10.17.41.163
    t=0 0
    m=video 45900 RTP/AVP 122
    a=rtpmap:122 H264/90000
    a=fmtp:122 profile-level-id=64E00C;max-br=384;packetization-mode=1
    a=sendonly

    2015-08-24 15:39:09,637|app.voip|548|DEBUG|receivedRequest method=ACK
    ua=
    for ua with queue

    2015-08-24 15:39:09,637|app.voip|280|DEBUG|received[473] from
    (‘172.22.42.150’, 5060)
    BYE sip:+8676985288031@10.17.41.163:5060 SIP/2.0
    Via: SIP/2.0/UDP
    172.22.42.150:5060;branch=z9hG4bK6v660847o6k4bo4d6da77obbbT39217
    Call-ID: asbc3fla9n82li2xl98nz8elyxeioll99a98@ATS.ats02.gd.ctcims.cn.1
    From: “Anonymous”;tag=sbc0510ra899ow3-CC-1
    To: ;tag=79341366520
    CSeq: 2 BYE
    Max-Forwards: 68
    Reason: SIP;text=”19505.1919.ATS.ats02.gd.ctcims.cn.1.3026.0.0.0.0.0.Offer-Answer
    not complete”
    Content-Length: 0

    1. Was there a 200 OK with SDP?

      1. Yes.
        The problem is due to a missing voice media in SDP.
        I added the voice media in SDP, now it works.
        Thank you!

  16. Altug D. · · Reply

    I came here to thank you Sir! I am executing tests with delayed offer but I wasn’t getting the idea beneath. Now understood 🙂

  17. Hi Mr. Andrew,

    I have a doubt, UAC sent UPDATE message, the UAS did not answer immediatly, after some time, the UAC sends re-invite message to UAS. The UAS answer 500 error message with retry-after. The UAC is mandatory to try again, or it can terminate with BYE?

  18. Great explanation, thank you!

  19. Vasanth · · Reply

    RFC6337 5.2.5 chapter:
    “When the new offer is sent in response to an offerless (re-)INVITE,
    it should be constructed according to the General Principle for
    Constructing Offers and Answers (Section 5.1 ): all codecs the UA is
    currently willing and able to use should be included, not just the
    ones that were negotiated by previous offer/answer exchanges. The
    same is true for media types — so if UA A initially offered audio
    and video to UA B, and they end up with only audio, and UA B sends an
    offerless (re-)INVITE to UA A, A’s resulting offer should most likely
    re-attempt video, by reusing the zeroed “m=” line used previously.”

    Hi, Need a clarity on the last line of the above. “A’s resulting offer should most likely
    re-attempt video, by reusing the zeroed “m=” line used previously.” means reusing the non-zero “m=” line which was initially offered right?????

  20. […] if your ITSP is not using early offer, you’ll have to hardcode g729 on CUBE’s side and watch the SDP included response from […]

  21. Beermania · · Reply

    Hi Andrew,

    Question, if caller is sending EO, should our SBC configure to accept early media? We are having issue with a ringback tone for incoming pstn calls. I cannot find anything wrong on the sip messages, but when i check the config on the SBC the early media is disabled.

    I know when we do outgoing calls to pstn we are sending invite + SDP. But for incoming calls, im not sure.

    1. I can’t be sure, but that may be necessary. Is it easy enough to try?

  22. Hi Andrew,

    Just want to say thank you for unselfishly sharing your expertise. I am looking for a documents on how I can learn more about SIP and just stumbled your page and what a gem. Looking forward for more blogs from you. Once again thank you!

    P.S.

    Hope you can create a blog about SIP Trunking 🙂

  23. Thanks a ton Mr.Andrew for enlightening people with topics covering core part of SIP through simple and easy to understand articles. Can’t you publish one on provisional responses , especially with 100 REL ??

  24. Very good and easy to understando…thank you.

  25. Nice work…clear, concise and with great analogies…

    Made the topic so easy to understand, even a caveman could grasp it..

  26. Andrew · · Reply

    Hi Andrew, great article! Always a great resource for SIP questions.

    I’ve run into a bit of a situation trying to integrate CUCM and Skype, and I am wondering if you could offer some guidance. The CUCM is configured to send EO, but we’ve come across a scenario where the CUCM is refusing to send EO in a mid-call invite (involved in a hold action), and the Skype server is choking because it’s requiring EO on all requests. Both vendors are throwing their hands up, so I am looking for alternatives. I have a SIP session router between the two systems, so I am envisioning an HMR to inject the SDP in that scenario, but will that even work or will the CUCM choke because we’ve broken the DO flow?

    Thanks in advance!

    1. Andrew, is your scenario a voip-only integraton?

  27. Well first time I enjoyed reading a technical article….Thanks a lot Andrew for the funny style of explaining a tech stuff !!!!!

  28. hello

    great article
    I have a scenario
    A is calling B and is using early offer

    A supports G.729 offer and B supports only G.711
    Now as per the article i supose the communication between A and B will happen over G.711 and a transcoder will be evoked on A’s side to convert G.729 to G.711, am i correct or am i missing something here

    1. If there is no common codec, the INVITE will fail.

  29. saikrishna · · Reply

    Hello

    which call flow secenario cases SDP in the INVITE and sdp in the ack

  30. Where on the Avaya side can (of if you can) set Early Offer versus Late Offer?

Leave a comment