volte
DESCRIPTION
VOLTETRANSCRIPT
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 UE’s 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 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 WiFiContact: <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 eHRPDContact: <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=4fa3560890To: sip:[email protected]
REGISTER Header contd...
CSeq: 1 REGISTERCSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog
Max-Forwards: 70Max-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=UDPThe 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: 0Length of the body. Register will not have message body.
200 OK (REGISTER)
SIP/2.0 200 OKFrom: <sip:[email protected]>;tag=4fa3560890To: <sip:[email protected]>; tag = 32299af7845
Tag is added here in To Field
Call-ID: apb03a0s09dkjdfglkj49111P-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.0tel:1234512345 -> tel URI (Mobile Directory Number (MDN) , vzims.com->Domain NameSupported: 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 DeviceP-Preferred-Identity: <sip:[email protected]>
Device sets its preferred identity out of multiple valid identities it has. Here it is its SIP URIP-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: 300Route:<sip:192.168.43.166:5060;lr>To:< tel:1234512345>From: sip:[email protected]; tag= 3456efa74510Call-ID: apb03a0s09dkjd546789CSeq: 1 INVITEVia: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPContent-Type: Application/sdpContent-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 uniquenessSession-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 Descriptiont= 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 Descriptiona=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 Descriptiona=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 Descriptionm=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 100a=rtpmap:102 AMR/8000a=fmtp:102 mode-set=7a=rtpmap:108 AMR/8000a=fmtp:108 mode-set=7; octet-align=1a=rtpmap:100 telephone-event/8000a=fmtp:100 0-15a=ptime:20a=maxptime:240a=sendrecv
SDP Answer -1
m=audio 49120 RTP/AVP 102 100a=rtpmap:102 AMR/8000a=fmtp:102 mode-set=7a=rtpmap:100 telephone-event/8000a=fmtp:100 0-15a=ptime:20a=maxptime:240a=sendrecv
SDP Offer-2
m=audio 49120 RTP/AVP 104 110 102 108 105 100a=rtpmap:104 AMR-WB/16000a=fmtp:104 mode-set=2a=rtpmap:110 AMR-WB/16000a=fmtp:110 mode-set=2; octet-align=1a=rtpmap:102 AMR/8000a=fmtp:102 mode-set=7a=rtpmap:108 AMR/8000a=fmtp:108 mode-set=7; octet-align=1a=rtpmap:105 telephone-event/16000a=fmtp:105 0-15a=rtpmap:100 telephone-event/8000a=fmtp:100 0-15a=ptime:20a=maxptime:240a=sendrecv
SDP Answer-2
m=audio 49120 RTP/AVP 104 105a=rtpmap:104 AMR-WB/16000a=fmtp:104 mode-set=2a=rtpmap:105 telephone-event/16000a=fmtp:105 0-15a=ptime:20a=maxptime:240a=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 = 0Last 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 HeaderPUBLISH sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPAccept: application/pidf+xml, application/rlmi+xml, multipart/relatedMax-forwards: 70Contact: <sip:[email protected];5060>Route:<sip:192.168.43.166:5060;lr>To: <sip:[email protected]>From: <sip:[email protected]>; tag = 3456efa74510Call-ID: 200737754dCSeq: 1 PUBLISHExpires: 1200Event: presenceContent-Type: application/pidf+xmlContent-Length: 1277
PUBLISH Body
<?xml version="1.0" encoding="UTF-8" ?> XML format
<presence Presence info part starts from hereentity=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
PUBLISH Body
<tuple id="t4fe357ba"> 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>
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 To: <sip:[email protected]>From: <sip:[email protected]>CSeq: 1 PUBLISH SIP-ETag: dx200xyzExpires: 1200
PUBLISH (Republish) Header
Device should send periodically PUBLISH message provided Etag is not expired
PUBLISH sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPTo: <sip:[email protected]> From: <sip:[email protected]>CSeq: 1 PUBLISH SIP-If-Match: dx200xyz Expires: 1200 Event: presenceContent-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
PUBLISH sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPTo: <sip:[email protected]> From: <sip:[email protected]>CSeq: 1 PUBLISH SIP-If-Match: dx200xyz Expires: 1200 Event: presenceContent-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
PUBLISH sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPTo: <sip:[email protected]> From: <sip:[email protected]>CSeq: 1 PUBLISH SIP-If-Match: dx200xyz Expires: 0 Event: presenceContent-Length: 0
The body of the unpublish is blank
Different scenarios of device capabilities & availabilities
SUBSCRIBE Header
SUBSCRIBE sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPAccept: application/pidf+xml, application/rlmi+xml, multipart/relatedMax-forwards: 70Contact: <sip:[email protected];5060>Route:<sip:192.168.43.166:5060;lr>To: <sip:[email protected]>From: <sip:[email protected]>; tag = 3456efa74510Call-ID: 200737754dCSeq: 1 SUBSCRIBEExpires: 1200Supported: eventlistRequire: recipient-list-subscribeAccept-Encoding:gzipEvent: presenceContent-Type: application/resource-list+xmlContent-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>
NOTIFY Header
NOTIFY sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPMax-forwards: 70Contact: <sip:[email protected];5060>To: <sip:[email protected]>; tag=234ab45230From: <sip:[email protected]>; tag = 3456efa74510Call-ID: 200737754dCSeq: 1 NOTIFYExpires: 600Event: presenceSubscription-State: activeContent-Type: application/rlmi+xml,application/pidf+xmlContent-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\nContent-ID:<tel:+16175551212_1312926684451> 1st resource/Content Id Content-Type:application/pidf+xml; charset=utf-8Content-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
SUBSCRIBE (Availability fetch)
SUBSCRIBE sip:[email protected]; SIP/2.0Via: SIP/2.0/UDP 192.168.43.144;branch=z9hG4bKnashds7;transport=UDPAccept: application/pidf+xmlMax-forwards: 70Contact: <sip:[email protected];5060>Route:<sip:192.168.43.166:5060;lr>To: < sip:[email protected]>From: <sip:[email protected]>; tag = 3456efa74510Call-ID: 200737754dCSeq: 1 SUBSCRIBEExpires: 0Event: presenceContent-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
SUBSCRIBE to all contacts
STANDARD REGISTRATION (Rest of registration scenarios)
REGISTER
PUBLISH (capabilities)
ADDING/MODIFYING A CONTACT
OPTIONS to all contacts
REGISTER
OPTIONS to new/modified contact SUBSCRIBE to new/modified contact
PERIODIC CAPABILITY POLLING (Polling period >0)
LIVE CAPABILITY/SERVICE DISCOVERY
SUBSCRIBE to all contacts whose capabilities have not been
recently updated
OPTIONS to all contacts whose capabilities have not been
recently updated
OPTIONS (contact) SUBSCRIBE (contact)
LIVE CAPABILITY/SERVICE UPDATE
PUBLISH (capabilities)OPTIONS (contact)
Enhanced Address Book (EAB)
• Overview
• EAB is a feature provided by Address Book Application• It has two functions
– Presence Publication– Presence Info Retrieval
• Presence Publication– 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 device’s capabilities associated with a contact– Discovery of other device’s availability associated with a contact– Performed by Presence Watcher of Address Book Application
Presence Publication
• 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 PUBLISH-
TIMER-EXTENDED– Default value of PUBLISH-TIMER=1200s (20 minutes) and PUBLISH-TIMER-
EXTENDED= 86400s (1 day)
Presence Publication
• 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
<?xml version="1.0" encoding="UTF-8"?><presence xmlns="urn:ietf:params:xml:ns:pidf" " entity="sip:[email protected]"> <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:version>1.0</op:version> <op:description> VoLTE Capabilities Discovery </op:description> </op:service-description> <contact>sip:[email protected]</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:[email protected]</contact> </tuple></presence>
SIP 200 OK (PUBLISH)
SIP/2.0 200 OKVia: SIP/2.0/TCP [2600:2:5:6:3:2:206:1356]:5060;branch=z9hG4bK97466916smg;transport=TCPFrom: <sip:[email protected]>;tag=1737480301To: <sip:[email protected]>;tag=4614552585Call-ID: 2065482978@2600:2:5:6:3:2:206:1356SIP-ETag: 13461603CSeq: 1 PUBLISHExpires: 1200Content-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 HeaderSUBSCRIBE sip:[email protected];pres-list=dummy-rfc5367 SIP/2.0Accept: application/pidf+xml,multipart/related,application/rlmi+xmlAccept-Encoding: gzipRequire: recipient-list-subscribeContent-Type: application/resource-lists+xmlExpires: 30Event: presenceSupported: eventlistFrom: "Anonymous" <sip:[email protected]>;tag=1094511641To: <sip:[email protected];pres-list=dummy-rfc5367>Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACKP-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=00101000010000001User-Agent: Samsung RCS 3.1Contact: <sip:+11234567890@[1111::1111]:5060>Route: <sip:[1112::1112]:5060;lr>Call-ID: 2030486758@1111::1111CSeq: 1 SUBSCRIBEMax-Forwards: 70Via: SIP/2.0/UDP [1111::1111]:5060;branch=z9hG4bK1260670180smg;transport=UDPContent-Length: 322
SIP 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:+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.0Event: presenceVia: SIP/2.0/TCP [fd00:0:20:1::1:4]:5060;branch=z9hG4bK1393604306523209-spirentvolteMax-Forwards: 70From: <sip:+ [email protected]>;tag=9982378004To: "Anonymous" <sip:[email protected]>;tag=2219518615Contact: <sip:[fd00:0:20:1::1:4]:5060>Call-ID: 443903722@fd00:0:0:1::1Subscription-State: activeContent-Type: multipart/related; type="application/rlmi+xml“; boundary="nxbound1312926427801"CSeq: 110 NOTIFYContent-Length: 1382
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"><instance id="001" state="active" reason="subscribe"cid="tel12145551234_1312926684451"/> </resource><resource uri="tel:+12146661234"><instance id="001" state="active" reason="subscribe" cid="tel12146661234_1312926684452"/> </resource><resource uri="tel:+12148881234"/><instance id="001" state="active" reason="subscribe" cid="tel12148881234_1312926684453"/> </resource></list>--nxbound1312926427801\r\n
SIP NOTIFY Body – PIDF + XML
Content-ID:<tel12145551234_1312926684451>Content-Type:application/pidf+xml; charset=utf-8Content-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">
<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>
SIP NOTIFY Body – PIDF + XML
<tuple id="t4fe354ed"><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 Calling 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> </presence>Boundary: --nxbound1312926427801\r\n……….Last Boundary: --nxbound1312926427801\r\n
Reference Documents
