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.