VOLTE

Agenda

• IMS architecture
• Overview of SIP
• Overview of SDP
3GPP IMS Architecture
IMS Home Network – Functional elements
 IMS Core Functions
 IMS CSCF - Call Session Control Server:   The IMS CSCF is the section of the
architecture that provides the registration of the endpoints. It also provides routing
for the SIP signaling messages. It also links to the interworking and transport layer
to provide QoS. The IMS CSCF can be further split into further entities:

 Server CSCF: This element in the overall IMS CSCF is a session control entity for
endpoint devices and it maintains session state.

 Proxy CSCF: This part of the IMS CSCF is the entry point to IMS for devices. The P-
CSCF is the first point of contact for the UE and it forwards SIP messages to the
user's home S-CSCF. It provides device control interworking security. Within the P-
CSCF, the PCF or Policy Control Function provides QoS management.

 Interrogating CSCF: This entity within the IMS CSCF is a session control entity for
endpoint devices that maintains session state.
 IMS Core Functions
 Home Subscriber Server, HSS:   This is an important element within the IMS
architecture which provides the subscriber data base for the home network.

 Breakout gateway control function, BGCF:   This entity within the IMS
architecture selects the network in which a PSTN breakout is to occur. If this is to
occur in the same network as the BGCF, then the BGCF selects a media gateway
control function, MGCF

 Media gateway control function, MGCF:   This entity interworks the SIP signaling.
It manages the distribution of sessions across multiple media gateways.

 Media server function control, MSCF:   This manages the use of resources on
media servers.
 SIP applications server, SIP-AS:   The SIP-AS is a service execution platform on
which one or more services are deployed.
 IMS Registration - Proxy- CSCF Discovery
The P-CSCF is the entry point to the IMS domain and serves as the outbound proxy
server for the UE.

The UE attaches to the P-CSCF prior to performing IMS registrations and initiating SIP
sessions.

During LTE attach procedure, the network sends ACTIVATE DEFAULT EPS BEARER
CONTEXT REQUEST message for the IMS PDN to UE

From Protocol Configuration Option (PCO) parameters of ACTIVATE DEFAULT EPS

BEARER CONTEXT REQUEST message, UE obtains IP address of the P-CSCF

When UE is attached to eHRPD, UE obtains IP address of the P-CSCF from PCO field of
the VSNCP-Config-Response message for the IMS PDN provided by the network  

 UE obtains at least three P-CSCF IP addresses

The IMS SIP port number is configurable parameter at UE. Its default value is of 5060
 IMS Registration Overview
Device performs IMS registration with the Proxy-CSCF and S-CSCF.

e
IMS Registration flow
SIP Timers for IMS
 EPS Bearer
 EPS Bearer Types:
• A Default EPS Bearer is always non-GBR
• A Dedicated EPS Bearer can be GBR on non-GBR
 QoS Class Identifier (QCI): Used as a reference to Access Node specific parameters that control how bearer
level packets are forwarded, are pre-configured by the operator. Every QCI (GBR or non-GBR) is associated
with a Priority Level.
 The GBR indicates the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit
rate that can be expected to be provided by a GBR bearer. Rel8 requires MBR=GBR. MBR and GBR can be
coded as high as 256 Mbps.
 Overview of SIP
• SIP is an application layer protocol that is used to establish, maintain, modify and end communications
sessions between two or more parties .
• SIP is a signaling protocol for IP-based networks that can support the standard call processing functions
found in the PSTN. The SIP protocol itself does not define these features, but enables their creation in
network elements, such as proxy servers and user agents.
• SIP-based clients (devices) use TCP or UDP or SCTP protocols to connect to SIP servers
• Key advantages of SIP protocol:
– Intelligence at the Edge: It is a peer-to-peer protocol with a blend of intelligence located at the edge (i.e., soft phone
or end-user device hardware), complimented by more scalable, granular, and rapidly deployed services offered by
service providers

– Flexibility: In IP suite, SIP is flexible and extraordinarily dynamic. Its functionality can be extended to any number of
applications, including enhanced signaling for value-added services, VoIP, and XML-tagged applications

– Supports any Network Transport Medium: SIP is designed to be completely independent of the transport layer., It
can use seamlessly across any transport scheme (TCP, UDP or SCTP) and be transported across any access modality
— cable, DSL, WiFi, Ethernet, and wireless. Thus, SIP can enable a broad range of applications and remote session
capabilities

– Mobility and Presence Support: Using SIP session establishment requests are sent to the network, which locates
the user’s “presence” and establishes a session based on the user’s current location and usage profile
 SIP Requests & Responses
• SIP message is either a request or response
• The following table includes, but not limited to, SIP messages used in
Verizon IMS-VoLTE network

g
Requests
Requests contd…
Requests contd…
Requests contd…
Requests contd…
Responses
Responses contd…
Request vs. Response
 REGISTER Header
REGISTER sip:vzims.com SIP/2.0

Route:sip:192.168.43.166:5060;lr>

P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-

3gpp=31148000000000002 Network type Access –Info Computed value
 REGISTER Header contd...
Expires: 3600
• Contact Header if device registered with IMS while on LTE or WiFi
Contact: <sip:[email protected]:5060>;+g.3gpp.icsi-ref="urn:urn-7:3gpp-
service.ims.icsi.mmtel"; +sip.instance=<device_IMEI>;+g.gsma.rcs.telephony="cs,volte"; video

• Contact Header if device registered with eHRPD

Contact: <sip:[email protected]:5060>; +sip.instance=<device_IMEI>
IMEI -> International Mobile Equipment Identity
 REGISTER Header contd...
Authorization: Digest username=“+12244004278”, realm="vzims.com", uri=“sip: vzims.com”,
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432“

From: <sip:[email protected]>;tag=4fa3560890
To: sip:[email protected]
 REGISTER Header contd...
CSeq: 1 REGISTER
CSeq or Command Sequence contains an integer and a method name. The CSeq
number is incremented for each new request within a dialog

Max-Forwards: 70
Max-Forwards serves to limit the number of hops a request can make on the way to its
destination. It consists of an integer that is decremented by one at each hop

Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP

The Via header field indicates the transport used for the transaction and identifies the
location where the response is to be sent. Here transport is UDP. Branch ID is unique
ID which identifies the transaction created by user.

Content-Length: 0
Length of the body. Register will not have message body.
 200 OK (REGISTER)
SIP/2.0 200 OK
From: <sip:[email protected]>;tag=4fa3560890
To: <sip:[email protected]>; tag = 32299af7845

Tag is added here in To Field

Call-ID: apb03a0s09dkjdfglkj49111
P-Associated-URI:<sip:[email protected]>
P-Associated-URI:tel:+15551234567
Registrar returns a set of associated URIs in P-Associated –URI header for a registered
address-of-record. Here SIP URI and TEL URI are returned

Max-Forwards: 70

Contact: <sip:[email protected]:5060>;+g.3gpp.icsi-ref; expires=1800

CSeq: 1 REGISTER

Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP

Content-Length: 0
 INVITE Header
INVITE tel:1234512345;phone-context=vzims.com SIP/2.0
tel:1234512345 -> tel URI (Mobile Directory Number (MDN) , vzims.com->Domain Name
Supported: 100rel, timer
Option tag “100rel” -> Endpoint supports PRACK. Option tag “timer” -> request other end to use
session timer

Allowed:
INVITE,ACK,PRACK,SUBSCRIBE,NOTIFY,CANCEL,INFO,BYE,UPDATE,REFER,MESSAGE,OPTIONS
List of Methods allowed at Device
P-Preferred-Identity: <sip:[email protected]>
Device sets its preferred identity out of multiple valid identities it has. Here it is its SIP
URI
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31148000000000002

Contact: <sip:[email protected]:5060>;+g.3gpp.icsi-ref="urn:urn-7:3gpp-
service.ims.icsi.mmtel"; +sip.instance=<device_IMEI>;+g.gsma.rcs.telephony="cs,volte"; video
Note: If Video calling is enabled
 INVITE Header contd...
Accept-Contact: * ;+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel“
The Accept-Contact header field allows the caller to specify that callee should be contacted if it
matches some or all of the values of the header field. Here, user has not specified any preferred
contact amongst contacts of the callee

User-Agent: SP VOIP IMS 2.0

In this Header, UAC reveals the specific software version it uses

Session Expires: 300

Route:<sip:192.168.43.166:5060;lr>
To:< tel:1234512345>
From: sip:[email protected]; tag= 3456efa74510
Call-ID: apb03a0s09dkjd546789
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP
Content-Type: Application/sdp
Content-Length: 370
 Overview of SDP
• SIP incorporates the use of a Session Description Protocol (SDP)
• SDP defines session content using a set of types similar to those used in
Multipurpose Internet Mail Extensions (MIME)
• SDP is intended for describing multimedia communication sessions for the
purposes of session announcement, session invitation, and parameter
negotiation to the participants
• SDP does not deliver media itself but is used for negotiation between end
points of media type, format, and all associated properties.
• The set of properties and parameters are often called a session profile.
• SDP is designed to be extensible to support new media types and formats
• An SDP session description includes the following:
 Session name and purpose
 Time(s) the session is active
 The media comprising the session
 Information needed to receive those media (addresses, ports, formats, etc.)
 SDP Offer & Answer
• SDP provides Offer & Answer model for media negotiation
• In this model, one participant in the session generates an SDP
message that constitutes offer – describing media types, codecs, IP
addresses, ports etc. to receive the media. This participant is
called Offerer.
• The offer is conveyed to the other participant, called the Answerer.
• The Answerer generates an answer, which is an SDP message that
responds to the offer provided by the Offerer.
• The answer has a matching media stream for each stream in the
offer, indicating whether the stream is accepted or not, along with
the codecs that will be used and the IP addresses and ports that
the Answerer wants to use to receive media
SDP Offer & Answer
 INVITE Message-Body (SDP)
• Session description

v= 0 [ protocol version, It is always 0]

o= SAMSUNG-IMS-UE 2987933615 2987933615 IN IP4 192.168.43.144

[<Originator/username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Session –id : globally unique identifier for the session. Normally, Network Time Protocol (NTP) format
timestamp is used to ensure uniqueness
Session-version: version number for this session description. It is incremented when this session data is
modified. Normally, Network Time Protocol (NTP) format timestamp is used]

s= Video [session name; it should not be empty]

i= A VT Session [session information/description]

c= IN IP4 192.168.43.144 [connection information]

 INVITE Message-Body (SDP)
• Time Description
t= 0 0
[specify the start and stop times for a session. Here start time =0 and stop time=0. If the <stop-time> is set to zero, then
the session is not bounded. If the <start-time> is also zero, the session is regarded as permanent]

• Media Description

m=audio 49120 RTP/AVP 104 110 102 108 105 100

[<Media type> <Media Port> < Media Protocol> < Media format List>

a=rtpmap:104 AMR-WB/16000
[ <rtpmap: payload type> <encoding name>/<clock rate>]
[‘a’ stands for media attributes. It maps from an RTP payload type number. AMR-WB has 9 variations in rate. Here,
Media format is Dynamic RTP Type-104 which has 12. 65kbps frame content and band efficient mode. Clock rate is
audio sampling rate. Here it is 16KHz]

a=fmtp:104 mode-set=2
[fmtp:<format> <format specific parameters>]
[Mode-set =2 means frame content has 12.65kbps]
 INVITE Message-Body (SDP)
• Media Description
a=rtpmap:110 AMR-WB/16000/1
[Here, Media format is Dynamic RTP Type-110 which has 12.65kbps frame content but octet-align mode. ]

a=fmtp:110; mode-set=2;Octet-align =1
[Mode-set =2 means frame content has 12.65kbps]

a=rtpmap:102 AMR/8000
[AMR has 8 variations in rate .Here, Media format is Dynamic RTP Type-102 which has 12. 2kbps frame content and
band efficient mode]

a=fmtp:102 mode-set=7
[Mode-set =7 means frame content has 12.65kbps]

a=rtpmap:108 AMR/8000/1
[Here, Media format is Dynamic RTP Type-108 which has 12. 2kbps frame content but band octet-align mode]

a=fmtp:108 mode-set=7; octet-align=1

 INVITE Message-Body (SDP)
• Media Description
a=rtpmap:105 telephone-event/16000
[Here, Media format is Dynamic RTP Type-105 for telephone events, clock rate 16KHz ]

a=fmtp:105 0-15
[ Telephone event range from 0 to 15 (0-9,*,#,A,B,C,D)]

a=rtpmap:100 telephone-event/8000
[Here, Media format is Dynamic RTP Type-100 for telephone events, clock rate 8KHz ]

a=fmtp:100 0-15

a=ptime:20
[Packetization time 20 sec]

a=maxptime:240
[Max. Packetization time 240 sec -> 7 packets]
a=sendrecv
[Both Send and receive media packets]
 INVITE Message-Body (SDP)
• Media Description
m=video 49121 RTP/AVP 117 34
[Here, Media format for video is Dynamic RTP Type-117 and 34]

a=rtpmap:117 H264/90000

a=fmtp:117 profile-level-id=428016

a=framerate:15

a=rtpmap:34 H263/90000

a=fmtp:34 profile=0

a=framerate:7

a=sendrecv
 SDP Offer-1
m=audio 49120 RTP/AVP 102 108 100
a=rtpmap:102 AMR/8000
a=fmtp:102 mode-set=7
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; octet-align=1
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
 SDP Answer -1

m=audio 49120 RTP/AVP 102 100

a=rtpmap:102 AMR/8000
a=fmtp:102 mode-set=7
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
 SDP Offer-2
m=audio 49120 RTP/AVP 104 110 102 108 105 100
a=rtpmap:104 AMR-WB/16000
a=fmtp:104 mode-set=2
a=rtpmap:110 AMR-WB/16000
a=fmtp:110 mode-set=2; octet-align=1
a=rtpmap:102 AMR/8000
a=fmtp:102 mode-set=7
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; octet-align=1
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
 SDP Answer-2

m=audio 49120 RTP/AVP 104 105

a=rtpmap:104 AMR-WB/16000
a=fmtp:104 mode-set=2
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
 Speech Codec & QoS
The UE shall support the speech codec:
• AMR ( all eight modes): 4.75 kbps ,5.15 kbps, 5.9 kbps, 6.7 kbps, 7.4 kbps,
7.95 kbps, 10.2 kbps, 12.2 kbps( Mode Set =7)

• AMR-WB ( all nine modes): 6.6 kbps, 8.85 kbps, 12.65( Mode Set =2) kbps,
14.25 kbps, 15.85 kbps, 18.25 kbps, 19.85 kbps, 23.05 kbps, 23.85 kbps.

Verizon specific Note: UE support all modes of AMR and AMR-WB.

Default modes : AMR 12.2Kbps, AMR-WB 12.65Kbps
 AMR –WB Band efficient Payload

 Payload Header : CMR( 4 bits )

CMR:
 Indicates a codec mode request sent to the speech encoder at the site of the receiver of this
payload.
 Code mode request field set to the frame type index of the corresponding speech mode
being requested.
 AMR –WB Band efficient Payload
Table of content: F (1 bit) + Frame Type (4 bits) + Q ( 1 bit)
F (1 bit):
• If set to 1, -> indicates that this frame is followed by another speech
frame in this payload;
• if set to 0, -> indicates that this frame is the last frame in this payload.

FT (4 bits):
• indicates either the AMR or AMR-WB speech coding mode or comfort
noise (SID) mode of the corresponding frame carried in this payload.

Q (1 bit ): Frame quality indicator.

• If set to 0, -> indicates the corresponding frame is severely damaged .
• if set to 1 -> indicates the corresponding frame is OK.
 Types of Payload format
Octet-aligned Mode :
• All the fields in a RTP payload (payload header + table of
contents entries + speech frames ) are individually
aligned to octet boundaries.
• Octet alignment means last octet is padded with zeroes
in the LSB(least significant bits) to fill the octet.

Bandwidth Efficient :
• In the bandwidth efficient format only the full payload is
octet aligned, so fewer padding bits are added and
makes efficient.
 Example of AMR-WB Band efficient Payload
Single Channel Payload Carrying a Single Frame :
f1 58 4e 04 2e ef bb bc bc 17 b8 e3 d6 4f e8 99 02 23 63 f7 7a 20 63 80 38 00 10 e7 6a
09 11 b6 3e
Payload is 33 Bytes.
Take first two bytes : i.e., f1 58

F=0
Last frame in this payload
 Setting up Conference Call
• AT1 calls AT2 and then places this call on hold.
• AT1 calls AT3 and places this call on hold.
• AT1 then generates a SIP INVITE using the conference server URI which is routed to
the Telephony Application Server (TAS).
• The TAS sets up a voice media path between AT1 and the MRF (which provides the
audio bridging function).
• To request AT2 to join the conference call, AT1 sends SIP REFER to conference
server URI with Refer-To header indicating AT2,
• TAS responds with SIP 202 Accepted, which creates an implicit subscription with
Event "refer".
• AT1 gets a SIP NOTIFY indicating "100 Trying" in the message body.
3-way conferencing with Subsequent Drop and Add
 Setting up Conference Call Continued…
• After AT2 accepts the SIP INVITE from TAS to join the
conference call, AT1 gets a SIP NOTIFY indicating "200 OK" in
the message body.
• AT1 can now send SIP BYE on the original dialog between AT1
and AT2
• Same process is followed to Add AT3
• After AT3 also successfully joins the conference call, there is a
3-way call between AT1, AT2 and AT3 (through the MRF,
providing the audio bridging function).
Continues…
 Adding Participant in Call
• AT1 puts the call with TAS on hold.
• Call AT4
• Use SIP REFER Message to conf. server URI to request AT4.
• SIP 202 Accepted from TAS
• AT1 joins back TAS
• AT4 joins the conference call
Continues… Adding AT4 now
 SUBSCRIBE Header
SUBSCRIBE sip:[email protected]; SIP/2.0
Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP
Accept: application/pidf+xml, application/rlmi+xml, multipart/related
Max-forwards: 70
Contact: <sip:[email protected];5060>
Route:<sip:192.168.43.166:5060;lr>
To: <sip:[email protected]>
From: <sip:[email protected]>; tag = 3456efa74510
Call-ID: 200737754d
CSeq: 1 SUBSCRIBE
Expires: 1200
Supported: eventlist
Require: recipient-list-subscribe
Accept-Encoding:gzip
Event: presence
Content-Type: application/resource-list+xml
Content-Length: 1277
 SUBSCRIBE Body
<?xml version="1.0" encoding="UTF-8" ?>
<resource-lists
xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="dummy-rfc5367">
<entry uri="tel:+16175551212 "/>
<entry uri="tel:+17815551212 "/>
<entry uri="tel:+19175551212 "/>
<entry uri="tel:+12125551212 "/>
</list>
</resource-lists>
 SUBSCRIBE (Availability fetch)
SUBSCRIBE sip:[email protected]; SIP/2.0
Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP
Accept: application/pidf+xml
Max-forwards: 70
Contact: <sip:[email protected];5060>
Route:<sip:192.168.43.166:5060;lr>
To: < sip:[email protected]>
From: <sip:[email protected]>; tag = 3456efa74510
Call-ID: 200737754d
CSeq: 1 SUBSCRIBE
Expires: 0
Event: presence
Content-Length: 0
 NOTIFY Header
NOTIFY sip:[email protected]; SIP/2.0
Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDP
Max-forwards: 70
Contact: <sip:[email protected];5060>
To: <sip:[email protected]>; tag=234ab45230
From: <sip:[email protected]>; tag = 3456efa74510
Call-ID: 200737754d
CSeq: 1 NOTIFY
Expires: 600
Event: presence
Subscription-State: active
Content-Type: application/rlmi+xml,application/pidf+xml
Content-Length: 1277
 NOTIFY Body
<list xmlns="urn:ietf:params:xml:ns:rlmi"  rlmi+xml part starts
uri="sip:+1234567890@@vzims.com;pres-list=dummy-rfc5367" version="0"
fullState="true">
<name>dummy-rfc5367</name>
<resource uri="tel:+16175551212 ">
<instance id="001" state="active" reason="subscribe"
cid="[email protected]_1312926684451"/>/>
</resource>
<resource uri="tel:+17815551212 ">
<instance id="001" state="active" reason="subscribe" cid="tel17815551212
_1312926684452"/>
</resource>
<resource uri="tel:+12244004301 "/> Both resources have not published
<resource uri="tel:+19175551212 "/>  rlmi+xml part ends
</list>
 NOTIFY Body
--nxbound1312926427801\r\n
Content-ID:<tel:+16175551212_1312926684451>  1st resource/Content Id
Content-Type:application/pidf+xml; charset=utf-8
Content-Transfer-Encoding:binary
 <?xml version="1.0" encoding="UTF-8"?>
<presence entity=" sip:[email protected] " xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:b="urn:ietf:params:xml:ns:pidf:caps" xmlns:op="urn:oma:xml:prs:pidf:oma-pres">
<tuple id="354edt4fe">  1st tuple starts
<status><basic>open</basic> </status>
<op:service-description>
<op:service-id>
org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcse.dp
</op:service-id>
<op:version>1.0</op:version>
<op:description> VoLTE Capabilities Discovery </op:description>
</op:service-description>
<contact>sip:[email protected]</contact>
</tuple>  1st tuple ends
 NOTIFY Body
<tuple id="t4fe354ed">  2nd tuple starts
<status> <basic>open</basic></status>
<op:service-description>
<op:service-id> org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel </op:service-id>
<op:version>1.0</op:version>
<op:description> VoLTE and Video Service</op:description>
</op:service-description>
<b:servcaps>
<b:audio>true</b:audio>
<b:video>true</b:video>
<b:duplex> <b:supported> <b:full/></b:supported></b:duplex>
</b:servcaps>
<contact>sip:[email protected]</contact>
</tuple>  2nd tuple ends
</presence>
--nxbound1312926427801

Pidf +xml part of cid “tel17815551212 _1312926684452”will be similar to above

Different scenarios of device subscription state in
NOTIFY message