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
Supplementary services

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.

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.

 

 

Advertisements

13 thoughts on “At your service..

  1. Pingback: You are running low on credit! | Real Time Communication

  2. Pingback: Ut interface – what is it for? | Real Time Communication

  3. Pingback: VoLTE flows – close encounters | Real Time Communication

  4. Pingback: VoLTE or RCS Voice Call? | Real Time Communication

  5. Pingback: Summer & IMS | Real Time Communication

  6. Pingback: WebRTC GW | Real Time Communication

  7. Pingback: SMS in 2G/3G | Real Time Communication

  8. Pingback: XCAP Protocol | Real Time Communication

  9. Pingback: Rainy-day Scenarios – S-CSCF Restoration | Real Time Communication

  10. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  11. Pingback: VoLTE in IMS | Real Time Communication

  12. Pingback: OTT and VoLTE Calls | Real Time Communication

  13. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s