DHCP/DNS procedure for P-CSCF discovery

In a DHCP/DNS procedure for P-CSCF discovery, a user equipment (UE) obtains the
necessary information to reach a Proxy-Call Session Control Function (P-CSCF) by
sending a DHCP request to acquire the P-CSCF's IP address or fully qualified domain
name (FQDN) from the network, then resolving the FQDN to an IP address using a DNS
query if needed; essentially, the UE uses the DHCP server to get the P-CSCF details and
then uses DNS to translate the domain name into an IP address if provided as such. [1, 2, 3]

Key steps involved: [1, 2, 3]

• Initiate DHCP request: The UE sends a DHCP request to the network, asking for an
IP address and additional information like DNS server addresses. [1, 2, 3]

• DHCP response: The DHCP server responds with the allocated IP address and
potentially the P-CSCF details, either as a direct IP address or as a FQDN. [1, 2, 3]

• DNS query (if necessary): If the P-CSCF information is provided as a FQDN, the UE
performs a DNS query to resolve the domain name into an IP address. [1, 3, 4]

• P-CSCF selection: Based on the received P-CSCF information and any configured
policies, the UE chooses the appropriate P-CSCF to use for communication. [1, 3, 5]

Important points to remember: [1, 3, 5]

• Policy-based selection: The UE may need to use specific policies set by the
network operator to select the right P-CSCF from multiple options. [1, 3, 5]

• IMS integration: This procedure is typically used within an IP Multimedia

Subsystem (IMS) network where the P-CSCF acts as the entry point for IMS calls. [1,
2, 3]

• Alternative methods: While DHCP/DNS is a common method, some scenarios

might involve pre-configured P-CSCF addresses directly within the UE. [1, 2, 3]

Here's a detailed explanation of the DHCP/DNS procedure for P-CSCF discovery in IMS
networks. This process allows a User Equipment (UE) to dynamically discover the address
of its Proxy-CSCF (P-CSCF) when connecting to the IMS network:

Key Concepts

1. P-CSCF: The UE's entry point into the IMS network.

 2. DHCP: Dynamically assigns IP addresses and network parameters (e.g., DNS server
addresses).

3. DNS: Resolves domain names to IP addresses (e.g.,

translating pcscf.ims.mnc001.mcc001.3gppnetwork.org to an IP).

Procedure Overview

The UE discovers the P-CSCF in two phases:

1. DHCP Phase: Obtain DNS server addresses and P-CSCF domain name.

2. DNS Phase: Resolve the P-CSCF domain name to IP addresses.

Step-by-Step Process

1. DHCP Phase

The UE uses DHCP to acquire network configuration details:

• Step 1: UE sends a DHCP Discover message to the network.

• Step 2: DHCP server responds with a DHCP Offer, including:

o UE’s IP address.

o DNS server IP address.

o P-CSCF domain name (via DHCP options, e.g., Option 43 or vendor-specific

options).

Example DHCP Option for P-CSCF Domain:

Copy

Option 43 (Vendor-Specific Information):

Sub-option: P-CSCF Domain Name (e.g., `pcscf.ims.mnc001.mcc001.3gppnetwork.org`)

2. DNS Phase

The UE uses DNS to resolve the P-CSCF domain name to IP addresses:

Step 3: UE sends a DNS NAPTR Query for the P-CSCF domain.

 • Purpose: Discover supported transport protocols (e.g., SIP over UDP, TCP, or TLS).

• NAPTR Record Example:

Copy

pcscf.ims.mnc001.mcc001.3gppnetwork.org. IN NAPTR

100 10 "S" "SIP+D2U" "" _sip._udp.pcscf.ims.mnc001.mcc001.3gppnetwork.org.

200 10 "S" "SIP+D2T" "" _sip._tcp.pcscf.ims.mnc001.mcc001.3gppnetwork.org.

o SIP+D2U: SIP over UDP.

o SIP+D2T: SIP over TCP.

Step 4: UE selects a transport protocol (e.g., UDP) and sends a DNS SRV
Query for _sip._udp.pcscf.ims....

• SRV Record Example:

Copy

_sip._udp.pcscf.ims.mnc001.mcc001.3gppnetwork.org. IN SRV

0 5 5060 pcscf1.ims.mnc001.mcc001.3gppnetwork.org.

0 5 5060 pcscf2.ims.mnc001.mcc001.3gppnetwork.org.

o Priority: 0 (load balancing).

o Port: 5060 (default SIP port).

Step 5: UE performs DNS A/AAAA Queries to resolve hostnames (e.g., pcscf1.ims...) to

IPv4/IPv6 addresses.

• A Record Example:

Copy

pcscf1.ims.mnc001.mcc001.3gppnetwork.org. IN A 192.168.1.100

pcscf2.ims.mnc001.mcc001.3gppnetwork.org. IN A 192.168.1.101

Final P-CSCF Address List

The UE compiles the resolved IP addresses and ports:

Copy
 P-CSCF 2: 192.168.1.101: 5060 (UDP)

P-CSCF 1: 192.168.1.100:5060 (UDP)

The UE selects a P-CSCF (e.g., based on priority or load balancing) and establishes a SIP
connection.

Key Notes

1. 3GPP Specifications:

o Defined in 3GPP TS 24.229 (IMS call control).

o DHCP options and DNS records follow IETF standards (RFC 3315 for
DHCPv6, RFC 3263 for SIP DNS).

2. Alternative P-CSCF Discovery:

o In LTE/5G networks, P-CSCF addresses may be provided by the PDN

Gateway (PGW/UPF) during PDN connection setup (via Protocol
Configuration Options, PCO).

3. Security:

o DNS responses may be secured via DNSSEC to prevent spoofing.

o SIP signaling with P-CSCF uses IPsec (for integrity/confidentiality).

Call Flow Summary

This procedure ensures the UE dynamically discovers the P-CSCF using standardized
DHCP and DNS mechanisms. Let me know if you need further clarification!

======================================================================

SIP IMS Call Flow

P-CSCF Discovery

1. Before sending any Session Initiation Protocol (SIP) requests, the UE must perform
“P-CSCF Discovery”, the process of identifying (by address) the correct Proxy-Call
Session Control Function (P-CSCF). The P-CSCF address may be discovered in one of
three different ways:
a. It may be stored in the IP Multimedia Services Identity Module (ISIM).
b. The UE may request it as part of the PDN connectivity request during the
Attach process.
c. The UE may request an IP address and Fully Qualified Domain Name (FQDN)
from a DHCP server and then perform a DNS query on the returned IP
address and FQDN.
SIP REGISTER Request:

After UE finishes radio procedures and it establishes radio bearers UE can start SIP
registration towards the IMS Network

2. The IMS client attempts to register by sending a REGISTER request to the P-CSCF.
a. The UE's IP address is the source IP address of the SIP message.
b. This IP address is assigned to the UE during the LTE attach procedure (by the
P-GW).
c. The P-CSCF uses this IP address to route responses back to the UE.
3. The P-CSCF forwards the REGISTER request to the I-CSCF.
a. The I-CSCF Interrogates the Home Subscriber Server (HSS) to determine the
target S-CSCF for a subscriber to decide which S-CSCF should manage the
REGISTER request.
b. Routes SIP requests to the correct S-CSCF based on subscriber profiles

4. The I-CSCF forwards the REGISTER request to the appropriate S-CSCF.

5. The S-CSCF receives the REGISTER request and initiates the authentication process.
6. The S-CSCF sends a 401 Unauthorized response to the UE, including:
a. Authentication challenge (e.g., nonce, algorithm).
b. Security parameters.
7. UE Responds with Credentials:
a. The UE calculates the authentication response using the received challenge
and its shared secret (stored in the ISIM or USIM).
b. The UE sends a new REGISTER request with the authentication response.
8. S-CSCF Verifies Credentials:
a. The S-CSCF verifies the authentication response with the HSS.
b. If successful, the S-CSCF registers the UE and updates the HSS with the UE's
registration status.
9. S-CSCF Sends 200 OK:
a. The S-CSCF sends a 200 OK response to the UE via the I-CSCF and P-CSCF.
b. The response confirms successful registration and may include:
i. Registration expiration time.
ii. Service route information.
10. UE is Registered:
a. The UE is now registered in the IMS network and can initiate/receive VoLTE
calls, SMS, and other IMS services.
=========================================================================

IMS (IP Multimedia Subsystem) Call Hold Scenario & Call Flow
The Call Hold feature in IMS allows a user to temporarily suspend an ongoing call and
resume it later. Below is a detailed explanation of the scenario and its call flow using SIP
(Session Initiation Protocol) signaling.

Key Components Involved

1. User Equipment (UE-A/UE-B): Endpoints (e.g., smartphones, SIP phones).

2. Proxy-CSCF (P-CSCF): Entry point to the IMS network.

3. Serving-CSCF (S-CSCF): Manages session control.

4. Application Server (AS): May handle supplementary services like call hold.

5. Media Resource Function (MRF): Provides media services (e.g., hold music).
Call Flow for Call Hold

The process involves three phases:

1. Initial Call Setup

2. Invoking Call Hold

3. Resuming the Call

1. Initial Call Setup

1. UE-A → P-CSCF → S-CSCF → UE-B:

o UE-A sends a SIP INVITE to UE-B (via P-CSCF and S-CSCF).

o SDP in the INVITE negotiates media parameters (e.g., codec, ports).

2. UE-B → S-CSCF → P-CSCF → UE-A:

o UE-B responds with 180 Ringing (optional) and 200 OK (final response).

3. UE-A → UE-B:

o UE-A sends ACK to confirm session establishment.

o Media flow begins between UE-A and UE-B.

2. Invoking Call Hold

UE-A decides to put the call on hold:

1. UE-A → P-CSCF → S-CSCF → UE-B:

o UE-A sends a re-INVITE (or SIP UPDATE) with modified SDP:

a=sendonly (UE-A stops sending media)

or

a=inactive (temporarily pauses media in both directions)

o This signals the network to suspend media.

2. UE-B → S-CSCF → P-CSCF → UE-A:

o UE-B acknowledges with 200 OK (with SDP a=recvonly or a=inactive).

 3. UE-A → UE-B:

o UE-A sends ACK to confirm the hold.

o Media flow stops.

Optional: If the network supports hold music:

• The AS/MRF sends an INVITE to UE-B to play music (via MRF).

• UE-B’s media path is redirected to the MRF.

3. Resuming the Call

UE-A decides to resume the call:

1. UE-A → P-CSCF → S-CSCF → UE-B:

o UE-A sends another re-INVITE (or UPDATE) with SDP:

a=sendrecv (restores bidirectional media)

2. UE-B → S-CSCF → P-CSCF → UE-A:

o UE-B responds with 200 OK (with SDP a=sendrecv).

3. UE-A → UE-B:

o UE-A sends ACK.

o Media flow resumes between UE-A and UE-B.

Key Points

• SIP Methods:

o re-INVITE is commonly used to modify sessions (e.g., hold/resume).

o UPDATE can also be used for mid-session changes (RFC 3311).

• SDP Attributes:

o a=sendonly, a=recvonly, a=inactive, a=sendrecv control media direction.

• Hold Music:

o If enabled, the MRF streams music to UE-B during hold.

Call Flow Diagram

This flow ensures seamless suspension and resumption of calls in IMS networks.

The Session Description Protocol (SDP) is a format used for describing multimedia
communication sessions for the purposes of announcement and invitation. It is widely
used in conjunction with protocols like SIP (Session Initiation Protocol), RTP (Real-time
Transport Protocol), and RTSP (Real-time Streaming Protocol)1.

Key Features of SDP:

1. Session Description: SDP describes a session as a group of fields in a text-based

format, with each field on a separate line. The fields include information about the
session, timing, and media descriptions1.

2. Session Information: This includes details like the session name, session title, URI
of the session description, email addresses, phone numbers, and connection
information.
 3. Timing Information: Specifies the time the session is active, including start and end
times.

4. Media Descriptions: Each media description starts with an "m=" line and includes
information about the media type, format, and transport protocol.

5. Attributes: Additional attributes can be included to provide more details about the
session, such as encryption keys, bandwidth information, and session-specific
attributes.

In this example:

• v=0 indicates the protocol version.

• o=alice 2890844526 2890844527 IN IP4 alice.example.com specifies the originator

and session identifier.

• s=Example SDP Session is the session name.

• c=IN IP4 alice.example.com provides connection information.

• t=0 0 indicates the time the session is active.

• m=audio 49170 RTP/AVP 0 describes the media type and port number.

• a=rtpmap:0 PCMU/8000 provides additional attributes for the media description.

SDP is extensible and can support new media types and formats, making it a versatile tool
for multimedia communication.
Emergency Call(911) with IMS

Key SIP Headers for Emergency Calls

1. Request-URI

2. Priority

3. P-Asserted-Identity

4. P-Access-Network-Info

5. Geolocation

6. Supported

7. Accept-Contact

8. Call-Info

9. Diversion (in some cases)

1. Request-URI

• Purpose: Indicates the service requested and helps route the call appropriately.

• Usage in Emergency Calls:

o The Request-URI contains a special URN (Uniform Resource Name) that

identifies the call as an emergency call.

o Format:

o Examples of URNs:

▪ General emergency: urn:service:sos

▪ Specific services:

▪ Police: urn:service:sos.police

▪ Fire: urn:service:sos.fire

▪ Ambulance: urn:service:sos.ambulance
 • Example:

2. Priority

• Purpose: Indicates the priority level of the SIP message.

• Usage in Emergency Calls:

o Set to emergency to denote that the call is an emergency call.

• Example:

3. P-Asserted-Identity

• Purpose: Conveys the identity of the user sending the SIP message, as asserted by
the network.

• Usage in Emergency Calls:

o Provides the caller’s identity to the network and emergency services.

o May include the telephone number in TEL URI format.

• Example:

4. P-Access-Network-Info

• Purpose: Provides information about the access network through which the user is
connected.

• Usage in Emergency Calls:

o Helps the network determine the user's location based on the access
network data.

• Example:
 o Explanation:

▪ 3GPP-E-UTRAN-FDD: Indicates the type of access network (LTE FDD).

▪ utran-cell-id-3gpp: The cell ID composed of MCC (Mobile Country

Code), MNC (Mobile Network Code), and CI (Cell Identity).

5. Geolocation

• Purpose: Conveys the geographical location of the caller.

• Usage in Emergency Calls:

o Includes the caller's location information within the SIP message.

o Uses the Geolocation header to reference location data in the message body.

• Example:

o In the Message Body:

▪ A multipart MIME message includes the location object, typically in

PIDF-LO (Presence Information Data Format - Location Object)
format.

6. Supported

• Purpose: Lists the SIP extensions supported by the sender.

• Usage in Emergency Calls:

o Indicates support for features like geolocation.

• Example:

7. Accept-Contact

• Purpose: Indicates preferences for the recipient’s characteristics or capabilities.

 • Usage in Emergency Calls:

o May specify that the call should be handled by a PSAP (Public Safety
Answering Point) or entities capable of handling emergency services.

• Example:

8. Call-Info

• Purpose: Provides additional information about the call.

• Usage in Emergency Calls:

o May include the service URN for emergency services.

• Example:

9. Diversion (if applicable)

• Purpose: Indicates that the call has been forwarded or redirected.

• Usage in Emergency Calls:

o In most emergency call scenarios, the Diversion header is not typically used.

o However, if applicable, it can provide information about call redirection.

Sample SIP INVITE Message for an Emergency Call

Below is a comprehensive example of a SIP INVITE message for an emergency call,

incorporating the key headers and elements discussed.
Explanation:

• Request-URI:

o sip:urn:service:[email protected] indicates an
emergency call.

• Priority Header:

o Priority: emergency marks the call as high-priority for emergency services.

• P-Access-Network-Info:

o Provides information about the access network and cell ID for location
purposes.

• P-Asserted-Identity:

o Conveys the caller's phone number to the network and PSAP.

• Geolocation Header and PIDF-LO:

 o Includes the caller's geographic location using the PIDF-LO format in the
message body.

o The Geolocation header references the location information by Content-ID.

• Supported Header:

o Indicates support for required features like geolocation.

• Content-Type and MIME Boundaries:

o multipart/mixed allows multiple content types (SDP and PIDF-LO) in the

message body.

Understanding the Key Headers in Context

Request-URI with Service URN

• The use of urn:service:sos enables the network and SIP proxies to recognize the call
as an emergency call without relying on local emergency numbers, which can vary
by region.

Overview of Emergency Calls in IMS/LTE Networks

In the transition from traditional circuit-switched networks to all-IP networks like LTE,
handling emergency calls reliably is paramount. IMS provides the necessary architecture to
support emergency services over LTE, ensuring that even without legacy networks, users
can make emergency calls efficiently.

Key Components Involved

1. User Equipment (UE):

o The mobile device initiating the emergency call.

o Must support emergency call capabilities without requiring SIM

authentication.

2. Evolved Node B (eNodeB):

o The LTE base station that provides radio access.

 o Transmits emergency call requests to the core network.

3. Mobility Management Entity (MME):

o Manages signaling and control functions for the LTE access network.

o Differentiates emergency calls from regular calls and handles them

accordingly.

4. Serving Gateway (S-GW) and PDN Gateway (P-GW):

o Route user data packets.

o Ensure proper Quality of Service (QoS) for emergency calls.

5. IP Multimedia Subsystem (IMS):

o Handles session control and signaling for VoLTE calls.

o Key elements include:

▪ Proxy Call Session Control Function (P-CSCF):

▪ First point of contact in IMS for the UE.

▪ Emergency Call Session Control Function (E-CSCF):

▪ Specialized CSCF that handles emergency sessions.

▪ Media Gateway Control Function (MGCF):

▪ Interfaces with legacy networks if needed.

▪ Location Retrieval Function (LRF):

▪ Provides location information of the UE to emergency services.

6. Public Safety Answering Point (PSAP):

o The emergency service center that receives and responds to emergency

calls.

Emergency Call Setup Process

Imagine you're in a situation where you need immediate assistance. Here's how your
emergency call is processed in an IMS/LTE network:

Step 1: Call Initiation

• User Dials an Emergency Number:

 o The UE recognizes emergency numbers (e.g., 911, 112) based on a
predefined list.

o The UE bypasses normal call procedures to prioritize the emergency call.

Step 2: Network Attachment

• Emergency Attach Procedure:

o If the UE isn't already connected, it performs an Emergency Attach.

o This allows devices without valid credentials (like a SIM card) to connect for
emergency services.

Step 3: Bearer Establishment

• Dedicated Bearer Setup:

o The network establishes a dedicated EPS (Evolved Packet System) bearer

with appropriate QoS parameters.

o QoS Class Identifier (QCI) for emergency calls ensures low latency and high
priority.

Step 4: Routing the Call in IMS

• SIP INVITE Message:

o The UE sends a SIP INVITE with an emergency indication to the P-CSCF.

o The INVITE includes:

▪ Emergency Indication: Flags the call as an emergency.

▪ Location Information (if available): Helps in routing the call to the

correct PSAP.

• P-CSCF Processing:

o Detects the emergency indication.

o Routes the call to the E-CSCF instead of the standard S-CSCF.

• E-CSCF Functions:

o Determines the appropriate PSAP based on the caller's location.

o May query the LRF for precise location data.

 o Routes the call to the PSAP via the appropriate network.

Step 5: Call Completion

• Media Setup:

o Media channels are established between the UE and the PSAP.

o Allows for voice communication, and potentially video or text if supported.

• Communication with PSAP:

o The caller can now interact with emergency responders.

o Location information is provided to assist in dispatching help

Conference Call
https://www.sharetechnote.com/html/Handbook_LTE_VoLTE_Conference.html#Case_1

IMS Conference Call Flow Diagrams

VoLTE Conference Call Flow

1. Conference Initiation

• User Initiates Conference:

o The conference initiator (User Equipment, UE) sends an INVITE request to

the network.

o The Request-URI in the INVITE message is set to a conference factory URI.

2. P-CSCF Handling

• P-CSCF (Proxy Call Session Control Function):

o The P-CSCF receives the INVITE request and responds with a 100 Trying
message.

o The P-CSCF forwards the INVITE request to the S-CSCF (Serving Call Session
Control Function).

3. S-CSCF Processing

• S-CSCF:

o The S-CSCF processes the INVITE request and determines the appropriate
Multimedia Resource Function Controller (MRFC) for the conference.

o The S-CSCF forwards the INVITE request to the MRFC.

4. MRFC Handling

• MRFC (Multimedia Resource Function Controller):

o The MRFC assigns a conference URI and configures the Multimedia

Resource Function Processor (MRFP).

o The MRFC sends a 200 OK response back to the S-CSCF, indicating that the
conference has been created.

5. Conference Setup

• MRFP (Multimedia Resource Function Processor):

o The MRFP sets up the necessary media channels for the conference.
 o RTP (Real-time Transport Protocol) data begins flowing between the
conference initiator UE and the MRFP.

6. Adding Participants

• Refer Procedure:

o The conference initiator uses the refer procedure to invite additional

participants to the conference.

o The new participants receive an INVITE request with the conference URI.

o The new participants respond with a 200 OK message, and the MRFP mixes
the media streams for all participants.

7. Conference In Progress

• Media Mixing:

o The MRFP mixes the media streams from all participants and propagates
them to everyone in the conference.

o Participants can communicate with each other in real-time.

8. Exiting the Conference

• Participant Leaves:

o When a participant decides to leave the conference, the MRFP is notified.

o The MRFP stops sending media streams to the exiting participant and
informs the remaining participants.

9. Conference Termination

• Ending the Conference:

o The conference initiator sends a BYE request to terminate the conference.

o The MRFP releases the media channels and resources used for the
conference.

o The MRFC and S-CSCF handle the termination process, and the conference
is ended.

Key Components Involved

1. User Equipment (UE): Initiates the conference call.

 2. P-CSCF: Handles initial INVITE request and forwards it to S-CSCF.

3. S-CSCF: Processes the INVITE request and routes it to MRFC.

4. MRFC: Manages the conference setup and media mixing.

5. MRFP: Handles media streams and mixing for conference participants.

6. Participants: Join the conference using the conference URI provided by MRFC.

PRACK
PRACK stands for "Provisional Response Acknowledgement" and in an IMS call flow, it
is a SIP message used to confirm the receipt of provisional responses (like "180 Ringing" or
"183 Session Progress") from the called party, ensuring reliable delivery of these interim
updates during a call setup process, especially when using unreliable transport protocols
like UDP; essentially acting as a way to check if the calling party received the important
progress information from the called party.

Key points about PRACK in IMS call flow:

• Function:

It provides a mechanism to acknowledge the receipt of provisional responses, which are

sent during the early stages of a call setup before the final answer is received.

• Reliability Enhancement:

By sending a PRACK message, the calling party can be confident that the called party
received the provisional response, even if there were network issues that could have
caused packet loss.

Where Does PRACK Involve in SIP Communications?

PRACK is involved in scenarios where reliable provisional responses are necessary. This
includes:

• Early Media Establishment:

o When media (audio, video) needs to be exchanged before the call is fully
connected.

o When early media (like ringback tones, announcements) needs to be reliably

set up before call completion
 • Session Progress Information: Providing in-call announcements or ringback tones
generated by the callee’s network.

• Resource Reservation: Ensuring that network resources are allocated before the
call is established, important in QoS (Quality of Service) sensitive environments.

How PRACK Works: Detailed Explanation

PRACK — Provisional Acknowledgement — is used to acknowledge the receipt of

provisional responses (excluding 100 Trying). Provisional responses like 180 Ringing or 183
Session Progress, may require reliable delivery to ensure smooth call setup in some cases.
PRACK enhances the reliability of these responses by confirming their receipt, similar to how
the ACK confirms the final response to an INVITE request.

To indicate support for PRACK, SIP messages include specific headers:

• Supported: 100rel shows that the sender supports reliable provisional responses.

• Require: 100rel indicates that the sender requires reliable provisional responses.

Here is how it works:

• INVITE with 100rel: The User Agent Client (UAC) includes the Supported:
100rel header in its INVITE request to indicate its support for reliable provisional
responses.

• Reliable Provisional Response: The User Agent Server (UAS) responds with a
provisional response(e.g.,180 Ringing) and includes the Require:100rel
 and RSeq headers, which mandates the requirement of PRACK, containing a
sequence number to uniquely identify the response.

• Sending PRACK: The UAC acknowledges the provisional response by sending a

PRACK request. The PRACK must include the RAck header, which mirrors the
sequence number from the RSeq header.

• 200 OK for PRACK: The UAS responds to the PRACK with a 200 OK message and the
call proceeds with further SIP exchanges leading to success or failure of the call.

Key Takeaways

• Reliability: PRACK ensures that provisional responses are reliably delivered and
acknowledged.

• Headers like Supported: 100reland Require: 100rel are essential for indicating
support and requirement for reliable provisional responses. Other key headers
involved are RSeq in provisional responses and RAck in PRACK requests.

• Implementation: PRACK is crucial in scenarios requiring assured delivery of

provisional responses, such as call flows involving early media.
Session Initiation Protocol (SIP) Overview

The Session Initiation Protocol (SIP) is a signaling protocol widely used for initiating, maintaining, modifying,
and terminating real-time sessions that involve video, voice, messaging, and other communications
applications and services between two or more endpoints on IP networks. Developed by the Internet
Engineering Task Force (IETF), SIP is an essential component in modern telecommunications, particularly in
Voice over IP (VoIP) and Unified Communications (UC) systems.

1. Key Characteristics of SIP

• Text-Based Protocol: Similar to HTTP and SMTP, SIP uses human-readable text, making it easier to
debug and implement.

• Transport Layer Agnostic: SIP can operate over various transport protocols, including UDP, TCP,
TLS (for secure SIP), and SCTP.

• Extensible and Modular: SIP's design allows for easy extension through additional headers and
methods to support new features and services.

• Peer-to-Peer Architecture: Facilitates direct communication between clients without requiring a

central server, although registrars and proxies can be used to enhance functionality.

2. SIP Architecture and Components

a. SIP User Agents

1. User Agent Client (UAC): Initiates SIP requests. It acts as the client in the SIP communication.

2. User Agent Server (UAS): Responds to SIP requests. It acts as the server in the SIP communication.

3. Combined User Agent: Functions as both UAC and UAS, handling both sending and receiving SIP
messages.

b. SIP Servers

1. Registrar: Handles the registration of user agents, mapping user addresses to their current location
(IP addresses).

2. Proxy Server: Routes SIP requests on behalf of user agents, acting as an intermediary that can
modify or forward messages.

3. Redirect Server: Provides information about the next-hop or target for a request, directing the UAC
to contact another server or user agent.

4. Back-to-Back User Agent (B2BUA): Operates as both a UAC and UAS simultaneously, managing SIP
signaling and media streams on behalf of clients.
c. SIP Messages

SIP messages are divided into two categories:

1. Requests: Initiate actions.

o INVITE: Initiates a call/session.

o ACK: Confirms receipt of a final response to an INVITE.

o BYE: Terminates a call/session.

o CANCEL: Cancels a pending request.

o OPTIONS: Queries capabilities of servers.

o REGISTER: Registers the user's current location.

o PRACK: Provisional Response Acknowledgment.

o SUBSCRIBE: Subscribes to event notifications.

o NOTIFY: Sends event notifications.

2. Responses: Indicate the status of requests.

o 1xx (Provisional): Informational responses (e.g., 100 Trying, 180 Ringing).

o 2xx (Successful): Indicate successful completion (e.g., 200 OK).

o 3xx (Redirection): Direct the client to a different server (e.g., 302 Moved Temporarily).

o 4xx (Client Error): Indicate errors caused by the client (e.g., 404 Not Found).

o 5xx (Server Error): Indicate errors caused by the server (e.g., 500 Server Internal Error).

o 6xx (Global Failure): Indicate permanent failures (e.g., 603 Decline).

3. SIP Message Structure

Each SIP message consists of three main parts:

1. Start Line:

o Requests: Contains the method (e.g., INVITE) and the Request-URI.

o Responses: Contains the SIP version, status code, and reason phrase.

2. Header Fields:

o Provide additional information about the message or the communication session.

o Examples include From, To, Call-ID, CSeq, Via, Contact, Content-Type, and Content-
Length.

3. Message Body (Optional):

 o Contains the session description using protocols like SDP (Session Description Protocol),
which describes multimedia communication sessions for the purposes of session
announcement, invitation, and parameter negotiation.

Example of a SIP INVITE Request:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

v=0

o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.example.com

s=Session SDP

c=IN IP4 pc33.atlanta.example.com

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

4. SIP Call Flow Example

Let’s walk through a typical SIP call flow between two users, Alice and Bob, to establish a VoIP call.

Scenario: Alice Calls Bob

1. Alice Initiates the Call

• Alice's UAC (User Agent Client) sends an INVITE request to Bob's UAS (User Agent Server) via SIP
proxies.

2. SIP Proxies Route the INVITE

• The INVITE traverses through one or more SIP Proxy Servers, which route the request based on the
Request-URI (e.g., sip @biloxi.example.com).
3. Bob's User Agent Receives the INVITE

• Bob's UAS receives the INVITE and responds with a 180 Ringing provisional response, indicating that
the call is ringing on Bob's device.

4. Bob Answers the Call

• When Bob accepts the call, his UAS sends a 200 OK response back through the SIP proxies to Alice.

5. Alice Sends ACK

• Alice's UAC receives the 200 OK and sends an ACK request to confirm the receipt of the 200 OK,
completing the call setup.

6. Media Streams Established

• Using the information exchanged in the SDP (Session Description Protocol) part of the SIP
messages, both Alice and Bob establish a RTP (Real-Time Protocol) stream for the actual voice
communication.

7. Call Termination

• When either party wants to end the call, they send a BYE request.

• The receiving party responds with a 200 OK, acknowledging the termination.

5. SIP URI and Addressing

a. SIP URI (Uniform Resource Identifier)

• Format: sip:user@domain or sips:user@domain (for secure SIP)

• Example: sip:[email protected]
b. Components of SIP URI:

1. Scheme: sip or sips (indicating whether the communication is secure)

2. User: Identifies the individual user or service (e.g., alice)

3. Domain: Specifies the SIP domain or server (e.g., atlanta.example.com)

4. Parameters and Headers (Optional): Additional information for routing or specifying call options
(e.g., ;transport=udp, ?subject=project)

6. SIP Registration Process

Before initiating or receiving calls, SIP user agents must register their current location (IP address) with a
Registrar Server. This process ensures that SIP messages are correctly routed to the user’s current location.

Registration Steps:

1. REGISTER Request:

o The UAC sends a REGISTER request to the Registrar Server, including the user's SIP URI
and contact information.

2. Authentication Challenge (If Required):

o The Registrar may respond with a 401 Unauthorized message, prompting the UAC to provide
authentication credentials.

3. REGISTER with Credentials:

o The UAC resends the REGISTER request with the necessary Authorization header
containing credentials.

4. Registrar Acknowledges Registration:

o Upon successful authentication, the Registrar responds with a 200 OK message, confirming
the registration.

Sequence Diagram: SIP Registration

7. SIP Message Types and Methods

a. SIP Request Methods:

1. INVITE: Initiates a session (e.g., a call).

2. ACK: Confirms receipt of a 200 OK response to an INVITE.

3. BYE: Terminates a session.

4. CANCEL: Cancels a pending request (e.g., cancels an INVITE before it's answered).

5. OPTIONS: Queries the capabilities of a server or user agent.

6. REGISTER: Registers a user’s current location with the SIP server.

7. PRACK: Provisional response acknowledgment, used to confirm receipt of provisional responses.

8. SUBSCRIBE: Subscribes to an event, such as call status or presence information.

9. NOTIFY: Sends event notifications to subscribers.

10. INFO: Sends mid-session information that does not modify the session state.

b. SIP Response Classes:

1. 1xx - Provisional Responses: Informational messages (e.g., 100 Trying, 180 Ringing).

2. 2xx - Success Responses: Indicate successful completion (e.g., 200 OK, 202 Accepted).

3. 3xx - Redirection Responses: Direct the client to contact a different server (e.g., 301 Moved
Permanently, 302 Moved Temporarily).

4. 4xx - Client Error Responses: Indicate errors caused by the client (e.g., 400 Bad Request, 404 Not
Found).

5. 5xx - Server Error Responses: Indicate errors caused by the server (e.g., 500 Server Internal Error,
503 Service Unavailable).

6. 6xx - Global Failure Responses: Indicate permanent failures that are not retriable (e.g., 603 Decline,
604 Does Not Exist Anywhere).

8. SIP Headers and Fields

SIP headers provide essential information about the SIP messages and the session. Key headers include:

1. Via:

o Indicates the path taken by the request and allows responses to follow the reverse path.

o Helps in loop detection and transaction identification.

2. From:

o Specifies the initiator of the request.

 o Includes a tag parameter to identify the dialog.

3. To:

o Specifies the recipient of the request.

o May include a tag after the dialog is established.

4. Call-ID:

o A unique identifier for the SIP session, ensuring that requests and responses are correctly
matched.

5. CSeq:

o Contains a sequence number and method, used to order requests within a dialog.

6. Contact:

o Provides the SIP URI where the user can be reached for future requests.

7. Content-Type:

o Indicates the media type of the message body (e.g., application/sdp).

8. Content-Length:

o Specifies the length of the message body in bytes.

9. User-Agent:

o Identifies the client software initiating the request.

10. Authentication Headers:

o Authorization: Contains credentials for authenticating the request.

o WWW-Authenticate: Challenges the client to provide authentication credentials.

9. Session Description Protocol (SDP) Integration

SIP often works in conjunction with SDP (Session Description Protocol) to describe the media parameters
of a session. SDP is typically included in the message body of SIP messages like INVITE and 200 OK.

Key SDP Components:

1. v=0: Protocol version.

2. o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.example.com:

o o=: Originator and session identifier.

o alice: Username.

o 2890844526 2890844526: Session ID and version.

 o IN IP4 pc33.atlanta.example.com: Network type, address type, and address.

3. s=Session SDP: Session name.

4. c=IN IP4 pc33.atlanta.example.com: Connection information.

5. t=0 0: Timing information (0 0 means the session is unbounded).

6. m=audio 49170 RTP/AVP 0: Media description (audio on port 49170 using RTP/AVP profile, payload
type 0).

7. a=rtpmap:0 PCMU/8000: Attributes (payload type mapping to codec, e.g., PCMU at 8000 Hz).

10. SIP Security Mechanisms

a. SIP over TLS (Transport Layer Security):

• Purpose: Encrypts SIP signaling messages to ensure confidentiality and integrity.

• Implementation: Uses sips: URI scheme and negotiates TLS during the SIP handshake.

b. Secure/Multipurpose Internet Mail Extensions (S/MIME):

• Purpose: Provides end-to-end encryption and signing of SIP message bodies.

• Implementation: Utilizes S/MIME certificates to encrypt and sign SDP payloads within SIP
messages.

c. Digest Authentication:

• Purpose: Authenticates users without transmitting passwords in clear text.

• Mechanism: Uses challenge-response mechanism with hashes (MD5) based on a shared secret.

d. IPsec (Internet Protocol Security):

• Purpose: Secures SIP traffic at the IP layer, providing encryption and authentication.

• Implementation: Can be used to protect SIP signaling between SIP proxies and servers.

11. Common SIP Use Cases

1. Voice over IP (VoIP):

o Initiating and managing voice calls over IP networks.

2. Video Conferencing:

o Setting up and controlling video communication sessions.

3. Instant Messaging and Presence:

o Managing real-time text communication and user availability information.

 4. Unified Communications (UC):

o Integrating various communication services like voice, video, messaging, and conferencing
into a single interface.

5. Call Forwarding and Voicemail:

o Managing supplementary telephony services by interacting with application servers.

12. SIP in Modern Telecommunications

SIP is foundational to many modern communication systems, enabling interoperability and flexibility across
diverse platforms and services. Its ability to handle multimedia sessions and integrate seamlessly with other
protocols makes it indispensable in both consumer and enterprise communications infrastructures.

a. Integration with IMS (IP Multimedia Subsystem):

• Role in IMS: SIP serves as the primary signaling protocol within the IMS architecture, facilitating the
delivery of IP-based multimedia services.

b. Mobile Networks:

• VoLTE (Voice over LTE): Utilizes SIP for establishing voice calls over the LTE data network.

• 5G Networks: Continues to leverage SIP for session management and service delivery within
advanced network architectures.

c. WebRTC (Web Real-Time Communication):

• Use of SIP: While WebRTC primarily uses protocols like WebSockets and STUN/TURN/ICE, SIP can
be integrated for signaling in WebRTC-based applications to manage sessions and user interactions.

IP Multimedia Subsystem (IMS) Protocol Overview

The IP Multimedia Subsystem (IMS) is an architectural framework for delivering IP-based multimedia
services. Developed by the 3rd Generation Partnership Project (3GPP), IMS enables the convergence of
voice, video, messaging, and data services over both wireless and wired networks. It is a pivotal component in
modern telecommunications, supporting services such as Voice over LTE (VoLTE), Video over LTE (ViLTE),
and various unified communication (UC) applications.

1. What is IMS?

IMS stands for IP Multimedia Subsystem, a standardized architecture designed to facilitate the delivery of
IP-based multimedia services. IMS decouples the service layer from the network layer, enabling service
providers to offer a wide range of services across different access networks (e.g., LTE, Wi-Fi) using a unified
framework.
Key Objectives of IMS:

• Service Convergence: Integrate various multimedia services (voice, video, messaging) into a single
platform.

• Interoperability: Ensure seamless interaction between different access technologies and service
providers.

• Scalability: Support large-scale deployments and accommodate growing user demands.

• Flexibility: Allow for easy addition and customization of new services without overhauling the
underlying network infrastructure.

• Quality of Service (QoS): Guarantee service quality and reliability for multimedia applications.

2. IMS Architecture and Components

IMS architecture is composed of several key components, each responsible for specific functions within the
system. The architecture is modular, allowing for flexibility and scalability.

a. Core Components:

1. P-CSCF (Proxy Call Session Control Function):

o Role: Acts as the first contact point for User Equipment (UE) within the IMS network.

o Functions:

▪ Forwards SIP (Session Initiation Protocol) messages between the UE and the IMS
core.

▪ Applies security measures like IPsec or TLS to secure SIP signaling.

▪ Implements DNS-based routing for SIP messages.

2. I-CSCF (Interrogating Call Session Control Function):

o Role: Serves as a query point within the home network to locate the appropriate S-CSCF.

o Functions:

▪ Interrogates the Home Subscriber Server (HSS) to determine the target S-CSCF for a
subscriber.

▪ Routes SIP requests to the correct S-CSCF based on subscriber profiles.

3. S-CSCF (Serving Call Session Control Function):

o Role: The central node in the IMS architecture responsible for session control.

o Functions:

▪ Manages SIP signaling for establishing, modifying, and terminating sessions.

 ▪ Interfaces with application servers to invoke services.

▪ Enforces service policies and QoS parameters.

4. HSS (Home Subscriber Server):

o Role: A central database that stores subscriber-related information.

o Functions:

▪ Maintains subscriber profiles, including service entitlements and authentication

credentials.

▪ Provides authentication vectors for security.

▪ Supplies routing information to the I-CSCF.

5. Application Servers (AS):

o Role: Provide value-added services and applications.

o Functions:

▪ Implement services like voicemail, call forwarding, video conferencing, and

messaging.

▪ Interact with the S-CSCF to receive and process service requests.

6. BGCF (Breakout Gateway Control Function):

o Role: Manages the routing of calls between the IMS network and external PSTN (Public
Switched Telephone Network) or other IMS networks.

o Functions:

▪ Determines the appropriate gateway for routing calls.

▪ Interfaces with MGCF (Media Gateway Control Function) and MGW (Media
Gateway) for media processing.

b. Support Functions:

1. PCRF (Policy and Charging Rules Function):

o Role: Manages policy control and charging rules for multimedia services.

o Functions:

▪ Determines QoS parameters based on subscriber profiles and service

requirements.

▪ Interfaces with the PGW (Packet Data Network Gateway) to enforce policies.

2. ENUM (Telephone Number Mapping):

o Role: Facilitates the mapping of telephone numbers to SIP URIs using DNS.
 o Functions:

▪ Translates E.164 numbers to URIs for SIP-based communication.

3. MGCF (Media Gateway Control Function) & MGW (Media Gateway):

o Role: Bridge the IMS network with traditional telephony networks.

o Functions:

▪ MGCF handles call control signaling, while MGW manages media (voice/video)
streams.

3. IMS Protocol Stack and Signaling

IMS leverages a variety of protocols to manage signaling, media transport, and service delivery. The primary
protocols involved are SIP, Diameter, HTTP, and SDP.

a. Session Initiation Protocol (SIP):

• Purpose: Manages the initiation, modification, and termination of multimedia sessions.

• Functionality: Handles call setup, routing, and teardown using SIP messages (INVITE, ACK, BYE,
etc.).

b. Diameter Protocol:

• Purpose: Provides AAA (Authentication, Authorization, and Accounting) services.

• Functionality: Facilitates communication between IMS core components like the MME and HSS for
subscriber authentication and authorization.

c. Session Description Protocol (SDP):

• Purpose: Describes multimedia sessions and negotiates media parameters.

• Functionality: Embedded within SIP messages to specify media types, codecs, and network
information for the session.

d. HTTP and XML-Based Protocols:

• Purpose: Enable communication between application servers and other IMS components.

• Functionality: Often used for service provisioning and management via RESTful APIs.

e. RTSP (Real-Time Streaming Protocol):

• Role: Manages streaming media sessions.

• Usage: May be used by Application Servers handling video streaming services.

4. IMS Call Flow Example: VoLTE Call Setup

To illustrate how IMS operates, let's examine a typical VoLTE (Voice over LTE) call setup process within the
IMS framework.

Key Steps in VoLTE Call Setup:

1. Registration:

o The UE (User Equipment) registers with the IMS network by sending a REGISTER SIP
message to the P-CSCF.

o The P-CSCF forwards the registration to the I-CSCF, which queries the HSS for the
appropriate S-CSCF.

o The S-CSCF updates the HSS with the UE's current location and handles authentication.

2. Session Initiation:

o Alice wants to call Bob, both registered on the IMS network.

o Alice's UAC sends an INVITE SIP message to the P-CSCF, specifying Bob's SIP URI.

o The P-CSCF routes the INVITE through the I-CSCF to the appropriate S-CSCF for Bob.

3. Service Invocation:

o The S-CSCF identifies the services required (e.g., voice call) and interacts with the Media
Gateway Control Function (MGCF) if the call needs to interface with the PSTN.

o The S-CSCF invokes the necessary Application Servers to handle supplementary services
like voicemail or call forwarding.

4. Media Negotiation:

o The INVITE contains an SDP payload detailing the media capabilities (e.g., codecs, IP
addresses).

o Bob's UAS responds with a 200 OK SIP message, agreeing to the session parameters.

5. Session Confirmation:

o Alice's UAC sends an ACK SIP message to confirm the session establishment.

o Media streams (voice) begin between Alice and Bob using RTP (Real-Time Protocol) as
negotiated.

6. Session Termination:

o Either party can terminate the call by sending a BYE SIP message.

o The other party responds with a 200 OK, concluding the session.

7. IMS Service Delivery and Applications

IMS supports a wide array of services, enabling service providers to offer rich, multimedia experiences to
users.

a. Voice Services:

1. VoLTE (Voice over LTE):

o Description: Provides high-quality voice calls over the LTE data network.

o Features: Enhanced voice clarity, lower latency, simultaneous voice and data transmission.

2. VoWiFi (Voice over Wi-Fi):

o Description: Allows voice calls to be made over Wi-Fi networks when LTE coverage is weak
or unavailable.

o Features: Extends coverage, reduces reliance on LTE, cost-effective for users.

b. Video Services:

1. ViLTE (Video over LTE):

o Description: Facilitates video calling over the LTE network.

o Features: High-definition video, real-time communication, integrated with VoLTE.

2. Video Conferencing:

o Description: Supports multi-party video sessions for business and personal use.

o Features: Collaboration tools, screen sharing, multimedia integration.

c. Messaging Services:

1. RCS (Rich Communication Services):

o Description: Enhances traditional SMS with features like group chats, high-resolution photo
sharing, and read receipts.

o Features: Multimedia messaging, presence information, integration with other services.

2. Instant Messaging:

o Description: Real-time text communication between users.

o Features: Presence indicators, multimedia attachments, typing indicators.

d. Supplementary Services:

1. Call Forwarding:

o Description: Redirects incoming calls to another number or voicemail based on predefined

rules.

o Features: Conditional forwarding (busy, no answer), unconditional forwarding.

2. Voicemail:
 o Description: Allows users to leave voice messages when the recipient is unavailable.

o Features: Message storage, retrieval, notification.

3. Call Waiting:

o Description: Notifies users of an incoming call while already on another call.

o Features: Ability to switch between calls, manage multiple calls.

e. Unified Communications:

• Description: Integrates various communication methods (voice, video, messaging) into a single
cohesive system.

• Features: Seamless transition between communication modes, centralized management, enhanced

collaboration tools.

TAS:

TAS (Telephony Application Server) Summary

The Telephony Application Server (TAS) is a critical component in modern IP Multimedia Subsystem (IMS)
architecture, enabling the delivery of voice, video, messaging, and multimedia services over IP networks. It
plays a vital role in VoIP (Voice over IP) and VoLTE (Voice over LTE) implementations, ensuring that traditional
telephony services can be delivered in an IP-based environment.

TAS is a carrier-grade application server designed to provide a wide range of telecommunication

services over IMS-based IP networks. It offers functionalities similar to traditional Class 5 voice
switches in legacy PSTN (Public Switched Telephone Network) systems, while also supporting
advanced multimedia services.

2. Key Functions of TAS:

1. Call Control:

o TAS manages call setup, modification, and teardown for voice and video calls over IP,
ensuring end-to-end signaling between IMS core network elements.

2. Supplementary Services:

o TAS enables supplementary services like call forwarding, call waiting, call barring, three-way
calling, and number portability.

3. Multimedia Support:

o TAS allows integration of voice with other media types like video, SMS, MMS, and instant
messaging, providing a unified communication experience.

4. SIP Signaling Management:

 o TAS acts as a SIP (Session Initiation Protocol) application server, handling SIP-based
communications between endpoints and coordinating with other IMS components.

5. Service Logic Execution:

o TAS executes service logic for applications, such as voicemail, conferencing, and interactive
voice response (IVR) systems.

3. Mapping Process: S-CSCF to TAS

The mapping between the S-CSCF and TAS involves several steps to ensure that the appropriate telephony
services are invoked based on the subscriber's profile and service requirements.

Step 1: User Registration

1. Registration Request:

o When a user (UE) attempts to register with the IMS network, the P-CSCF forwards the
registration request to the I-CSCF.

2. Routing to S-CSCF:

o The I-CSCF queries the HSS to determine the appropriate S-CSCF for the subscriber based
on the SIP URI or IMS Public User Identity (IMPU).

3. Authentication and Session Setup:

o The S-CSCF communicates with the HSS to authenticate the user and retrieve the
subscription profile, which includes information about the services the user is entitled to.

Step 2: Retrieving Service Profiles

1. Service Profile Access:

o The S-CSCF accesses the HSS to obtain the S-CSCF Service Profile for the subscriber. This
profile contains information about:

▪ Subscribed Services: Details about telephony and other IMS services.

▪ Application Server Triggers: URIs of application servers (like TAS) that need to be
invoked for specific services.

Step 3: Mapping S-CSCF to TAS

1. Service Trigger Identification:

o Based on the subscription profile, the S-CSCF identifies which services are active for the
user. For telephony services, the TAS is designated as the application server to handle these
services.

2. URI of TAS:
 o The HSS provides the URI (Uniform Resource Identifier) of the TAS. This URI is typically in
the form of a SIP address (e.g., sip:tas.example.com).

3. Session Initiation:

o When a user initiates a call or requests a telephony service, the S-CSCF uses the SIP
protocol to route the signaling to the TAS based on the retrieved URI.

Step 4: Communication Between S-CSCF and TAS

1. SIP Signaling:

o The S-CSCF sends SIP INVITE messages to the TAS to invoke the desired telephony service.
For example, if the user activates call forwarding, the S-CSCF communicates this request to
the TAS.

2. Service Execution:

o The TAS processes the request, executes the service logic (e.g., setting up call forwarding),
and responds back to the S-CSCF with the appropriate SIP responses (e.g., 200 OK).

3. Session Continuation:

o The S-CSCF manages the session by coordinating between the UE, the TAS, and other
network elements as needed to maintain the call or service.

Step 5: Handling Multiple Application Servers

1. Service Chaining:

o A subscriber might have access to multiple services that require different application
servers. The S-CSCF maintains a mapping table retrieved from the HSS that links specific
services to their respective application servers.

2. Dynamic Invocation:

o Based on the service requested, the S-CSCF dynamically routes signaling to the appropriate
AS (e.g., TAS for telephony, another AS for video services).

4. Technical Flow Example: Call Forwarding Service

To illustrate the S-CSCF to TAS mapping, let's walk through a call forwarding service scenario:

a. User Activation

1. User Action:

o The user configures call forwarding on their device.

2. Signaling:

o The device sends a SIP REGISTER or SIP UPDATE message to activate call forwarding.
b. S-CSCF Processing

1. Session Management:

o The S-CSCF receives the activation request and updates the session state.

2. Service Invocation:

o Recognizing that call forwarding is a telephony service, the S-CSCF consults the HSS to
retrieve the TAS URI.

c. Interaction with TAS

1. SIP INVITE:

o The S-CSCF sends a SIP INVITE to the TAS to set up the call forwarding rule.

2. TAS Processing:

o The TAS processes the request, updates the user's call forwarding settings, and responds
with a SIP 200 OK to confirm activation.

d. Confirmation to User

1. Final Response:

o The S-CSCF relays the confirmation back to the user's device, indicating that call forwarding
has been successfully activated.

Applications of TAS

• VoLTE (Voice over LTE): TAS is essential for managing voice services over LTE networks, allowing
mobile operators to deliver high-definition voice services.

• Rich Communication Services (RCS): TAS helps facilitate RCS for delivering enhanced messaging,
file sharing, and video calls.

• VoWiFi (Voice over Wi-Fi): TAS is used in VoWiFi deployments, where it ensures seamless
handovers between LTE and Wi-Fi networks for voice services.

• Fixed-Mobile Convergence (FMC): TAS supports FMC solutions, allowing operators to deliver
services across both fixed-line and mobile networks.
VOLTE Call flow

1. The mobile subscriber indicates on their LTE-enabled smartphone the desire to

make a VoIP call.

2. LTE identifies a PDN Gateway (P-GW) that offers a connection to the IMS network.

3. LTE establishes a Default bearer for SIP from the subscriber to the selected P-GW.
The default EPS bearer is established with a QoS Class Identifier (QCI) value of 5
(the QCI value required for SIP signaling).

4. The smartphone sends a SIP “Invite” message toward the IMS network. Contained in
the SIP message is a Session Description Protocol (SDP) that carries the QoS
requirement.Note that although SIP messages are carried through the LTE network,
the LTE network is unaware of the
content of the message (nor the need for special QoS treatment at this stage).

5. The IMS network extracts the required QoS setting from the SIP message.

6. If a charging policy applies, then the IMS network sends an initial diameter Credit
Control Request (CCR) to the OCS over the Ro interface and an initial amount of
credit is reserved anticipating the need to precisely
meter flow data during the call.

7. The QoS requirement is sent from the IMS network through the Rx interface (using
the Diameter protocol) to the PCRF.

8. The PCRF creates actionable charging and QoS rules and forwards these across the
Gx interface to the Policy and Charging Enforcement (PCEF) that lives with the P-GW
in the LTE network.

9. The P-GW now sends a request to establish a separate “dedicated bearer” (with a
QCI value of 1) to the smartphone.

10. After the smartphone confirms that LTE can support the new dedicated bearer, it
sends a SIP “UPDATE” message to the IMS network.

11. The IMS network completes the setup process and establishes the call.

12. Bidirectional VoIP call packets flow inside the LTE network (to the P-GW) and
smartphone.

13. For charging, the IMS network requests credit from the OCS throughout the call
(e.g., every 10 seconds). If credit does not exist, a 402 (payment required) message
 is sent back to the smartphone and the call is
cancelled. If credits expire during the call, it is terminated.

14. When the call terminates, the smartphone sends a SIP “BYE” message to the IMS
network.

15. The IMS network sends a diameter CCR termination request to the OCS, which ends
the charging metering and triggers actions to collect IMS billing records.

16. The IMS network notifies the PCRF of call termination.

17. The PCRF tells the PCEF to close out the LTE billing, and instructs the P-GW to tear
down the dedicated bearer established for the VoIP call.

image984×772 83.7 KB
04. VoLTE SIP Call Flow – Mobile Originating (MO) & Terminating (MT)

Updated: Jun 7, 2020

Contents

VoLTE MO and MT Call Flow :- Covering VoLTE to VoLTE SIP IMS Call flow for Mobile
Originating & Mobile Terminating Calls . It Provides extract of 3GPP / GSMA Specs
simplified way

Originating Call Flow Sequence described in Video :-

1. SIP INVITE message : UE –> IMS

2. SIP 100 Trying : UE <– IMS

3. SIP 183 Progress SDP : UE <– IMS

4. SIP PRACK : UE –> IMS

5. SIP 200 OK PRACK : UE <– IMS

6. SIP UPDATE SDP : UE –> IMS

7. SIP 200 OK UPDATE : UE <– IMS

8. SIP 180 Ringing : UE <– IMS

9. SIP 200 OK INVITE : UE <– IMS

10. SIP ACK : UE –> IMS

Along with SIP Call flow , We will also cover Codec Negotiation in Detail in the End where
We will be covering AMR , AMR-WB & EVS Codec which supports both super-wideband and
full-band speech communication and provide crystal clear HD Voice

Download PPT ( pdf ) - Click here

VoLTE Call Flow – Introduction

This Video is all about SIP Signaling & Codec Negotiation happens in VoLTE where we will
go thru Complete Mobile Originating & Mobile Terminating call flow for VoLTE to VoLTE Calls
.

SIP stands for Session Initiation Protocol (SIP) , In a VoLTE call SIP protocol is used to
create, modify and terminate sessions, essentially negotiating a session between two
users. SIP does not perform transport layer (delivering data) those are done by RTP/RTCP .
SIP is a sequential protocol with request/response similar to HTTP both in functionality
and format

VoLTE Call Flow Steps Involved

This figure shows high Level steps involved in VoLTE Call . Prior to Ringing called Party User
, It is required to includes negotiation of Codecs & allocation of necessary resources . This
requires communication between End points to indicate whether local resources have
been allocated successfully under Precondition framework RFC 3312 . Both UE must
decide what type of Media they are going to exchange which can be Audio or Video or Any
IMS App .

Point 1 is Media Handshake ( which includes SDP Offer & Answer ) : SDP Stands
for session description protocol . This works on handshake of Media Bearers & Codes
Negotiation for HD Voice call between A Party & B Party . This SDP Message is carried inside
SIP Messages . This helps in Exchange of many critical & Important messages such as IP
Address , Bandwidth Required & Codecs supported by User . These parameters are
Negotiated on basis of SDP Offer & Answer mechanism used .. Both UE communicate with
each other via SDP Offer / Answer Model to Negotiate QOS & Codec Information

As shown in Point. No 2 … During , This Negotiation & Media Handshake , The Dedicated
Bearer needs to be established for this voice call on QCI=1 . This Dedicated bearer is used
to carry voice Payload & Interconnect user and LTE network for carrying voice Bits n Bytes .
This is done with help of Network Node PCRF which enables communication between IMS
& LTE Network to establish & tear down these Dedicated Bearers for Voice Calls between
User and LTE Network .
Only after satisfying QOS Pre-Conditions , Call can proceed with Ringing user as
mentioned in 3rd Step . This communication happens over SIP Protocol

As mentioned in 4th point , Once the called party picks the call , Both UE begin
exchanging Media Packets

Please Note : Media Packets may be sent directly and don’t traverse the same path as
signaling

Messages Exchanged in VoLTE Call flow

Here , I am going to cover brief overview of SIP Call flow just to give you High level Idea on
How SIP Works , We will cover same call flow again much detail in coming Slides

1. SIP INVITE : The VoLTE Calling (A) Party User initiates a Voice Call by sending SIP
INVITE request, This SIP Invite containing the SDP offer with IMS media
capabilities. The SDP offer shall contain the Required codec , Bandwidth details
etc.. Required for HD Call

2. 100 trying : The Receiving (B) Party Acknowledge SIP Invite by Sending 100 trying
 3. SIP 183 Progress : The terminating (B) party user will respond with an SDP answer in
a SIP 183 Progress message. This SDP answer should contain Codec supported and
indicates that preconditions are also desired but not met yet at the terminating
side . During this SDP 183 , Dedicated Bearers are created at both A Party & B Party
Side on LTE Networks . This is done with help of PCRF connecting both P-CSCF &
LTE Network

4. PRACK : The Originator (A) Party sends Provisional Response ACKnowledgement , It

is provisional acknowledgement. As name says, it is used to acknowledge SIP
provisional responses like 180 Ringing, 183 Session Progress etc.

5. 200 OK for PRACK : This PRACK is responded by Called (B) Party with 200 OK

6. SIP Update : Now, The Calling (A) Party reserves internal resources to reflect the SDP
answer and confirms resource reservation by sending a SIP UPDATE message with a
new SDP Offer. The offer contains the selected codec and information that the local
preconditions have been met at the originating (A) Party side and that the media
stream is now set to active.

7. 200 OK for Update : The 200 OK for the SIP UPDATE response with the SDP answer
contains in a Agreed voice codec and confirmation that the preconditions are met at
the terminating (B) Party side too and that the media stream is active

8. SIP 180 Ringing : The Called (B) Party can start to ring and replies back with SIP 180
Ringing response

9. 200 OK for INVITE : Now , Called (B) Party has answered the call , it responds with a
200 OK to the Calling (A) Party

10. ACK : Last ACK shows that the call has been established. The voice traffic goes over
the dedicated bearer to A Party IMS to B Party IMS to B Party to Called Party User via
dedicated LTE bearer of B Party

SIP Call Flow – SIP Invite

Here , We are again going to run thru Call flow & will try to cover Parameter level details
which will bring some more clarity

SIP Invite : The UE sends an INVITE request through the originating leg , This message
contains Request-URI with details of destination subscriber . This SIP Invite is sent using
with Route header that contains both the P-CSCF and S-CSCF addresses obtained during
registration . This SIP INVITE contains an SDP which is used for carrying & Negotiating
Media Information . Critical key information included in SIP Invite is :-

1. SDP offer

2. This contains IMS media capabilities (<media type><port><protocol>)

3. This contains Bandwidth Information Requested (AS (application specific) –

maximum RTP session bandwidth (kbytes))

4. Codec Supported information (<payload type><encoding name><clock

rate><encoding parameters>)

5. This SDP Offer Preconditions indicated resource reservation is required for the
originating network , but resources have not yet been reserved

6. Other important Information such as A Party Details – IMPU , IMPI

7. SIP Invite also contains information on B Party details such as tel-URI etc..
SIP Call Flow – 100 Trying

After receiving SIP-Invite , Every Hop in Network responds back with a 100 Trying
provisional response. The provisional response is a one-way response sent back to the
originating side used as generic Information . It is not necessarily guaranteed for its safe
arrival

SIP Call Flow – 183 Session in progress

183 Session in progress

 1. Till now , The Preconditions of call are not satisfied . Due to this B-Party UE can’t
begin to alert the user for incoming call & can’t send back 180 Ringing response ,
Instead it sends 183 Session Progress message also includes SDP Answer as
response to Original SIP Invite SDP Offer

2. The terminating UE locally allocates resources, generates the 183 Session In

Progress along with SDP answer and sends it back towards the originating UE. The
183 Session In Progress arrives the originating S-CSCF following the reverse path of
the SIP messages

3. The SDP Answer indicates support of relevant Codecs by Called Party subscriber
.This helps both Users to selects Common Code which are mutually supported by
both A Party and B Party User

Dedicated Bearer Creation on QCI=1

1. Dedicated bearers are now created on both Originating Side & Terminating Side

2. Upon receiving the 183 Session In Progress, the P-CSCF of respective Origination or
Terminating Party triggers the Authentication & Authorization request (AAR) towards
the PCRF to inform that there is new IPCAN Session required . This is done over Rx
Protocol connecting P-CSCF & PCRF

3. Upon receiving the AAR, the PCRF generates PCC rules which triggers SGW/PGW to
perform bearer creation on QCI=1 for Voice Calls . This is done over Gx interface
between PCRF & PGW

4. The PGW initiates the EPS bearer creation procedure and responds with the Re-
Auth-Answer (RAA) to the PCRF , Similarly PCRF reply back to P-CSCF with AAA
Message

5. Now , P-CSCF continues the SIP signaling by forwarding the 183 towards Originating
Party

SIP Call Flow – SIP PRACK , 200 OK PRACK

PRACK : PRACK is defined in RFC 3262 , This is used for Reliability of Provisional
Responses, i.e. A Party sends PRACK to acknowledge 183 Session Progress Message
received earlier . The PRACK request plays the same role as ACK, but for provisional
responses. To avoid Missing of these Provisional response such as 183 Session Progress ,
‘100rel’ extension is used during call setup which indicates called party to send provisional
response reliably and keep re-transmitting until PRACK message is received or timeout
happens

Also , A Party also uses this PRACK to communicate Final Selected Codec which is decided
for Voice Call via 2nd Offer

200 OK (PRACK) : With 200 OK , B Party Accepts Final selected Codec Offered by A Party in
PRACK Request . Now , Final Agreement on Codec to be used have been completed . Both
A & B Party Agree that Reservation of Resources are required but resources have not yet
been reserved With this , Codec Negotiation have been done by both Parties but Resource
reservation is still pending
SIP Call Flow – SIP UPDATE , 200 OK UPDATE

UPDATE

Now , Originator (A) Party user sends 3rd Offer Request to B party with Update Request
depicting Resource Reservation status . Here , Originator will perform critical Task of
Reserving resources & Will send Update request without changing rest of Parameters such
as Codec etc.. . Since Codec have been already Agreed between both Parties via PRACK
Message discussed Earlier , Same Selected Codec will be used in this Offer without Any
further changes .

200 OK (UPDATE)

With 200 OK , B Party also reserves resources & confirm back to Originator

SIP Call Flow – 180 Ringing , SIP 200 OK INVITE , SIP ACK
180 Ringing

The 180 Ringing provisional response is received by the UE. It indicates the voice call setup
request is being notified to the recipient. The Called (B) Party Started Ringing

SIP 200 OK (INVITE)

Now , Called (B) Party has answered the call , it responds with a 200 OK to the Calling (A)
Party . Upon receiving the message , The originator UE allocates the media resource

SIP ACK

The UE sends SIP ACK towards the terminating user as acknowledgment . Last ACK shows
that the call has been established. The voice traffic goes over the dedicated bearer to A
Party IMS to B Party IMS to B Party to Called Party

SIP Call Flow – Actual IMS Nodes – MO / MT Call Flow

This is only Pictorial diagram of Whatever we discussed this now , This represents actual
flow of Packets between various IMS Nodes

1. We can clearly see SIP Invite Going from Originator to A Party P-CSCF to S-CSCF ,
Every Node Provides back Acknowledgement back to Previous Node by 100 Trying
Message . This Cycle continues in B Party Network as well .

2. Calling Party SCSCF involves TAS to process the Outgoing call & to execute
originating service , Post this , S-CSCF tries to find out terminating subscriber
network. so it sends ENUM query for B party number and finds out details of B party
Network here

3. Now , Traffic get’s handed over to B Party Network where I-CSCF does Interrogation
with HSS & Finds appropriate B Party S-CSCF to be used . Here B Party S-CSCF
triggers TAS to Process Incoming Call & Execute Terminating Service

4. Here , TAS is involved in almost all transactions passing thru both A Party S-CSCF
and B Party S-CSCF , We are not showing same keeping away clutter from Screen

5. Finally , SIP Invite is forwarded to B Party I-CSCF to S-CSCF to P-CSCF & Finally to B
Party User

6. B Party User responds back with 183 Session in Progress to B party P-CSCF

7. Here P-CSCF creates Dedicated bearer on QCI=1 for Voice Call for B Party on LTE
Network with help of PCRF
8. P-CSCF forwards this 183 Session in Progress containing SDP Answer back to B
Party S-CSCF to I-CSCF & Ultimately its handed over back to A Party S-CSCF & P-
CSCF

9. Now , A Party P-CSCF also creates Dedicated Bearer for A Party user over LTE
Network using PCRF Node

10. Finally , This 183 Session in Progress is sent back to A Party User

1. The Originator (A) Party sends Provisional Response ACKnowledgement with PRACK
Message . Pls Note , For Simplicity .. We have removed LTE Networks & B Party I-
CSCF from this Slide as they are no more required for further processing of Signaling

2. This PRACK is responded by Called (B) Party with 200 OK

3. Now, The Calling (A) Party reserves internal resources to reflect the SDP answer and
confirms resource reservation by sending a SIP UPDATE message with a 3rd SDP
Offer

4. The 200 OK for the SIP UPDATE response with the SDP answer

5. The Called (B) Party can start to ring and replies back with SIP 180 Ringing response

6. Now , Called (B) Party has answered the call , it responds with a 200 OK to the
Calling (A) Party
 7. Last ACK shows that the call has been established. The voice traffic goes over the
dedicated bearers

Now , We have closed the Entire chain for VoLTE to VoLTE voice call . We will cover or last
section on Codec used in VoLTE moving ahead

SIP Call Flow – VoLTE Codecs

For many operators the HD voice quality was one of the market drivers for 4G . Let’s
understand , What is Codec & How VoLTE uses these codecs to offer HD Voice .

VoLTE uses RTP ( which is Real time transfer Protocol ) . This is widely used protocol for real
time communications such as Voice or Video . RTP ensures Reliable delivery . As far as
speech codecs are concerned, the basic Adaptive Multi Rate (AMR) speech codec is
mandatory; the popular data rate for good speech quality is 12.2 kbps . AMR is old codec &
in use since few Years now after 3G Era . RTP over UDP is used to transport AMR speech.

For AMR : The UE & IMS Network must support the AMR with all eight codec modes

By launching HD voice using AMR-WB (Adaptive Multi-Rate Wideband) the subscribers

could feel the Real difference . GSMA PRD IR.92 has also mandated AMR / AMR-WB codecs
to be used for VoLTE. These codecs have to be implemented by all equipment
manufactures to ensure a good voice quality as well as facilitating inter-operability
and avoiding transcoding.

For AMR-WB : The UE & IMS Network must support AMR-WB including all nine modes

Now , Last Comes the New Codec by Name of EVS which supports both super-wideband
and full-band speech communication . If the EVS codec is supported, These may be used
as an alternative implementation of AMR-WB . Although EVS May requires higher
bandwidth , But It ensures absolutely crystal clear voice Quality .

Please Note : All these Specs are Governed by 3GPP Specs .. I have shown 3GPP Website
link on screen where all required information is readily available with Specs Detail
1. What is GSM MAP?

GSM MAP (Mobile Application Part) is a signaling protocol defined by the 3rd Generation Partnership
Project (3GPP) as part of the SS7 (Signaling System No. 7) framework. It facilitates the exchange of signaling
messages between different network entities in a GSM network, enabling functionalities such as subscriber
management, call setup, SMS delivery, and mobility management.

Key Objectives of GSM MAP:

• Subscriber Management: Handle subscriber data, authentication, and authorization.

• Mobility Management: Manage subscriber location updates, handovers, and roaming.

• Call Control: Facilitate call setup, routing, and termination.

• Short Message Service (SMS): Enable the delivery and management of SMS messages.

• Billing and Charging: Support accurate billing by tracking usage and applying charging rules.

2. GSM MAP Architecture and Components

GSM MAP operates within the SS7 protocol stack and interacts with various network elements to perform its
functions. Below are the primary components involved:

a. Network Elements Utilizing MAP:

1. HLR (Home Location Register):

 o Role: Central database storing permanent subscriber information, including service
subscriptions, authentication data, and current location.

o Functions: Responds to queries about subscriber information, manages roaming data, and
handles authentication requests.

2. VLR (Visitor Location Register):

o Role: Temporary database storing subscriber information for users currently within a
particular MSC's (Mobile Switching Center) service area.

o Functions: Facilitates call routing, location updates, and manages temporary data during
subscriber presence in the area.

3. MSC (Mobile Switching Center):

o Role: Core network element responsible for call setup, routing, and termination.

o Functions: Connects calls between subscribers, interfaces with the PSTN (Public Switched
Telephone Network), and manages mobility.

4. SMSC (Short Message Service Center):

o Role: Manages the sending, receiving, and storage of SMS messages.

o Functions: Routes SMS messages between mobile devices and external networks or
applications.

5. GMSC (Gateway Mobile Switching Center):

o Role: Interfaces with external networks for call routing and SMS delivery.

o Functions: Routes calls and messages to/from the PSTN or other mobile networks.

b. MAP Protocol Layers:

GSM MAP operates at the Application Layer of the SS7 protocol stack. Below is a brief overview of the SS7
layers relevant to MAP:

1. Physical Layer: Defines the hardware and physical media used for SS7 signaling (e.g., fiber optics,
copper lines).

2. Data Link Layer (MTP3 - Message Transfer Part Level 3): Handles the routing and management of
signaling messages between SS7 nodes.

3. Network Layer (MTP2): Provides error correction and flow control for message transmission.

4. Application Layer (MAP): Implements the actual signaling procedures for GSM functionalities.

3. GSM MAP Protocol Functions

GSM MAP supports a wide range of functions essential for the operation of GSM networks. Below are some of
the primary functionalities facilitated by MAP:
a. Subscriber Management:

• Registration and Deregistration:

o Handles subscriber registration with the network, including updating location information.

• Authentication and Security:

o Facilitates the verification of subscriber identities and ensures secure access to network
services.

• Service Subscription Management:

o Manages the activation, modification, and deactivation of subscriber services.

b. Mobility Management:

• Location Updating:

o Tracks the current location of subscribers as they move across different MSC areas.

• Handover Management:

o Manages the seamless transfer of active calls/data sessions when a subscriber moves from
one cell to another.

• Roaming Management:

o Handles subscriber access to services while roaming outside their home network.

c. Call Control:

• Call Setup and Termination:

o Manages the initiation and ending of voice calls between subscribers.

• Call Routing:

o Determines the optimal path for call delivery based on subscriber location and network
topology.

d. Short Message Service (SMS):

• SMS Delivery:

o Manages the transmission of SMS messages between mobile devices and external
applications or networks.

• SMS Storage and Forwarding:

o Temporarily stores messages when recipients are unavailable and forwards them once
reachable.

e. Billing and Charging:

• Usage Tracking:
 o Monitors subscriber usage of services for accurate billing.

• Charging Information Exchange:

o Communicates charging data between network elements for processing and billing.

4. Key GSM MAP Messages and Procedures

GSM MAP defines various messages used to perform specific procedures within the GSM network. Below are
some of the essential MAP messages and their corresponding procedures:

a. Registration Procedure:

1. Update Location (ULR):

o Purpose: Sent by the MSC/VLR to the HLR to update the subscriber's current location.

o Message Flow: MSC/VLR → HLR

2. Update Location Answer (ULA):

o Purpose: Response from the HLR confirming the location update and providing necessary
subscriber information.

o Message Flow: HLR → MSC/VLR

b. Authentication Procedure:

1. Authentication Request (AUT_REQ):

o Purpose: Sent by the HLR to the subscriber to initiate authentication.

o Message Flow: HLR → Subscriber (via MSC/VLR)

2. Authentication Response (AUT_RES):

o Purpose: Subscriber's response to the authentication challenge, proving their identity.

o Message Flow: Subscriber → HLR (via MSC/VLR)

c. SMS Procedures:

1. Send Routing Information (SRI):

o Purpose: Sent by the SMSC to the HLR to obtain routing information for delivering an SMS to
a subscriber.

o Message Flow: SMSC → HLR

2. Send Routing Information Answer (SRA):

o Purpose: HLR responds with routing information, typically pointing to the subscriber's
current VLR.

o Message Flow: HLR → SMSC

d. Call Control Procedures:

1. Send Routing Information (SRI):

o Purpose: Similar to SMS, used to determine the routing for incoming calls.

o Message Flow: MSC → HLR

2. Send Routing Information Answer (SRA):

o Purpose: HLR provides the necessary routing information for the call.

o Message Flow: HLR → MSC

e. Service Control Procedures:

1. Provide Roaming Number (PRN):

o Purpose: Sent by the VLR to the HLR to request a temporary roaming number for a
subscriber.

o Message Flow: VLR → HLR

2. Provide Roaming Number Answer (PRNA):

o Purpose: HLR responds with the roaming number assigned to the subscriber.

o Message Flow: HLR → VLR

5. GSM MAP Call Flow Example

To illustrate the operation of GSM MAP, let's walk through a typical Voice Call Setup procedure involving a
subscriber moving into a new MSC area.

Scenario: Subscriber Roaming into a New MSC Area and Receiving a Call

Network Elements Involved:

• Subscriber (UE)

• New MSC/VLR (Visited Location Register)

• HLR (Home Location Register)

• Call Originating MSC/VLR

• GMSC (Gateway MSC)

• SMSC (Short Message Service Center)

Step-by-Step Call Flow:

1. Subscriber Roaming into New MSC Area:

o UE moves into the coverage area of a new MSC.

2. Registration Update:

o New MSC/VLR detects the presence of the UE and initiates a Location Update.

o MAP ULR (Update Location Request): New MSC/VLR → HLR

o MAP ULA (Update Location Answer): HLR → New MSC/VLR

3. Call Origination:

o A caller (Caller A) initiates a call to the roaming subscriber (Subscriber B).

o Caller A's MSC forwards the call to the GMSC for routing.

4. GMSC Call Routing:

o GMSC uses the MAP SRI (Send Routing Information Request) to the HLR to obtain the
current location of Subscriber B.

o MAP SRI: GMSC → HLR

o MAP SRA (Send Routing Information Answer): HLR → GMSC (providing the VLR address of
the new MSC)

5. Call Setup with New MSC/VLR:

o GMSC forwards the call to the New MSC/VLR based on the routing information received.

o New MSC/VLR initiates the Call Setup process towards Subscriber B.

6. Call Notification:

o Subscriber B's UE receives the incoming call notification (e.g., ringing).

7. Call Acceptance:

o Subscriber B answers the call.

o New MSC/VLR establishes the call path between Caller A and Subscriber B.

8. Voice Transmission:

o Voice data is transmitted between Caller A and Subscriber B via the established call path.

9. Call Termination:

o Either party terminates the call.

o MAP BYE (Call Termination Request): Initiated to release the call resources.
 6. GSM MAP Protocol Details

Understanding GSM MAP requires familiarity with its protocol stack, message types, and
procedures. Below are the essential details:

a. Protocol Stack:

GSM MAP operates within the SS7 protocol stack, specifically at the Application Layer.
Here's a brief overview:

lua

Copy code

+---------------------+

| Application Layer | <-- GSM MAP

+---------------------+

| Network Layer (MTP3)|

+---------------------+

| Data Link Layer (MTP2)|

+---------------------+

| Physical Layer |

+---------------------+

b. MAP Message Structure:

Each MAP message consists of the following components:

1. Message Type: Identifies the purpose of the message (e.g., ULR, ULA, SRI, SRA).

2. Transaction ID: Uniquely identifies the transaction to match requests with responses.

3. Parameters: Carry specific information required for the procedure (e.g., subscriber ID, routing
information).

c. Common MAP Procedures:

1. Location Management:

o Update Location (ULR/ULA): Updates the subscriber's current location in the HLR.

o Send Routing Information (SRI/SRA): Retrieves routing information for calls/SMS.

2. Authentication and Security:

 o Authentication Request/Response: Verifies subscriber identity.

o Reset Procedures: Handles signaling link resets and recovery.

3. Service Control:

o Call Forwarding, Call Barring, etc.: Manages supplementary services.

4. SMS Handling:

o SRI/SRA for SMS: Routes SMS messages to the correct SMSC.

7. GSM MAP in Modern Networks

While GSM MAP is integral to traditional GSM networks, its relevance extends to modern 3G,
4G, and even some 5G networks that maintain compatibility with GSM infrastructure.
However, with the evolution of network technologies, newer protocols like Diameter have
emerged, especially in LTE and IMS architectures, offering enhanced capabilities and
flexibility.

a. Transition to LTE and IMS:

• Diameter Protocol: Replaces some functionalities of MAP in LTE networks, providing more robust
AAA services and better support for IP-based communication.

• Integration with IMS: In LTE and IMS environments, MAP continues to support backward
compatibility with GSM-based services and subscribers.

b. VoLTE and MAP:

• VoLTE (Voice over LTE): Utilizes IMS for voice services, where Diameter handles AAA, while MAP
maintains interactions with GSM-based HLRs for subscriber data