VOLTE

VOLTE
Agenda
VOLTE Introduction
IMS architecture
Overview of SIP
Overview of SDP
Introduction on RCS
Capability discovery
Enhanced address book
Advantages of VOLTE
Provide faster call setup time

Enhance voice quality with wideband codec
Enable simultaneous voice and LTE data
Provide evolution from voice to rich next
generation IMS services like video calling, file
transfer, instant messaging with QoS support
Migrate from dual radio CDMA + LTE devices to
LTE only devices
Take benefit of low band LTE for extended
coverage
Improve spectral efficiency
Prepare evolution to LTE only deployments
Mandatory features for Supporting VoLTE

From the UEs point of view there are
4 requirements from Network to
support VoLTE.
Semi-Persistent Scheduling (SPS)
Transmission Time Interval (TTI)
Bundling
Discontinuous Reception (DRX)
Robust Header Compression
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 domainand serves as theoutbound
proxy server for theUE.
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 SCSCF.
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 users presence and establishes a session based on the users 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
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-id3gpp=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:+12244004278@192.168.43.144:5060>;+g.3gpp.icsiref="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:+12244004278@192.168.43.144:5060>;
+sip.instance=<device_IMEI>
IMEI -> International Mobile Equipment Identity

Authorization: Digest username=+12244004278, realm="vzims.com",
uri=sip: vzims.com,
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432
From: <sip:+12244004278@vzims.com>;tag=4fa3560890
To: sip:+122440042787@vzims.com

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
200 OK (REGISTER)
SIP/2.0 200 OK
From: <sip:+15551234567@vzims.com>;tag=4fa3560890
To: <sip:+15551234567@vzims.com >; tag = 32299af7845
Tag is added here in To Field

Call-ID: apb03a0s09dkjdfglkj49111
P-Associated-URI:<sip:+15551234567@vzims.com>
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:+15551234567@192.168.43.144: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:+1234567890@vzims.com>
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:+1234567890@192.168.43.144:5060>;+g.3gpp.icsi-ref="urn:urn-7:3gppservice.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:+1234567890@vzims.com; tag= 3456efa74510
Call-ID: apb03a0s09dkjd546789
CSeq: 1 INVITE
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 describingmultimedia 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
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

192.168.43.144
IN
IP4
[<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]

Time Description
t= 0 0
[specify the start and stop times for a session. Here start time =0 and stop time=0. If the <stoptime> 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
[<Media type> <Media Port>
a=rtpmap:104
RTP/AVP
104 110 102 108 105 100
< Media Protocol> < Media format List>
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]

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
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=rtpmap:108 AMR/8000/1
[Here, Media format is Dynamic RTP Type-108 which has 12. 2kbps frame content but band octetalign mode]
a=fmtp:108 mode-set=7; octet-align=1

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]

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=fmtp:100 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
SDP Answer -1
m=audio 49120 RTP/AVP 102 100
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:105 0-15
a=fmtp:100 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
SDP Answer-2
m=audio 49120 RTP/AVP 104 105
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
PUBLISH Header
PUBLISH sip:+1234567890@vzims.com; SIP/2.0
Accept: application/pidf+xml, application/rlmi+xml, multipart/related
Max-forwards: 70
Contact: <sip:+1234567890@vzims.com;5060>
Route:<sip:192.168.43.166:5060;lr>
To: <sip:+1234567890@vzims.com>
From: <sip:+1234567890@vzims.com>; tag = 3456efa74510
Call-ID: 200737754d
CSeq: 1 PUBLISH
Expires: 1200
Event: presence
Content-Type: application/pidf+xml
Content-Length: 1277
PUBLISH Body
<?xml version="1.0" encoding="UTF-8" ?>
XML format
<presence Presence info part starts from here

entity=sip:+1234567890@vzims.com
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:+1234567890@vzims.com</contact>
</tuple>
1st tuple ends
PUBLISH Body
<tuple id="t4fe357ba"> 2nd tuple starts
<status>
<basic>open</basic>
</status>
<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>
<b:servcaps>
<b:audio>true</b:audio>
<b:video>true</b:video>
<b:duplex>
<b:supported> <b:full/> </b:supported>
</b:duplex>
</b:servcaps>
</tuple>
2nd tuple ends
</presence>
200 OK (PUBLISH Response)

Presence server sends the ETag in the 200 OK
response
The device should use the ETag in order refresh
the event state
SIP/2.0 200 OK
From: <sip:+1234567890@vzims.com>
CSeq: 1 PUBLISH
SIP-ETag: dx200xyz
Expires: 1200
PUBLISH (Republish) Header

Device should send periodically PUBLISH message provided
Etag is not expired
Via: SIP/2.0/UDP
CSeq: 1 PUBLISH
SIP-If-Match: dx200xyz
Expires: 1200
Event: presence
Content-Length: 0
The body of the republish is blank.
PUBLISH (Update) Header

Device should send Publish message to Presence server
for updating if there is a change in its capabilities and
availability and previous Etag is not expired
CSeq: 1 PUBLISH
Expires: 1200
Event: presence
Content-Length:
The body of the update PUBLISH message is similar to that shown for initial PUBLISH
message, varying according to the actual capabilities and availability at that time.
PUBLISH (Unpublish) Header

Device should send Publish message to Presence
server for unpublishing its presence at device
shutdown and airplane mode ON
CSeq: 1 PUBLISH
Expires: 0
Event: presence
Content-Length: 0
The body of the unpublish is blank
Different scenarios of device capabilities &

availabilities
SUBSCRIBE Header
SUBSCRIBE sip:+1234567890@vzims.com; SIP/2.0
Accept: application/pidf+xml, application/rlmi+xml, multipart/related
Max-forwards: 70
Route:<sip:192.168.43.166:5060;lr>
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
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/XMLSchemainstance">
<list name="dummy-rfc5367">
<entry uri="tel:+16175551212 "/>
<entry uri="tel:+17815551212 "/>
<entry uri="tel:+19175551212 "/>
<entry uri="tel:+12125551212 "/>
</list>
</resource-lists>
NOTIFY Header
NOTIFY sip:+1234567890@vzims.com ; SIP/2.0
Via: SIP/2.0/UDP
Max-forwards: 70
Contact: <sip:presenceserver@vzims.com;5060>
To: <sip:+1234567890@vzims.com >; tag=234ab45230
Call-ID: 200737754d
CSeq: 1 NOTIFY
Expires: 600
Event: presence
Subscription-State: active
Content-Type: application/rlmi+xml,application/pidf+xml
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="tel16175551212@vzims.com_1312926684451"/>/>
</resource>
<resource uri="tel:+17815551212 ">
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:+16175551212@vzims.com "
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-id>
org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcse.dp
</op:service-id>
<op:description> VoLTE Capabilities Discovery </op:description>
</tuple>
1st tuple ends
NOTIFY Body
<tuple id="t4fe354ed"> 2nd tuple starts
<status> <basic>open</basic></status>
<op:service-id> org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel </op:service-id>
<op:description> VoLTE and Video Service</op:description>
<b:servcaps>
<b:duplex> <b:supported> <b:full/></b:supported></b:duplex>
</b:servcaps>
</tuple>
2nd tuple ends
</presence>
--nxbound1312926427801
Pidf +xml part of cid tel17815551212 _1312926684452will be similar to
above
Different scenarios of device subscription

state in NOTIFY message
SUBSCRIBE (Availability fetch)

SUBSCRIBE sip:+11111111111@vzims.com; SIP/2.0
Via: SIP/2.0/UDP
Accept: application/pidf+xml
Max-forwards: 70
Route:<sip:192.168.43.166:5060;lr>
To: < sip:+11111111111@vzims.com>
Call-ID: 200737754d
CSeq: 1 SUBSCRIBE
Expires: 0
Event: presence
Content-Length: 0
Introduction on RCS
RCS Versions
RCS-e ( RCS Enhanced)
Initial implementation for advanced communication
services
Based on GSMA RCS Release 2 spec.
RCS 5.1
Provides a framework for discoverable and interoperable
advanced communication services
Based on GSMA RCS Release 1 to 4, RCS-e 1.2 and RCS 5.0
Joyn BlackBird
RCS marketed by the GSMA under the brand name joyn
Based on RCS 5.1
RCS Features Summary
RCS Features Summary
CAPABILITY DISCOVERY
Capability Discovery is a process

It enables users to understand the subset of RCS services
available with their contacts
User needs this information at certain points of time to
access/communicate its contact
RCS 5.1 provides two alternative mechanisms to perform the
capability discovery:
SIP OPTIONS
PRESENCE ( VZW requirements follow this procedure)
OPTIONS Vs. PRESENCE

REGISTER
REGISTER
OPTIONS to all contacts
SUBSCRIBE to all contacts
STANDARD REGISTRATION (Rest of registration scenarios)

REGISTER
REGISTER
PUBLISH (capabilities)
ADDING/MODIFYING A CONTACT
OPTIONS to new/modified
contact
SUBSCRIBE to new/modified
contact
PERIODIC CAPABILITY POLLING (Polling period >0)

SUBSCRIBE to all contacts
OPTIONS to all contacts
whose capabilities have
whose capabilities have
not been recently
not been recently updated
updated
LIVE CAPABILITY/SERVICE DISCOVERY
OPTIONS (contact)
SUBSCRIBE (contact)
LIVE CAPABILITY/SERVICE UPDATE

OPTIONS (contact)
PUBLISH (capabilities)
Enhanced Address Book (EAB)

Overview
EAB is a feature provided by Address Book Application

It has two functions
Presence Publication
Presence Info Retrieval
Device publishes its own capabilities and availability
Capabilities include but not limited to HD voice and video calling
Required for other devices to retrieve
Performed by Presence User Agent (PUA) of Address Book
Application
Presence Info Retrieval (Presence Discovery)

Discovery of other devices capabilities associated with a contact
Discovery of other devices availability associated with a contact
Performed by Presence Watcher of Address Book Application
Presence Publication achieved by using SIP PUBLISH method
Different contexts of PUBLISH
Full initial publish
Periodic or scheduled or refresh publish
Update publish
Un-publish
Full initial publish

First time presence object instance of UE is created at presence server
Periodic or scheduled or refresh publish

Device sends publish message to presence server periodically to
refresh its capabilities and availability
The period is controlled by PST parameter PUBLISH-TIMER or PUBLISHTIMER-EXTENDED
Default value of PUBLISH-TIMER=1200s (20 minutes) and PUBLISHTIMER-EXTENDED= 86400s (1 day)
Update publish
Device updated its capabilities and
availability as and when its capabilities
and availability status changes
Un-publish
Device requests presence server to
remove its capabilities and availability
Presence server destroys presence
object instance for the device
PUPLISH Request
SIP PUPLISH Header (Initial publish)
SIP PUPLISH Body PIDF + XML

<presence xmlns="urn:ietf:params:xml:ns:pidf" " entity="sip:
+11234567890@test.3gpp.com">
<tuple id="disc415192695">
<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:description> VoLTE Capabilities Discovery </op:description>
</op:service-description> <contact>sip:+11234567890@test.3gpp.com</contact>
</tuple>
<tuple id="caps415192696">
<status> <basic> open </basic> </status> <caps:servcaps>
<caps:audio>true</caps:audio>
<caps:video>true</caps:video>
<caps:duplex> <caps:supported> <caps:full/>
</caps:supported> </caps:duplex> </caps:servcaps>
<op:description> VoLTE service </op:description>
</op:service-description> <contact>sip:+11234567890@test.3gpp.com</contact>
</tuple>
</presence>
SIP 200 OK (PUBLISH)

SIP/2.0 200 OK
Via: SIP/2.0/TCP
[2600:2:5:6:3:2:206:1356]:5060;branch=z9hG4bK974669
16smg;transport=TCP
From: <sip:
+11234567890@test.3gpp.com>;tag=1737480301
To: <sip:
+11234567890@test.3gpp.com>;tag=4614552585
Call-ID: 2065482978@2600:2:5:6:3:2:206:1356
SIP-ETag: 13461603
CSeq: 1 PUBLISH
Expires: 1200
Content-Length: 0
Difference Between Various Publish Types
Presence Info Retrieval

Presence Info Retrieval achieved through SIP
SUBSCRIBE method
Two types of presence info retrieval or discovery
Capability polling
Availability fetch
Capability polling
For existing contact(s) or new contact(s)
For existing contact(s), it is periodic or scheduled or refresh
capability polling
For new contact(s), it is instantaneous capability polling
Resource-list subscription (multiple contacts or contact with
multiple numbers)
Single resource subscription (single contact with 1 number)
Capability Polling/Availability Fetch
Capability polling triggered if

Device registered with IMS successfully
Last PUBLISH is successful
Device having at least 1 contact number
When first time device activated
Periodic capability polling
Controlled by PST parameter CAPABILITY-POLL-INTERVAL
Default value 604800s ( 7 days)
Instantaneous capability polling
New contact added
Existing contact modified
NAB sync
Availability Fetch
Performed for existing contact only
User opens a contact in NAB
User opens a contact in Call Log History
Not performed outside of LTE and eHRPD coverage
SIP SUBSCRIBE Header

SUBSCRIBE sip:+11234567890@test.3gpp.com;pres-list=dummy-rfc5367 SIP/2.0
Accept: application/pidf+xml,multipart/related,application/rlmi+xml
Accept-Encoding: gzip
Require: recipient-list-subscribe
Content-Type: application/resource-lists+xml
Expires: 30
Event: presence
Supported: eventlist
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1094511641
To: <sip:+11234567890@test.3gpp.com;pres-list=dummy-rfc5367>
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=00101000010000001
User-Agent: Samsung RCS 3.1
Contact: <sip:+11234567890@[1111::1111]:5060>
Route: <sip:[1112::1112]:5060;lr>
Call-ID: 2030486758@1111::1111
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Via: SIP/2.0/UDP [1111::1111]:5060;branch=z9hG4bK1260670180smg;transport=UDP
Content-Length: 322
SIP SUBSCRIBE Body

<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:+12145551234"/>
<entry uri="tel:+12146661234"/>
<entry uri="tel:+12148881234"/>
</list>
</resource-lists>
SIP NOTIFY Header

NOTIFY sip:+11234567890@[fd00:0:0:1::1]:5060 SIP/2.0
Event: presence
Via: SIP/2.0/TCP
[fd00:0:20:1::1:4]:5060;branch=z9hG4bK1393604306523209spirentvolte
Max-Forwards: 70
From: <sip:+ 11234567890@vzims.com>;tag=9982378004
To: "Anonymous"
<sip:anonymous@anonymous.invalid>;tag=2219518615
Contact: <sip:[fd00:0:20:1::1:4]:5060>
Call-ID: 443903722@fd00:0:0:1::1
Subscription-State: active
Content-Type: multipart/related; type="application/rlmi+xml;
boundary="nxbound1312926427801"
CSeq: 110 NOTIFY
SIP NOTIFY Body PIDF + XML

<list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:
+11234567890@@vzims.com;pres-list=dummy-rfc5367" version="0"
fullState="true">
<name>dummy-rfc5367</name>
<resource uri="tel:+12145551234">
cid="tel12145551234_1312926684451"/> </resource>
<resource uri="tel:+12146661234">
cid="tel12146661234_1312926684452"/> </resource>
<resource uri="tel:+12148881234"/>
cid="tel12148881234_1312926684453"/> </resource>
</list>
--nxbound1312926427801\r\n

Content-ID:<tel12145551234_1312926684451>
Content-Type:application/pidf+xml; charset=utf-8
Content-Transfer-Encoding:binary
<presence entity=" sip:+12145551234@vzims.com
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">
<status> <basic>open</basic> </status>
<op:service-id>
org.3gpp.urn:urn-7:3gpp-application.ims.iari.rcse.dp
</op:service-id>
<op:description>
VoLTE Capabilities Discovery </op:description>

<tuple id="t4fe354ed">
<status> <basic>open</basic> </status>
<op:service-id>
org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
</op:service-id>
<op:description> VoLTE and Video Calling Service</op:description>
<b:servcaps>
<b:duplex> <b:supported> <b:full/> </b:supported>
</b:duplex> </b:servcaps>
</tuple>
</presence>
Boundary: --nxbound1312926427801\r\n
.
Last Boundary: --nxbound1312926427801\r\n
Reference Documents

VOLTE

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VOLTE

Uploaded by

Copyright:

Available Formats

VOLTE

Provide faster call setup time

Mandatory features for Supporting VoLTE

3GPP IMS Architecture

IMS Home Network Functional elements

IMS Core Functions

IMS Core Functions

IMS Registration - Proxy- CSCF Discovery

IMS Registration Overview

IMS Registration flow

SIP Timers for IMS

SIP Requests & Responses

SIP message is either a request or response

Request vs. Response

P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id3gpp=31148000000000002 Network type

REGISTER Header contd...

Contact Header if device registered with eHRPD

REGISTER Header contd...

REGISTER Header contd...

Tag is added here in To Field

Registrar returns a set of associated URIs in P-Associated URI header for a

List of Methods allowed at Device

INVITE Header contd...

User-Agent: SP VOIP IMS 2.0

Session Expires: 300

SIP incorporates the use of a Session Description Protocol

SDP Offer & Answer

SDP Offer & Answer

INVITE Message-Body (SDP)

[ protocol version, It is always 0]

o= SAMSUNG-IMS-UE 2987933615 2987933615

[session name; it should not be empty]

i= A VT Session [session information/description]

INVITE Message-Body (SDP)

[<Media type> <Media Port>

104 110 102 108 105 100

< Media Protocol> < Media format List>

[ <rtpmap: payload type> <encoding name>/<clock rate>]

INVITE Message-Body (SDP)

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

INVITE Message-Body (SDP)

INVITE Message-Body (SDP)

Speech Codec & QoS

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

AMR WB Band efficient Payload

Payload Header : CMR( 4 bits )

AMR WB Band efficient Payload

Types of Payload format

Example of AMR-WB Band efficient Payload

Take first two bytes : i.e., f1 58

Setting up Conference Call

AT1 calls AT2 and then places this call on hold.

3-way conferencing with Subsequent Drop and Add

Setting up Conference Call Continued

Adding Participant in Call

Continues Adding AT4 now

<presence Presence info part starts from here

200 OK (PUBLISH Response)

PUBLISH (Republish) Header

The body of the republish is blank.

PUBLISH (Update) Header

PUBLISH (Unpublish) Header

Different scenarios of device capabilities &

Different scenarios of device subscription