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

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

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

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

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

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

Leave a Reply

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