VoLTE in GSMA IR.92 is defining a set of standard Supplementary Services:
- Originating Identification Presentation 3GPP TS 24.607
- Terminating Identification Presentation 3GPP TS 24.608
- Originating Identification Restriction 3GPP TS 24.607
- Terminating Identification Restriction 3GPP TS 24.608
- Communication Forwarding Unconditional 3GPP TS 24.604
- Communication Forwarding on not Logged in 3GPP TS 24.604
- Communication Forwarding on Busy 3GPP TS 24.604
- Communication Forwarding on not Reachable 3GPP TS 24.604
- Communication Forwarding on No Reply 3GPP TS 24.604
- Barring of All Incoming Calls 3GPP TS 24.611
- Barring of All Outgoing Calls 3GPP TS 24.611
- Barring of Outgoing International Calls 3GPP TS 24.611
- Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611
- Barring of Incoming Calls – When Roaming 3GPP TS 24.611
- Communication Hold 3GPP TS 24.610
- Message Waiting Indication 3GPP TS 24.606
- Communication Waiting 3GPP TS 24.615
- Ad-Hoc Multi Party Conference 3GPP TS 24.605
- Explicit Communication Transfer – Consultative 3GPP TS 24.629 (5G)
Update:
There is not much different in VoNR (5G), the same 3GPP documents are referred by GSMA NG.114. Explicit Communication Transfer is explicitly listed as one of the services.
IR.92 also says that for supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
The supplementary services are applied on the traffic by application server (MMTel) based on the information received from HSS/CNTDB (Sh/LDAP). Note we distinguish the originating and terminating services (based on presence of the ‘orig’ tag in the top-most Route header). We also distinguish weather or not is the user currently registered in the LTE network (based on the ‘regstate’ tag in the P-Served-User). E.g. some services are applied for recipients (terminating service) who are not present in the LTE (regstate=unreg) – as voice mail. More details can be found in the 3GPP TS 24.229.
Route: <sip:mmtel@mmtel01.operator.com;lr;orig>,sip:1.2.3.44.50678.0.9000.@10.22.1.2:5070;lr;OdiPsi=mmtel>
P-Served-User: <sip:+123456789123@operator.com>;sescase=orig;regstate=reg
VoLTE Supplementary Services
Identity
Originating Identification Presentation (OIP)
Allows the terminating user to receive the identity information of originator.
If the OIP service is not activated (recipient has not subscribed to the OIP), the MMTel shall remove any P-Asserted-Identity or Privacy header fields included in the request. MMTel can also remove the contents of the From header and replace it with an ‘anonymous’ identity.
Originating Identification Restriction (OIR)
Allows the originating user to restrict presentation of his/her identity to the recipient.
The MMTel shall insert a Privacy header field set to “id” or “header”. Additionally, based on policy, the MMTel shall either remove the identification information from the From header, or add a Privacy header field set to “user”.
The presentation restriction function shall not influence the forwarding of the originating user’s identity information within the network as part of the supplementary service procedures. However the originating user’s identity information shall not be presented to the diverted-to user.
Terminating Identification Presentation (TIP)
Allows the originating user to receive the identity information of recipient.
If the originator is not subscribed to the TIP service, the MMTel removes any P-Asserted-Identity header fields or Privacy headers included in the SIP response. It also removed the option tag “from-change”.
Terminating Identification Restriction (TIR)
Allows the terminating user to restrict presentation of his/her identity to the originator.
Communication Diversion (CDIV)
When we apply a CDIV service, the terminating MMTel acts as an Originating UA. It means it will initiate an originating request on behalf of the served user. The MMTel will insert a new top-most Route header pointing to the S-CSCF (for the orginal recipient) and append the “orig” parameter. The P-Served-User header is included with the identity of the served user.
VoLTE Call Forwarding
Communication Forwarding Unconditional (CFU)
Enables the user to divert the communication to another address.
Call Forwarding
Communication Forwarding on not Logged in (CFNL)
Enables the user to divert the communication to another address in case the subscriber is not registered.
Communication Forwarding on Busy (CFB)
Enables the user to divert the communication to another address in case the subscriber is on an active call.
Communication Forwarding on not Reachable (CFNRc)
Enables the user to divert the communication to another address in case the subscriber is not reachable in IMS.
Communication Forwarding on No Reply (CFNR)
Enables the user to divert the communication to another address in case that the subscriber doesn’t establish the session in a given time.
Call Barring
Barring of All Incoming Calls (ICB)
Rejects all incoming traffic (that fulfill certain provisioned/configured conditions).
Barring of All Outgoing Calls (OCB)
Rejects all outgoing traffic (that fulfill certain provisioned/configured conditions).
Outgoing Call Barring + Announcement
Barring of Outgoing International Calls
Rejects all outgoing international traffic.
Barring of Outgoing International Calls – ex Home Country
Rejects all outgoing international traffic excluding the home country.
Barring of Incoming Calls – When Roaming
Rejects all incoming traffic in case the user is roaming.
Miscellaneous Services
Communication Hold (HOLD)
Enables to suspend media of an established call and resume later.
Hold is done by changing the SDP attribute. For each media stream that shall be held
- “a=sendonly”, if the stream was previously a sendrecv media stream;
- “a=inactive”, if the stream was previously a recvonly media stream.
Call Hold
Message Waiting Indication
Enables to informed the user that no resources are available for an incoming message.
Communication Waiting (CW)
Enables to inform the user that no resources are available for an incoming communication. The user then has the choice of accepting, rejecting or ignoring the incoming communication (as per basic communication procedures).
Ad-Hoc Multi Party Conference (CONF)
Enables the user to participate in and control a simultaneous communication involving a number of users. Described in VoLTE Conference Call post.
Real Time Communication 
What are the Volte Drop causes and how to find out Drop in IMS network i mean which node drop is happen.
what is the negative reposes will receive from Server for volte Drop.
How to resolve the volte drop in terms of IMS.
LikeLike
not sure what exactly you mean, but it’s typically SBC which deals with call droping (e.g. because of bearer loss). SBC then updates TAS.
LikeLike
Do we have any other causes for Volte Drop in IMS network. if Bearer loss then which SIP response gets from Server.
LikeLike
Hello,
I have one question that I cannot find in the relevant 3GPP doc.
In call forwarding scenarios what is the header modified by Application Server in the terminating side so the new INVITE (with the new modified ‘forwarded to/destination’ R-URI sent by the Term-AS) knows that in the S-CSCF should be handled as an ‘originating’ INVITE ? I have a guess that ‘P- Served-User’ header ‘sescase’ parameter value is modified by AS to ‘orig’ so S-CSCF handles the INVITE as a new call but I cannot officially verify if this is how S-CSCF would understand that.
Thank you in advance,
Chris
LikeLike
🙂 this is a good one – not everything is immediately clear from spec. Table A.1.1-9: INVITE request (AS to S-CSCF) in 3gpp 24.604 should be the answer. However I’m not sure whether I have ever seen SIP message like this to work in practice. The main trick is to add Route header which points back to (T)AS and which contains ‘orig’ tag. E.g.:
INVITE sip:01150005001@operator.com;user=phone SIP/2.0
To:
Via: SIP/2.0/UDP 10...
CSeq: 1000 INVITE
From: ;tag=...
Allow: INVITE, ACK, INFO, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE
Route:
Call-ID: ...
Contact: ;q=1;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel,urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel.gsma.videocall";audio;video
Supported: 100rel,eventlist
Content-Type: application/sdp
Max-Forwards: 68
Record-Route: ...
P-Served-User: ;sescase=orig;regstate=reg
Content-Length: 325
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel,urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel.gsma.videocall"
P-Charging-Vector: ...
P-Asserted-Identity: ,
Request-Disposition: no-fork
P-Access-Network-Info: IEEE-802.11g
P-Charging-Function-Addresses: ..
P-Served-User can be updated too, but it’s not always the case.
LikeLike
Updating the Route header with orig parameter is clear to me (in order to trigger let’s say an originating call from scratch since B user that applies the CF service will be now the originating side and another C user will be the terminating one).
The confusing point is for me how the S-CSCF knows that when getting the INVITE with the modified by the AS R-URI(targeting the C user that call should be forwarded to) this INVITE knows that its Route header must be modified with orig parameter.
BR,
Chris
LikeLike
Sorry for the delay, traveling now. Not sure if we understand one each other 😀 but orig is not used just towards TAS, but also the other way:
The “orig” parameter is a uri-parameter intended to:
– tell the S-CSCF that it has to perform the originating services instead of terminating services;
– tell the I-CSCF that it has to perform originating procedures.
LikeLike
Thanks for the answer, your description it is how it is described in RFC 5502 too (part 4.3), the only confusing point for me is that I have been through some CF/Diversion traces that let’s say user B’s route header is not modified to orig but stays terminating when diversion is applied. At high level my example is like A (S-CSC to AS -> route header: orig) -> B(S-CSC to AS -> route header: term and it is not modified by AS to create a new orig leg) -> C (forwarded by B to C- route header: term)
LikeLike