You have seen a couple of IMS flows. You know the registration, the 3rd party registration. Flows of SIP INVITE, SDP, SIP MESSAGE, RTP and RTCP, MSRP … do you think you know enough? For the core functionality this is nearly all we need. But for a real service there are many other things we have to learn. Yes in theory there is the Signaling and Media Plane. But there is also a parallel world of Presence and Capabilities. (And some other parallel worlds of billing, provisioning, monitoring, etc.)
The cornerstone mechanism for all the VoLTE/ViLTE, Instant Messaging and particularly for the RCS is a capability discovery. Users want to see their contacts with the RCS services that are available to communicate. This can be implemented either using the SIP OPTIONS or using a Presence-based solution defined in RCS Release 1 -4. Both will result in one of three types of response:
- The contact is registered for service resulting in the contacts current service capabilities
being received and logged, or, - the contact is not registered (they are provisioned but not registered),
- the contact is not found (they are not provisioned for service).
This discovery mechanism is important since it ensures that users can determine what services are available before the communication starts. The same mechanisms can be used to initially discover (and/or periodically check) the service capabilities of all the contacts within an address book when we first register for the service. For the Service Providers it is also very useful because they can add new types of communication channels without compatibility issues.
Capabilities of a device are shared during SIP Registration, over SIP OPTIONS and using the presence system.
SIP OPTIONS for VoLTE
In practice in VoLTE networks we can find the SIP OPTIONS messages to be used as application-layer pings or heart-beats. Via them we can monitor an availability of IMS network servers (instead of SNMP traps for example). E.g. S-CSCF monitors Applications Servers using SIP OPTIONS. If TAS is able to respond with 200 OK, it means it is up and running and not overloaded.
Moreover in VoLTE/ViLTE the SIP OTIONS can be also used for capabilities sharing. The IR.94 says that a Contact header field in a 200 OK response message to a SIP OPTIONS request must include the IMS Communication Service Identifier (ICSI) value of “urn:urn-7:3gppservice.ims.icsi.mmtel”, as defined in 3GPP TS 24.173. In addition for ViLTE, a contact header in a 200 OK response message to a SIP OPTIONS request must include a “video” media feature tag.
SIP OPTIONS for Presence and Capability Discovery
In this post we’ll address mainly the SIP OPTIONS presence/capabilities discovery and basic presence system. The SIP OPTIONS method is send as end-to-end message. It is used both to query the capabilities (services which the other user has available) of the target contact and to pass the information about which capabilities are supported by the requester. Using this method, both users get updated information in a single transaction.
SIP OPTIONS
Note the difference between capability discovery and SDP passed in SIP INVITE. The capability discovery is a more general, relates to user identity rather than a device and it is intended for the real user. E.g. we’ll see that Richard is active and we can communicate with him via Instant Messaging, Voice Chat or Video Chat. Once we’ll make our mind the SDP comes into play. The information passed by SDP is intended for the application only and it is more detail. In the SDP body we can find information about what address a particular device has, what media sources can be used, what codecs are available, etc. In the past this was enough – as the only type of communication was a voice channel.
Using SIP OPTIONS users are allowed to hide their service capabilities to some undesired contacts. To this end, clients may support a locally stored capability blacklist which could be configured manually by the user or be generated automatically by setting any contacts that do not exist in the user‟s address book as the blacklisted contacts. This blacklist is different with the blacklist that is used for chat, file transfer and content share services. If a SIP OPTIONS request is received from a capability blacklisted contact, the client should answer the request with an empty 200 OK which does not include any of the service tags used by RCS.
Although on the picture the SIP OPTIONS goes directly in practice we need some AS (B2BUA) to be involved. That is because of the multidevice support and, potentially, include optimizations to avoid too many massages in the network. Still you can see that the load of messages can be quite high comparing to Presence. Why we use the SIP OPTIONS then? There are two main reasons. Firstly the SIP OPTIONS is easier to implement. Secondly not all the devices support the Presence (SIP PUBLISH, eventlists, rich data format, etc.). The principle of interoperability is that all devices support SIP OPTIONS exchange
either as a default or a device fall-back mechanism.
OPTIONS Call Flow
The information about capabilities is in the tags in the Contact and Accept contact headers (RCS spec):
Image Share +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-is”
Video Share +g.3gpp.cs-voice
Chat +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.im”
Full Store and Forward Group Chat +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gppapplication.ims.iari.rcs.fullsfgroupchat”
File Transfer +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.ft”
File Transfer Thumbnail +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftthumb”
File Transfer Store and Forward +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ftstandfw”
File Transfer via HTTP +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.fthttp”
IP Based Standalone messaging +g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gppservice.ims.icsi.oma.cpm.msg,urn%3Aurn-7%3A3gppservice.ims.icsi.oma.cpm.largemsg”
Video Share outside of a voice call +g.3gpp.iari-ref=”urn:urn-7:3gpp-application.ims.iari.gsma-vs”
Social presence information +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcse.sp”
IP Voice Call (as per MMTEL) +g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”
IP Video Call (as per MMTEL) +g.3gpp.icsi-ref=”urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel”;video
RCS IP Voice Call +g.gsma.rcs.ipcall
RCS IP Video Call +g.gsma.rcs.ipcall;video
RCS IP Video Call where video media cannot be removed by the user +g.gsma.rcs.ipvideocallonly
Geolocation PUSH +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopush”
Geolocation PULL +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopull”
Geolocation PULL using File Transfer +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.geopullft”
Service Provider specific service +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.mnc<mnc>.mcc<mcc>.<service name>”
Third-Party specific service +g.3gpp.iari-ref=”urn%3Aurn-7%3A3gpp-application.ims.iari.rcs.ext.<identifier>”
List of all the Uniform Resource Identifiers for capabilities can be found at http://www.3gpp.org/specifications-groups/34-uniform-resource-name-urn-list
Presence Server
In case PS in place we can do an ad-hoc subscription, when the Expires is set to 0. In this case in doesn’t mean un-subscribe but rather it is a kind of a ‘single shot’ information retrieval.
Capabilities via PS
In this case the capabilities are not transferred in the Contact header but in the body of the NOTIFY message as xml paylod xmlns:caps=”urn:ietf:params:xml:ns:pidf:caps”. The format is defined in the RFC 5262 and in OMA Presence SIMPLE Data Specification.
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:user@operator.com"
version="123">
<tuple id="example">
<status>
<basic>open</basic>
</status>
<timestamp>2075-11-08T20:15:59Z</timestamp>
<contact priority="0.500">sip:+123456789012@operator.com</contact>
<op:willingness opd:until="2018-10-25T02:21:00Z">
<op:basic>open</op:basic>
</op:willingness>
<caps:servcaps>
<caps:audio>true</caps:audio>
<c:message>true</c:message>
<caps:video>true</caps:video>
<caps:duplex>
<caps:supported><caps:full/></caps:supported>
</caps:duplex>
<caps:methods>
<caps:supported>
<caps:ACK/>
<caps:BYE/>
<caps:CANCEL/>
<caps:INVITE/>
</caps:supported>
</caps:methods>
<caps:schemes>
<caps:supported>
<caps:s>sip</caps:s>
<caps:s>tel</caps:s>
</caps:supported>
</caps:schemes>
</caps:servcaps>
<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>IPVideoCall</op:description>
</op:service-description>
</tuple>
</presence>
So this was just an introduction into this new world of capabilities and presence.
More information about presence can be found in following posts:
Real Time Communication 