Have you ever thought about how this simple announcement works? Most of the (IMS aware) people believe that in order to establish a media session an UAC (originator’s handset) has to send the SIP ACK. This is true as long as we don’t need to inform the originator before the real voice or video call is established – e.g. running low on credit, informing about calling into foreign network, playing customized ring back tones etc.
In order to achieve this functionality the RFC 3960 introduced a concept of Early Media. The basic call can look like this:
Early Media
In general this early media can be generated by caller, callee or both. In case that B2BUA is present – which is the case of TAS in VoLTE, the B2BUA can establish the Early Media session too.
There are two basic ways how to establish the early media. Firstly it can be based on forking. This simple mechanism has problems which relate to forking itself and security. Generally this method is supposed to be obsolete. Therefore we will not go into the details.
The second way requires a support of early media by network elements. Actually there are two models – Gateway Model and Application Server Model. The Gateway Model is only acceptable in situations where the UA can’t distinguish between early media and regular media e.g. PSTN GW. The Application Server Model is the most important for us and requires a support of early media by UA.
P-Early-Media: supported Supported: early-session Content-Disposition: early-session
In a common scenario when we need to play an announcement before the regular media session the TAS and MRF will do the job. That’s why we call it Application Server Model. TAS is responsible for the signalling and selection of the announcement and MRF is responsible for the media.
Early media in VoLTE
I hope you noticed that the flow is a bit simplified. Of course, the response has to always backtrack the path of the request and we can’t skip like this 🙂
Once the TAS is informed that the announcement was played it can continue with forwarding of the original SIP INVITE. Or it can send a final response as e.g. 487 Request Terminated (see the example for Outgoing Call Barring). Note that early media can be triggered by both O-TAS (e.g. calling in a foreign network) and T-TAS (e.g. ring back tones).
Real Time Communication 
Hmm My question to this though is where on does is it ‘checked’ to see if early media is needed to be used? When the invite comes in, how does the receiving SBC or proxy know if the called party should be providing any early media tones or announcements etc..
LikeLike
When INVITE comes to SBC, it learns only whether the PEM is supported or not. The decision is done by AS. It can be both originating AS and/or terminating one – that means potentially a peer network (e.g RBT). Moreover in some networks it can be also SBC playing the tones directly. But that’s more common in enterprise.
LikeLike
is early media mandatory in IMS?
LikeLike
I believe not for IMS. But definitely it is mandatory for VoLTE. Btw. in VoLTE UE should be able to maintain
at least forty (40) parallel early dialogs!
LikeLike
Hi,
Does 183 Sessions Progress need to be send as a reliable response?
LikeLike
As long as it contains SDP, then yes. SDP has to be always acknowledged.
LikeLike
Can you kindly share the call flow for request INVITE where caller insufficient credit (that is Credit Control Answer is unauthorized)?
What IMS element handles the credit verification and where in the call setup is it invoked (before IFC filters and triggers). Can the SCSCF forward the invite for failed credit to another server for special treatment other than announce?
LikeLike