At your service..

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

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
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
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
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.

 

 

Print Friendly, PDF & Email

Realtimecommunication.info

4G/5G, VoLTE, RCS, IMS, SIP, WebRTC, IoT/M2M Descrition, CallFlows, Illustrated Guides, Tests and other stuff for telco egineers

3 thoughts to “At your service..”

  1. 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.

    1. 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.

      1. Do we have any other causes for Volte Drop in IMS network. if Bearer loss then which SIP response gets from Server.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.