Speaking of Standards

This past week brought the announcements of two new SIP-related Working Groups out of the IETF. In the long-standing tradition of having entertaining names, they are naturally “LSD” and “SALUD”.

The first announcement was for the “Loosely-coupled SIP Devices” Working Group (LSD) covering a topic of personal interest to me – disaggregated media. From the charter description:

Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams coming from different devices under his or her control so that they are treated by the far end of the session as a single media session.

Generally, a given participant uses a single device to establish (or participate in) a given multimedia session. Consequently, the SIP signaling to manage the multimedia session and the actual media streams are typically co-located in the same device. In scenarios involving disaggregated media, a user wants to establish a single multimedia session combining different media streams coming from different devices under his or her control. This creates a need to coordinate the exchange of the those media streams within the multimedia session.

There are a number of existing mechanisms that can be used to coordinate different devices under user’s control and to involve them in the call (e.g. Message Bus (Mbus) [RFC3259], Megaco [ITU-T H.248.1] and SIP 3pcc [RFC3725]). However, these mechanisms are intended to be used in “tightly coupled” scenarios. The use of all those mechanisms requires the presence of a “master” device. That is, at least one among the different devices under the control of the same user must support the control mechanism and be able to become a controller for the other devices in the call. Moreover, the “master” device is supposed to remain involved in the user’s session for its entire duration given that performing a handover of the master role is typically cumbersome and sometimes impossible.

The objective of this working group is to develop a framework for disaggregated media in “loosely-coupled” scenarios, where no single device needs to remain in the session for its entire duration and no single device needs to act as a master. Coordination among devices in this type of scenario is less tight than in the scenarios described above since they do not assume central elements with complete knowledge of the whole media session. While the framework may describe how to use existing mechanisms (e.g., the SIP REFER method) to coordinate devices, the working group will not develop new device coordination mechanisms. The framework may identify the need for new (non-device-coordination) mechanisms to enable the implementation of loosely-coupled scenarios. In case the need for such new mechanisms is identified, the working group will specify them.

For those interested in participating or monitoring the discussion, there is a LSD mailing list to which anyone can subscribe.

The second announcement was for the “Sip ALerting for User Devices” (SALUD) Working Group. This group is looking to tackle an area of interoperability around the semantics behind one part of SIP signaling. The description provides these examples:

RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone.

RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played.

This Working Group is going to be working to define a standardized set of URNs that can be used in the Alert-Info SIP header to pass along the meaning rather than a specific URI of a media file to be played (for instance). This would allow different systems to provide the most appropriate alert to the user based on local or personal settings.

Again, there is a mailing list available for anyone interested in participating in or monitoring the developments of the WG.