2.7.5 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Nov-97


Ruth Lang <rlang@sri.com>
Eve Schooler <schooler@cs.caltech.edu>
Mark Handley <mjh@isi.edu>
Joerg Ott <jo@cs.tu-berlin.de>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

Transport Area Advisor:

Allyn Romanow <allyn.romanow@eng.sun.com>

Mailing Lists:

General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

- distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP),

- providing security for session announcements -- SAP Security,

- controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP),

- initiating sessions and inviting users -- Session Initiation Protocol (SIP), and

- managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332).

The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP.

Goals and Milestones:

Jul 97


Conduct WG Last Call for SAP Internet-Draft

Jul 97


Submit a revised Internet Multimedia Conferencing Architecture I-D.

Jul 97


Submit SDP to the IESG for consideration as a Proposed Standard.

Jul 97


Submit a revised SIP I-D.

Aug 97


Submit a revised ITU Interoperability Scenarios I-D.

Aug 97


Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.

Oct 97


Conduct WG Last Call for RTSP Internet-Draft.

Oct 97


Submit Internet-Draft on Internet Multimedia Conferencing Architecture.

Nov 97


Submit RTSP to IESG for consideration as a Proposed Standard.

Nov 97


Submit ITU Interoperability Scenarios Internet-Draft to IESG for consideration as an Informational RFC.

Jan 98


Conduct WG Last Call for SIP Internet-Draft.

Feb 98


Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.

Apr 98


Conduct WG Last Call for SAP Security Internet-Draft.

Apr 98


Conduct second WG Last Call for SAP.

May 98


Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.

May 98


Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.


No Request For Comments

Current Meeting Report

Minutes of the MMUSIC Working Group

Prepared by: Joerg Ott <jo@tzi.uni-bremen.de>

Acknowledgement: Special thanks to Colin Perkins who has done an excellent job taking notes of the MMUSIC WG session.

The MMUSIC WG met once during the 40th IETF. The meeting started with a brief review of the status of Internet Drafts due for last call: Mark Handley noted that the Real Time Streaming Protocol (RTSP) is already at last call with the IESG and that the Session Description Protocol (SDP) will go to last call shortly after this meeting. No further discussion was needed on those two subjects.

I. Session Initiation Protocol (SIP)

Henning Schulzrinne gave a presentation on the latest revision of SIP elaborating on operational aspects of the protocol as well as indicating the functional changes after the Munich IETF. A long discussion was held on the reliability needed for SIP messages if SIP messages are carried in UDP packets. Henning pointed out that for many client messages (intermediate) answers are required from the server which imply acknowledgment of the previously sent message. For some messages from the server to the client, an additional ACK message is needed, this may also be the case for the BYE message from the client to the server (since then resources can be released at the server). A combination of implied acknowledgments, ACK messages, and timeouts with message repetition should solve these problems. However, some details remain to be sorted out.

Henning's presentation of multicast invitations extended the mechanism to make use them to simultaneously invite several persons. It was noted that the semantics of such invitations are unclear and that they may lead to answer message implosions. It was agreed to stay with the exclusive use of multicast invitations for user location purposes -- what they were originally intended for -- in the basic SIP specification (see below).

Furthermore, Henning proposed various extensions in the direction of what is referred to as "supplementary services" in the telephony / PBX world. Some functions of call forwarding / call deflection can be implemented in the SIP proxy or the SIP server of a user using basic SIP messaging. Newly added functionality includes call disposition and call delegation. Call disposition allows a calling party to influence the called user's SIP server behavior, e.g. to avoid forwarding or to queue a call if the user is busy / unavailable. Call delegation allows the called endpoint to redirect the call to others -- by changing the parties to which the call is addressed. Finally, the location header of the SIP Invite message may be used to indicate alternatives where to reach the called user -- which may be given relative preferences or which may be associated with different quality levels. This would allow the caller to make an intelligent decision on which of the alternatives to try next and would also allow more sophisticated searching which is achieved at the cost of higher complexity. Many participants expressed that -- although some of these features may be desirable -- they prefer it to go into the next version of or an extension to SIP rather than into the base specification to be completed soon.

For configuration purposes, Henning proposed SIP messages that allow a client to register and unregister with a SIP server; this would include user id, location information, etc. It was noted that is addresses (local) configuration of SIP servers / proxies and is an orthogonal to the functions SIP is intended to perform. In particular, this is moving the protocol into a new area, which it wasn't intended to solve, and for which different mechanisms (e.g., with respect to security) were required. Mark Handley pointed out that the UCL session directory (sdr) implemented configuration by means of the HTTP POST message. No consensus was reached in the group for the inclusion of these features in the (basic) SIP specification.

Overall, it was noted felt the scope of the base SIP specification and its delineation from extension / profile documents seems unclear at the moment. The conference chairs and the editors agreed to sort out the details soon after the IETF (again, see below).

It should be noted that from the intense discussions during the meeting and lack of such controversies on the mailing list -- although the SIP draft was published for quite some time and many features were in there since late summer 1997 -- it became apparent that the expected review of the SIP draft did not take place before the IETF. The chairs encourage people to timely look at Internet Drafts as they appear and debate them on the mailing list -- otherwise, silence may be mistaken as consensus even though there is no agreement.

Joerg Ott presented a proposal on how to proceed with SIP to achieve a stable document to become a standards track RFC soon. In particular, he noted that although the basic SIP idea has been around for a while no stable state has been reached yet and that in the past only little third party review took place. Recently, SIP started broadening its scope and keeps steadily growing which prevents it from becoming stable. He pointed out that, as there is the desire from other WGs to make use of SIP, reaching a stable specification soon is a mandate; otherwise, SIP may loose this last chance of gaining relevance in some place. As progress of the specification as it stands right now in draft-ietf-mmusic-sip-04.txt depends on too many factors, he proposed to split SIP into a basic specification that only defines the most elementary features of SIP and one or more profile documents that enhance SIP to meet the needs of other groups. He also noted that some of these extensions may not be in the scope of the MMUSIC WG and in which case those would taken care of by other WGs. The following discussion confirmed this approach, and it was decided that the WG chairs and the editors are to work out a delineation between the basic SIP specification -- which is to contain a mandatory core and a few generic extensions / options -- and potential profiles -- which may address third party call setup (as required by PINT), advanced supplementary services, user location, and others. It is expected that some extensions / profiles will be handled within the MMUSIC WG while others will be developed in those WGs that intend to use SIP for their purposes.

II. Session Announcement Protocol (SAP)

Mark Handley presented recent considerations on the Session Announcement Protocol (SAP). One major intended change stems from the recent efforts on multicast address allocation undertaken by the IDMR WG and from the discussion on using multiple Session Directories for announcements (see Ross Finlayson's presentation described below). This work will require to split away the part of SAP dealing with multicast address allocation. Mark noted that this does not require protocol changes, but updates to the descriptive text may be needed in various parts of the document. Furthermore, the SAP specification shall force people towards the use of administratively scoped multicast addresses (to replace the currently used TTL scoping) and hence the corresponding section on TTL scoping shall be removed/replaced.

It was noted that SAP payloads (if carrying SDP data) may easily grow larger than a typical MTU so that a UDP datagram carrying a SAP message may need fragmentation. It is suggested to use the GZIP compression algorithm, but it was pointed out that GZIP is not sufficiently well specified at this point. Further work is needed here.

A brief discussion on the use of the delete message for session announcements was held. It was found that the default means to delete session announcements should be a timeout with delete messages used as an optimization.

Finally, SAP shall be kept entirely independent of the payload type SAP messages carry, i.e. the payload does not have to be SDP. However, for the base session announcement multicast address, SDP should be the default payload type.

With respect to the further work plan, it was agreed to put SAP and SAP Security (see next item) on the Standards track early 1998.

III. Session Announcement Protocol (SAP) Security

Edmund Whelan gave a presentation of the current status of work on security. SAP itself provides hooks to integrate security functions (beyond encryption) but does not specify specific algorithms. The current Internet Draft draft-ietf-mmusic-sap-sec-03.txt defines authentication and privacy based upon the PGP or PKCS#7 algorithms to close these holes in the base SAP specification.

For authentication, a generic authentication header is provided which is followed by an algorithm-specific subheader. For symmetric encryption, the approach of the basic SAP specification is followed, hybrid encryption schemes make use of a combination of a generic header and an algorithm-specific subheader.

The changes since the previous draft of Secure SAP include the following. Draft -03 now specifies two algorithms to be used with SAP: PGP (RFC 1991) and PKCS#7. Two open issues were raised by Edmund for discussion in the group but not yet resolved: whether the group should move from PGP to Open PGP to avoid mandatory support for encumbered algorithms and, similarly, whether S/MIME version 3 should be used instead of PKCS#7. It was found that people seem to be keen to make such moves, but the success depends on the progress of Open PGP and S/MIME. Another question raised in this context was whether it was possible to mandate only a single algorithm rather than requiring any implementation to support both. There was no resolution to this issue.

Finally, Edmund reported on the implementation status of Secure SAP: symmetric encryption and PGP-based authentication and encryption were reported to be complete in SDR. He expect the remaining functions to be completed in the near future -- i.e. in the January 1998 time frame.

Work is continuing on the Secure SAP Internet Draft; a new revision shall be coming up soon after the publication of the revised SAP draft.

IV. Multiple Directories in SDP

Ross Finlayson presented an approach to support multiple session directories instead of a single one for session announcements. The motivation for this idea stems from the observation that a single directory does not scale. Even with today's moderate use of the Mbone announcement channel and despite regional announcements, the session directory tools such as SDR show several dozens of sessions (with this number continuously increasing). This results in the user interface getting cluttered and -- with only a single multicast group being used to distribute all the announcements -- the interval between two announcements of the same session gets very large (eventually rendering this retransmission scheme useless) because of the fixed bandwidth allocated to the announcement channel.

The solution proposed by Ross uses multiple directories with distinct respective multicast addresses, bandwidth limitations, etc. The use of multiple independent directories is enabled because the recent work on multicast address allocation allows decoupling this task from SAP. A possible approach is to continue using the current announcement session as "base directory" and announce new session directories within the base directory as another session with a certain subject, e.g., "test sessions," "radio/tv sessions," etc. A new SDP media type for session directory announcement could be

m=directory <port> <protocol> <format>

with the initial protocol and format defined being "SAP" and "SDP". Ross pointed out that this concept would in principle not require a single root directory session but allow directories to be related to one another in arbitrary graphs (like the world wide web), media sessions could be coupled with related directory sessions, encrypted directories are possible, and other (standardized or proprietary) announcement protocols and directory formats could be used. Finally, it was pointed out that allowing multiple directories may require changes to firewalls.

In the following discussion in the working group, a variety of issues were raised that need to be solved in conjunction with the concept of multiple directories. It needs to be sorted out who controls the creation of new directories and what happens with sessions announced within a directory when this directory is deleted. One approach could be to see what happens and worry about it later; another would be to follow a policy style comparable to NetNews. As a policy will eventually be needed anyway, one should think about a proper policy right from the beginning. In any case, security mechanisms (particularly authentication) are a prerequisite for controlling use of multiple directories. Another issue pointed out is that arbitrary graphs of directories may easily lead to confusion and make it difficult to find the session directories or sessions of interest. It was also noted that the functionality of multiple directories could in principle be easily provided by dedicated announcement newsgroups, too, and hence care should be taken not to duplicate effort to solve a well understood problem in an incompatible fashion.

It was concluded that much further investigation is needed. Best current practice should be documented to explain how multiple directories are to be used, to delineate this concept from other solutions for announcement channels (such as NetNews), to clarify which features should be included in such a directory system, and to enable deriving a feasible policy for its use.

V. Future Work in MMUSIC

Joerg Ott briefly reviewed the status of the MMUSIC WG: RTSP and SDP will be done soon, SIP is expected to go into last call by the end of February or the beginning of March. It was pointed out that SIP requires authentication mechanisms; the editors agreed to investigate the work on Secure SAP for re-use within SIP and incorporate the necessary functions into the revised SIP specification. Further work on SIP profiles may be required to satisfy various usage scenarios for this protocol and to provide support for other working groups that do want to make use of SIP for other purposes.

The group decided to move SAP and Secure SAP should go experimental RFC by the end of January to freeze the current specification and their revisions should become standards track documents later in 1998. The Internet Multimedia Conferencing Architecture draft should be re-issued in the second week of January and go to last call shortly thereafter.


Suporting Multiple Directories in SDP
Security in SAP
SIP Draft 04

Attendees List

go to list

Previous PageNext Page