In a previous blog, I addressed the concepts of early offer and late offer. You are welcome to read the article, SIP Media Management: Early Offer vs. Late Offer, but it all boils down to a simple notion. With early offer you put SDP in the INVITE message and with late offer you put SDP in the ACK. This changes who gets to decide which codec will be used for the session. The called party decides with early offer and the calling party decides with late offer.
However, this has nothing to do with when media actually starts. Early and late offer simply define when media capabilities are exchanged. With early offer, you can put SDP in the INVITE request, but that doesn’t mean that media will be sent prior to the call being answered.
Early and late media have to do with when media starts to flow. Simply put, early media indicates that media is sent prior to the call being answered and late media indicates that media waits until the call has been answered.
Early and late media actually have nothing to do with early and late offer. You can have late offer and early media and its possible to have early offer and late media.
In order to make sense of this, you need to shift from thinking about SIP and VoIP to that analog telephone back home. For those of you who don’t own a land line, you can think about the phone at grandma’s house. The point is you need to focus on telephony prior to SIP.
When you pick up that home phone, what’s the first thing you hear? Dial tone, of course. The phone company sends dial tone to let you know that the line is working and is ready to accept digits. This is not media. This is simply a friendly, comfort noise that acts like the on/off light on a piece of electronic equipment.
Let’s keep going. You hear the dial tone, you enter the telephone number, and the call is launched. Depending on the number you dialed and the state of the called party you will hear a variety of different sounds.
Ringing is a good thing. That tells you that the called party’s telephone is alerting. You might also hear a busy signal if the other party is on an existing call.
You might also hear a message telling you that “the number you dialed is no longer in service.” Lastly, it’s possible to hear what we telephone people know of as re-order tone. This “fast busy” is often used to indicate that all circuits are busy and the call cannot be placed.
Whether it’s ring-back or re-order tone, this is media. These sounds are sent from the telephone company to tell you something about your call. If you think about it, how else can they inform you of call progress? Those old analog telephones don’t have displays. So, instead of your eyes, you use your ears to monitor how your call is progressing.
In SIP, we don’t use sounds to indicate call progress. Instead, we have response messages. 180 Ringing tells you that far-end is ringing. 486 Busy Here informs you that the far-end is busy. Your SIP device can do whatever it wants with those messages including playing sounds or displaying messages. However, if a sound is played it’s a local sound. It is not media sent to the SIP device from either the far-end or the communications system.
So, what happens when you need to interface the SIP world with the non-SIP world? Specifically, how do you deal with a system that uses media for call progress?
You let it.
Early media is simply media that is sent before a call is answered. It’s not the voice of the person you called, but rather system tones, announcements, or any other sound that the phone company wants to send your way. It’s the distinctive ringing you hear when you call a telephone in England. It’s an “all circuits are busy” message. It’s anything you might hear until you hear the called party’s voice.
Early media is typically supported by the use of the 183 Session In Progress response. Unlike a 180 Ringing response, 183 will contain SDP. This SDP is used to establish a media connection that carries those network tones and messages. It will eventually be torn down when the call is answered, but until then, it’s a way for the caller to audibly hear call progress.
I have been talking about early media in terms of the public switched telephone network (PSTN), but early media is also used by some IP PBXs. Why? Because they want to play the same kinds of sounds that the PSTN uses. They want to play announcements and country specific ring-back. Remember, PBXs are rooted in the same TDM world as the PSTN and have adopted much of its behavior.
On an Avaya system, there are a couple of places where you can enable early media. First, you can configure it on the Communication Manager by enabling Direct IP-IP Early Media on the SIP signaling group. Second, the 46xxSettings.txt file contains the parameter Enable_Early_Media. Setting it to 1 instructs the telephone to include SDP in 18x progress messages.
That’s it, folks. If you work with SIP as much as I do, I guarantee that you will run into early media, so it’s important that you are aware of what is happening. It’s not a change in SIP. It’s simply a difference in behavior that creates a bridge from the old world of TDM to the new world of IP telephony.
Hi Andrew, I’m a fan! Love your blogs! I came across your blogs because I was searching online for possible solutions on the issue I’m facing. We’re currently migrating our telephony infra to SIP and we’re getting a one-way voice path. Here’s the situation:
– To reach our contact center, customers can either call a short code, long code (mobile number), pilot number (fixed line) and some DIDs (fixed).
– When the call comes in from a fixed line towards those numbers above, we get voice path on both sides however, when a call originated from a mobile number, we get one voice path (where called party cannot hear the calling party).
What do you think is the issue?
Thank you, Erk!
One way audio is often caused by a Codec mismatch or a Firewall/NAT issue. Are the paths different for fixed line or mobile phone? Is the same SBC involved?
The codec is consistent using G711A and yes the path are the same:
Mobile Core -> IMS Network -> SBC -> ASM
Fixed Network -> IMS Network -> SBC -> ASM
Same SBC is involved. Just an update though:
So we have a pilot number: 4005xxxx – when called from mobile and fixed line – works perfectly!
We have a short code: 17x – when called from a fixed line – works fine! When called from a mobile – one way voice path.
Been trying to get this fixed for the last 2 weeks but no luck.
We have tried – IP-IP direct media, TDM, enabling/disabling audio hairpinning, early media, late media, with/without codec transcoding – but nothing works. 😦
At this point I would be looking at your SBC. It may also be a problem back at the carrier’s SBC. I wish I could be of greater assistance, but it’s hard fixing a difficult problem without being able to actually debug it. Good luck.
Could you take a trace and maybe you can see that somebody send a a “recvonly”
Perhaps it worth expanding this to include call flows with Wireshark traces highlighting 18X/PRACK signalling, in both SDP and non-SDP scenarios?
I will see what I can do. 🙂
Is there a way to disable the SDP in 180 ringing from CM. I dont see any field in Avaya CM where we can disable it. Even tried disabling the “Initial IP-IP Direct Media” but no luck.
Hi Deepak, I don’t know of a way, but I will ask around and if I find something, I will let you know.
Is early media is similar to precondition?
what is the difference?
Here is the difference between the two:
Preconditions require that the participant reserve network resources before continuing with the session. With Preconditions, the chances of a session establishment failure are minimum. Since the participants have already reserved resources needed for the session.
Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. An offer/answer exchange that takes place before a final response for the INVITE is sent establishes an “early” media session.
Nice article, it was well written and easy to understand. Thanks for doing your blog!
Would you elaborate more on SDP in case of early media? I mean, there is an offer in INVITE (with bunch of codecs), than we have early media answer in 183 Session Progress with certain SDP (a specific codec is chosen) and than 200OK comes with final response. Must SDP in 200OK be the same as in 183 (in terms of chosen codec)? What if early media codec is narrowband and final is intended to be wideband – is UPDATE used?
Ian, the SDP answer in the 200 OK must match the SDP answer in the 183.
From RFC 3261:
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
thanks a lot for your explanation!
Hello Andrew. I would like to suggest a small change in your blog. You mention that “On an Avaya system, there are a couple of places where you can enable early media. First, you can configure it on the Communication Manager by enabling Direct IP-IP Early Media on the SIP signaling group. Second, the 46xxSettings.txt file contains the parameter Enable_Early_Media. Setting it to 1 instructs the telephone to include SDP in 18x progress messages.”. However it is the other way round. When the Initial IP-IP Direct Media field on the Communication Manager signaling
group form page 1 is set to ‘y”, Communication Manager sends a “183 Session Progress”
*without* SDP during an inbound PSTN call that is forwarded to another PSTN call just
before a 183 is sent with SDP information to the far end.
Quick Question Andrew, Can we consider IVR announcements as early media?
Hello Andrew, I have a confusion
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.”
In the above RFC, does ‘zeroed “m=” line’ means non-zero “m= line” with a port which was used previously? Or UA A has to offer with “m=” line as 0
I have a question related to Early Media.Does Early Media impacts SIPREC recording.As far as i know,SIPREC starts from SIPREC Client(SBC) only upon successful session establishment i.e After 200 ok and ACK for INVITE.
Is SIP 183 response dependent on UE as well? Consider Smartphone A does not send 183 but Smartphone B sends 183 response? Would there be issues in call establishment?
There is no requirement that each side sends a 183.
Thanks. So if there is no requirement then IMS should be able to handle this scenario, correct?
Very useful blog, thanks.
you quoted “Early media is typically supported by the use of the 183 Session In Progress response. Unlike a 180 Ringing response, 183 will contain SDP. This SDP is used to establish a media connection that carries those network tones and messages.”
But you said earlier that the 183 message contains the answer for the offer brought within the INVITE.
My question is how can I make the difference between both SDP present in the 183 message? is there a way to tell this is SDP for the ring back tone whereas that one is simply the answer for the early offer?
Hello Andrew ;
We are connected VOIP carrier with Avaya SBC (IP Trunk). We do not hear ringback tone for only outbound calls. Carrier sending 183 message with SDP however we cant hear ringback tone Other than disabling Early Media (It didnt work ) , what can be done differently for this issue, I need your advise.
AVAYA –> INVITE CARRIER
AVAYA <– 100 TRYING CARRIER
AVAYA <– 183 SESSION (with SDP G711) CARRIER
AVAYA <– 200 OK CARRIER
Andrew, great blog. In light of the recent FCC enforcement action against T-Mobile, can you comment on what you think the latter was up to from a SIP perspective? It appears from the FCC case (EB-IHD-16-00023247) that T-Mobile were connecting to rural carriers via a SIP trunk and generating local ringback to the caller when in reality the far end was not alerting at all.
is early media enabling mandatory for every SIP call.
Mandatory? I wouldn’t think so. Every decent SIP system should support it, though.
That’s optional. thanks andrew
Is precondition settings mandatory for every SIP call?
Does PRACK is needed for early media if the INVITE already has SDP and after receiving 183 Session Progress?
Have not being able to find a doc that clear this..
hi Erk, i have not gone through your SIP trace but since you have SBC and issue is pertaining to Media, one way audio issue, i suggest you to check upon Media-latching on SBC.
our customer complains about Avaya One-X communicator, Is it Ok if after an INVITE the softphone send back multiple 180 RINGING to the Session Manager? It sends back 19 RINGING then finally a 487 Request Terminated.
In the INVITE the session-expires was 1200 and the RINGING has been finished around this time. There was network problem and Session Manager has never got the TRYING and the first RINGING messages so here the INVITE timed-out. On the other side at the softphone there was nobody to pick up the call.
So this kind of repeating the RINGING is fit into the RFC?
Is PRACK in place? If so, the Ringing message will be sent until it gets an acknowledgement.
There is no any Require in the Ringing header but
the initial INVITE has
Supported: 100rel, histinfo, join, replaces, sdp-anat, timer
“You can have late offer and early media” How you need an offer which includes the info of where to send the media (ip, port, codec) . how is media come before an offer and not know where to send it
It all depends on who is sending to who.
I am wondering, how the calling party should behave in this scenario.
Should they start RBT locally or still listen to “early media” from 183?
<– 180 (without SDP)
and delta time between 183 and 180 is only 0.42ms
180 after a 200? That’s weird. Also, where is the 183? Before the PRACK?
I am correcting the call scenario > I wrote incorrectly
183 (with SDP)
180 (without SDP)
and delta time between 183 and 180 is only 0.42ms