RJIO Call Flows v1.8

RJIO 4G Call Flows
Phase 1
Document No.
R4G-XX-XXX-XXX
03-09-
1.8 IFU
2014
Mavenir System WLS CORE-NPE
Rev.
Date Reason for Issue Prepared by Reviewed by Approved by
No.
For more information on Mavenir Systems, visit our Web site:
http://www.mavenir.com/
Every reasonable effort has been made to ensure the information and procedures detailed in this
document are complete and accurate at the time of printing. However, information contained in this
document is subject to change without notice.
© 2014 Mavenir Systems Inc.

Contents
Change History...................................................................................................................................... 4
1 Introduction..................................................................................................................................... 5
1.1 Purpose.................................................................................................................................. 5
1.2 Scope of Document................................................................................................................ 5
1.3 Agreed methods..................................................................................................................... 5
2 LTE Attach...................................................................................................................................... 6
3 Non-LTE UE access procedures.................................................................................................... 7
3.1.1.1 Home GW behind LTE...............................................................................................7
3.1.1.2 FTTH End Device....................................................................................................... 8
3.1.1.3 Wi-Fi End Device....................................................................................................... 8
4 Registration.................................................................................................................................... 9
4.1 Registration @ Home PLMN.................................................................................................. 9
4.1.1 Initial Registration............................................................................................................. 11
4.1.2 Refresh Registration........................................................................................................ 14
4.1.3 De-Registration................................................................................................................ 15
4.2 Registration @ visited PLMN (IMS Roaming)......................................................................16
4.2.1 Initial Registration............................................................................................................. 16
4.2.2 Refresh-Registration........................................................................................................ 18
4.2.3 De-Registration................................................................................................................ 18
5 Voice............................................................................................................................................. 19
5.1 Originator @Home PLMN.................................................................................................... 19
5.1.1 IMS to IMS....................................................................................................................... 19
5.1.2 IMS –IMS Telemarketing call flow (with DND Check)......................................................23
5.1.3 IMS to other PLMN or PSTN............................................................................................ 24
5.1.4 IMS to other operator 2g/3g subscriber............................................................................25
5.1.5 IMS to RJIO IMS PSTN.................................................................................................... 26
5.1.6 PLMN or PSTN to IMS..................................................................................................... 27
5.2 Intra-Circle Call Flows.......................................................................................................... 28
5.2.1 IMS to CS (Intra circle RJIO roamer)...............................................................................28
5.2.2 CS (Intra circle RJIO roamer) to IMS...............................................................................29
5.2.3 CS (Intra circle RJIO roamer) to IMS Different Circle.......................................................30
5.2.4 CS (Intra circle RJIO roamer) to Non Registered IMS User (B is in CS termination).......31
5.3 National Long Distance (NLD/ILD).......................................................................................32
5.3.1 IMS Roaming Inter-Circle................................................................................................. 32
5.3.2 Roaming CS Origination to IMS Different circle...............................................................34
5.3.3 Roaming CS Origination to CS Different circle.................................................................34
6 Emergency Call flow..................................................................................................................... 35
7 Messaging.................................................................................................................................... 36
7.1 Third Party Registration With Sh Interface at IPSM.............................................................37
7.1.1 On Arrival of a Third Party Registration (UE details not in the local cache).....................38
7.1.2 On Arrival of a Third Party Registration (re-registration, UE details already in the local
cache) 38
7.1.3 On Arrival of a Third Party Registration (de-registration).................................................38
7.2 On-Net................................................................................................................................. 39
7.2.1 IMS to IMS same circle.................................................................................................... 39
7.2.2 IMS – IMS Different circle................................................................................................ 41
7.3 ICR and Inter-Circle............................................................................................................. 42
7.3.1 RJIL User is in ICR........................................................................................................... 42
7.3.2 ICR to IMS....................................................................................................................... 45
7.3.3 RJIL (A and B party)user in ICR.......................................................................................46
7.3.4 IMS to Other operator CS................................................................................................ 46
7.3.5 CS(other operator) to RJIO IMS User.............................................................................48
7.4 National Roaming in LTE/IMS network................................................................................49
7.5 P2A message call flow......................................................................................................... 50
7.6 A2P call flow........................................................................................................................ 51
7.7 Message Origination in IMS domain as SMSIP (Transport Interworking) – MO Long
Message........................................................................................................................................... 51
7.8 Domain selection and CS RETRY.......................................................................................53
7.9 Deferred message delivery.................................................................................................. 55
7.10 Memory non available.......................................................................................................... 56
8 Announcements............................................................................................................................ 57
8.1 Session Reject OCB (Early Dialog/Early Media)..................................................................57
8.2 Session Reject: OCB Confirmed Dialog...............................................................................58
8.3 Session Reject: ICB Early Dialog......................................................................................... 59
8.4 Announcement during Mid-Call............................................................................................ 60
9 Supplementary Services............................................................................................................... 61
9.1 Feature Request.................................................................................................................. 61
9.2 Per-Call-OIR-Activation........................................................................................................ 62
10 Call Forwarding......................................................................................................................... 63
10.1 CFU to another IMS User - Caller from IMS.........................................................................63
10.2 CFU to CS User - Caller from IMS.......................................................................................64
10.3 CFB to another IMS User (IMS to IMS)................................................................................64
10.4 CFB to another IMS User- Caller from CS...........................................................................66
10.5 CFBRc (IMS to IMS)........................................................................................................... 66
10.6 CFNRc to IMS User - Caller from CS...................................................................................68
10.7 CFNR to another IMS User - Caller from IMS......................................................................69
11 Suppressing LCF (late call forwarding) Scenarios....................................................................70
11.1 CFNRc (with CS Retry)........................................................................................................ 71
11.2 CFNR (with CS Breakout).................................................................................................... 73
12 Call Waiting............................................................................................................................... 76
12.1 Call Waiting - Call Accepted................................................................................................. 76
12.2 Call Waiting - Call Ignored................................................................................................... 78
12.3 Call Waiting - Call Rejected................................................................................................. 79
13 Conference............................................................................................................................... 80
13.1 Three way Conference Creation, REFER sent in Conference Dialog..................................80
13.2 Add Participant – without Replaces Option..........................................................................84
13.3 Abnormal Scenarios-Conference creation...........................................................................86
13.3.1 Conference creation..................................................................................................... 86
13.3.2 Adding a participant..................................................................................................... 86
13.4 Leaving a conference........................................................................................................... 87
13.4.1 Participant leaving a conference..................................................................................87
13.4.2 Controller removing a participant.................................................................................88
13.4.3 Abnormal Scenarios- while participant leaving a conference.......................................89
13.4.4 Controller Leaving the Conference...............................................................................90
13.4.5 Removing Conference Participant................................................................................91
13.4.6 Removing all Conference Participants.........................................................................92
13.4.7 Last Participant (not controller) Leaving Conference...................................................93
13.5 Conference, addition of Waiting call.....................................................................................94
13.6 Conference: Addition of 4th Party........................................................................................ 95
14 Hold Resume Call flow.............................................................................................................. 97
15 CRBT........................................................................................................................................ 98
15.1 UAC does not support multiple early dialogs.......................................................................98
15.2 UAC supports multiple early dialogs..................................................................................101
16 MCA........................................................................................................................................ 103
17 Sh interface call flow -TAS...................................................................................................... 104
17.1 Initial Registration as well as subscription for Notification..................................................104
17.2 Profile Recovery................................................................................................................. 104
17.3 De Registration.................................................................................................................. 105
17.4 Un-Registered Terminated Request (MT Flow).................................................................105
17.5 Interrogation....................................................................................................................... 106
17.6 Manipulation....................................................................................................................... 107
18 Rx Call Flows.......................................................................................................................... 108
18.1 Subscription to IP-CAN Type Change................................................................................108
18.2 Subscription to Signaling Path Status................................................................................109
18.3 Provision SIP Signaling Flow............................................................................................. 109
18.4 Initial Session Provisioning – Originating UAG..................................................................110
18.5 Session Modification – Originating UAG............................................................................111
18.6 Session Modification – Originating UAG............................................................................112
18.7 Initial Session Provisioning – Terminating UAG.................................................................113
18.8 Session Modification – Terminating UAG...........................................................................114
18.9 Initial Session Provisioning (Bearer Loss) – Originating UAG............................................115
18.10 Initial Session Provisioning (Bearer Recovery) – Originating UAG................................116
18.11 Initial Session Provisioning (Bearer Loss) – Terminating UAG......................................117
18.12 Initial Session Provisioning (Bearer Recovery) – Terminating UAG...............................118
18.13 Established session (bearer loss) - Originating UAG.....................................................119
18.14 Established session (bearer recovery) - UAG Originating..............................................120
19 GBA authentication................................................................................................................. 121
20 Ut Interface call flow................................................................................................................ 122
20.1 Retrieving the entire document.......................................................................................... 122
20.2 CFU Deactivation............................................................................................................... 122
20.3 CFU Activation, Changing a Forward-To Number..............................................................123
21 Contact center call flow........................................................................................................... 124
21.1 RJIO Subscriber calling contact center..............................................................................124
21.2 Contact center to RJIO 4G................................................................................................... 125
22 TAS Charging Flow................................................................................................................. 126
22.1 Credit Session Setup- Mobile Origination – CCR [Update] Upon quota expiry..................126
22.2 Charged Party abandons the call.......................................................................................127
22.3 Handling Low Balance Indication.......................................................................................128
22.4 IMS Origination – Media Change in Update Request................................................................129
22.5 Credit Session Setup- Media Change.......................................................................................130
22.6 Credit Session Setup- Mobile Origination – CCR [Update] Upon quota expiry –TQT.....................131
Change History
Rev. Date Prepared Reviewed Approved Details

No. by by by
1.0 23-03-2014 Mavenir Internal Draft
1.1 3-04-2014 Mavenir Internal Updated with internal review comments
1.2 15-04-2014 Mavenir NPE Team Updated as per NPE comments
1.3 12-05-2014 Mavenir NPE Team Added description to call flow

Updated as per NPE comments and added
1.4 15-04-2014 Mavenir NPE Team
Telemarketing flow
Updated as per ICR flow as MGCF
discussion
Updated CRBT and MCA flow as per
discussion with CRBT vendor.
Added following flows:
 Sh interface
 Rx interface
 Conference flow with and without
replace header in REFER.
 Flow for suppressing late call
forwarding
 Flow for GBA authentication
 Sh interface flow for IPSM and
domain selection
 CRBT flow when UE support
multiple early dialogue
 Updated Roaming call flow
 Ut interface flow
1. Added RP-SMM flow

2. Added UNRI flows
3. Added LTE and FTTX details
4. Added IPSM Sh details
1 Introduction
RJIO intends to launch VoLTE and Enhanced Communication Services over their LTE network and in
partnership with other operators (e.g. RCOM) for fallback to the legacy CS network when the
environment demands – e.g. loss of LTE coverage. To implement this in a standard/future proof way,
a 4G Core network based on the 3GPP IMS architecture has to be deployed.
1.1 Purpose
The purpose of this document is to provide the call flows for the overall solution architecture.
1.2 Scope of Document

For this phase of the project, the following flows are provided.
- Registration
- Voice and Video
- Messaging
- Announcements
- Supplementary Services
1.3 Agreed methods

- Roaming is identified by comparing the P-Visited-Network-Id with the home domain of the
subscriber
- NLD/ILD calls identified by translations framework
- On-Net/Off-Net identified by MNP Query
- For PSTN Breakout MGCF does trunk selection based on the tgrp, trunk-context parameters
(RFC 4904) added by IMS Core/TAS based on PVID.
2 LTE Attach
UE eNODEB MME SGW DRA PCRF HSS/EIR OCS
1. Attach Request 2 3 AIR

4
5 AIA
6
8 7 Attach Request
9. Attach Resp. 9a
10 Security Mode
command
12Security Mode command

Complete
13 14 Update Location Request
15
Cancel location and Delete session request is not shown
16 Update Location
17 Answer
18 Create
Session
request
19 CCR 20 CCR
21 CCA
22
23 CCR
24
27Create
28 Initial Conext Session 25
Setup Req/Attach Resp. 26
accept
29 Attach accept
30 Cotext setup res.
31 Attach Complete
32 Attach Complete
33 Modify
bearer Req.
34 Modify
Bearer Res.
35 NOR
36
38 NOA 37 NOA
39 Create
Bearer
40 Activate EPS
Request
41 Activate EPS Bearer Req.
Bearer Req.NOA
42 Activate EPS
Bearer Res. 43 Activate EPS 44 Activate
Bearer Res. EPS
Bearer Res.
LTE Attach procedure enables the UE to receive services from the network and it helps to establish
default EPS bearer ensuring the always-on IP connectivity for the UE.UE initiates Attach procedure
by the transmission of an Attach Request, eNodeB passes the attach request to the MME. MME send
an Authentication Identification Request to the HSS. In response, the HSS authenticates the UE and
sends Authentication Identification Answer. MME sends Authentication Request to the eNodeB which
it forwards to the UE. MME sends an Update Location Request message to the HSS. HSS
acknowledges the Update Location message by sending an Update Location Ack message to the
MME and stores the new location of the MME and UE.
SGW returns Create Session Response along PCO option parameters such as SBC Address and
DNS address.
3 Non-LTE UE access procedures

This section describes how the non-LTE User equipment (UE) can attach to the R4G network. The
following use cases are described: Home Gateway behind LTE, FTTx and WiFi
3.1.1.1 Home GW behind LTE

Access is done via End devices like Smart Phone, Set Top Box (STB) & Internet Access Devices(IAD)
connected using Home Gateway in routed mode. Home Gateway will interconnect with LTE ODU in
Bridge mode. LTE ODU shall be connected to S&P Gateway via eNodeB.
User Device Home GW LTE CPE eNodeB S/P-GW
Attach Request
Attach Accept
Attach Complete
DHCP Discovery
PCO Option
Request: PCO/ Option 00 CH
DHCP Offer
Result: UP IP address and list of
available P-CSCF addresses
DHCP Discovery
DHCP Offer
DHCP Discovery + Option 120
The procedure is as follows:

 LTE CPE request for P-CSCF address in PCO during attach process.
 Network i.e. S&P Gateway provides the PCSCF IP addresses in response apart from user’s
IP address & DNS address. These IP address allocation by SAE gateway shall be based on
PLMN / Cell_id, to ensure that UE/device gets its own serving domain / Circle P-CSCF/SBC
IP addresses.
 DHCP offer option 120 SIP_SERVER has to be offered by the outdoor CPE to the WAN
interface of home gateway (HGW).
 This DHCP offer option 120 message has to use the P-CSCF address obtained in PCO.
 This activity is somewhat similar to obtaining the DNS address from the network in LTE
protocol stack & using it in DHCP offer option 6 DNS server in the DHCP Offer message.
 The HGW connected to the bridge mode outdoor CPE receive the P-CSCF address on its
WAN interface.
 Now the HGW sends this information in its own LAN side DHCP offer message to end
devices in response to their DHCP request.
 Device which will connect to the HGW can receive the P-CSCF address which in turn will be
captured by the IMS/SIP client running on that device.
3.1.1.2 FTTH End Device

 SIP Proxy address / P-CSCF discovery process for UE device in FTTH House Hold.
 Client will request DHCP Server (OLT) to assign the IP address and other configuration
parameter such as SIP Proxy IP address (P-CSCF), DNS IP, etc.
 OLT will do the DHCP relay function and forward the request to DHCP Server including
Option 82 details.
 DHCP server will assign IP address from a predefined pool and other related network
configuration parameters to the DHCP client (OLT) corresponding to Option 82 inputs (switch
id / circuit / port id). This is to ensure that end user gets its own Circle/domain serving P-
CSCF/SBC Proxy / SBC IP address or FQDN address.
 OLT will act as DHCP relay and pass all the information to Client.
BNG acts as
DHCP Relay
User Device ONT OLT BNG DHCP

DHCP Discovery
DHCP Offer
DHCP Option 82
DHCP Discovery
DHCP Offer
DHCP Discovery +
Option 120
3.1.1.3 Wi-Fi End Device

SIP Proxy address / P-CSCF discovery process for UE device in Wi-Fi.
 Client will request DHCP Server (WLC) to assign the IP address and other configuration
parameter such as SIP Proxy IP address (P-CSCF), DNS IP, etc.
 WLC will do the DHCP relay function and forward the request to DHCP Server including
Option 82 details.
 DHCP server will assign IP address from a predefined pool and other related network
configuration parameters to the DHCP client (WLC) corresponding to Option 82 inputs (switch
id / circuit / port id). This is to ensure that end user gets its own Circle/domain serving P-
CSCF/SBC Proxy / SBC IP address or FQDN address.
 WLC will act as DHCP relay and pass all the information to Client.
WLC acts as
DHCP Relay
User Device AP WLC DHCP

DHCP Discovery
DHCP Offer
DHCP Option 82
DHCP Discovery
DHCP Offer
DHCP Discovery +
Option 120
4 Registration
4.1 Registration @ Home PLMN

This section will describe the concept of IMS registration, how it is used, triggered and what is
involved in registering an IMS subscriber in the IMS network.
IMS registration is the procedure where the IMS user requests authorization to use the IMS services
in the IMS network. Once the IMS terminal has followed the procedures of getting access to an IP
Connectivity Access Network, has acquired an IPv4 address or built an IPv6 address, and has
discovered the IPv4 or IPv6 address of its P-CSCF, the IMS UE can begin registration at the IMS
level.
S-CSCF acts as a SIP registrar in the IMS network. Supporting registrar functionality requires S-
CSCF keeping a binding between an address of record and the contact address for the address of
record. It also requires storing the ‘path’ related information for the contact address. The binding is
kept active for a limited period of time, which will be removed if not refreshed before the registration
expiry time.
S-CSCF supports the following registration scenarios acting as a Registrar:

o Initial Registration
o Re-Registration (or Refresh Registration)
o De-Registration
Initial Registration
During the Initial Registration, the UE (User Equipment) is Authenticated by the IMS core to validate
the user and to authorize its access to the IMS services.
Any REGISTER request received unprotected by the S-CSCF without an Authorization header field,
or with an Authorization header field having the "integrity-protected" header field parameter in the
Authorization header field set to "no", or without an "integrity-protected" header field parameter is
considered to be an initial registration.
Refresh Registration
As per 3GPP specifications, the IMS registration for a given subscriber has an expiry time. The
primary purpose of the IMS refresh registration from a UE is to notify the IMS network that the UE is
still available and still requires IMS services. After every refresh registration the registration timer is
reset.
In the RelianceJIO implementation, the re-registration procedure does not require UE to be re-
authenticated.
Third-Party Registration
In the IMS architecture, the S-CSCF is the SIP Call Server which invokes subscriber’s services hosted
by Application Servers (AS). The interface used for this purpose is called ISC (IP multimedia Service
Control), and S-CSCF initiates SIP messages to the AS for requesting the specific service execution.
In the scope of the Reliance JIO implementation, the Mavenir TAS (Telephony Application Server),
IPSMGW and RCS are the Application Server hosting the various VoLTE services.
IMS architecture offers the capability for AS to receive Third Party REGISTER message from the S-
CSCF each time users are registering themselves into the IMS domain. This is intended to inform AS
of the Subscriber status so it can prepare for offering the service.
Important information carried in the 3rd Party REGISTER request includes the public user identity, S-
CSCF address and registration expiration time which was sent to the UE in 200Ok response for
incoming REGISTER request. S-CSCF will initiate 3rd Party REGISTER request towards Application
Server(s) based on the iFCs downloaded from HSS.
S-CSCF will initiate 3rd Party Registration procedure during:

o UE Initial Registration
o UE Refresh Registration
o UE De-Registration
o Network Initiated De-registration
Following are the types of Third-Party registration
o Initial 3rd Party Registration
o 3rd Party Re-Registration
o De-Registration
4.1.1 Initial Registration
UAG /P-
UE-A IP-SM
CSCF I-C SCF S-CSCF TAS R CS H SS
GW
1.REGISTER (IMPU,
IMPI,PANI,Expires > 0)
P-CSCF selects I-CSCF

based on DNS query
2 3. UAR (IMPU, IMPI)
4.UAA (S-CSCF Capabilities)
I-CSCF queries DNS with default FQDN.

DNS resolves FQDN and returns IP 5
addres s to I-CSCF.I-CSCF forwards the 6 MAR (IMPU, IMPI)
request to the provided S-CSCF IP adr.
7 MAA (IMPU, IMPI, auth vectors)
8. 401
10. Unauthorize
401 Unauthorized (auth d (auth
challenge) 9 challenge)
HSS returns S-CSCF name/
11. REGISTER (IMPU, IMPI, adr received in the MAR.
auth resp) 13 UAR (IMPU, IMPI) Although UE is not
registered yet, HSS tracks
14 UAA (S-CSCF address) the S-CSCF trying to
15 authenticate him.
S-CSCF selects T AS for TPR
REGISTER based on iFC execution.
(auth resp)
S-CSCF accepts UE authentication response,
then downloads UE profile and uploads S-
CSCF restoration info on HSS.
16 SAR (IMPU, IMPI S-CSCF Name. SA

Type=REGISTRATION)
20 HSS records/updates S-
200 OK 19 18 17 SAA (IMPU, User Profile) CSCF address serving
S-CSCF selects TAS for TPR this UE.
based on iFC execution.
IMS UE registered. TAS will fetch

the subscriber profile from HSS via
Sh or LDAP interface
23 22
200 OK Profile retrieval (LDAP)
S-CSCF selects IP-SM-GW for

TPR based on iFC execution. TAS stores the profile received
24
REGISTER (IMPU,
Service-Info) IMS UE registered. IP-SM GW will fetch
the subscriber profile from HSS via Sh or
LDAP interface
IP-SM GW stores the profile 25 Profile retrieval (Via Sh)

received from the SUB DB
26
200 OK
TPR for RCS AS will be same a s of TAS a nd IPSMGW
IP-SM GW updates gsmSCF-Address on subscribers profile in HLR
U AG /P- IP-SM
UE-A I-C SCF S-C SCF TAS HLR
CSCF GW
27 ATM (gsmSCF Addr = IP-SM

GW)
This will trigger HLR to s end ALERT-SC to 28 MAP-READY-For-SM (MS)

SMSC to start delivery of stored messages
UE Subscribe for reg. event

29 SUBSCRIBE (event=reg
Expires=xyz) 30 S-CSCF can trust the content of the P-Ass erted-Identity header and is on the list of
the authorized users for the "reg" event package stored by S-CSCF, therefore S-CSCF
sends an a cknowledgement towards the UE indicating that the subscription was
32 31 successful
200 OK 200 OK
AS Subscribe for reg. event

33 SUBSCRIB E (event=reg
Expires=xyz)
34
200 OK
IPSM-Gw and RCS Subscription for reg. event is not shown , it will remain same a s shown for TAS
Call flow description

P-CSCF Discovery
PGW has multiple IPs configured as P-CSCF address. PGW will provide two IP addresses (Primary
and Secondary) to the UE during the PDP attach. These two are selected from the pool of the P-
CSCF IPs configured on PGW and provided to the UEs in a round-robin fashion.
1.The UE sends a REGISTER message to the home network to perform SIP registration
for public user identity.
2. P-CSCF will perform DNS (NAPTR,SRV and A/AAA query) to find out I-CSCF address.Load
balancing towards can be achieved by configuring the DNS servers with its supported load balancing
capability.
3-4. In order to obtain the S-CSCF address, the I-CSCF performs the User Registration
Status Query procedures over the Cx interface.The I-CSCF sends out a Diameter User Authorization
Request (UAR) to the HSS to resolve S-CSCF address.
5. I-CSCF sends the REGISTER request to the S-CSCF address that it either got from the HSS.
6-7.MAR/MAA commands are used between the S-CSCF and the HSS to exchange information to
Support the authentication between the end user and the home IMS network. S-CSCF takes care of
user authorization, there exists the need to transfer security data over the Cx reference point. When
the S-CSCF needs to authenticate a user it sends a Multimedia-Auth-Request (MAR) command to the
HSS. The HSS responds with a Multimedia-Auth-Answer (MAA) command. The answer contains
among other information Authentication Data. It includes one or more authentication vector, which is
Comprised of an Authentication Scheme (e.g., Digest-AKAv1-MD5), Authentication Information
(Authentication challenge RAND and the token AUTN), Authorization Information (expected response,
or XRES), Integrity Key and a Confidentiality Key. Additionally, it contains an Item Number, which
indicates the order in which the authentication vectors are to be consumed when multiple vectors are
returned.
8-9. In order to authenticate, the S-CSCF rejects the initial REGISTER request from the
user with a 401 (Unauthorized) response, which includes (among other parameters) the
RAND, the AUTN, the IK and the CK.
10.The P-CSCF, when receiving the 401 (Unauthorized) response, removes the IK and the
CK from the response before sending it to the UE.
11-12. UE sends the authentication challenge response (RES) in the second REGISTER request
back to the S-CSCF via same path i.e. P-CSCF and I-CSCF
13-14. I-CSCF quires HSS for serving S-CSCF, HSS returns S-CSCF name/adr received in the MAR.
Although UE is not registered yet, HSS tracks the S-CSCF trying to authenticate him (from previous
registration request).
15.I-SCSF relays request to S-CSCF.
16-17. S-CSCF accepts UE authentication response, uploads record using SAR request.
18-19-20. 200 OK response to SIP REGISTER Request.
21. After successful registration the S-CSCF will check the downloaded filter criteria of the
User, Based on IFC configured, S-CSCF informsTAS about the subscriber REGISTRATION i.e.
subscriber has now been registered and is, therefore, available.
22. TAS downloads subscriber profile from HSS and put into local cache.
23 200 OK response for Third party registration request.
24-25. Based on I-FC configured S-CSCF informs IPSM-GW about subscriber registration. IPSM-GW fetches
subscriber profile using Sh interface.
26.200 OK response for Third party registration request.
27-28. IPSM-GW registers himself as serving VLR/MSC in the HLR using MAP_ATM message once
subscriber is registered. This will also trigger HLR to send ALERT-SC to SMSC to start delivery of stored
messages (if any deferred messages are there).
Details of the parameters sent by IPSM-GW to the HLR during the IMS 3 rd party registration
procedure is shown in the table from the 3GPP specification below.
29-30. UE subscribers for the respiration event package by sending SUBSCRIBE request.
31-32.S-CSCF sends an acknowledgement towards the UE indicating that the subscription was successful
33-34.Application service (TAS) also subscribe for the registration event package. IP-SM , RCS will also
subscribe for regevnt..
4.1.2 Refresh Registration
IP-SM
UE-A P-CSCF I-CSCF S-CSCF TAS HSS
GW
1
REGISTER (IMPU, IMPI-,
PANI, Expires > 0)
based on DNS query 3
2 UAR (IMPU, IMPI, UA-Type = REGISTRATION)
4.UAA (S-CSCF address)
5
UE Authentication is not required in this deployment during UE refresh registration
6. SAR (IMPU, IMPI, S-CSCF Name. SA-

Type=RE_REGISTRATION,
10
200 OK 9 8 7 SAA (IMPU)
S-CSCF selects same TAS used during UE

initi al registration.
11 REGISTER 1. Profile retrieval will be only required

(IMPU) if profile is not available at TAS
2. TAS will update the expiry timer
12
200 OK
S-CSCF selects same IP-SM-GW used

during UE initial registration.
13
REGISTER (IMPU)
14 1. Profile retrieval will be only required

200 OK if profile is not available at TAS
2. TAS will update the expiry timer
1. The registration expires in UE. UE reregisters by sending a new REGISTER request. This request is
sent to the same P-CSCF with which UE initially registered.
Authorization: It carries authentication information. The private user identity is carried in the username field
of the Digest AKA protocol. As this is a re-registration process, the cached information (realm, nonce,
algorithm, uri, response) is also sent.
Security-Client: Lists the supported algorithm(s) by UE1.
Security-Verify: Contains the security agreement as represented by the previously received Security-
Server header. Upon receiving this request P-CSCF will detect that it already has a registration record for
UE and will reset its SIP registration timer for UE1 to the Expires time in this request.
2. Based on the user's URI, P-CSCF performs the DNS queries to locate the I-CSCF in the home
network. The look up in the DNS is based on the domain name specified in the Request URI. The DNS
provides P-CSCF with the address of the I-CSCF in the home network.
3.4 Cx-Query, or Diameter UAR: User-Authorization-Request: The I-CSCF makes a request for
information related to the Subscriber registration status by sending the private user identity ,public user
identity and visited domain identifier to the HSS.Cx-Query response, or Diameter UAA: User-
Authorization-Answer: The HSS returns the S-CSCF required capabilities and the I-CSCF uses this
information to select a suitable S-CSCF.
1. Upon receiving this request S-CSCF will detect that it already has a registration record for UE and will
reset its SIP registration timer for UE to the Expires time in this request.
6-7. S-CSCF updates the timer at HSS via diameter SAR/SAA response.
8-10. Registration response 200 OK is sent to UE
11-14. S-CSCFsend TPR to IMS-AS i.e. TAS/IP-SM-GW/RMS based on IFC will update the timer.
4.1.3 De-Registration
UAG /P- IP-SM
UE-A I-CSCF S-CSCF TAS HSS HLR
CSCF GW
1 REGISTER (IMPU, IMPI)

PANI,Expires=0)

based on DNS query
2 3 UAR (IMPU, IMPI, UA-Type = DE_REGISTRATION)
4 UAA (S-CSCF)
5 REGISTER (Expires=0)
S-CSCF does not apply UE Authentication during De-registration
6 SAR (IMPU, IMPI, S-CSCF Name. SA-Type=USER_DEREGISTERATION)

9 8
200 OK 200 OK 7 SAA (IMPU)
IFC
10 REGISTER (Expires=0)
11 UE Profile removed from local cash
200 OK
IFC
12 REGISTER (Expires=0) UE Profile removed
13 from local cash
200 OK
14 ATM
Absence of Modification request for IP-SM-GW data indicates
that the subscriber is no longer registered 15 ATM Ack
Steps remains same as explained in Refresh-Registration request only difference is Expiry timer will be set 0
Upon receiving SIP REGISTER request (as TPR) IMS-AS i.e. TAS/IP-SMGW/RMS will delete the profile.
1.
4.2 Registration @ visited PLMN (IMS Roaming)
4.2.1 Initial Registration

Visited Network Home Network
V: V: H AS
UE-A I-CSCF S-CSCF HSS
P-CSCF IBCF IBCF (TAS/RCS/IPSMGW)
Registration of the UE roaming in another circle

1 REGISTER (IMPU, IMPI)
 UAG compares RURI with PVNI to identify ROAMER and user is marked
as ROAMER and its stored in the cache in UAG.
 UAG routes the message to the V-IBCF( this is selected from a pool of
local IBCFs defined for routing the request to the home network.
 Adds path header(FQDN)
2
V-IBCF selects the peer H-IBCF
to forward the register based 4
5 UAR (IMPU, IMPI)
upon the RURI home domain
Adds path header (FQDN) 6 UAA
Adds path
header (FQDN) 7 REGISTER (IMPU, IMPI)
8 MAR (IMPU, IMPI)
10
401
9 MAA (IMPU, IMPI, auth vectors)
Unauthorized
14 13 12 11 (auth
challenge)
15 REGISTER (IMPU,
IMPI, auth resp) 16 17 18 19
20 SAR (IMPU, IMPI, S-CSCF Name)
21 SAA (IMPU, User Profile)
22 S-CSCF adds service-

26 25 24 23 200 OK route=cscf-zone1
FQDN address.
H-IBCF adds itself in
service route
27
REGISTER (IMPU,
IMS UE registered. AS (e.g. TAS) 28
Service-Info)
will fetch the subscriber profile from Profile retrieval
HSS via Sh or LDAP interface
29
200 OK
Other 3rd party registration procedures can occur after (not shown here)
1.The purpose of this request is to register the user's SIP URI with a S-CSCF in the home network. The
calling IMS subscriber is currently roaming outside the home network.
PGW will provide two IP addresses (Primary and Secondary) to the UE during the PDP attach. These two are
selected from the pool of the P-CSCF IPs configured on PGW and provided to the UEs in a round-robin
fashion.
2. Visitor P-CSCF detects user is roaming based on R-URI. (R-URI domain is different from domains that P-
CSCF is currently serving) UAG will cache this information. If so it will route the REG towards the user’s home
domain via IBCF. Once Roaming is identified at UAG, UAG will select V-IBCF FQDN form routing profile at
UAG (only for roamers). UAG will add itself in PATH (FQDN)
.
3. V-IBCF selects the peer H-IBCF to forward the register based upon the RURI home domain. V-IBCF will
add itself in PATH header(FQDN).
4.H-IBCF will route to I-CSCF based on RURI home domain. H-IBCF will adds itself in PATH header (FQDN).
.
5-6. In order to obtain the S-CSCF address, the I-CSCF performs the User Registration
Status Query procedures over the Cx interface.The I-CSCF sends out a Diameter User Authorization Request
(UAR) to the HSS to resolve S-CSCF address.
7. I-CSCF sends the REGISTER request to the S-CSCF address that it either got from the HSS.
8-9.MAR/MAA commands are used between the S-CSCF and the HSS to exchange information to
Support the authentication between the end user and the home IMS network. S-CSCF takes care of user
authorization, there exists the need to transfer security data over the Cx reference point. When the S-CSCF
needs to authenticate a user it sends a Multimedia-Auth-Request (MAR) command to the HSS. The HSS
responds with a Multimedia-Auth-Answer (MAA) command. The answer contains among other information
Authentication Data. It includes one or more authentication vector, which is comprised of an Authentication
Scheme (e.g., Digest-AKAv1-MD5), Authentication Information
(Authentication challenge RAND and the token AUTN), Authorization Information (expected response, or
XRES), Integrity Key and a Confidentiality Key. Additionally, it contains an Item Number, which indicates the
order in which the authentication vectors are to be consumed when multiple vectors are returned.
10-14. In order to authenticate, the S-CSCF rejects the initial REGISTER request from the
User with a 401 (Unauthorized) response, which includes (among other parameters) the
RAND, the AUTN, the IK and the CK.
Rest of steps are similar to UE doing registration from home domain. Signaling path will remain same.
Note: Here AS stands for TAS,IPSMGW and RCS application

4.2.2 Refresh-Registration
Visited IMS Network

V: V: H
UE-A I-CSCF S-CSCF AS HSS
P-CSCF IBCF IBCF
Subsequent Initial Registration or Refresh TPR.
REGISTER
(IMPU, IMPI) P-CSCF detects user is roaming based on R-URI. (R-URI domain is
different from domains that P-CSCF is currently serving).
UAR (IMPU, IMPI)
UAA [DIAMETER_SUBSEQUENT_REGISTRATION-2002, S-CSCF-Name]
REGISTER (IMPU, Service-Info)
200 OK
AS looks up local cache for subscriber’s profile. Profile retrieval
If not found, AS will fetch the subscriber profile
from HSS
The purpose and steps to Refresh-Registration remains same as explained in 2.1.2 Refresh-
Registration.
4.2.3 De-Registration
Visited IMS Network

V: H
UE-A P-CSCF I-CSCF S-CSCF AS HSS
IBCF IBCF
Explicit User Deregistration or Network Initiated Deregistration
REGISTER P-CSCF detects user is roaming based on R-URI. (R-URI domain is

(IMPU, IMPI)
Expires=0 different from domains that P-CSCF is currently serving).
UAR (IMPU, IMPI)

UAA [DIAMETER_SUBSEQUENT_REGISTRATION-2002, S-CSCF-Name]
200 OK
REGISTER (IMPU, Service-Info, Expires=0)

200 OK
The purpose and steps to Refresh-Registration remains same as explained in 2.1.3 De-Registration

5 Voice
The following is a summary of interactions applied for ICR and Roaming call flows.
5.1 Originator @Home PLMN

Each of the following call flow titles is self-explanatory with regards to the use case being described.
The Call flows will depict end-to-end events and messaging covering all network nodes involved. The
call flows will also cover the path and type of signaling and bearer flow across the end-to-end network
nodes.
5.1.1 IMS to IMS

S-CSCF TAS S-CSCF TAS
UE-A UAG(A) I-CSCF HSS UAG(B) UE-B
(A) (A) B B
OriginatingServices
1 INVITE [from:A, to: B, SDPo]
2 3
4. MNP
Normalize Number before ENUM
ENUM Query DB Query ENUM query should return LRN + SIP URI or TEL URI
4.a
OCS
5. CCR
5.a CCA
6 INVITE add tgrp parameter in contact header

TAS will
1.RN based routing 7 INVITE based on PVNI
2. prefix based routing will happen
8 LIR (B)
9.LIA (S-CSCF Name)
10. INVITE 11
Terminating services
12
13 14
16 15. 183 (SDP)

17
18. 183 (SDP)
20 19
21
24 23 22
25 PRACK 26 27
28
29 30
31
32
34 200
35 OK(PRACK)
36
38 37
39
42 41 40
If preconditions are used, a subsequent UPDATE (SDP offer) and 200 OK (SDP answer) would occur end to end here
44 43. 180 Ringing
45
48 47 46 180 Ringing
49
53 51 50
180 Ringing does not need to be sent reliably, but if it is it would be followed by a PRACK and 200 OK (not shown)
55 54. 200 OK
56
59 58 57
60
63 62 61
64. ACK 65 66
67
68 69
70
72
200 OK ACK is not shown

Call is answered, RTP session setup between UE-A and UE-B

UE-A UAG-A I-CSCF HSS UAG-B UE-B
(A) (A) B B
RTP RTP RTP
1-2.UE builds an SDP offer containing bandwidth requirements and characteristics for each set of codecs
that it is capable of supporting for this session. It assigns local port numbers for each possible media flow.
 -Request-URI: contains the international E.164 number from the user.
 -Via: contains the IPv6 address or FQDN (fully qualified domain name) of the originating UE.
 -Route: Contains the P-CSCF address learnt during P-CSCF discovery, plus the elements from
the Service-Route header from registration. The P-CSCF URI contains the port number learnt
during the security agreement negotiation.
 -P-Preferred-Identity: The user provides a hint about the identity to be used for this session.
 -P-Access-Network-Info: The UE provides the access-type and access-info, related to the
serving access.
 -Privacy: The user does not require privacy, therefore the Privacy header is set to the value
"none" as specified in RFC 3325 and RFC 3323.
 -Security-Verify: Contains the security agreement as represented by the received Security-Server
header.
 P-CSCF1 adds itself to the Record-Route header and Via header. As the request is forwarded to
an interface that is not compressed, the own P-CSCF SIP URI does not contain the
"comp=sigcomp" parameter.
- P-CSCF1 removes the Security-Verify header and associated "sec-agree" option-tags prior to
forwarding the request. As the Proxy-Require header is empty, it removes this header
completely.
 -P-Asserted-Identity: P-CSCF inserts the SIP URI in the P-Asserted-Identity header field and it
also removes P-Preferred-Identity header field.
 -P-Charging-Vector: P-CSCF inserts this header and populates the icid parameters with a
globally unique value.
2.S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. For this
example and routes to TAS.
3. TAS applies number normalization before MNP Query. Currently MNP DB and ENUM DB are same. So in
single query TAS can perform both task. Based on ENUM response TAS forms outgoing RURI.
IMS Call Type Query Type Response Type

sip:
{inputphonenumber};npdi;rn={rn}@{domain};use
Mavenir RJIL Wireless (ONNET) ENUM r=phone
Other Wireless OFFNET (CS
tel:{inputphonenumber};npdi;rn={rn}
Mavenir User) ENUM
sip:{inputphonenumber@domain}; user=phone
Mavenir RJIL Wireline (ONNET) ENUM
sip:
Other IMS {inputphonenumber};npdi;rn={rn}@{domain};use
Mavenir Wireless(OFFNET) ENUM r=phone

5. Trigger to OCS. Please refer Ro specification for details.

6.TAS routes back the INVITE to S-CSCF.
7.If S-CSCF receives SIP URI from TAS, then all it has to do is a DNS query to resolve the next hop.
Otherwise it has to do an ENUM query again to convert TEL to SIP URI.
8-9. LIR/LIA Diameter query to find out Terminating S-CSCF
10-14. Terminating Invite is routed to Terminating TAS, where T-TAS applies Terminating services and
Routes back to S-CSCF, which is routed towards to UE-B.
15-24.UE-A replies with 183 Session in progress response with answer of the Initial offer, which relayed to
UE-A.
25-42. PRACK/200 OK exchange between UE-A and UE-B.
43-53. UE-B send 180 Ringing response to UE-A.
54-73. 200 OK (for INVITE) and ACK message flow.
Note: CCR on MT leg is not shown.

5.1.2 IMS –IMS Telemarketing call flow (with DND Check)
(A) (A) B B
OriginatingServices
2 3 Normalize Number
before ENUM Query
3.a. DND
DND query done only if calling party is
telemarketer (identified by DN prefix) DB Query
3b.
4. MNP
ENUM query should return LRN + SIP URI ENUM
or TEL URI 4.a
OCS
5. CCR
5.a CCA

TAS will
1. RN based routing based on PVNI

7 INVITE
2. prefix based routing
8 LIR (B)
9.LIA (S-CSCF Name)
10. INVITE 11
12
13 14
16 15. 183 (SDP)

17
18. 183 (SDP)
20 19
21
24 23 22
25 PRACK 26 27
28
29 30
31
32 33
34 200
35 OK(PRACK)
36
38 37
39
42 41 40
44 43. 180 Ringing
45
48 47 46 180 Ringing
49
53 51 50
55 54. 200 OK
56
59 58 57
60
63 62 61
64. ACK 65 66
67
68 69
70
72

(A) (A) B B
RTP RTP RTP
Purpose to show this flow is, TAS will perform DND query if calling party is telemarketer number which is
identified by DN prefix.Rest of flow remains same as of 3.1.1 (IMS-IMS) call flow.
5.1.3IMS to other PLMN or PSTN
TAS MGCF/ PSTN
UE-A UAG S-CSCF I-CSCF BGCF
(A) GMSC (B)
OriginatingServices
2
Originating services 3
Normalize Number
MNP
4 ENUM: MNP query
4b.ENUM: MNP resp

(RCODE 3 ("Name Error")
add tgrp parameter in contact
TAS will
OC S
header based on PVNI
5.CCR
5b.CCA
6 INVITE [from:A, to: B, SDPo] ENUM/
For PSTN users RN will not be DNS
available, BGCF will analyze
calling party number to find
correct MGCF
In Actual deployment S-
Terminating Services
CSCF+BGCF are collocated
7. INVITE [SDPo]
8
9. 183 Session
10 Progress [SDPmgcf]
9.a IAM (B DN))
14 13 12
9b ACM
PRACK / 200 OK not shown
16 15 180 Ringing
17
20 19 18 21
22 200 OK 9c. ANM
23
26 25 24
27 ACK 28 29
30
32
TAS MGCF/MGW/ PSTN

(A) GMSC (B)
RTP RTP TDM
1-3. Reliance subscriber is calling to other operator PSTN number.

4-4b TAS will normalize the number before ENUM query. For other operator PSTN number,
ENUM will return response code “3”. TAS will add node indication in egress INVITEwhen this response code is
returned, the TAS will continue with normal call setup using the Request-URI received in the incoming request.
This Request-URI will include “node” parameter. TAS will also add tgrp pars based on a Party number.
5-5b. OCS trigger, Please refer to Ro specification.
7-8. MGCF selection at BGCF will happen based on calling party analysis (as LRN is not Available).
.-13. 183 response to relayed to UE-A
9a-9b. based on Calling, called party number, LRN and tgrp paras MGCF will select POI
15-20. 180 Ringing is relayed to UE-A
21-26. 200 OK response is relayed to UE-A
27-32. ACK for Initial INVITE is relayed to other operator PSTN user.
5.1.4 IMS to other operator 2g/3g subscriber
TAS MGCF/ PSTN

(A) GMSC (B)
OriginatingServices
2
Originating services 3
Normalize Number
MNP
4 ENUM: MNP query
4b.ENUM: MNP
tel:{inputphonenumber};npdi;
rn={rn}
add tgrp parameter in contact
TAS will
OCS
header based on PVNI
5.CCR
5b.CCA
Based on RN routing will happen.
Based on RN BGCF will select
MGCF.
In real deployment S-CSCF and Terminating Services
BGCF are colloacted.
7. INVITE [SDPo]
8
BGCF will select MGCF
based on RN
9. 183 Session
10 Progress [SDPmgcf]
9.a IAM (B DN))
14 13 12
9b ACM
16 15 180 Ringing
17
20 19 18 21
22 200 OK 9c. ANM
23
26 25 24
27 ACK 28 29
30
32
TAS MGCF/MGW/ PSTN

(A) GMSC (B)
RTP TDM
Call flow steps will remain same as IMS-Other Operator Landline user flow. The only difference in this flow is
ENUM will return response with “rn” number based on which S-CSCF will decide breakout case and BGCF will
select MGCF.
POI sectionat MGCF will be based on “rn”,”tgrp”, Called and calling party number.
5.1.5 IMS to RJIO IMS PSTN
OriginatingServices
(A) (A) B B
1-3 INVITE [from:A, to: B, SDPo]
4. ENUM
Normalize Number before ENUM
ENUM Query DB Query ENUM query should return SIP URI
For RJIL Wireline user domain will
4.a
be available.
OCS
5. CCR
5.a CCA

TAS will
Based on domain routing will happen
or based calling party prefix analysis I- 7 INVITE based on PVNI
CSCF will be selected.
8 LIR (B)
9.LIA (S-CSCF Name)
10. INVITE 11
12
13 14
16 15. 183 (SDP)

17
20 19 18. 183 (SDP)
21
24 23 22
25 PRACK 26 27
28
29 30
31
32 33
34 200
35 OK(PRACK)
36
38 37
39
42 41 40
44 43. 180 Ringing
45
48 47 46 180 Ringing
49
53 51 50
55 54. 200 OK
56
59 58 57
60
63 62 61
64. ACK 65 66
67
68 69 70
71
73

(A) (A) B B
RTP RTP RTP
Call flow remain same as explained in IMS-IMS call flow.
For RJIL Landline IMS subscriber, ENUM response will not contain “rn” number.
ENUM response format is sip:{inputphonenumber@domain}; user=phone.
Routing of RJIL IMS Landline will remain same as IMS user.
5.1.6 PLMN or PSTN to IMS
CS Origination to IMS Registered User
UE-B S-CSCF TAS

UAG I-CSCF HSS MNP MGCF MSC
(B) (B)
1a.ENUM: 1. IAM (MSISDN)

MNP Query
1b. ENUM: MGCF performs MNP dip for
MNP screening and based on LRN,
Response decides to route to RJIO IMS
or another network
2. INVITE [ MSISDN, SDPo]
3. LIR
4. LIA(S-
CSCF)
5 INVITE [ MSISDN, SDPo]
6
7
9 8. INVITE
10-13.
183 Session Progress (SDP)
14-17.
PRACK
18-21 Default RBT by MGCF
200-OK
(PRACK)
22-26
180 Ringing
28-32. 27 ACM
200-OK
(INVITE)
33 ANM
34.37
ACK (200-OK)
UE-B S-CSCF TAS

UAG I-CSCF HSS MNP MGW MSC
(B) (B)
RTP RTP TDM
1-1a-1b. MGCF performs MNP dip for screening and based on LRN, decides to route to RJIO IMS or
another network.
2.Based on RN , MGCF will select IMS domain and will find I-CSCF address.
3-4. Via LIR/LIA diameter messages I-CSCF will find out
5-9. Terminating INVITE will be relayed to UE-B via TAS. TAS will apply terminating supplementary
services.
10-13. UE-B sends SIP message 183 session in progress.
14-21. PRACK/200 OK exchange
22-26. 180 Ringing response send by UE-B
27. ISUM ACM response sent to User-A.
28-32. 200 OK response by UE-B
33. ISUM ANM response is sent to user-A
34-37. ACK for 200 OK response.
5.2 Intra-Circle Call Flows
5.2.1IMS to CS (Intra circle RJIO roamer)

Here A and B both are VOLTE Reliance JIO subscriber and B is Intra circle roaming.
O T AS T TAS MGCF/ MSC
UE-A P-CSCF I-CSCF HSS HLR
S-CSCF (A) S-CSCF (B) GMSC (B)
OriginatingServices
INVITE [from:A, to: B, SDPo]
MNP
ENUM
OCS
CCR
CCA
INVITE
DNS
S-CSCF will do enum query ENUM query for routing
for routing
INVITE
LIR (B)
LIA ( 2003 UNREGIS TERED SERVICE)
Terminating Services
O T AS T TAS MGCF/ MSC

UE-A P-CSCF I-CSCF HSS HLR
S-CSCF (A) S-CSCF (B) GMSC (B)
INVITE (REGSTATE= unregistered)

TAS will fetch profile
SRI-MT(B MSISDN)
Since subscriber is not attached to IMS, so
TAS will do PRN(B MSISDN)
SRI-MT Ack(MSRN) PRN Ack(MSRN)
INVITE (MSRN)
183 Session Progress [SDPmgcf]
180 ISUP: ACM
200 OK ISUP: ANM
O TAS T TAS MGW/ MSC

UE-A UAG I-CSCF (B) HSS HLR
S-CSCF (A) S-CSCF GMSC (B)
RTP RTP TDM
5.2.2 CS (Intra circle RJIO roamer) to IMS

S-CSCF TAS
UE-B I-CSCF HSS OCS/IWF MGCF MNP MSC UE-A
(B) (B)
Setup(CdPN=MSISDN-
B)
Visited NW performs orig services incl. MNP Visited NW performs orig services
dip and Prepaid charging CAP InitialDP(DP2)
MNP Query
MNP Query Response

Ro
Ro
CAP CUE,RRB
IAM (MSISDN)
MNP
ENUM: MNP
Query MGCF performs MNP
dip for screening
ENUM: MNP
Response
INVITE [ MSISDN, SDPo]
LIR
LIA(S-CSCF)
INVITE
PRACK/200 OK is not shown
180 Ringing
ACM
200-OK
(INVITE)
ANM
ACK (200-OK)

5.2.3 CS (Intra circle RJIO roamer) to IMS Different Circle
S-CSCF TAS
UE-B I-CSCF HSS OCS/IWF MGCF MNP MSC UE-A
(B) (B)
Setup(CdPN=MSISDN-
B)
Visited NW performs orig services incl. MNP Visited NW performs orig services
dip and Prepaid charging CAP InitialDP(DP2)
MNP Query
MNP Query Response

Ro
Ro
CAP CUE,RRB
IAM (MSISDN)
MNP
ENUM: MNP
Query MGCF performs MNP
dip for screening
ENUM: MNP
Response
LIR
LIA(S-CSCF)
INVITE
PRACK
200-OK
(PRACK)
180 Ringing
ACM
200-OK
(INVITE)
ANM
ACK (200-OK)

5.2.4 CS (Intra circle RJIO roamer) to Non Registered IMS
User (B is in CS termination)
TAS(B) S-CSCF/ OCS IWF MGCF(A) MSC-O UE-A
UE-B MGCF(B) I-CSCF HLR HSS Visited NW performs
BGCF
orig services Setup(CdPN=MSISDN-B)
CAP InitialDP(DP2)
MNP
MNP Query
MNP Resp
Ro
Ro
CAP CUE, RRB
Visited MSC
routes the call to
MNP home circle based
IAM (MSISDN)
on MCC/MNC
MGCF performs MNP
MNP Query
dip for routing
Terminating services MNP
Response
Based on LRN received from
INVITEsip:{inputphonenumber};rn;@{domain} MNP response,MGCF decides
INVITE to route to CS/PSTN
(regstate=unr LIR
eg) INVITE LIA (unreg)
Since subscriber is Roaming in CS,

i.e.subscriber is not registered in IMS.
MAP_SRI
(CFNRc active)
SRI_RESPONSE(MSRN)
T-TAS will add Tgrp based on home domain.?
S-SCF will determine it as breakout scenario

INVITE
based on called party prefix
tel:msrn;npdi
MGCF selection will happen based on number
analysis.
BGCF will select MGCF based on

IAM Called, calling and Tgrp parms
183(SDP)
PRACK and 200 OK is not shown

ACM
180 Ringing will be sent. Not shown

ACM
ANM
200 OK
ANM
O-TAS(TAS MGCF(A)
MGCF(B) MSC-O UE-A
UE-B B) T-TAS(B) S-CSCF I-CSCF HLR HSS /MGW
/MGW
TDM RTP TDM TDM

5.3 National Long Distance (NLD/ILD)
5.3.1IMS Roaming Inter-Circle

For this call flow, it is important to remember the roaming registration flow in section 4.2.1.
VPLMN-A HPLMN-A HPLMN-B VPLMN-B

V-IBCF TRF
UAG(P- S-CSCF TAS S-CSCF TAS IBCF/ IBCF/ UAG-B
UE-A TRG w IBCF(A) MGCF(A) HSS I-CSCF UE-B
CSCF) (A) (A) B B TrGW TrG W P-CSCF
INVITE[SDPo] UAG will dip into cache to identify roamer.

If Roamer UAG will identify V-IBCF based on TRG Originating Services
profile and will add Feature Caps:+g.3gpp .trf Terminating Services
OMR functionality will be disabled at UAG
INVITE V-IBC will route as per entry in the route header

Feature Ca ps:+g.3gpp IP address, port number and the IP realm
Route :<sip: v-ibcf.net;lr> Va.operatorV.net of the UE-A is included as the
Route:<sip:scscf1.net;lr>
visited-realm 1 instance
FeatureCaps:+g.3gpp..trf="<sip:trf1.visite
dV.net>"
SDPo]
IBCF will apply OMR algorithm i.e IBCF will update

SDP media parameters of the TrGW are included in INVITE H-ibcf will add vistaed relam
the SDP and IP address, port number of the TrGW Feature Ca ps:+g.3gpp Based on route header routing will
and the IP realm are included as the visited-realm Route :<sip: v-ibcf.net;lr> happen to s-cscf
instance Route:<sip:scscf1.net;lr>
FeatureCaps:+g.3gpp..trf="<sip:
trf1.visitedV.net>" a=visited-
realm:1 Va.operato rV.net IN IP4 Identifies roamers based on trf and
allows loopback
Add trf address in route.
TAS routes the INVITE back to SCSCF for further routing, CSCF
detects the loopback routing based upon the local policy and
using trans routing profile S-CSCF routes back to H-IBCF
INVITE
sip:<msisdn;npdi;rn@domain
Route:<sip:trf1.visitedV.net;lr>
FeatureCaps:+g.3gpp.loopback
INVITE a=visited-realm:1
sip:<msisdn;npdi;rn@domain Va.operatorV.net IN IP4
Route:<sip:trf1.visitedV.net;lr> a=visited-realm:2
FeatureCaps:+g.3gpp.loopback Va.operatorV.net IN IP4
a=visited-realm:1 H-ibcf routes the request back to visited network IBCF based
Va.operato rV.net IN IP4
upon the domain specified in TRF address in Route header
192.0.2.1 49170
Source based DNS may be required to resolve the query.
Exit I-BCF will route based on RN or domain

if RN and domain are present in that routing
will be prefix based
Apply IFC H-IBCF of B is in termination

path as it included its own
address in “Path” during
REGISTRATION.
183
Continue as in IMS to IMS call flow Bearer path is setup as follows:

UE-A  UAG-V-PLMN(A) IBCF/TrGW  H-PLMN(B) IBCF/TrGW  V-PLMN IBCF/TrGW  V-PLMN(B) UAG  UE-B
VPLMN-A HPLMN-A HPLMN-B VPLMN-B

UAG(TrG
UE-A
W) S-CSCF TAS S-CSCF TAS IBCF/ IBCF/ UAG-B
IBCF(A) TRF IBCF(A) MGCF(A) I-CSCF UE-B
(A) (A) B B TrGW TrG W P-CSCF
RTP RTP RTP RTP RTP RTP

RJIL 4G user

Homedomain of user = ims.mnc874.mcc405.3gppnetwork.org (Mumbai)
Visited domain of the user = ims.mnc861.mcc405.3gppnetwork.org (karnataka)
 UE sends an INVITE to Visited UAG (Karnataka). ( RURI in tel:URI and From: can be tel: or
sip:).
 Visited UAG(karanataka) checks in its cache and founds that user is a roamer. (it can either
use tel:URI or user part of the sip: URI to dip into the cache to find its roaming status). UAGL
adds the TRF header Feature-Caps:+g.3gpp.trf="<sip:trf1-
karnataka.ims.mnc861.mcc405.3gppnetwork.org>" . it routes the request to any local
ibcf(example ibcf-karnataka-2) in Karnataka circle which is used for for routing the requests
to the home domain specified in the service-route header containing home ibcf address(ibcf-
mumbai domain).
 VisitedIbcf (Karnataka) then routes the request to the Home ibcf (mumbai) as per entry in the
route.
 Home Ibcf(Mumbai) then routes the request to scscf (after decrypting its address from
service-route after removing IBCF’s own address).
 SCSCF will provide the services to the user (after executing its iFCs and giving it to TAS).
 When TAS routes the INVITE back to SCSCF for further routing, CSCF detects the loopback
routing based upon the local policy
o CSCF then updates the route header with TRF address as in the features-cap
header. Route: sip:trf1-karnataka.ims.mnc861.mcc405.3gppnetwork.org
o includes in a Feature-Caps header field the feature tag +g.3gpp.loopback to indicate
that loopback routing is ongoing; and
 CSCF now needs to select one of the home IBCFs in the home domain of the user. CSCF will
select Home Ibcf based on trans routing profile.
 CSCF then routes the request via this home IBCF(selected via trans routing profile) say , ibcf-
mumbai-2.
 Home Ibcf(Mumbai) now routes the request back to visited network IBCF (karnataka) based
upon the domain specified in TRF address in Route header.
 Visited Ibcf(Karnataka) then routes the request to the TRF as in the route address.
 Visited Ibcf(Karnataka) now has to route the request to the terminating network.
o The INVITE needs to be routed to ICSCF based upon RN if the B-party is RJIL 4G
wireless.
o Routed to MGCF on the basis of RN analysis if the B-party is offnet wireless user.
o Route to MGCF on the basis of rjil-fixed-line-domain in case B-party is RJIL wireline.
o Route to MGCF on the basis of prefix analysis in case B-party is offnet wireline.
5.3.2Roaming CS Origination to IMS Different circle
OCS/IWF MSC-O UE-A
Visited NW performs orig services

Setup(CdPN=MSISDN-B)
CAP InitialDP(DP2)
MNP
MNP Query
MNP Resp
Ro
Ro
CAP CUE, RRB
MNP
MSC-O
performs
MNP dip for
P-CSCF TAS routing
UE-B S-CSCF I-CSCF HSS MGCF MNP Query
B B
MNP Response
MSC-O uses
IAM (MSISDN; npdi=Y) the LRN to
route to the
INVITE
right circle
LIR
LIA
INVITE
INVITE
INVITE
INVITE
INVITE
Continue same MT to IMS flow
5.3.3 Roaming CS Origination to CS Different circle

GMSC-T OCS/IWF MGCF/ MSC-O UE-A
MGW
Visited NW performs
orig services Setup(CdPN=MSISDN-B)
CAP InitialDP(DP2)
MNP
MNP Query
MNP Resp
Ro
Ro
CAP CUE, RRB
MSC-O
MNP performs
MNP dip
for routing
MNP Query
MNP Response
IAM (MSISDN; npdi=Y) IAM (MSISDN; npdi=Y)

6 Emergency Call flow
E-CSCF/
UE-A UAG MGCF PSAP
LRF
INVITE tel:108 OriginatingServices

PANI=utran-cell-id-
3gpp=40587400060001911 Identify Emergency/Special Number based
From=tel:+91702107548 on called party digit.
sos indication may or may not be present
If Cell-id is present, E-CSCF will map cell id to Area

code and prefix the Area code in egress invite
If Cell id is not present E-CSCF will use calling party
number to map area code and prefix in outgoing
Invite
E-cscf will add tgrp parameter in

contact header based on Area
code or PVNI.
Selection of MGCF will be based

on Area code+Dialed digit or Area
code
INVITE tel:+9122108,phonecontext=local
PANI=utran-cell-id-3gpp=40587400060001911
From=tel:+91702107548
IAM
183 Session Progress [SDPmgcf]
ACM
180
ANM
200 OK
ACK is not shown
E-CSCF/ MGCF/MGW/ PSTN

UE-A UAG
LRF GMSC (B)
RTP RTP TDM
Note: Above flow applies for roaming subscriber also.

7 Messaging
SMS: ICR & Roaming

Roaming
MO SMSC check spam
MNP at SMSC
Ro at SMSC
RN returned used by SMSC for
routing
MT SRI to IPSM or HLR?
HLR has to support Rel8
different TT support
DND check
7.1 Third Party Registration With Sh Interface at IPSM
UE A P-CSCF I-CSCF S-CSCF Primary IP-SM-GW1 HSS HLR
REGISTER
UAR
UE capabilities UAA
indicated via feature
tags in Contact header REGISTER
401 Unauthorized
REGISTER
UAR
UAA
REGISTER
SAR
SAA (iFCs with ServiceInfo containing MSISDN)

200 OK
iFC execution
REGISTER (XML[MSISDN])
MSISDN stored
200 OK
SUBSCRIBE (reg)
200 OK
Feature tags sent in

reginfo XML doc
Messaging capabilities stored
NOTIFY (reginfo XML)
200 OK
Optional MAP ATM inv (MSISDN, IP-SM-GW

shared E.164 address)
MAP ATM rsp
HLR records IP-

SM-GW address
GW1 downloads subscription and regData information from HSS over Sh
interface using public identity received from S-CSCF. No support for Notif-Eff UDR (IMPU, DataReference=RepData,
ServiceIndication=RMS_DYNAMIC_DATA)
UDA (RMS_DYNAMIC_DATA)
PUR (IMPU, DataReference=RepData,

GW1 updates the registration related information in HSS for subscriber User-Data=<actual data>)
PUA
SNR (IMPU, DataReference=RepData,

GW1 subscribes for change in notification of repository data for
configurable period which is refreshed before subscription expiry.
SNA
7.1.1On Arrival of a Third Party Registration (UE details
not in the local cache)
 The IP-SM-GW sends UDR to the HSS to get the RMS_DYNAMIC_DATA (represented
by repository data) stored in the HSS (if any). RMS_DYNAMIC_DATA includes IMS registration
information including S-CSCF name, feature tags, contact details of UE besides the tUNRI
element, which is the last known state of UNRI (known to an IP-SM-GW).
 The HSS responds with UDA containing this data (if any is available).
 The IP-SM-GW sends PUR containing the information about the subscriber that it has
cached locally (MSISDN, IMSI, S-CSCF name, UE Capabilities, regInfo from S-CSCF, tUNRI) so
that this is available at other IP-SM-GW instances in a failure scenario. This update clears tUNRI
in the RMS_DYNAMIC_DATA (if it was set earlier). The HLR/HSS UNRI flag is cleared by
sending MAP readyForSM and MAP ATM. Either of them causes the UNRI flag to be cleared in
HLR/HSS.
 The HSS responds with PUA.
 The IP_SM-GW sends SNR to subscribe for changes to RMS_DYNAMIC_DATA (just in
case if any subsequent registration messages go to other RMS node in case of failover etc. or
there is no AS anchoring in IMS core).
 The HSS responds with SNA.
 Optionally (to cover the case where the IP-SM-GW has subscribed and then been
rebooted, and the UDA actually contains registration details including UNRI) IP-SM-GW sends an
SNR to unsubscribe for UE Reachability in IP domain notifications from the HSS.
7.1.2 On Arrival of a Third Party Registration (re-

registration, UE details already in the local cache)
If UNRI is set in the local cache
 The IP-SM-GW sends UDR to the HSS to get the latest version number for the
repository data.
 The HSS responds with UDA containing this data.
 The IP-SM-GW sends PUR to clear the cached copy of UNRI in tUNRI. The HLR/HSS
UNRI flag is cleared by sending MAP readyForSM.
 The HSS responds with PUA.
7.1.3 On Arrival of a Third Party Registration (de-

registration)
 The IP-SM-GW sends UDR to the HSS to get the latest version number for the
repository data.
 The HSS responds with UDA containing this data.
 The IP-SM-GW sends PUR to remove RMS_DYNAMIC_DATA from the HSS.
 The HSS responds with PUA
7.2 On-Net
7.2.1 IMS to IMSsame circle

IMS UE RMS
IMS Core IP-SMSC
A IPSM GW
iFC execution
Anti
Spam
MNP
9 ENUM: MNP result
RJIL
STP HLR
HNR: During
registration, IPSM GW
10 SRI-SM updates gsmSCF-
Reg. info found Address on subscribers
MSISDN is found to be associated with an IMS 12 SRI-SM profile in HLR to point to
public user identity IPSM GW. If IPSM GW
MT Correlation ID created/IMSI 14 SRI-SM-RESP (IPSM GW, Correlation-ID) address is present, HLR
will forward the SRI
15
OCS
16.a Ro CCR
16 MO-FSM rsp (SMS- 16b
SUBMIT-REPORT) Ro CCA
19. 200 OK
IMS UE 22 MT FSM inv (SMS-DELIVER)

B
27 MESSAGE (SMS-DELIVER-
REPORT)
31 MT FSM rsp (SMS-
29. 200 OK
DELIVER-REPORT)
If delivery report is required to user A
34 SRI-SM
36 SRI-SM-RESP (IPSM GW, Correlation-ID)
38 MTFSM (sms-delvery-
report)
41 200 OK
STP will route the MAP SRI request to Reliance HLR based on based on Translation Type(TT) in the
SCCP CalledPartyAddress.
Upon receiving the MAP_SRI_For_SM ind, the HLR .The HLR relays the message MAP_ SEND_
ROUTING_INFO_FOR_SM received from the IP-SMSC to the IP-
SMGW on SCCP level. How this is done is implementation specific. The method by which it does
could be for example done by SCCP GT analysis e.g. forward all MAP_SRI_For_SM messages on to
the IPSM GW that have not come from the IPSM GW, or even on a per subscriber basis by usage of
a flag in the subscriber's profile.
Note: Delivery report is optional.For the scenario where delivery report is not required steps 27 to 42
will not happen.
7.2.2 IMS – IMS Different circle
HPLMN-A HPLMN-B
UAG-A S-CSCF IPSM-GW IPSM-GW S-CSCF UAG -B
UE-A IP-SMSC UE-B
P-CSCF (A) (A) (B) (B) P-CSCF
IPSMGW will get the roaming status of the

SIP: MESSAGE(SMS SUBMIT) subscriber by comparing the home domain and
visited network identifier.
MO-FSM inv (SMS-SUBMIT)
Anti
Spam
Anti-spam Req
Anti-spam resp
MNP
MNP Query
MNP Result
Reg. info found
RJIO MSISDN is found to be associated with an IMS
HLR public user identity
SRI-SM INV SRI-SM INV MT Correlation ID created/IMSI
SRI-SM ACK (IPSM-GW B, correlation ID)
OCS
MO-FSM rsp CCR

(SMS-SUBMIT-
REPORT) CCA
MESSAGE
(SMS-
SUBMIT-
REPORT)
200 OK
MT FSM inv (SMS-DELIVER)
MESSAGE (SMS-DELIVER)
200 OK
Delivery Report and MT FSM rsp (SMS-DELIVER-REPORT) is not shown

7.3 ICR and Inter-Circle
National 2G/3G Roaming
 SMS over regular 2G/3G will get routed to RJIO home SMSC
 For MT SMS, SRI SM from SMSC routed to IPSMGW will be routed back to HLR by IPSMGW to
get the CS Visited MSC Number.
 This CS Visited MSC number is relayed back to the HLR and eventually to SMSC.
 The RJIO Home SMSC will route the terminating SMS to visited network after getting the visited
CS MSC number in the SRI SM Return Result.
7.3.1RJIL User is in ICR

Here 4G user is sending to another 4G user who is in ICR.
UE-A P-CSCF S-CSCF IPSM STP SMSC HLR MSC
MESSAGE
(+g.oma.sip-im, IM) or
MO FSM
(plain/text)
MO FSM rsp (SMS-
SUBMIT-REPORT)
202 Accepted
Anti
Spam
Diam. Antispam
req.
Diam.Anti Spam
res.
MNP
Enum:MNP dip
ENUM:MNP dip
res.
SRI for SM inv (MSISDN)
STP load balances SRI-SM traffic to all the

available IP-SM-GWs
Registration information not found. IPSM must check

1st if user is available in IM S or not before falling
back to CS/PS domain. No support for Notif-Eff
HSS
UDR (IMPU derived from MSISDN, DataReference=RepData,

ServiceIndication=IP_SM_GW_DYNAMIC_DATA)
UDR is done only if subscriber

UDA (no rep.data) information is not locally cached at non-
primary IMP.
IPSM determines IMPU is not

registered in IMS domain .
SRI
SRI for SM resp.(IMSI,MSC/SGSN address)
SRI for SM resp.(GT=IPSM

address)
ocs
CCR
MO-FSMrsp (SMS Submit CCA
Message (SMS-Submit- Report)
Report)
MTFSM
MTFSM response is not shown
IPSM support sending UDR over the Sh interface with the contents as described below:
Information Mapping to Cat. Description
element Diameter
name AVP
User Identity User- M IMS Public User Identity, Public Service Identity, or MSISDN of
Identity the user for whom the data is required.
Always set to IMPU if available otherwise MSISDN

Requested Data- M This information element indicates the reference to the
data Reference requested information.
RMS shall always download “Repository Data” and if required

“IMSUserState” and/or “S-CSCF Name” and/or “IMS Public
Identities” when only MSISDN is available.
Requested Identity-Set O If Data-Reference indicates that IMS Public Identities is the
Identity set requested data set to be downloaded, this information element
should be included when User Identity is set to MSISDN not
otherwise.
This information element shall always set to value

REGISTERED_IDENTITIES. The HSS shall provide all non-
barred IMS Public Identities whose state is registered,
belonging to all Private Identities that the IMS Public Identity or
MSISDN in the User-Identity AVP is associated with. If the User
Identity is a Public Service Identity, the HSS shall return no
identities in the response.
Service Service- C IE that identifies, together with the User Identity included in the
Indication Indication User-Identity AVP and Data-Reference, the set of service
related transparent data that is being requested.
Set to RMS_DYNAMIC_DATA when Data Reference is set to

Repository Data otherwise not included.
Application Origin-Host M IE that identifies the AS originator of the request and that is
Server used to check the AS permission list.
Identity
Set to FQDN of IPSM
UDA (Sh Pull Resp)

IPSM support receiving UDA over the Sh interface with the contents as described below :

element Diameter AVP
name
Result Result-Code / M Result of the request.
Experimental_Result
Result-Code AVP shall be used for errors defined in the
Diameter Base Protocol.
Experimental-Result AVP shall be used for Sh errors. This is a

grouped AVP which contains the 3GPP Vendor ID in the
Vendor-Id AVP, and the error code in the Experimental-Result-
Code AVP.
Data User-Data C Requested data. This element shall be present if the requested
data exists in the HSS and the AS has permissions to read it.
PUR (Sh Update)

IPSM support sending PUR over the Sh interface with the contents as described below:
element name Diameter AVP
User Identity User-Identity M IMS Public User Identity or Public Service Identity for
which data is updated.
Always set to IMPU.

Requested Data-Reference M This information element includes the reference to the
data data on which updates are required.
Always set to Repository Data.

Data User-Data M Updated data.
Application Origin-Host M IE that identifies the AS originator of the request and

Server Identity that is used to check the AS permission list.
PUA (Sh Update Resp)

IPSM support receiving PUA over the Sh interface with the contents as described below:
Information Mapping to Cat Description

element name Diameter AVP .
Result Result-Code / M Result of the update of data in the HSS.
Experimental-
Result Result-Code AVP shall be used for errors defined in the
Diameter Base Protocol.
Experimental-Result AVP shall be used for Sh errors.

This is a grouped AVP which contains the 3GPP
Vendor ID in the Vendor-Id AVP, and the error code in
the Experimental-Result-Code AVP.
7.3.2ICR to IMS
Foreign Originating Network RJIL 4G NW
IPSM
UE-A SMS-GMSC-A IP-SMSC HLR IMS Core UE
GW
SMS transfer MOFSM
SRI-SM (MSISDN=B, SMSC-A) Destination registered in IMS

RO,MNP and Antispam trigger will
happen as per normal,not shown here
REG. info found and subscriber info
is in cache so Sh query will not
SRI-SM-RESP (IPSM, Correlation-ID) happen
MOFSM-Resp (SMS-Submit-Report)
200 OK
MTFSM
200 OK
MTFSM Resp
7.3.3 RJIL (A and B party)user in ICR
IPSM
UE-B UE-A SMS-GMSC-A IP-SMSC HLR IMS Core
GW
SMS transfer MOFSM
SRI-SM (MSISDN=B, SMSC-A) Destination registered in IMS

RO,MNP and Antispam trigger will
happen as per normal,not shown here
REG. not found and subscriber info is
not in cache so Sh query not happen
HSS
UDR(IMPU,si=ip-sm-gw-dynamic-data
UDA (no xml)
SRI
SRI Resp (MSC/SGCN address

SRI-SM-RESP (IPSM, Correlation-ID)
MOFSM-Resp (SMS-Submit-Report)
MTFSM
MTFSM
MTFSM Response is not shown
7.3.4 IMS to Other operatorCS

Here RJIL 4G user is sending message to other operator CS user.
IMS UE RMS IP- Other NW Other NW
IMS Core
A IPSM GW SMSC HLR MSC/SGSN
Anti
MESSAGE (SMS-SUBMIT) Spam
MO-FSM inv
iFC execution
(SMS-SUBMIT)
Diameter: antispam req
MNP
ENUM: MNP result
STP
SRI-SM inv
SRI - SM rsp (MSC/GGSN address, )
MT FSM inv (SMS-DELIVER)

200 OK
Note: delivery report is not shown.

7.3.5 CS(other operator) to RJIO IMS User
This call flow is applicable to:
- CS MO from non-RJIO subscriber to RJIO subscriber

Without HNR
IPSM IMS Core/

UE-A SMSC STP IP-SMSC HLR
GW UE
SMS transfer Destination registered in IMS

SRI-SM (MSISDN=B, SMSC-A)
REG. info found and subscriber info
is in cache so Sh query will not
SRI-SM-RESP (IPSM, Correlation-ID) happen
MT-FWD-SM (SMSC-A, SMS-DELIVER)
SMS delivery
MT-FWD-SM-ACK (SMS- 200 OK
notification:sent
DELIVER-REPORT)
-
7.4 National Roaming in LTE/IMS network
VPLMN-A HPLMN-A HPLMN-B

UAG -A S-CSCF IPSM-GW S-CSCF UAG -B
UE-A IPSM-GW SMSC UE-B
P-CSCF (A) (B) (B) P-CSCF
1 SIP: MESSAGE(SMS SUBMIT) IPSMGW will get the roaming status of the
2 subscriber by comparing the home domain and
3 visited network identifier.
4. MO-FSM inv (SMS-SUBMIT)
Anti
Spam
5 Anti-spam Req
5a. Anti-spam res
MNP
6.MNP Query
6a.MNP Result
OCS
7.Ro
CCR
7b.Ro
CCA
8. MO-FSM rsp (SMS-SUBMIT-REPORT)
RJIO
9.MESSAGE (SMS-SUBMIT-REPORT) HLR
11 10 11 SRI-SM INV
12. SRI-SM-RESP (IPSM GW, Correlation-

ID)
13
14. MT FSM inv (SMS-DELIVER)
15.MESSAGE (SMS-DELIVER)
16
17
19 18.200 OK
20
21. MESSAGE (SMS-

22 DELIVER-REPORT)
24. MT FSM rsp (SMS-DELIVER-REPORT) 23
25.200 OK
26 27
National LTE/IMS Roaming

 SMS over IP will come via visited P-CSCF to home network IP-SM GW.
 The IPSMGW will get the roaming status of the subscriber by comparing the home domain and
visited network identifier.
 MO SMS will be sent with SCCP Calling party address different from the home one, so that
charging for roaming can be done properly at SMSC. For MT SMS, SRI will get routed to
IPSMGW and it can send back an MSC Number which will indicate roaming status of the user, so
that SMSC can charge the SMS accordingly.
For RCS services, the roaming status will be identified by comparing the home domain and visited
network identifier. To be discussed and finalized
Note : Visiting IBCF and Home IBCF is not shown here.

7.5 P2A message call flow
IMS UE RMS IP-SMSC/
IMS Core HLR ESME
A IPSM GW SMGW
MESSAGE (SMS-SUBMIT) MO-FSM inv

iFC execution
(SMS-SUBMIT)
OCS
Ro CCR
Deliver_SM
200 OK
Delivery_SM_RESP
7.6 A2P call flow
IMS UE RMS IP-SMSC/ ESME
IMS Core
A IPSM GW SMSGW
Submit_SM
Submit_SM resp.
DND
MNP
RJIL
HLR
SRI-SM INV
SRI-SM INV
SRI-SM-RESP (IPSM GW, Correlation-ID)
MT FSM
IMS UE
B
200 OK
MESSAGE (SMS-DELIVER-REPORT)
MT FSM rsp (SMS-
200 OK DELIVER-REPORT)
7.7 Message Origination in IMS domain as SMSIP (Transport Interworking) – MO

Long Message
Below flow describes when large size(more than configured) message is received at IPSM.
UE A P-CSCF S-CSCF IP-SM-GW HSS HLR SMSC
MESSAGE (SMS-SUBMIT)
each 134 Octets of UD seg Client shall segment the long message with UDH
1/n info and send multiple segment to IP_SM_GW.
iFC execution
134 Octets of UD seg 1/n
202 Accepted (segment 1/n)
Authorization, screening, etc.
MO-FSM (SMS-SUBMIT) (Segment 1/n)
MESSAGE (SMS-SUBMIT- MO-FSM-Resp (SMS-SUBMIT-REPORT) (Segment 1/n)

REPORT) (Segment 1/n)
200 OK (Segment 1/n)
.
.
.
.
.
.
134 Octets of UD seg n/n
iFC execution
134 Octets of UD seg n/n
202 Accepted (Segment n/n)
Authorization, screening, etc.
MO-FSM (SMS-SUBMIT) (Segment n/n)
MESSAGE (SMS-SUBMIT- MO-FSM-Resp (SMS-SUBMIT-REPORT) (Segment n/n)

REPORT) (Segment n/n)
200 OK (Segment n/n)
SRI-SM (MSISDN)
Determines that subscriber is registered
in IMS domain with IP-SM-GW hence it
forwards message to correct node.
SRI-SM (MSISDN)
MSISDN is found to be associated

with an IMS public user identity
SRI-SM-Resp (IMSI, IP-SM- SRI-SM-Resp (IMSI, IP-

GW GT) SM-GW GT)
MT-FSM (IMSI, SMS-STATUS-REPORT)

MESSAGE (SMS-STATUS-
REPORT)
200 OK
Message (SMS-DELIVER-
REPORT)
MT-FSM-Resp (SMS-DELIVER-REPORT)
202 Accepted
7.8 Domain selection and CS RETRY
Below flow describes domain selection happen at IPSM and when IMS delivery is failed and CS-
RETRY is enabled, IPSM will try to deliver the message in CS
UE-A P-CSCF S-CSCF IPSM STP SMSC HLR MSC UE-B
MESSAGE
MO FSM
(plain/text)
MO FSM rsp (SMS-
SUBMIT-REPORT)
202 Accepted
Anti
Spam
Diam. Antispam
req.
Diam.Anti Spam
res.
MNP
Enum:MNP dip
ENUM:MNP dip
res.

available IP-SM-GWs

1st if user is available in IMS or not before falling
HSS

UDR is done only if subscriber

UDA (rep.data) information is not locally cached at non-
primary IMP.
IPSM determines IMPU is


address) ocs
CCR
CCA
MESSAGE (SMS-Submit- MO-FSM Resp (SMS Submit
Report) Report)
MTFSM
MESSAGE
Case1 : Subscriber switch off mobile phone

Case2 : Subscriber out of coverage area
Case 3 : No response from UE
Upon receiving Failure response or no response for

the sen t Request, IP-SM-GW will do CS Fall back
Based on configuration.
Determines that subscriber
is registered in CS domain
with MSC hence provides
IPSM will do PUR/PUA to update UNRI=1 i.e.
MSC address.
subscriber is not available in IMS. Not shown
in flow
IP-SM-GW checks if recipient SRI Resp.

MT-FSM-Resp (SMS-
is available in CS domain.
DELIVER-REPORT) MTFSM
SMS
Transfer
MTFSM Resp
MT-FSM-Resp (SMS-
DELIVER-REPORT)
If CS RETRY is not enabled, and IPSM receives 4xx
MT-FSM-Return Error (Absent

Subscriber)
PUR (RMS-
DYNAMIC-DATA, HLR records actual
with UNRI=1) SMSC address in its
Report-SM-Delivery-Status (UNRI, MWD list.
MNRF, SMSC Address)
Report-SM-Delivery-Status
(UNRI, MNRF, SMSC HLR will ignore this
Address) request
7.9 Deferred message delivery
UE-B UE-A P-CSCF S-CSCF IPSM STP SMSC HLR MSC
MESSAGE
MO FSM
(plain/text)
MO FSM rsp (SMS-
202 Accepted SUBMIT-REPORT)
Anti
Spam
Diam. Antispam
req.
Diam.Anti Spam
res.
MNP
Enum:MNP dip
ENUM:MNP dip
res.

available IP-SM-GWs
Registration information not found. IPSM mu st check

1 st if u se r is available in IM S or not be fore falling
back to CS/PS domain. No suppor t for Notif-Eff
HSS

ServiceIndication=IP_SM_GW_DYNAMIC_DATA)
UDR is done only if s ubscriber

UDA (rep.data) information is not l oc ally cached at non-
primary IMP.

registered in IMS doma in .

address) ocs
CCR
MO-FSMrsp (SMS Submit CCA

Message (SMS-Submit- Report)
Report)
200 OK
MTFSM
MESSAGE
Case1 : Subscriber switch o ff mobile phone

Case2 : Subscriber out of co ve rage area
Case 3 : No response from UE Upon receiving Failure response or n o resp onse for
the sen t Request, IP-SM-GW will do CS Fall back
4xx (can be Based on configuration.
404/408/480)
IPSM will do PUR/PUA to update UNRI
PUR(RMS- Determines that
DYNAMIC-DATA as subscriber is not availab le in IMS. Not subscriber is registered in
wit h UNRI=1) shown in flow CS domain with MSC
hence provides MSC
PUA address.
SRI
SRI-SM-Resp (IMSI, MSC GT)

IP-SM-GW ch ecks if recipient
is available in CS domain.
MTF SM
MT-FSM-Return Error (Absent Subscriber)
HLR records act ual

Since all domain delivery failed hence SMSC address in its
IP-SM-GW sets UNRI in HLR. MWD list.
(UNRI, MNRF, SMSC
Address)
Report-SM-Delivery-Status ACK is HLR will ignore this
not shwon request
Report-SM-Delivery-Status (MNRF, SMSC Address)
When user is registered in IMS , IPSM will get TPR; IPSM will download
subscriber profile from HSS and if in subscriber profile UNRI flag is set ,
IPSM will send REDADY-FO R-SM to HLR
When user is registered in CS , HLR will get READY-FO R-SM from MSC.
HLR will send Alert_SC to SMSC
Assuming in current case subscriber re-registers in 4G

MAP-READY-FO R-SM- MAP-READY-FO R-SM-RESP
RESP Alert-SC
Subscriber is registered in 4G and SRI for SM inv (MSISDN)

IPSM has subscriber profile in cache
address)
Message (RP-DATA)
200 OK
RP-ACK is not sjown

7.10 Memory non available
UE-B UE-A P-CSCF S-CSCF IPSM STP SMSC HLR MSC
MESSAGE
MO FSM
(plain/text)
MO FSM rsp (SMS-
202 Accepted SUBMIT-REPORT)
Anti
Spam
Diam. Antispam
req.
Diam.Anti Spam
res.
MNP
Enum:MNP dip
ENUM:MNP dip
res.

available IP-SM-GWs

1st if user is available in IM S or not before falling
HSS

UDA (rep.data) UDR is done onl y if subscriber

information is not locally cached at non-
primary IMP.

address)
ocs
CCR
CCA
Message (SMS-Submit- MO-FSMrsp (SMS Submit
Report) Report)
MTFSM
MESSAGE
200 OK
Memory not available at UE
MESSAGE (RP-ERROR
Cause=22 ,Memory capacity
exceeded) MT-FSM-Resp (SMS-
DELIVER-REPORT)
200 OK SM Delivery
Failure:memoryCapacity HLR records actual
Exceeded (0) SMSC address in its
MCE list.
(memoryCapacityExceed
ed, SMSC Address)
Report-SM-Delivery-Status HLR ignores this
Once Memory is available (memoryCapacityExceed request.
ed, SMSC Address)
MESSAGE (RP-SMMA)
MAP-REDAY-FO R-SM(Alert
Reason=memoryAvailable)
Alert-SC
Alert-SC Resp
MESSAGE (RP-ACK)/200 ok flow for RP-SMMA is not shown
MAP-SRI
IPSM has subscriber
binding in cache
SRI for SM resp.(GT=IPSM address)
MTFSM
MESSAGE (RP-DATA)
Delivery report flow is not shown.

8 Announcements
8.1 Session Reject OCB (Early Dialog/Early Media)

UE-A I-CSCF UE-B MRF
(A) (A) (B) (B)
INVITE B (SDP1)
PEM=supported
OCB active, annc to be played
INVITE sip:msml@domain SDP1
200-OK [tag=<conn: id:msisdnA>] SDP2
Whether to use early or confirmed dialog to

183 (SDP2) play announcement is configurable.
Require: 100Rel
PEM=sendonly
PRACK
ACK
200-OK (PRACK)
INFO
<dialogstart type="application/moml+xml" target="conn: id:msisdnA" name="playAnnouncement"
mark="1"><play maxtime="100s" barge="true" cleardb="false"> <audio uri="file://provisioned/messageID"/
></play></dialogstart></dialogstart></msml><exit namelist="play.amt play.end"></exit>
200-OK
RTP (Announcement)
Announcement completed
INFO
<event name=”msml.dialog.exit” id=”conn:id”><name>play.end</name><value>play.complete</value></
event>
200-OK
BYE
487 Request 200-OK

Terminated
487 Request ACK

Terminated
ACK
The originator UE may also terminate the call before

announcement is completed.
CANCEL
BYE
200-OK
200-OK
487 Request
487 Request
Terminated
Terminated
ACK
ACK
8.2 Session Reject:OCB Confirmed Dialog
(A) (A) (B) (B)
INVITE B (SDP1)
PEM=supported
OCB active, annc to be played
Whether to use early or confirmed dialog to

play announcement is configurable.
200-OK (SDP2)
ACK
ACK
INFO
<dialogstart type="application/moml+xml" target="conn: id:msisdnA" name="playAnnouncement"
mark="1"><play maxtime="100s" barge="true" cleardb="false"> <audio uri="file://provisioned/messageID"/
></play></dialogstart></dialogstart></msml><exit namelist="play.amt play.end"></exit>
200-OK
RTP (Announcement)
Announcement completed
INFO
<event name=”msml.dialog.exit” id=”conn:id”><name>play.end</name><value>play.complete</value></
event>
200-OK
BYE
200-OK
BYE
200-OK
The originator UE may also terminate the call before

announcement is completed.
BYE
BYE
200-OK
200-OK
8.3 Session Reject: ICB Early Dialog
(A) (A) (B) (B)
INVITE B (SDP1)
Require=Preconditio
n,100Rel
PEM=supported
ICB active, annc to be played

Require=Precondition, 100Rel
183 (SDP2) 183 (SDP2)

Require=100Rel Require=100Rel
PEM=sendonly
Authorize Early Media
PRACK
PRACK
200-OK (PRACK)
200-OK (PRACK)
UPDATE (SDP3)
UPDATE (SDP3)
200-OK (SDP4)
200-OK (PRACK)
Whether to use early or confirmed dialog to 200-OK [tag=<conn: id:msisdnA>]

play announcement is configurable. If
configured to use early dialog, the 200-OK final
answer from the MRF is consumed.
200-OK (INVITE) INFO <audio uri="file://provisioned/
messageID"/><play>
200-OK
ACK (200-OK)
RTP (Announcement)
INFO
<event name=”msml.dialog.exit”
id=”conn:id”><play.complete>
200-OK
BYE
BYE
200-OK
200-OK
8.4 Announcement during Mid-Call
(A) (A) (B) (B)
Call between UE-A and UE-B is in Active State
User A is running out of prepaid balance, warning

tone needs to be provided.
reINVITE (SDP3)
200-OK (SDP1)
ACK
ACK
INFO <audio uri="file://provisioned/messageID"/><play>
200-OK
RTP (Announcement)
INFO Announcement completed

<event name=”msml.dialog.exit” id=”conn:id”><play.complete>
reINVITE (SDP2)
200-OK
200-OK (SDP1)
BYE
ACK
200-OK
9 Supplementary Services
9.1 Feature Request

S-CSCF TAS
UE-A HSS
(A) (A)
INVITE [from:A, to: *FC, SDPo]

Translation Profile (TRN) identifies the Star/Pound Code
being dialled and invokes FEAT Profile. FEAT Profile
analyzes the dialled string and sets the corresponding
SVCCAUSE.
UDR
UDA
PUR
PUA
200-OK [SDPa]
The SDP Answer returned will be a dummy SDP with
ACK media sessions rejected by setting port equal to 0.
BYE
200-OK (BYE)
603 Decline
ACK If the Feature Request is not Successful
9.2 Per-Call-OIR-Activation
S-CSCF TAS S-CSCF TAS BGCF/
UE-A I-CSCF HSS UE-B HLR
(A) (A) B B MGCF
INVITE
[from:A, to:
*FC#B, SDPo] Translations [FEAT] detects the dialed Feature code for PER
Call OIR Activation and if the served user has OIR active in
Temporary Mode (default- Not Restricted), the From header is
Anonymized and Privacy set for the originator.
INVITE [to: B,
SDPo] From: "Anonymous" <sip:anonymous@anonymous.invalid>
and
Privacy is set with “id” for P-Asserted-Identity
RTP
10 Call Forwarding
10.1 CFU to another IMS User - Caller from IMS

The CFU service enables a served user to have the network redirect to another user communications
which are addressed to the served user's address.
Pre-requisites for this use case:

 The served user (B party) has CFU active.
Orig TAS (T) TAS (O) TAS
S-CSCF (B Party) (B Party) UAS UE-C
UA (C-Party)
INVITE B
P-Early-Media: supported
[SDP Offer 1]
Served user has CFU Active.
181 Call is being Forwarded If cfuNotifCallPty is enabled, originating

HI:;index=1 user is notified of call being diverted
HI:<sip|tel:C;cause=302>;index=1.1
INVITE <sip|tel:C;cause=302>
Route: orig@<scscf-from-incoming-route>
P-Served-User: B,
HI:;index=1
HI:<sip|tel: C;cause=302>;index=1.1
[SDP Offer 1]
INVITE <sip|tel:C;cause=302> Originating Services for B is applied.

P-Served-User: B,
HI:;index=1
[SDP Offer 1]
183 Session in Progress [SDP Answer 1]
183 Session in Progress If 18x or 200 OK response does not contain

HI:;index=1 History-Info header, the TAS serving
HI:<sip|tel:C;cause=302>;index=1.1 diverted-to user will include the stored
[SDP Answer 1] History-Info header.
PRACK/200 OK not shown
180 Ringing
180 Ringing
HI:;index=1
200 OK (INVITE)
200 OK
HI:;index=1
ACK (200 OK)
RTP (Two way speech)
Use case description:

 CFU is invoked if the statusCfu flag in the served user’s profile is set to a value of 7.
 If cfuNotifCallPty subscription option is enabled, the TAS will notify the caller of the call being diverted
by generating 181 Call is being Forwarded provisional response.
 After checking the diversion limits, the TAS will generate an initial request on behalf of a public user
identity.
 At the TAS serving the diverted-to user, the TAS will store the History-Info entry received in the
incoming request, and will include it in 180 (Ringing), 181 (Call Is Being Forwarded) or 200 OK
response, if it does not contain a History Info header field.
10.2 CFU to CS User - Caller from IMS
UE-A I-CSCF HSS UE-C HLR MGCF
(A) (A) (BC) (BC)
INVITE B
TAS performs origination services including DND, MNP and Ro interactions
LIR (B)
LIA (S-CSCF
Name)
181 B has CFU enabled to FTN=C

PEM=inactive
History-Info: <sip:B@mav.com>;index=1,
History-Info: <sip:C@mav.com;cause=302>;index=1.1;
INVITE C
LIR (C)
LIA (5001)
MT to C continues
10.3 CFB to another IMS User (IMS to IMS)

The CFB service enables a served user to have the network redirect to another user communications
which are addressed to the served user's address and meet busy.

 The served user (B party) has CFB active.
 The originating device supports multiple early dialogs
TAS (T) TAS (O)
Orig TAS
S-CSCF (B Party) (B Party) UE-B UE-C
UA (C-Party)
INVITE B
[SDP Offer 1]

(D1)
180 Ringing
(D1)
486 Busy
ACK
Served user has CFB Active.
181 Call is being Forwarded (D1) If cfbNotifCallPty is enabled, originating

HI:<B?Reason:SIP;cause=486>;index=1 user is notified of call being diverted
HI:<sip|tel:C;cause=486>;index=2
Route: orig@<scscf-from-incoming-route> Since precondition has already been met,
P-Served-User: B, the SDP Offer 2 should be one indicating
HI:<B?Reason:SIP;cause=486>;index=1 preconditions have been met.
[SDP Offer 2 = SDP Offer 1]
180 Ringing
HI:<B?Reason:SIP;cause=486>;index=1
200 OK
(D2)
HI:<B?Reason:SIP;cause=486>;index=1
[SDP Answer 2]
(D2)
ACK (200 OK)

 TAS will determine busy condition based 486 Busy and 603 Decline (default values).
 Since terminal based busy indication is to be supported, when a served user has one or more active
calls, the TAS will not trigger Network Determined User Busy (NDUB) and will let terminal decide on
invoking User Determined User Busy (UDUB).
o When there is call establishment in progress for the served user i.e. the call is not yet transitioned to
Active state, the NDUB will be applied and CFB is invoked, if active.
 When 486 (Busy) or 603 Decline received in response to the Initial INVITE request sent to the served
user, the TAS serving the served user, will invoke CFB, if the statusCfb flag in the served user’s
profile is set to a value of 7.
 486 Busy or 603 Decline may be received before early dialog has been established i.e. 183 or 180
received or after early dialog has been received.
 If cfbNotifCallPty subscription option is enabled, the TAS will notify the caller of the call being diverted
by generating 181 Call is being Forwarded provisional response
identity.
10.4 CFB to another IMS User- Caller from CS

UE-A I-CSCF HSS UE-C HLR MGCF
(A) (A) (BC) (BC)
INVITE B
LIR (B)
LIA (S-CSCF
Name)
TAS knows that maximum number of simultaneous calls

181 are in progress for B, hence triggers CFB which is
PEM=inactive configured with FTN to A
INVITE A
History-Info: <sip:A@mav.com;cause=486>;index=1.1;
LIR (A)
LIA (S-CSCF
Name)
INVITE A
MT to A continues
10.5 CFBRc (IMS to IMS)

The CFNRc service enables a user to have the network redirect all incoming communications, when the
user is not reachable (e.g. there is no IP connectivity to the user's terminal), to another user.

 The served user (B party) has CFNRc active.
TAS (T) TAS (O)
Orig TAS
S-CSCF (B Party) (B Party) MRF UE-B UE-C
UA (C-Party)
INVITE B
[SDP Offer 1]
4xx (except 486/603), 5xx, 6xx
ACK
Served user has CFNRc Active.
If CS Retry is disabled for the SIP response

code, CS retry procedure is NOT applied.
181 Call is being Forwarded If cfnrcNotifCallPty is enabled, originating

HI:<B?Reason:SIP;cause=4xx/5xx/ user is notified of call being diverted
6xx>;index=1
P-Served-User: B,
HI:<B?Reason:SIP;cause=4xx/5xx/
6xx>;index=1
[SDP Offer 1]
183 Session in Progress

HI:<B?Reason:SIP;cause=4xx/5xx/6xx>;index=1
[SDP Answer 1]
180 Ringing
200 OK
ACK (200 OK)

 When TAS receives an SIP error (other than 486, 603 and 3xx) in response to the Initial INVITE
request sent to the served user and if the SIP error response received matches with the SIP error
code configured in the non-reachable SIP error code list, the TAS serving the served user will invoke
CFNRc, if the statusCfnrcflag in the served user’s profile is set to a value of 7.
o If the SIP error received is not configured in the non-reachable SIP error code list, the TAS will not
apply any Call Forwarding.
 Prior to invoking CFNRc procedure, the TAS will check if the CS Retry procedure is applicable for the
SIP error code received. If CS Retry is disabled, the TAS will continue with CFNRc procedure.
 If cfnrcNotifCallPtysubscription option is enabled, the TAS will notify the caller of the call being
diverted by generating 181 Call is being Forwarded provisional response.
identity.
10.6 CFNRc to IMS User - Caller from CS

UE-A I-CSCF HSS UE-B HLR MGCF
(A) (A) (BC) (BC)
INVITE B
LIR (B)
LIA (S-CSCF
Name)
4XX response
TAS can be configured to treat 408 as CFNRc

condition. Any 4xx/5xx/6xx can be configured to
be treated as CFNRc condition. This will also
include not-reachable timer expiry.
If User is not available in IMS ,UAG can send 408
SRI [B]
SRI Ack [absentSubscriber]
CFNRc active, FTN to /a

181
INVITE A
LIR (A)
LIA (S-CSCF
Name)
INVITE A
MT to A continues
10.7 CFNR to another IMS User - Caller from IMS
The CFNR service enables a served user to have the network redirect to another user communications which
are addressed to the served user's address, and for which the connection is not established within a defined
period of time.

 The served user (B party) has CFNR active.
TAS (T) TAS (O)

Orig TAS
S-CSCF (B Party) (B Party) MRF UE-B UE-C
UA (C-Party)
INVITE B
[SDP Offer 1]

(D1)
180 Ringing
(D1)
Tno-answer
expires
CANCEL/200 OK
Reason: SIP;cause=408
CANCEL/200 OK
487/ACK not shown
Served user has CFNR Active.
181 Call is being Forwarded If cfnryNotifCallPty is enabled, originating

HI:;index=1 user is notified of call being diverted
P-Served-User: B,
HI:;index=1
[SDP Offer 2 = SDP Offer 1]
180 Ringing
180 Ringing
HI:;index=1
(D2)
200 OK
[SDP Answer 1]
200 OK
HI:;index=1
[SDP Answer 1]
(D2)
ACK (200 OK)

 After receiving the first 180 (Ringing) response the no-answer timer shall be started.
 The no-answer timer started may be any of the below, selected in the precedence order as defined:
o The no-answer timer configured in the user’s profile (timerCfnry) is used.
o Else, the network no-answer timer is used.
 When no-answer timer expires, the TAS serving the served user will invoke CFNR, if the
statusCfnryflag in the served user’s profile is set to a value of 7.
 The dialog to the diverting user will be terminated by sending a CANCEL request, including a Reason
header field with the protocol set to “SIP” and the cause value set to “408”.
 If cfnryNotifCallPty subscription option is enabled, the TAS will notify the caller of the call being
diverted by generating 181 Call is being Forwarded provisional response
identity.
11 Suppressing LCF (late call forwarding) Scenarios

The user profile configured in the HSS will be in shared HLR view. In the Shared HLR view, the same set
of CFx service is available when the user is attached to PS or CS domain.
 When the call anchored at the TAS breaks out to CS domain due to CS breakout or retry, the Shared
HLR view will lead to race conditions and unexpected behavior, when the two separate nodes are invoking
CFx based on the same CFx data. For example, the same no-reply timer will be started by the VMSC and
also the TAS acting as a GMSC. It could be possible that the no-reply timer started at the VMSC expires
first followed by that started at the TAS. When the no-reply timer expires at the TAS, it will end up
cancelling the INVITE Request routed to the CS domain, which might have already triggered a CFNR.
 The Shared HLR view could also lead to multiple invocation of CFx. For example, if CFB is invoked in
the legacy MSS, leading to forwarding of the call to a user C. If the user C, who does not have CFB active,
rejects the call, the mapped SIP response code when received at the TAS might invoke CFB once again
resulting in another CFB call to the C party.
 In order to avoid such unexpected behavior and race conditions with the Shared HLR view, the TAS
supports a configuration to suppress invocation of the Late CF (CFB, CFNR, CFNRc), when the user
terminating call leg is anchored in the CS domain. The suppression of the late CF is done using the CF
Routing (CFRTE) Service Profile, which gets applied for all CF invocation.
 The CFRTE will support defining rules using the input criteria defined below:
 CALLEVENT – This is used to differentiate between PS and CS Termination.
 CDIVTYPE – Identifies the different types of CDIV Service, including Operator Controlled Call
Forwarding. For example, “CFB”, “CFNR”, “CFDforCFNR”, etc.
 ROAMTYPE – Identifies the Roaming Status of the Served user, based on the value of the MSRN
returned in the SRI Query. For example, “HOME”, “INTLR”, etc.
An example of the rule configured would be:
IF (CALLEVENT = CSTERM) AND (CDIVTYPE = CFNR) AND (ROAMTYPE!= HOME) THEN
RELCALL = 3400 (CC_CFNR_CSLEG_SUPPRESSED).
 Based on the internal cause code set, the TAS will apply error handling procedures. An exception to
this is when no-reply timer expires, in which case, the TAS will reset the no-reply timer to allow the
CFNR to be invoked by the legacy MSS. On subsequent expiry of the no-reply timer, the TAS will
proceed with the error handling procedure, after cancelling the CS call leg.
 When a late CF has to be invoked, if the suppress condition matches, the TAS will not invoke CF.
11.1 CFNRc (with CS Retry)
The CFNRc service enables a user to have the network redirect all incoming communications, when
the user is not reachable (e.g. there is no IP connectivity to the user's terminal), to another user.
It could be possible that the served user might have lost connectivity to the IMS network and attached
to the CS domain. In order to ensure the user’s availability in CS domain is checked prior to applying
CFNRc, the CS Retry procedure is applied. CS Retry is special error case, where the access network
returns an error response indicating that the client is no longer available in IMS domain or due to any
other reason resulting from routing the terminating request to the device.

 The served user (B party) has CFNRc active.
 The served user (B party) is registered in IMS, but not reachable and is attached to CS
domain.
Orig TAS
S-CSCF HLR UE-B MGCF
UA (B-Party)
INVITE B
[SDP Offer 1]
4xx (except 486/603), 5xx, 6xx

ACK
If CS Retry is enabled for the SIP response

code, CS retry procedure is applied.
SRI [MSISDN-B, Suppress T-CSI]

INVITE sip|tel:+[csrn prefix][cc][ndc][snr];
rn=+[cc][msrn] SRI Ack [MSRN]
[SDP Offer 1]
User is not reachable in MSS.

Served user has CFNR active, call is
forwarded to C party
183 Session in Progress

[SDP Answer 1]
If CFRTE rule is configured to suppress

CFB/CFNRx, the 18x is relayed
PRACK/200 OK between Orig UA and UAS not shown
180 Ringing
200 OK (INVITE)
ACK for 200 OK not shown

 When TAS receives an SIP error (other than 486, 603 and 3xx) in response to the Initial INVITE
request sent to the served user and if the SIP error response received is matches with the SIP error code
configured in the list of non-reachable SIP error code list the TAS serving the served user will invoke
CFNRc, if the statusCfnrcflag in the served user’s profile is set to a value of 7.
 Prior to invoking CFNRc procedure, the TAS will check if the CS Retry procedure is applicable for the
SIP error code received. If CS Retry is enabled, the TAS will apply CS Retry procedure.
 The CS Retry INVITE request containing the CSRN in the Request-URI is routed with the Route
header containing the original ODI received in the incoming INVITE request.
 The TAS will map the Q.850 cause received to appropriate CFx service and invoke the CFx service if
active for the served user. If CFRTE rule applied as part of CFx procedure results in suppressing of CFx
service, the TAS will relay the 183 received as is.
11.2 CFNR (with CS Breakout)
This use case describes a CFNR scenario, where the user with IMS subscription is attached to CS
domain and the user does not respond within the defined period of time. CS Breakout is triggered
when unregistered termination request is received at the TAS.

 The served user (B party) has CFNR active.
 The B party is attached to CS domain.
TAS TAS
I-MGCF S-CSCF HLR UE-B
(B-Party) (C-Party)
INVITE B
[SDP Offer 1] Since B party is attached to CS domain, the
TAS will not have the user profile. User profile
is retrieved from OneNDS (not shown)
CS Breakout procedure is applied

SRI [MSISDN-B, Suppress T-CSI]
INVITE sip|tel:+[csrn prefix][cc][ndc][snr]; SRI Ack [MSRN]

rn=+[cc][msrn]
[SDP Offer 1]
183 Session in Prog

[SDP Answ
183 Session in Progress (D1)

[SDP Answer 1]
PRACK/200 OK between Orig UA and UAS not shown
180 Rin
No-answer timer expires at the MSS

180 Ringing (D1)
Served user has CFNR active, call is
forwarded to C party
181 Call is being Forwa
HI:;ind
HI:<sip|tel:C;cause=408>;index
(D1)
No-answer timer is stopped 180 Rin
HI:;ind
(D1) No-answer timer is restarted
Due to some failure at the MSS, error response

is returned. (call term failed or C party does not
VM, etc). End of Call Annc might be played.
183 Session in Prog
HI:;ind
Reason: Q.850; cause=18;text=no user respon
PEM: send
If Q.850/SIP response code matches with
busy or not-reachable condition, CFB/
CFNRc is invoked.
(D1) CFB/CFNRx, the 18x is relayed
4xx
CFB/CFNRx, the 4xx/5xx response is
relayed
ACK for 4xx/5xx not shown

 Since the B party is not registered at TAS, the TAS will retrieve the profile and apply CS
Breakout procedure. As part of the CS breakout procedure, the TAS will generate SRI request
to retrieve the MSRN.
 The call is routed to CS network, with Request-URI containing the CSRN.
 The CS Breakout INVITE request containing the CSRN in the Request-URI is routed with the
Route header containing the original ODI received in the incoming INVITE request.
 Since the TAS and the MSS shares the user profile configured with the no-answer timer,
same timer value is started by both on receiving Alerting indication. This could lead to race
condition, with both the timers expiring nearly at the same time.
 If the no-answer timer started at the TAS expires first, the TAS will invoke CFNR procedure
as part of which rules configured in CFRTE service profile is applied. The CFRTE service
profile might have a rule to suppress CFNR for call leg routed to the CS domain. If CFNR is
suppressed for CS leg, the TAS will reset the no-answer timer.
 When the no-answer timer expires at the MSC, it is likely to invoke CFNR. If CFNR is not
active, it will result in the MSC playing an end of call announcement.
 The ACM/CPG sent with an ISUP cause, the MGCF might send a 183 with PEM: sendonly
and Reason header included to indicate in-band announcement being played.
 On receiving 18x with Reason header, if the SIP/Q,850 cause code included matches with the
cause code applicable for busy and not-reachable condition, the TAS will invoke CFB/CFNRc.
 If the CFRTE applied as part of CFB/CFNR procedure has a rule to suppress CFB/CFNRc,
the 18x received will be relayed as received.
 With the CFB/CFNR being disabled, any 4xx/5xx error response received from the CS
domain will be relayed without invoking any mapped CFx.
12 Call Waiting
12.1 Call Waiting - Call Accepted

Call Waiting – Call Answered

UE-A I-CSCF HSS UE-B UE-C
(A) (A) BC BC

INVITE A
TAS performs origination services including

DND, MNP and Ro interactions
LIR (A)
LIA (S-CSCF
Name)
If the served terminating user has CW
activated, the call is presented to the
recipient.
183 Session
Progress
(SDPa)
PEM=inactive
PRACK/200-OK not shown.

180 Ringing TAS will insert a Alert-Info header field set to
PEM=inacti
“<urn:alert:service:call-waiting>”
ve
Tas-w timer started
User accepts the waiting call which results

in existing call being placed on hold before
answering the waiting call.
reINVITE
(SDP,
a=sendonly)
200-OK (a=recvonly)
ACK
Call between UE-A and UE-B is in Held State

200-OK
[INVITE)
ACK
Call is answered, RTP session setup between UE-A and UE-C

12.2 Call Waiting - Call Ignored
Call Waiting – Call Ignored

(A) (A) BC BC

INVITE B
TAS performs origination services including

DND, MNP and Ro interactions
LIR (A)
LIA (S-CSCF
Name)
If the served terminating user has CW
recipient.
183 Session
Progress
(SDPa)

TAS will insert a Alert-Info header field set to
180 Ringing “<urn:alert:service:call-waiting>”.
Tas-w timer started
User ignores the waiting call.
Tas-w expires. CFNR is invoked, if active for

A.
12.3 Call Waiting - Call Rejected
P/S-CSCF TAS P/S-CSCF TAS
(A) (A) BC BC

1.INVITE A
2
TAS performs origination services

4 3 including DND, MNP and Ro
interactions
5.LIR (A)
6. LIA (S-
CSCF Name)
7
8
10 9 If the served terminating user has CW

11. 183
recipient.
Session
Progress
(SDPa) 12
13
14 15 16
17
18
TAS will insert a Alert-Info header field set to
19 180 Ringing 20 “<urn:alert:service:call-waiting>”.
Tas-w timer started
21
22 23 24
25
26
User rejects the waiting call.
27 486 Busy 28
30 29 ACK CFB is invoked if active for user A.
31
486 Busy
32 33 34
35
36
13 Conference
13.1 Three way Conference Creation, REFER sent in

Conference Dialog
UE-A I-CSCF HSS UE-B UE-C MRF
(A) (A) BC BC
Call between UE-A and UE-B is in HELD state.

Call between UE-A and UE-C is ACTIVE.
User A does a Merge
reINVITE (A-C)
(a=sendonly)
INVITE
ConfURI SDPo
Translation [TRN] identifies Conference
Request and invokes MRF 200-OK (A-C) (a=recvonly)
ACK (200-OK)
INVITE sip:msml@domain SDPo (no m line)
200-OK [tag=<conn: id:A>SDPa (no m line)

Control Dialog
ACK
INVITE sip:msml@domain SDPo (A)
200-OK [tag=<conn: id:A>SDPmrf
ACK
INFO
<createconference, stream=audio and/or video> <join id1=”conf” id2=”conn:id=A”>
200-OK
200-OK
(SDPmrf)
ACK
REFER sip:conferenceURI
REFER (A- Refer-To=<sip:B@lab; method=INVITE;
Conf) Replaces=CID1%to-tag%from-tag>
202 Accepted
INVITE sip:msml@domain [no SDP]
NOTIFY[state:
Active] 200-OK [tag=<conn: id:B>][SDP (all supported media)]
(100 Trying)
200-OK
Redirect B Party’s SDP to the Conference,
reINVITE (A-B) which enabled B to join the conference.
(SDPmrf)
200-OK (SDPa) (B)
ACK (200-OK)
ACK (SDPa) (B)
INFO <join id1=”conf” id2=”conn:id=B”><stream type=”audio”/><stream type=”video”/>

NOTIFY[state:
terminated] 200-OK
(200-OK)
200-OK Since the UE has requested for the dialog to be replaced

using the “replaces” parameter in the Refer-To header,
BYE TAS should clear the dialog after a successfully redirecting
the recipient to the conference focus.
200-OK
1. The IMS user sets up a call with user agent B (UA-B) and puts it on hold
2. The IMS user establishes a call with user agent C (UA-C)
3. The IMS user then creates a conference by initiating INVITE with:
a. Conference Factory URI in the Request-URI in SIP URI format
b. An SDP offer indicating audio conference only
4. S-CSCF routes the INVITE to the TAS assigned to the originating user. The following is the
relevant information in the INVITE request:
SIP Header Value
P-Asserted-Identity Set to an IMPU of the subscriber.
5. TAS identifies the INVITE request is for conference creation based on the translations profile
TRN.
6. TAS on receiving an INVITE to create conference establishes a MSML connection object request
towards MRF, resulting in initiating an INVITE being sent with:
SIP Header Value

Request-URI Set to the service url indicating MSML usage.
Ex: sip:msml@hostport
From Set to the calling party number received in the P-
Asserted-Identity header of ingress INIVTE in either a
TEL URI or SIP URI
To SIP URI of the Media Server. Same as Request-URI
P-Asserted-Identity Set to the calling party number received in the ingress
INIVTE in either a TERL URI or SIP URI
Contact SIP URI containing the IP address: port or FQDN of
TAS as the UAC
The SDP offer in the INVITE includes an audio media description.

7. The Initial INVITE request for conference creation may be generated using the precondition
mechanism. The precondition procedure is achieved transparently between the end points i.e.
the conference invoking user and the MRF hosting the conference bridge.
8. TAS on receiving 200 OK response from MRF stores the local tag parameters received in the
“To” header and the SDP answer.
9. TAS generates ACK (for 200 OK from MRF) and then invokes MSML script from SIP for
conference creation and joining the controller to the conference by generating SIP INFO request
containing the MSML script document within the INVITE dialog. The SIP INFO message
contains the following significant headers:
SIP Header Value

Ex: sip:msml@hostport
From As per the INVITE dialog established
To As per the INVITE dialog established
Content-type application/msml+xml
MSML Content
MSML document tags populated as below:
Tag Attribute Description
msml N/A Parent tag
createconference name Set to the conference ID which uniquely
identifies the conference object. The conference
ID format is:
conf:”{conference-controller-msisdn}{timestamp-
ddhhmmss} “
where in timestamp, the dd=two-digit day of the
month (01-31_, the hh=two digit hour (00=23),
the mm=two-digit minute (00-59) and the
ss=two-digit second (00-59).
An example: “conf:469972214401213459”
deletewhen Set to ‘nocontrol’
mark Set to 1
audiomix id A unique id of 64 alphanumeric chars identifying
the audio mixer. This id will be used if there is a
need to modify the audio mixer characteristics
join id1 Set to the conference id
id2 Set to the connection id
mark Set to 1
stream media Set to “audio”
10. On successful conference creation TAS sends 200 OK for the INVITE from the UE. Following
headers are included in the 200OK
SIP Header Value

Contact Conference uri with the isfocus as the header field
parameter
Content-type application/sdp
SDP Content: Includes the SDP received from MRF
11. Upon conference creation the UE adds participants to the conference by sending SIP REFER
message within the conference dialog. The REFER is routed to TAS via IMS Core using standard
in-dialog request routing procedures. The TAS receives REFER message as shown below
SIP Header Value
Request-URI Conference focus instance. UE populates this based
on the value received in the Contact header of 200 OK
response to the INVITE for conference creation.
From As per the conference dialog
To As per the conference dialog
Refer-To Contains the to-be-invited user and the corresponding
SIP method, INVITE in this case. It also includes
Replaces parameter with the local access dialog
identifier between the referrer and to-be-invited user
Ex: Refer-To:
<sip:2149894433@mavenir.lab;method=INVITE?
Replaces=000381d5-1baec49a
%254010.112.1.15%253Bto-tag
%253DoperatorUA_0000507BA3EE-2fb3-44808940-
167-4f99a8b8-ab312%253Bfrom-tag
%253Dlgims_00038200-1baec49a>
P-Asserted-Identity As per the conference dialog, indicating the controlling
user
SIP Header Value
Replaces The Refer-To header may contain Replaces header
as per the format defined in RFC 3891.
An example of the Refer-To header with Replaces
header is:
Refer-To:
<sip:9845900028@mavenir.lab;method=INVITE?
Replaces=1758656165%40172.16.85.61%3Bto-tag
%3DMavenirUA_001FD0E37884-32b4-b27a8b90-78-
4e057fc5-28494%3Bfrom-tag%3D203346236>
Referred-By If present will be set to the inviting user, matching P-
Asserted-Identity header
12. The TAS extracts the conference URI from the Request-URI and the to-be-invited user from
Refer-To header. TAS validates if the user adding the participant has an active dialog with the
participant.Upon successful validation of REFER request contents and sending 202 Accepted
response to UE, TAS then establishes the MRF leg for the user to be joined to the conference.
The SDP Offer included in the request will be the latest SDP received from the to-be-joined-user
within the dialog between the controller and the to-be-joined-user. The media attribute shall be
modified as below:
 “recvonly” if the stream were previously set to “inactive” media stream; or
 “sendrecv” if the stream were previously set to “recvonly” media stream
13. On successful establishment of the MRF leg for the to-be-joined-user, the TAS forms and sends
re-INVITE to the remote end (to-be-joined-user) in order to redirect it to the conference bridge. ..
The re-INVITE generated will contain:
 Referred-by header field matching the (P-Served-User or P-Asserted-Identity, in the order
specified) of the REFER request; and
 The contact header field modified to include the conference uri with “isfocus” feature
parameter; and
 SDP Offer set to the SDP Answer received from the MRF.
14. TAS also sends SIP NOTIFY to the user for the received REFER request within conference
dialog. REFER creates implicit subscription at TAS to send notification. Populates the NOTIFY as
below:
SIP Header Value

Subscription-State active
Content-Type message/sipfrag
Content “SIP/2.0 100 Trying”
15. When a final 200 OK response is received from the to-be-joined-user in response to the re-
INVITE and an ACK is generated, the TAS joins the to-be-invited user to the conference by
generating an INFO request on the MSML control channel (identified by the conference URI,
which may be associated with the conference object). The SIP INFO message contains the
following significant headers:
SIP Header Value

From As per the INVITE dialog established for creating
connection object for to-be-invited user
To As per the INVITE dialog established for creating
connection object for to-be-invited user
Content-type application/msml+xml
MSML Content
16. The MSML document tags are populated as shown below while adding a participant to
conference:

msml N/A Parent tag
join id1 Set to the conference id
id2 Set to the connection id of the user to be joined
to the conference
mark Set to 1
stream media Set to ‘audio’
17. Upon receiving 200 OK for the SIP INFO message from the MRF, the TAS sends a SIP NOTIFY
request to the controlling user with message body set to “SIP/2.0 200 OK” and Subscription State
set to “terminated” indicating the call transfer is completed based on the REFER request
NOTIFY request below:

SIP Header Value
Subscription-State terminated
Content “SIP/2.0 200 OK”
18. Upon receiving 200 OK for NOTIFY request, TAS initiates a BYE to tear down the participant leg
(who got added to the conference) towards controlling user. The dialog information is extracted
from the “Replaces” (could be received as part of Refer-To header or standalone Replaces
header) by TAS to release that call leg after the participant has been added to the conference.
19. Other users are added to the conference following the same procedures described above.
13.2 Add Participant – without Replaces Option

TAS supports adding of a participant to a conference on receiving REFER request without “Replaces”.
This scenario is compliant to 3GPP 24.147 procedures but is not mandated by GSMA IR.92
specification.
If “Replaces” is not included in the REFER request, TAS does not initiate a BYE to tear down the
participant leg (who got added to the conference) towards controlling user. The controlling user upon
successful addition of the user to the conference (on receiving NOTIFY with “SIP/2.0 200 OK”) closes
the active session it has with the participant by sending BYE request. TAS releases the partial leg
(local access leg part) on receiving such BYE from the user.
UE-A IMS TAS-A TAS-B TAS-C MRF UA-B UA-C
A has called B, put B on hold, and then called C. A then creates a multiparty conference with B and C.
INVITE sip:ConfFactoryURI [SDP]
INVITE sip:msml@domain
Conference request detected, create a
[SDP from UE-A]
conference at the MRF and add UE-A.
200 OK [SDP]
ACK
INFO
<createconference name=”confURI"/>
<join id1=”confURI” id2=”UE-A”>
<stream media=”audio”/>
</join>
200 OK
Contact: sip:ConfUR 200 OK
[SDP from MRF]
ACK
The next sequence of messages shows B being referred to the created conference. The same sequence of messages would occur for C as well (not shown).
REFER sip:confereceURI
Refer-To: <sip:B@host;
method=INVITE;
202 Accepted
NOTIFY
Subscription-State: active
[100 Trying]
200 OK
Redirect UE-B to the conference by sending a
re-INVITE within the A-B dialog
INVITE sip:msml@domain [SDPo (B party)

(recvonly -> sendrecv), (inactive -> recvonly)]
200-OK [tag=<conn: id:B>][SDPmrf]

(sendrecv or sendonly)
reINVITE (A-B)
[SDPo = SDPmrf (sendrecv, ACK
recvonly)]
200-OK[SDPa (sendrecv, recvonly)]
ACK
Join B to the conference

INFO
<join id1=”confURI” id2=”UA-B”>
<stream media=”audio”/>
</join>
NOTIFY
Subscription-State: terminated 200 OK
[200 OK]
200 OK
The A-B dialog is released
BYE
200 OK
13.3 Abnormal Scenarios-Conference creation
13.3.1 Conference creation

Following table highlights the error scenarios while creating a conference:
Scenario Action
Controlling user not subscribed for conference TAS sends 403 “Forbidden” in response to the
feature INVITE request received for conference creation
Non-2xx (other than 503 or 486 or transaction TAS sends 500 “Server Internal Error” in
timeout) response from MRF in response to the response to the INVITE request received for
INVITE sent for creating connection objects conference creation
Transaction time out waiting for response from
MRF for INVITE sent
Transaction time out waiting for response from
MRF for INFO sent
Non-2xx response from MRF in response to the
INFO sent
Time out waiting for the ACK from controlling user TAS removes the conference created and
in response to the 200 OK final response corresponding connection object on MRF
generated in response to initial INVITE for
conference creation
13.3.2 Adding a participant

Following table highlights the error scenarios while adding a participant to a conference:
Scenario Action
Conference URI not allocated TAS sends 603 “Decline” in response to the REFER
request
No active dialog/session between the TAS sends 603 “Decline” in response to the REFER
controller and the participant the controller is request
adding to the conference
Maximum number of participants added to TAS sends 603 “Decline” in response to the REFER
the conference exceeds the value configured request
at the TAS
Method parameter in Refer-To header is set TAS sends 603 “Decline” in response to the REFER
to value other than INVITE while adding request
participant
Transaction timeout waiting for 200 OK for TAS sends SIP NOTIFY with message body set to
INFO sent to MRF for “join” operation “SIP/2.0 503 Service Unavailable”
Non-2xx final response received for the re- TAS sends SIP NOTIFY with message body set to
INVITE sent towards the participant which “SIP/2.0 603 Declined”
needs to be added to the conference
481 or 408 or timeout response for the re- TAS sends SIP NOTIFY with message body set to
INVITE sent towards the participant which “SIP/2.0 603 Declined” and clears the dialog between
needs to be added to the conference the controlling user and the participant by generating
BYE
Participant to be joined to the conference TAS sends SIP NOTIFY with message body set to
hangs up the call before joined to the “SIP/2.0 503 Service Unavailable” and terminate the
conference connection object, if created, towards MRF
Non-2xx response or transaction timeout for TAS sends SIP NOTIFY with message body set to
the INFO (w/ join) sent to MRF “SIP/2.0 503 Service Unavailable” and re-INVITE with
original SDP towards the participant to fall back to the
original state of the call
13.4 Leaving a conference
Pre-requisites for the use cases described in this section:
 Successful creation of the conference
 Participant(s) is/are added to the conference successfully
13.4.1Participant leaving a conference

1. Participant decides to leave the conference resulting in BYE request sent towards the TAS
2. BYE is routed to the TAS (conference focus AS) using standard in-dialog request routing
procedures
3. Upon receiving a BYE request from a conference participant who is not the controller, the TAS
generates SIP INFO message with the MSML document to remove the participant from the
conference object at MRF. The MSML document tags to remove the participant from a
conference are shown below:
msml N/A Parent tag
unjoin id1 Set to the conference id
id2 Set to the connection id of the user which needs to be
removed from the conference
mark Set to 1
4. Upon successful SIP INFO transaction, the TAS sends a BYE request to release the dialog
related to the connection object corresponding to the participant leaving the conference
Use case is shown below in the call flow:

(A) (A) BC BC
UE-A connected to Conference
UE-B connected to
Conference
UE-C
connected to
Conference
User B decides to
leave the Conference
BYE
TAS-A (as conference AS), informs

MRF of participant leaving using SIP INFO <unjoin id1=”conf” id2=”conn:id=B”>
INFO
200-OK
TAS-A(as conference AS) releases BYE

the dialog created for the participant
towards MRF 200-OK
200-OK
13.4.2Controller removing a participant
1. Controller decides to remove a participant from the conference resulting in REFER request sent
towards the TAS. REFER request received by the TAS will be as following:
SIP Header Value
Request-URI Conference focus instance. UE populates this based on the
value received in the Contact header of 200 OK response to
the INVITE for conference creation.
From As per the conference dialog
To As per the conference dialog
Refer-To Contains the to-be-removed user and the corresponding SIP
method, BYE in this case. E.g.:
Refer-To: <sip:2149894433@mavenir.lab;method=BYE
P-Asserted-Identity As per the conference dialog, indicating the controlling user
2. The TAS identifies the REFER request received is to remove a participant based on the Refer-To
header. The Refer-To header will be set to the participant who needs to be removed in the user
portion of the URI and the method parameter to BYE.
3. The TAS performs the following authorization checks on the request:
a. The Conference URI received in the Request-URI header of REFER request is
allocated and valid.
b. The user attempting to remove the participant from the conference is the controller of
that conference.
c. The user being removed by the controller is a participant of the conference and is still
part of the conference.
4. On successful authorization and identification of the party to be removed, the TAS generates SIP
INFO message with the MSML document to remove the participant from the conference. The
MSML document tags to remove the participant are shown below
msml N/A Parent tag
unjoin id1 Set to the conference id
id2 Set to the connection id of the user which needs to be
removed from the conference
mark Set to 1
5. Upon successful SIP INFO transaction, the TAS

a. Sends SIP NOTIFY to the user for the received REFER request within conference
dialog. Populates the NOTIFY as below:
SIP Header Value
Subscription-State active
Content “SIP/2.0 100 Trying”
b. Generates BYE request to the release the dialog related to the connection object
corresponding to the participant being removed from the conference
c. Generates BYE towards the party who is being removed from the conference
6. Upon successful tear down of the call legs associated to the participant being removed the TAS
the sends SIP NOTIFY to the user indicating successful operation.
NOTIFY request below:
SIP Header Value
Subscription-State terminated
Content “SIP/2.0 200 OK”
Use case is shown below in the call flow:
UE-A IMS TAS-A TAS-B TAS-C MRF UA-B UA-C
RTP
RTP
Controller of the conference
decides to remove a participant RTP
from the conference
REFER sip:confereceURI
Refer-To: <sip:B@host;
method=BYE;
202 Accepted
TAS-A (as conference AS) identifies that a

participant has to be removed from the
INFO [<unjoin id1=”confURI” id2=”UE-B”/>]
conference and informs MRF
200 OK
NOTIFY
Subscription-State: active
[100 Trying]
200 OK
TAS-A (as conference AS) releases the

dialog created for the participant towards
remote end and towards MRF
BYE
200 OK
BYE
NOTIFY 200 OK
Subscription-State: terminated
[200 OK]
200 OK
13.4.3Abnormal Scenarios-while participant leaving a

conference
Following table highlights the error scenarios while participant leaving a conference:
Scenario Action
Non-2xx response or transaction timeout for the TAS proceeds to release the connection object for the
INFO (with unjoin) sent to MRF participant leaving conference towards MRF by
generating BYE request
Conference URI in REFER Request-URI is TAS sends a 404 Not Found response
invalid
User removing a participant is not the controller TAS sends a 403 Forbidden response
Scenario Action
Participant being removed is not in the TAS sends a 404 Not Found response
conference
The “method” parameter is set to a value other TAS sends a 603 Decline response
than BYE and INVITE in the Refer-To header of
REFER request
13.4.4Controller Leaving the Conference

(A) (A) BC BC
UE-B connected to
Conference
UE-C
connected to
Conference
Controller decides to
end the conference.
BYE
End the conference as the controller is
200-OK leaving.
INFO <destroyconference id=”conf:msisdnAtimestamp"/>
200-OK
BYE
200-OK
If “nomedia” option is used while creating the Conference, the MRF

deletes the conference when:
· At least one connection was joined to the conference after the
conference was created AND
· There are currently no connections joined to the conference.
If “nocontrol” option is used while creating the Conference, the
MRF deletes the conference when the SIP dialog that created it no
longer exists.
Setting of “nomedia” or “nocontrol” is configurable at TAS.
BYE
200-OK
BYE
Clear the control dialog
200-OK
BYE
200-OK
User C removal not

shown
13.4.5Removing Conference Participant
(A) (A) BC BC
UE-B connected to
Conference
UE-C
connected to
Conference
Controller decides to REFER sip:conferenceURI
remove a participant Refer-To=<sip:B@lab; method=BYE>
(B) from the
conference NOTE: The Refer-To may also contain the
ConferenceURI, in which case, all conference
participants are removed.
REFER (A-
Conf) REFER sip:conferenceURI
Refer-To=<sip:conferenceURI; method=BYE>
202 Accepted
TAS authorizes the participant removal
request (only a controller is allowed to remove
a participant) and identifies the participant to
be removed.
INFO <unjoin id1=”conf” id2=”conn:id=B”>

NOTIFY[state:
Active] 200-OK
(100 Trying)
200-OK
BYE (B-Conf)
200-OK
BYE
200-OK
NOTIFY[state:
terminated]
(200-OK)
200-OK
13.4.6Removing all Conference Participants
(A) (A) BC BC
UE-B connected to
Conference
UE-C
connected to
Conference
Controller decides to
remove all
participants from REFER sip:conferenceURI
Refer-To=<sip:conferenceURI; method=BYE>
conference
REFER (A-
Conf)
202 Accepted
TAS authorizes the participant removal
request (only a controller is allowed to remove
a participant) and identifies the participant to
be removed. If the request is to remove the
conference uri, then all the participants are
removed, including the controller.
NOTIFY[state: INFO <destroyconference id=”conf:msisdnAtimestamp"/>

Active]
(100 Trying) 200-OK
200-OK
BYE
200-OK
BYE
200-OK
BYE
200-OK
Clear the control dialog
BYE
200-OK
User C removal not

shown
NOTIFY[state:
terminated]
(200-OK)
200-OK
BYE
200-OK
13.4.7Last Participant (not controller) Leaving Conference
(A) (A) BC BC
UE-B connected to
Conference
User B decides to leave the

Conference.
Last participant (excluding controller)
is leaving the conference.
BYE
INFO <unjoin id1=”conf” id2=”conn:id=C”>
200-OK
BYE
200-OK
200-OK
TAS identifies that the conference has only a

controller remaining in the conference. If the flag
(controller_last_participant_close_conference) is
enabled, conference is cleared.
INFO <destroyconference id=”conf:msisdnAtimestamp"/>
200-OK
BYE
200-OK
Clear the control dialog BYE
200-OK
BYE
200-OK
13.5 Conference, addition of Waiting call
(A) (A) BC BC

UE-B connected to
Conference
INVITE A (SDPo)
LIR/LIA not shown
183 (SDPa)/PRACK/200-OK
180 Ringing
Controller (A) places conference on

HOLD and accepts the incoming call
reINVITE (A-
Conf)
(a=sendonly)
200-OK (a=recvonly)
200-OK
(INVITE)
ACK not shown
Controller (A) add C to conference. Prior to which it does a call swap, retrieves the
conference call and places the A-C call on Hold. Retrieve Conference not shown.
reINVITE (A-C)
(a=sendonly)
REFER (A-C)
202 Accepted
200-OK (a=recvonly)

NOTIFY[state:
Active] 200-OK [tag=<conn: id:C>][SDP (all supported media)]
(100 Trying)
200-OK
reINVITE (A-C)
(SDPmrf)
200-OK (SDPa) (C )/ACK not shown

ACK (SDPa) (C)
INFO <join id1=”conf” id2=”conn:id=C”><stream type=”audio”/><stream type=”video”/>

NOTIFY[state:
terminated] 200-OK
(200-OK)
200-OK
BYE
200-OK
13.6 Conference: Addition of 4th Party
UE-A I-CSCF UE-B UE-C UE-D MRF
(A) (A) BCD BCD

UE-B connected to Conference
Controller (A) holds the conference
and calls D UE-C connected to
Conference
reINVITE (A-
Conf)
(a=sendonly)
200-OK (a=recvonly)
INVITE D
(SDPo)
183 (SDPa)/PRACK/200-OK/180 Ringing

200-OK
ACK not shown
Call is answered, RTP session setup between UE-A and UE-D
Controller (A) add D to conference. Prior to which it does a call swap, retrieves the
conference call and places the A-D call on Hold. Retrieve Conference not shown.
reINVITE (A-D)
(a=sendonly)
REFER (A-D)
202 Accepted
200-OK (a=recvonly)

NOTIFY[state:
Active] 200-OK [tag=<conn: id:D>][SDP (all supported media)]
(100 Trying)
200-OK
reINVITE (A-D)
(SDPmrf)
200-OK (SDPa) (C )/ACK not shown

ACK (SDPa) (C)
INFO <join id1=”conf” id2=”conn:id=D”><stream type=”audio”/><stream type=”video”/>

NOTIFY[state:
terminated] 200-OK
(200-OK)
200-OK
BYE
200-OK
1. The controlling user puts the conference on hold and makes a call to a new user
2. Re-INVITE (with a=sendonly option) is used to put the conference call on hold and standard 2-
way call establishment procedures to set up a call with the new user using SIP INVITE
3. Upon successful call establishment with the new user the controlling user adds the user to the
conference
4. The client after receiving an acknowledgement from the CTAS that the new user is added to the
conference resumes the conference call which was on hold by sending re-INVITE (w/ a=sendrecv
option).
14 Hold Resume Call flow
UE-A CSCF TAS-A TAS-B UE-B
RTP MEDIA [CID:1, 2 & 3. SDP1 & SDP2]

RE-INVITE [RURITEL=B]
[CID1, SDP3 (a=sendonly)]
Client A RE-INVITE [RURITEL=B]

presses [CID2, SDP3 (a=sendonly)]
HOLD
200-OK (SDP4 (a=recvonly)
ACK (200-OK)
No RTP voice packet
[CID1, SDP5 (a=sendrecv)]
Client A [CID1, SDP5 (a=sendrecv)]
presses
HOLD
200-OK (SDP6 (a=sendrecv)
ACK (200-OK)
RTP MEDIA [CID:1, 2 & 3. SDP5 & SDP6]

15 CRBT
15.1 UAC does not support multiple early dialogs

The RBT Routing Number will take the following format:
tel:+[cs breakout prefix][cc][ndc][snr];rn=+[cc][RBT infix][ndc][snr]
Where
 “cs breakout prefix” is the preconfigured CSRN prefix configured at TAS
 Rest of the user part portion is the original called party number received in the Request-URI of the
incoming request.
 “rn” parameter is include containing the following:
o A leading “+” followed by country code.
o A preconfigured RBT infix
o ndc, snr taken from the original called party received in the Request-URI of the incoming
request.

 The RBT service is active for the served terminating user.
 It’s assumed that the caller does not support multiple early dialogs. This is indicated by the
presence of “no-fork” directive in the Request-Disposition header of the initial INVITE.
S-CSCF T AS S-CSCF TAS
UE-A UAG (A) I-CSCF HSS UAG (B) UE-B CRBT
(A) (A) B B
OriginatingServices
1-3
INVITE [from:A, to: B, SDPo]
PEM=Supported 4a. MNP
Request-Disposition: no-fork ENUM
(charging) ENUM query should return LRN + SIP URI or TEL URI
4b
OCS
4.c CCR(I)
4.d CCA
If S-CSCF receives SIP URI from 5. INVITE

TAS, then all it has to do is a DNS
query to resolve the next hop. 6 INVITE
Otherwise it has to do an ENUM query 7. LIR (B)
again to convert TEL to SIP URI 8. LIA (S-CSCF Name)
9-10. INVITE
11
12-13 INVITE
14-16. 183 (SDP)
17-19. PRACK
20-21. 200
OK(PRACK)
Terminating subscriber has RBT service active
Since the originating device does not support Multiple Early
Dialogs, save SDP Answer from B, and respond with
PRACK.
22-24. 180
Ringing
Establish RBT Leg
25-26. INVITE tel:00090 

TAS will use preconfigured RBT RURI in [SDP0]
egress INVITE
PRACK/200 OK between UE-A and CRBT server is not shown
Absorb it. ACK
UE-A and CRBT are conencted
RTP (Personal RBT)

41-46. 200 OK
ACK
47-53.
UPDAT E
(SDP)
PEM=inactiv Redirect the A party to B’s media
e SDP= SDP answer received from
UE-B
Check for the changes in the following in comparison to

54-60.200 OK
SDP Offer from UE-B:
(Update),SDP2
Address, port or transport
Media formats (m= line) for the (m=) lines in SDP Offer 2
Attribute changes (addition or removal) for the (a=) lines in
SDP Offer 2
61-
65 .BYE
Termination of CRBT leg
200 OK(BYE)
ACK for 200 OK is not shown

 If the served terminating subscriber has the RBT service active , when 183 provisional
response is received with an SDP answer, since the originating UA does not support multiple
early dialogs, the TAS will not relay the 183 to the caller. Since the 183 is sent reliably, the
TAS will respond with a PRACK.
o It may also be possible that 183 provisional response with or without SDP answer
may not be received. The terminating UE may choose to send 180 Ringing instead.
 When 180 Ringing is received, the TAS will establish the RBT call leg. The outgoing INVITE
request will contain the following relevant headers:
SIP Header Value

Request-URI Set to the RBT Routing number created as described above
From As received in the incoming INVITE
P-Asserted-Identity As received in the incoming INVITE, if received
To As received in the incoming INVITE
Route As received in the incoming INVITE request, this contains the ODI
with SCSCF address.
Contact Set to the local FQDN configured for TAS
P-Early-Media Set to “supported”
Message Body Containing Original SDP offer received in the incoming INVITE
 In the response to the initial INVITE to the MGCF/RBT player, it may respond with:
o 183 provisional response with SDP answer, followed with a 200 OK final answer OR
o 183 provisional response with SDP answer, without any 200 OK final answer OR
o 200 OK final response with SDP answer, without any 18x provisional response.
180 Ringing is not expected to be received from the MGCF/RBT player, if received will be
consumed at TAS.
 If 183 provisional response is received with SDP answer, the TAS will relay it to the
originating UA establishing early dialog between the originating UA and the MGCF. P-Early-
Media header field will be included with a value “sendonly”, if not already present.
 If 200 OK final response is received with SDP answer, the TAS will establish early dialog with
the caller by sending reliable 183 provisional response with the SDP answer received in 200
OK.
 Any 200 OK final response received from the MGCF on the RBT call leg is consumed, as
RBT is always played using early dialog.
 When the 200 OK final answer is received from the B-party, the TAS will clear the RBT call
leg and in parallel redirect the caller’s media to the B-party. In order to redirect the caller’s
media to the B party, the TAS will generate UPDATE towards caller with remote SDP from the
B party. When 200 OK response with SDP Answer is received in response to the UPDATE,
the TAS will not rely on change in SDP Version to identify the change in SDP, it will instead
check change in any SDP attributes. If there is a change in SDP compared to the previous
SDP from the caller, the TAS will use reINVITE towards B party to update it with the modified
SDP.
15.2 UAC supports multiple early dialogs
This use case describes a call termination attempt to a user with the RBT service active and the caller
supports multiple early dialogs.

 The RBT service is active for the served terminating user.
It’s assumed that the caller supports multiple early dialogs. This is indicated by the presence of “fork”
directive in the Request-Disposition header of the initial INVITE or absence of “fork” directive.
UE-A UAG(A) I-CSCF HSS UAG (B) UE-B CRBT
(A) (A) B B
INVITE [from:A, to: B, SDPo] OriginatingServices

PEM=Supported
MNP
ENUM
(charging) ENUM query should return LRN + SIP URI or TEL URI
OCS
CCR(I)
CCA
If S-CSCF receives SIP URI from INVITE

query to resolve the next hop. INVITE
Otherwise it has to do an ENUM query LIR (B)
again to convert TEL to SIP URI LIA (S-CSCF Name)
INVITE
INVITE
14-16. 183 (SDP)
Terminating subscriber has RBT service

active Since the originating device support
Multiple Early Dialogs, so 183 response
form UE-B will be relayed to UE-A
PRACK/200 ok PRACK is not shown
180 Ringing
Establish RBT Leg
INVITE tel:00090 

[SDP0] TAS will use preconfigured RBT RURI in
egress INVITE
PRACK/200 OK between UE-A and CRBT server is not shown
Absorb it. ACK
UE-A and CRBT are conencted
RTP (Personal RBT)

41-46. 200 OK
61-
65 .BYE
Termination of CRBT leg
200 OK(BYE)

o Since the originating UA supports Multiple Early Dialogs, the TAS will relay 183 provisional response
received from the B-party to the originating UA to establish an early dialog. P-Early-Media header field
will be included with a value set to “inactive”.
o The P-CSCF/A-BGF which may have media gated based on the SDP Answer received on the early
dialog from the caller and the B party, should selectively open the gate when early media is authorized
between the caller and the RBT server.
o When the 200 OK final answer is received from the B-party, the TAS will clear the RBT call leg and
relay the 200 OK to confirm the early dialog established between the caller and the B party.
16 MCA
S-CSCF TAS S-CSCF TAS MCA Ser ver/
UE-A UAG(A) I-CSCF HSS UAG (B) UE-B HLR RJIO S MS C
(A) (A) B B CRBT
OriginatingServices
1-3 INVITE [from:A, to: B,

SDPo] MNP
PEM=Supported
4a.ENUM ENUM query should return LRN + SIP URI or TEL
URI
4b
OCS
4c.CCR(I)
4d.CCA
If S-CSCF receives SIP URI from 5. INVITE

query to resolve the next hop. 6. INVITE 7. LIR (B)
Otherwise it has to do an ENUM query
8. LIA ( 2003 UNREGISTERED SERVICE)
again to convert TEL to SIP URI
9. INVITE
(REGSTATE=unregistered) 10
TAS will ftech subscriber profile if not available at TAS
11. MAP_SRI
12. MAP_SRI(Absent subscriber)
Terminating subscriber has active MCA ruri set

to MCA server address (MCA RURI=
Prefix+CLDPN )
13-15. INVITE SIP: MCA RURI

[SDP0]
TAS will use preconfigured MCA RURI in
egress INVITE
UE-A will be informed. 4xx response not shown
S-CSCF TAS S-CSCF TAS MCA Server/

UE-A UAG(A) I-CSCF HSS UAG(B) UE-B HLR RJIO S MS C
(A) (A) B B
MCA server sends a silent message to the

UE(protocol ID 64) on reception of first
missed call notification by TAS.
19. Submit_SM
With Protoocl
ID=64
20. Submit_SM
Response
UE is Not reachable. Delivery to the UE fails and SMSC deposits the sms in its
database and sends ReportSMDelivery Failure to HLR. When UE becomes
reachable, SMSC Is alerted by HLR using alert-SC and silent message is
delivered to the UE.(silent message not displayed on the UE). Now SMSC
sends a status report back to the MCA Server (Configured as an
LargeAccount at SMSC).
21.
Delivery_SM
(Status report)
22.Delivery_SM
Resp
On reception of this delivery report , MCA delivers the

aggregated message to the UE with missed call alert count
per caller. Each SMS will have corresponding caller number.
23.Submit_SM
(Miss call Alert
SMS)
24. MT-FSM (Miss call alert SMS)

Submit_SM
Response
Delivery SM ACK
17 Sh interface call flow -TAS
17.1 Initial Registration as well as subscription for Notification
UE-A CSCF TAS
UE Registration in IMS, not shown

REGISTER
To: IMPU-A
Expires: reg-T1
[embedded REGISTER Authorization: SNR(IMPU-A,
IMPI-A)/ Repository Data,
200-OK body] SUBSCRIBE,
SDI=USER_DATA_REQUESTED,
SI = (MMTEL-Services, IMS-ODB-
subDataStore = HSS
Information))
HSSsupportsNotifEff =enabled
SNA (2001,
User-Data)
200-OK
REGISTER (refresh)
To: IMPU-A Reg-T1
Expires: reg-T2
[embedded REGISTER Authorization:
IMPI-A)/
200-OK body]
The SNR sent during Initial

Registration does not include Expiry-
Time, which is an indication to the
HSS to treat it as an unlimited
subscription.There is no need to
200-OK refresh the Subscription during
Refresh Registration.
17.2 Profile Recovery

UE-A CSCF TAS HSS
INVITE
INVITE PAI: IMPU-A Subscriber for the IMPU received in
P-Asserted-Identity is not available,
retrieve it from the HSS
subDataStore = HSS
SNR(IMPU-A,
Repository Data,
SUBSCRIBE,
SDI=USER_DATA_REQUESTED,
Information))
SNA (2001,
User-Data)
INVITE
17.3 De Registration
UE-A CSCF TAS HSS
Network Initiated DeRegistration
REGISTER
To: IMPU-A
Expires: 0
[embedded REGISTER Authorization:
IMPI-A)/
200-OK body]
SNR (IMPU,
UNSUBSCRIBE,
Repository Data,
subDataStore = HSS SI=MMTEL-Services, IMS-ODB-
nsrDataStorage=HSS Information)
SNA (2001)
200-OK
User Profile will be removed from

the local cache.
17.4 Un-Registered Terminated Request (MT Flow)
UE-A CSCF TAS HSS
INVITE
PAI: IMPU-A
P-served-User:sescase=term Termination request for unregistered
INVITE ;regstate=unreg user is received.
TAS will neither store the received
user data nor subscribe for notification
subDataStore = HSS
nsrDataStorage=HSS
HSSsupportsNotifEff =enabled UDR(IMPU-A,
RepositoryData,
Information, ))
Flow when HSSsupportsNotifEff UDA (2001, User-Data)

=disabled must be supported,
not shown here.
INVITE
17.5 Interrogation
UE HEP/AP TAS HSS
HTTP/XCAP GET {node-selector, XUI} User Profile is available and Active.

Simservs XML document is built based
on the Services configured in the User
Profile.
HTTP/200-OK
[simservs XML]
Alternate Scenario: HTTP/XCAP requests lands on the TAS which is not anchoring the Subscriber.
HTTP/XCAP GET {node-selector, XUI}

User Profile is not available. User Profile
is retrieved from the HSS and simservs
XML document is created.
subDataStore = HSS
HSSsupportsNotifEff =enabled UDR(IMPU-A,
HSSQueryMethod =UDR RepositoryData,
SI = (MMTEL-Services, IMS-ODB-Information))
UDA (2001, User-Data)
HTTP/200-OK
[simservs XML]
17.6 Manipulation
UE HEP/AP TAS HSS
HTTP/XCAP PUT {node-selector, XUI}

{xml-fragment|xml-full-document}
If User Profile is not available, Subscriber
Data is retrieved from HSS by generating
an UDR (not shown)
subDataStore = HSS
userConfigMethod = Sh
PUR (IMPU-A,
Repository Data,
SI=MMTEL-Services)
PUA (2001)
If PUA returned is a success, the

HTTP/200-OK modification is updated to the subscriber
[simservs XML] profile.
It is assumed that Notification will be

generated after a successful modification.
TAS processes like any notification
request. PNR (IMPU, User-Data)
PNA (2001)
18 Rx Call Flows
18.1 Subscription to IP-CAN Type Change

UE UAG PCRF IMS Core
SIP REGISTER(IMPU, IMPI,…) Configuration indicates to

subscribe for IP-CAN type
change
DIAM AAR (Specific-Action=IP-
CAN_CHANGE, Framed-IP-Address=UE IP
Address, Flow-Number=0, Flow-
Usage=AF_SIGNALING)
Session Binding and
PCC rules identification
DIAM AAA (Result-Code = SUCCESS)
SIP REGISTER(IMPU, IMPI, ….)
SIP 200 OK
SIP 200 OK
Failure Response DIAM AAA (Result-Code = FAILURE)
ACTION indicates
CONTINUE
SIP REGISTER(IMPU, IMPI…)
SIP 200 OK
SIP 200 OK
DIAM AAA (Result-Code = FAILURE)
ACTION indicates
REJECT
Configurable Non 2xx response
Timeout
Timeout waiting for response.
ACTION indicates CONTINUE
SIP REGISTER(IMPU, IMPI…)
SIP 200 OK
SIP 200 OK

ACTION indicates REJECT
Configurable Non 2xx response
18.2 Subscription to Signaling Path Status
SIP REGISTER(IMPU, IMPI,…)

Note: 401 and other messages
are not shown for brevity SIP 200 OK
SIP 200 OK
Configuration indicates to
subscribe for signaling
path status
DIAM AAR (Specific-

Action=INDICATION_OF_LOSS_OF_BEARER
, INDICATION_OF_RELEASE_OF_BEARER,
Framed-IP-Address=UE IP Address, Flow-
Number=0, Flow-Usage=AF_SIGNALING)
Session Binding and
Do Nothing
Timeout
Do Nothing
18.3 Provision SIP Signaling Flow
SIP REGISTER(IMPU, IMPI,…)

Note: 401 and other messages
are not shown for brevity SIP 200 OK
SIP 200 OK
Configuration indicates to
provision signaling flow
DIAM AAR (Media-Component-Description,

Flow-Status=Enabled, Framed-IP-Address=UE
IP Address, Flow-Number=0, Flow-
Usage=AF_SIGNALING)
Session Binding and

Do Nothing
Timeout
Do Nothing
18.4 Initial Session Provisioning – Originating UAG
SIP INIVTE (Calling Party, Called Party, SDP

Offer,...) UAG allocates media
resources locally. Trigger
to send AAR is ON
Downlink and Uplink

connection information is
available

Flow-Status=Enabled, Flow-
Usage=AF_SIGNALING, Flow-Description,
Number=0 etc)
Store session information
and identifies IP-CAN
DIAM AAA (Result-Code = SUCCESS) session
SIP INVITE (calling Party, Called Party, SDP Offer…)

Note: Complete call setup flow
is not shown for brevity
SIP 183 (Term SDP Answer)
SIP 183 (UAG SDP Answer...)
Failure Response
Default ACTION
indicates REJECT
503 Service Unavailable OR Configurable Non
2xx response
Timeout
Default ACTION indicates
503 Service Unavailable OR Configurable Non REJECT
2xx response
18.5 Session Modification – Originating UAG
SIP INIVTE (Calling Party, Called Party, UE

SDP Offer)
UAG allocates media
to send AAR is ON
Downlink and Uplink

available

Number=0,
SERVICE_INFO_STATUS=FINAL_SERVICE_
INFORMATION, etc)
SIP INVITE (calling Party, Called Party, UE SDP Offer…)
Note: Preconditions supported

SIP 183 (UAG SDP Answer)
SIP PRACK/200 OK SIP PRACK/200 OK
Resource allocation
completed
SIP UPDATE (Updated Offer)

Modify the session
information at PCRF

Number=0,
INFORMATION, etc)
Update session
information and identifies
DIAM AAA (Result-Code = SUCCESS) IP-CAN session
SIP 200 OK (Term SDP Answer)
SIP 200 OK (UAG SDP Answer)

18.6 Session Modification – Originating UAG
Call Active or Held
SIP Re-INIVTE (Calling Party, Called Party,

UE updated SDP Offer)
UAG allocates media
to send AAR is ON
Downlink and Uplink

available

Number=0,
INFORMATION, etc)
SIP Re-INVITE (calling Party, Called Party, UE SDP Offer…)
Note: Complete call flow is not

shown for brevity
Failure Response
Default ACTION
indicates REJECT
503 Service Unavailable OR Configurable Non
2xx response

Default ACTION indicates
503 Service Unavailable OR Configurable Non REJECT
2xx response
18.7 Initial Session Provisioning – Terminating UAG
SIP INVITE (calling Party, Called Party, Remote SDP Offer…)
UAG allocates media

resources locally.
SIP INIVTE (Calling Party, Called Party, UAG
SDP Offer,...)
SIP 183 (UE SDP Answer...)

Trigger to send AAR is
ON for term UAG on
receiving answer
Downlink and Uplink

available

Number=0 etc) Store session information
session

Failure Response
Default ACTION
indicates REJECT
SIP 503 Service Unavailable OR Configurable Non 2xx response

SIP CANCEL
Timeout Timeout waiting for response.

Default ACTION indicates REJECT

SIP CANCEL
18.8 Session Modification – Terminating UAG
UAG allocates media

resources locally.
SDP Offer,...)

Trigger to send AAR is is not shown for brevity
ON for term UAG on
receiving answer
Downlink and Uplink

available

session
SIP PRACK/200 OK SIP PRACK/200 OK

ON for term UAG on
receiving answer
Downlink and Uplink

SIP UPDATE (UAG Updated Offer) available
SIP 200 OK (UE updated answer)

Number=0 etc)
session
SIP 200 OL (UAG SDP Answer)

18.9 Initial Session Provisioning (Bearer Loss) – Originating UAG

to send AAR is ON
Downlink and Uplink

available

Number=0 etc)

SIP 183 (UAG SDP Answer...) DIAM RAR (Specific Action

[INDICATION_OF_LOSS_OF_BEARER],
Media-Component-Description, Flow-Number
etc)
DIAM RAA
UAG waits for SDP modification from UE

through re-INVITE/UPDATE/PRACK
SIP UPDATE (modified SDP Offer,...)

DIAM AAR
DIAM AAR

Timeout Beraer recovery doesn’t happen and

all flows are affected
503 Service Unavailable OR Configurable Non DIAM STR

2xx response
DIAM STA
Timeout NO UPDATE received from UE

DIAM AAR
200 OK (SDP Answer)
DIAM AAR
200 OK (SDP Answer)

18.10 Initial Session Provisioning (Bearer Recovery) – Originating UAG

to send AAR is ON
Downlink and Uplink

available

Number=0 etc)

SIP 183 (UAG SDP Answer...) DIAM RAR (Specific Action

etc)
DIAM RAA


DIAM AAR
DIAM AAR

DIAM RAR (Specific Action

[INDICATION_OF_RECOVERY_OF_BEARER
], Media-Component-Description, Flow-Number
etc)
DIAM RAA
UAG waits for SDP modification from

UE through re-INVITE/UPDATE

DIAM AAR
DIAM AAR


DIAM AAR
200 OK (SDP Answer)
DIAM AAR
200 OK (SDP Answer)

18.11 Initial Session Provisioning (Bearer Loss) – Terminating UAG
UAG allocates media

resources locally.
SDP Offer,...)

ON for term UAG on
receiving answer
Downlink and Uplink

available

session

etc)
Note: Compl ete call setup flow
DIAM RAA
UAG waits for SDP modificati on from UE



DIAM AAR

Beraer recovery doesn’t happen and

Timeout
DIAM STR
DIAM STA
SIP CANCEL


DIAM AAR

18.12 Initial Session Provisioning (Bearer Recovery) – Terminating UAG
UAG allocates media

resources locally.
SDP Offer,...)

ON for term UAG on
receiving answer
Downlink and Uplink

available

session

etc)
DIAM RAA



DIAM AAR


etc)
DIAM RAA



DIAM AAR


DIAM AAR

18.13 Established session (bearer loss) -
Originating UAG
Call Active or Held

etc)
DIAM RAA
Note: Complete call flow is not UAG waits for SDP modification from UE
shown for brevity through re-INVITE/UPDATE/PRACK
SIP INVITE (modified SDP Offer,...)

DIAM AAR
DIAM AAR

Timeout Beraer recovery doesn’t happen and

SIP BYE (Reason Header [503 Service DIAM STR

Unavailable],..)
DIAM STA
SIP 200

DIAM AAR
200 OK (SDP Answer)
DIAM AAR
200 OK (SDP Answer)

18.14 Established session (bearer recovery) - UAG
Originating
Call Active or Held

etc)
DIAM RAA
Note: Complete call flow is not UAG waits for SDP modification from UE
shown for brevity through re-INVITE/UPDATE/PRACK

DIAM AAR
DIAM AAR


etc)
DIAM RAA


DIAM AAR
DIAM AAR


DIAM AAR
200 OK (SDP Answer)
DIAM AAR
200 OK (SDP Answer)

19 GBA authentication
UE BSF AG NAF/AP AS HSS
HTTP REQUEST / HTTP/1.1

Host: naf.home.com:80
User-Agent: ”3gpp-gba”
Accept: */* NAF decides to authenticate using
401 Unauthorized bootstrapped security association
WWW-Authenticate: Digest algorithm=MD5 nonce= <generated-value>, (based on local configuration)
realm=”3GPP-bootstrapping@naf.operator.com”, qop=”auth-int”
User initiates bootstrapping procedure by

sending HTTP GET request to home BSF
GET / HTTP/1.1
Host: bsf.home.com:80
User-Agent: Bootstrapping client
Authorization: Digest username=”<User IMPI>”,
realm=”bsf.home.com”, nonce=””, response=””
BSF retrieves the authentication vectors from

Zh MAR (User Name = IMPI, Authentication-Scheme=Digest-AKAv1-MD5, Optional GUSS-
the HSS. It obtains the IMPI from the
Timestamp,...)
Authorization header of HTTP GET request
Default authentication HSS generates authentication vectors and
scheme will be Digest-AKA. fetches GUSS (if requested) for the private
401 Unauthorized
Server: Mavenir BSF user identity
WWW-Authenticate: Digest, algorithm=AKAv1-MD5,
nonce=base64(RAND+AUTN), realm=”bsf.home.com”, Zh MAA (User-Name = IMPI, SIP-Auth-Data-Item=AKA vectors, ... )
qop=”auth-int”
Client runs AKA, verifies AUTN and derives RES

using the shared keys and calculates IK and CK
GET / HTTP/1.1
User-Agent= Bootstrapping client
Authorization = Digest username=<User IMPI>,
realm=”bsf.home.com”, none=base64(RAND+AUTN)
response=<RES calculated using Keys> BSF validates the RES value with the response received from the HSS in
200 OK MAA. On successful authentication the BSF generates key material Ks and B-
Server: Mavenir BSF TID, and stores the tuple (B-TID, IMPI, CK, IK). The B-TID returned to the UE
Authentication-Info: rspauth = response,... also identifies (via hostname) the specific BSF which owns the keys
Content-Type: application/vnd.3gpp.bsf+xml
<xml version =”1.0" encoding=”UTF-8"?>

<BootstrappingInfo xmlns=”uri.3gpp-gba”>
<btid>value@loc1.bsf.home.com</btid>
<lifetime>2013-10-24T13:20:00Z</lifetime>
</BootstrappingInfo>
UE generates the key material by concatenation

IK and CK and stores the tuple (B-TID, Ks)

User-Agent=”3gpp-gba”
Authorization = Digest username=<B-TID>,
algorithm= MD5, realm=”3GPP-bootstrapping@naf.home.com” nonce=nonce-value qop= “auth-init”
response = <Ks_NAF (base64 encoded)> NAF Retrieves the Ks_ext_NAF from BSF over
Zn interface. BSF is integrated within AG and
SOAP requestBootstrappingInfoRequest internal interface will be used for this
(btid=B-TID, nafid=NAF Idenfitier,
gsid=Service Id
BSF checks if the tuple for the receiped B- SOAP requestBootstrappingInfoResponse(
TID exists. If exists, derives the key impi=IMPI
material and returns that to NAF. meKeyMaterial=Ks_NAF/Ks_ext_NAF
uiccKeyMaterial=Ks_int_NAF NAF validates the Ks_(ext)_NAF received from
KeyExpiryTime=, ussList=, gbaType=3G GBA the BSF and the client. On successful
validation, NAF forwards the request to the
application server
HTTP 200 OK HTTP 200 OK

20 Ut Interface call flow
20.1 Retrieving the entire document

The entire simservs document is retrieved using the following HTTP request:
GET simservs.ngn.etsi.org/users/<IMPU>/simservs HTTP/1.1
If authorization checks pass, TAS will return the entire simservs document in a 200 OK response
using the application/vnd.etsi.simservs+xml MIME type.
UE AGW TAS
XCAP GET
TAS retrieves the MMTel profile from the

HSS, if necessary
200 OK
Content-Type: application/simservs+xml
[simservs XML document]
20.2 CFU Deactivation

UE AGW TAS
Interrogation happens here (not shown)
XCAP PUT/XCAP DELETE

HSS, if necessary
Over Sh interface TAS updates recored

in HSS. Flow is not shown
200 OK
The CFU service is deactivated by setting the “active” attribute of the <communication-diversion >
element to “false” (this disables all MMTel Communication Diversion services) or by deleting the “cfu”
rule.
The CFU service can be deactivated by performing an XCAP PUT or DELETE operation on the
application usage defined by 3GPP TS 24.623. The UE can deactivate CFU by either:
1. Including the entire simservs XML document in the XCAP PUT, with the CFU service deleted
2. Using the node selector procedures and including only the XML elements or attributes
relevant to the CFU service
3. Using the node selector in a XCAP DELETE request
4. Adding a “rule-deactivated” condition to the CFU rule.
20.3 CFU Activation, Changing a Forward-To Number
UE AGW TAS
Interrogation happens here (not shown)
XCAP PUT

HSS, if necessary
TAS updates it in HSS over Sh interface
200 OK
The CFU service is activated by setting the “active” attribute of the <communication-diversion>
element to “true” and either omitting the <conditions> element or including an empty <conditions>
element in the “cfu” rule. The Forward-To Number is modified by updating the <forward-to> element in
the “cfu” rule.
The CFU service can be activated by performing an XCAP PUT operation on the application
usage defined by 3GPP TS 24.623. The UE can activate CFU by either:
1. Including the entire simservs XML document in the XCAP PUT, with the CFU service activated
2. Using the node selector procedures and including only the XML elements or attributes relevant to
the CFU service
21 Contact center call flow
21.1 RJIO Subscriber calling contact center

O TAS
UE-A UAG I-BCF CUBE
S-CSCF (A)
INVITE Tel:121 OriginatingServices
from:A, to: B, SDPo] TAS identifies as call center number

based on dialled digit
TAS translates incoming number based on PVNI and prefix

it with service code 1000. i.e. if PVNI is Delhi Circel , TAS
prefixes 11 on service code 1000.
TAS Skips MNP dip
OCS
CCR
CCA
INVITE
Tel:111000
S-CSCF identifies ICM call based on RURI

S-CSCF selects H-IBCF based on calling party home domain
i-bcf may need to do DNS based load

sharing to multiple CUBE’s
180 Ringing (SDP)
200 OK
ACK is shown
Mid dialogue Media negotiation is not required as only one coded will be used between I-BCF and CUBE
O TAS i-BCF MSC

UE-A UAG
S-CSCF (A) (B)
RTP RTP RTP
1. Based on dilled digit TAS will identify call center trigger.

2. Based on PVNI header TAS will translate outgoing called party number as for example shown in
below table
Caller CLID
Caller Call to Be
(Example Caller Cust
Home Offered to DNIS to be
Numbers to Current ome Service
Circle Service Code Ingress GW presented to
be Circle r Dialed
(HSS/UPSF of Which Ingress Gateway
allocated ID/Prefix Type
) Circle
by IMS)
9899248292 Delhi (11) Delhi (11) Local 121 1000 Delhi (11) 111000
9899248292 Delhi (11) Mumbai Roam 121 1000 Delhi (11) 121000
(12) ing
Mumbai
9910174999 Mumbai (12) Local 121 1000 Mumbai (12) 121000
(12)
Roam
9910174999 Mumbai (12) Delhi (11) 121 1000 Mumbai (12) 111000
ing
Prosp
7822152212 Unknown Delhi (11) 9888877777 1001 Delhi (11) 111001
ect
Mumbai Prosp
8833263323 Unknown 9888877777 1001 Mumbai (12) 121001
(12) ect
3.S-CSCF will select H-IBCF based on home domain of the calling party.
4. I-BCF will do NNI with CUBE.
21.2 Contact center to RJIO 4G

Disclaimer: To re-visited once solution is closed.
Call will enter to IMS based on MGCF MNP query. MGCF will select I-CSCF based on RN received
form MNP.
TAS
UE-A UAG I-CSCF HSS MGCF CUBE
S-CSCF (A)
OriginatingServices
IAM
MGCF will perform MNP query to

MNP identify terminating network.
MNP Query
INVITE sip:+91-7021075483
@<domain>
LIR
LIA(S-
CSCF)
183
180 Ringing , 200 OK for INVITE not shown. Call will continue normally
TAS MGCF/ MSC

UE-A UAG MGW
S-CSCF (A) (B)
RTP RTP RTP

22 TAS Charging Flow
22.1 Credit Session Setup- Mobile Origination – CCR

[Update] Upon quota expiry
UE-A O-CTAS
S-CSCF MRF UAS OCS
(A)
CCR [INITIAL_REQUEST,
INVITE B [SDPo]
MSCC.RSU.CC-Time=<config-value>
MSCC.RSU.Service-Identifier = <config-value>
The TAS, upon receiving INVITE request, determines
MSCC.RSU.Rating-Group = <config-value>]
whether the subscriber has sufficient balance by
invoking a credit control session with OCS.
CCA [INITIAL_REQUEST
RC=2001
INVITE MSCC.GSU.CC-Time=X]
[SDPo]
183 Session in Progress [SDPa]
PRACK / 200 OK transactions not shown
180 Ringing
200 OK (INVITE)
ACK
Tcp1 T1=X CCR [UPDATE_REQUEST,

MSCC.USU.CC-Time=Tcp1,
MSCC.Reporting Reason=3 (QUOTA_EXHAUSTED)]
delta CCA [UPDATE_REQUEST

RC=2001,
MSCC.GSU.CC-Time=Y]
Tcp2
T2=
Y-delta
CCR [UPDATE_REQUEST,

RC=2001,
MSCC.GSU.CC-Time=Z]
Tcp3
T3=
Z-delta
BYE
CCR [TERMINATION_REQUEST,
MSCC.USU.MSCC.USU.Reporting Reason=2 (FINAL),
MSCC.Termination-Cause=DIAMETER_LOGOUT]
CCA [TERMINATION_REQUEST
RC=2001]
200 OK (BYE)
22.2 Charged Party abandons the call
UE-A O-CTAS MRF
S-CSCF UAS OCS
(A)
INVITE B [SDPo]
MSCC.RSU.Service-Identifier=<config-value>
MSCC.RSU.Rating-Group]=<config-value>
CCA [INITIAL_REQUEST,
Result-Code=2001
INVITE MSCC.GSU.CC-Time=Y]
[SDPo]
183 Session In Progress (SDPa)
PRACK and 200 OK not shown
180 Ringing
CANCEL
200 OK
CANCEL CCR [TERMINATION_REQUEST,
200 OK MSCC.USU.CC_TIME=0,
MSCC.USU.Reporting-Reason=FINAL,
MSCC.Termination-
Cause=DIAMETER_SERVICE_NOT_PROVIDED]
200 OK CCA [TERMINATION_REQUEST,

Result-Code=2001]
CANCEL
200 OK
487 Request Cancelled
ACK (487)
22.3 Handling Low Balance Indication
O-CTAS
UE-A S-CSCF MRF UAS
(A)
INVITE B [SDPo] CCR [INITIAL_REQUEST,

Result-Code=2001
MSCC.GSU.CC-Time=Y
Due to Low-Balance-Indication, the TAS MSCC.Low-Balance-Indication=1]
plays announcement before setting up the
session
183 Session in INVITE sip:msml@domain SDPo
Progress (D1)
[SDP-mrf Answer]
PEM=sendonly
PRACK
200 OK (PRACK)
INFO
<dialogStart name=annc,
audio uri="file://provisioned/
messageID"/>
200 OK (INFO)
RTP (Low balance Annoucememt)
INFO
<id=conn:id:msisdnA/
dialog:annc>
<name>play.end<value>play.com
plete
INVITE 
[SDPo] 200 OK (INFO)
BYE
200 OK (INFO)
183 Session In Progress (SDPa)
UPDATE (D1) Redirect the A party to the
P-Early-Media: B’s media
inactive
[SDP Offer 2=SDPa]
200 OK
180 Ringing
200 OK (INVITE)
ACK
Tcp1T1=Y CCR [TERMINATION_REQUEST,

MSCC.USU.Reporting-Reason=FINAL,
BYE MSCC.Termination-Cause=DIAMETER_AUTH_EXPIRED ]
200 OK (BYE)
BYE CCA [TERMINATION_REQUEST
Result-Code=2001,
MSCC.Low-Balance-Indication=1]
200 OK (BYE)
22.4 IMS Origination – Media Change in Update Request
UE CSCF TAS UAS OCS
INVITE sip:msisdn@host (SDPo)
CCR [
CC-Request-Type=INITIAL_REQUEST,
MSCC.RSU.CC-Time=X]
MSCC.RSU.Service-Identifier
MSCC.RSU.Rating-Group
INVITE sip:msisdn@host
(SDPo)
183 Session In Progress sip:msisdn@host (SDPa)
UPDATE SDPo1
The TAS triggers CCR[UPDATE] when there is a

change in media characterstic. Session setup and
CCR[UPDATE] continues in parallel
CCA [
CC-Request-Type=UPDATE_REQUEST
Result-Code=2001
MSCC.GSU.CC-Time=Y]
180 [Ringing]
200 OK [INVITE]
ACK
T (Z=(X+Y)
Call answered, TAS starts quota consumption here.

CCR [
CC-Request-Type=TERMINATION_REQUEST,
MSCC.USU.CC-Time=Y,
BYE MSCC.USU.Reporting-Reason=2 (FINAL),
MSCC.Termination-Cause=DIAMETER_LOGOUT ]
CCA [
CC-Request-Type=TERMINATION_REQUEST
Result-Code=2001]
200 OK (BYE)
22.5 Credit Session Setup- Media Change
UE-A O-CTAS
S-CSCF UAS OCS
(A)
INVITE B [SDPo]
RC=2001
INVITE MSCC.GSU.CC-Time=X]
[SDPo]
180 Ringing
200 OK (INVITE)
ACK
Tcp1 T1=X
CCA [UPDATE_REQUEST
RC=2001,
delta MSCC.GSU.CC-Time=Y]
re-INVITE SDPo1 MSCC.RSU.CC-Time<Config-Value>
MSCC.Service-Identifier <Config-Value> {video-call}
Tcp2 MSCC.Reporting Reason= 6
(RATING_CONDITION_CHANGE)
MSCC.Trigger.Trigger-Type=40
(CHANGE_IN_MEDIA_COMPOSITION)]]

RC=2001,
MSCC.GSU.CC-Time=Z]
Tcp3
BYE
RC=2001]
200 OK (BYE)
22.6 Credit Session Setup- Mobile Origination – CCR [Update] Upon quota expiry –
TQT
UE-A O-CTAS
S-CSCF MRF UAS OCS
(A)
INVITE B [SDPo]
invoking a credit control session with OCS. CCA [INITIAL_REQUEST
RC=2001
MSCC.GSU.CC-Time=X
INVITE MSCC.Time-Quota-Threshold=Y]
[SDPo]
180 Ringing
200 OK (INVITE)
ACK
Tcp1 T1=X-Y CCR [UPDATE_REQUEST,

CCA [UPDATE_REQUEST
delta RC=2001,
MSCC.GSU.CC-Time=Y
MSCC.Time-Quota-Threshold=Z]
Tcp2
T2=
(Y-Z) -delta
CCA [UPDATE_REQUEST
delta RC=2001,
MSCC.GSU.CC-Time=Z,
MSCC.Time-Quota-Threshold=A]
Tcp3
T3=
(Z-A)-delta
BYE
RC=2001]
200 OK (BYE)

RJIO Call Flows v1.8

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

RJIO Call Flows v1.8

Caricato da

Copyright:

Formati disponibili

RJIO 4G Call Flows

© 2014 Mavenir Systems Inc.

Rev. Date Prepared Reviewed Approved Details

1.1 3-04-2014 Mavenir Internal Updated with internal review comments

1.2 15-04-2014 Mavenir NPE Team Updated as per NPE comments

1.3 12-05-2014 Mavenir NPE Team Added description to call flow

1. Added RP-SMM flow

1.2 Scope of Document

1.3 Agreed methods

1. Attach Request 2 3 AIR

12Security Mode command

Cancel location and Delete session request is not shown

3 Non-LTE UE access procedures

3.1.1.1 Home GW behind LTE

User Device Home GW LTE CPE eNodeB S/P-GW

DHCP Discovery + Option 120

The procedure is as follows:

3.1.1.2 FTTH End Device

User Device ONT OLT BNG DHCP

3.1.1.3 Wi-Fi End Device

User Device AP WLC DHCP

4.1 Registration @ Home PLMN

S-CSCF supports the following registration scenarios acting as a Registrar:

S-CSCF will initiate 3rd Party Registration procedure during:

P-CSCF selects I-CSCF

I-CSCF queries DNS with default FQDN.

16 SAR (IMPU, IMPI S-CSCF Name. SA

IMS UE registered. TAS will fetch

S-CSCF selects IP-SM-GW for

IP-SM GW stores the profile 25 Profile retrieval (Via Sh)

TPR for RCS AS will be same a s of TAS a nd IPSMGW

IP-SM GW updates gsmSCF-Address on subscribers profile in HLR

27 ATM (gsmSCF Addr = IP-SM

This will trigger HLR to s end ALERT-SC to 28 MAP-READY-For-SM (MS)

UE Subscribe for reg. event

AS Subscribe for reg. event

Call flow description

15.I-SCSF relays request to S-CSCF.

18-19-20. 200 OK response to SIP REGISTER Request.

26.200 OK response for Third party registration request.

6. SAR (IMPU, IMPI, S-CSCF Name. SA-

S-CSCF selects same TAS used during UE

11 REGISTER 1. Profile retrieval will be only required

S-CSCF selects same IP-SM-GW used

14 1. Profile retrieval will be only required

Security-Client: Lists the supported algorithm(s) by UE1.

8-10. Registration response 200 OK is sent to UE

1 REGISTER (IMPU, IMPI)

P-CSCF selects I-CSCF

S-CSCF does not apply UE Authentication during De-registration

6 SAR (IMPU, IMPI, S-CSCF Name. SA-Type=USER_DEREGISTERATION)

4.2.1 Initial Registration

Registration of the UE roaming in another circle

21 SAA (IMPU, User Profile)

22 S-CSCF adds service-

Note: Here AS stands for TAS,IPSMGW and RCS application

Visited IMS Network

Subsequent Initial Registration or Refresh TPR.

UAR (IMPU, IMPI)

UAA [DIAMETER_SUBSEQUENT_REGISTRATION-2002, S-CSCF-Name]

REGISTER (IMPU, Service-Info)

Note: Here AS stands for TAS,IPSMGW and RCS application

Visited IMS Network