The most visited page in my blog is CUCM SIP Trunk to ITSP connection. From time to time my readers and students ask me to explain what the difference between the Early Offer and Delayed Offer in the SIP signaling is. Let's say your ITSP want you to use SIP signaling with Early Offer in the SIP Trunk. How can you be sure, that your SIP trunk really works in Early Offer mode?
First of all, let's define, what the both definitions refers to. When we say "Early Offer" or "Delayed Offer", we want to clarify how the SIP devices exchange their media information or do so called Media Negotiation. Media Negotiation is the procedure when the parties inform each other about the type of media traffic (audio/video), codecs used for audio and video, their media ports and IP addresses. Typically, the media information is provided with Session Description Protocol (SDP) messages.
In SIP Delayed Offer the media parameters are negotiated only after the called party goes off-hook and answers the call - no information about the calling device’s media characteristics are sent in the SIP INVITE. Let's have a look to the diagram below.
As you see here, the SDP messages in SIP Delayed Offer are sent in 200 OK and ACK SIP messages. 200 OK is the message confirming the answer of the call. The remote party encapsulates the SDP information into 200 OK and sends it to the calling party. It says something like "My codec is G711, my traffic is audio, my media IP is 10.1.1.1 and my media port is 16384. Do you support and accept this?"
If the calling party supports the codec offered, it returns its own media information in SIP ACK message. It also includes the near-end party's codec, port, IP address, etc. However, if we have codec mismatch, then the media negotiation fails and the call is dropped. Of course, in calls with SIP Delayed Offer the called party is always bothered - its phone is ringing, the user have to answer the call and immediately after that the call is released in case of codec mismatch (assume here that we have wrong codec configuration).
In order to avoid bothering the remote user with such calls, when codec negotiation fails, we can use SIP Early Offer mode. In this mode the session initiator (calling device) sends its capabilities (including supported codecs) in the SDP contained in the initial SIP INVITE in the very beginning of the call. The offer in the SDP message body contains the IP address, UDP port number, list of codecs, and so on, that the calling device supports. This method allows the called device to choose its preferred codec for the session.
Thank you for the article!
ReplyDeleteWith SIP Delayed Offer, is it possible that there will be several codecs in the SIP ACK/SDP. If it is possible (I'm sure yes), what codec will be the resulting one and by what principle will the choice be made?
Thank you for your feedback! No, in SIP Delayed Offer the ACK message contains the final codec selection done by the calling party. The called party can provide its own list of preferred codecs in 200 OK message and the calling party has to make a selection. Let's say the called party sends G729, G711u, G711a as the list of codec. The list specify also the priority for the codec selection. So in this example the called party says, that it prefers G729 first to be selected, if not - then G711u, and finally G711a. Imagine the calling party support all these three codecs. Then the codec G729 will be selected and sent in ACK message, because the G729 was announced as the most desired one by the called party. If the calling party doesn't support G729, but supports both G711u and G711a, then the G711u will be negotiated and so on.
DeleteThanks for the answer. I’ll read the RFC deeply and return :), for example, for Early Offer, the situation with several codecs in 200 OK/SDP is quite common and the choice of the final codec lies on the client side (as far as I remember, this is described in RFC3264).
ReplyDeleteOf course, the media negotiation in SIP is not so simple as it may seem ) No matter if it is Early Offer of Delayed Offer, the so called SDP Offer/Answer model is used. For Early Offer the Offer comes in the SIP INVITE, and the Answer returns in 200 OK, while for the Delayed Offer the Offer is in 200 OK and the Answer is in ACK. The RFC3264 defines the behavior of the systems during Offer/Answer stage. And and RFC4317 shows different scenarios for Offer/Answer negotiations (https://www.rfc-editor.org/rfc/rfc4317). You will see there several examples, when the parties support list of codecs.
DeleteIn my understanding, not all SIP platforms behaves the same way, and not all platforms can offer multiple codecs in the SDP Answer. My previous answer to you was for Cisco SIP devices. This is what Cisco says about Media Negotiations:
"SIP EARLY OFFER: The Offer is sent in the SIP INVITE and contains the IP Address, UDP port number, list of codecs etc, supported by the calling device. The called device selects which one of the offered codecs it wishes to use for the call and returns it in its Answer in 200 OK.
SIP DELAYED OFFER: No information about the calling device's media characteristics are sent in the SIP INVITE. The Offer is sent by the called device in 200 OK and contains its IP Address, UDP Port Number, list of codecs etc. The calling device selects which of the offered codecs it wishes to use for the call and returns its Answer in the SDP body of SIP ACK"
So, if we have a look to RFC4317, it seems that Cisco supports the Scenario 1 in both SIP Early Offer and Delayed Offer.