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.