2.7.9 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99


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

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Vern Paxson <vern@ee.lbl.gov>

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.


Request For Comments:







Real Time Streaming Protocol (RTSP)



SDP: Session Description Protocol

Current Meeting Report

Minutes of the MMUSIC WG

Reported by Mark Handley and Joerg Ott

The authors would like to thank to Colin Perkins for the notes.

The MMUSIC WG met once at the 44th IETF, on Wednesday morning 9.00-11.30. Joerg Ott briefly introduced the agenda for the meeting, virtually all items relating to the SIP specification itself and to extenions to it. The meeting agenda was set up to allow for high bandwidth discussion of the major issues that surfaced on the mailing list since the last IETF. Mark Handley briefly reported that SIP now has been published as RFC 2543 and that the formal SIP bakeoff is scheduled to happen on 8/9 April 1999 at Columbia University, New York.

Jonathan Rosenberg introduced the concept of caller preferences for SIP-based calls. Caller preferences constitute one component of the earlier SIP call control I-D that has been split up. Caller preferences allow a caller to indicate preferences where and how to reach a callee (e.g. location, media types, etc.), control proxy behavior (forking or not, etc.). However, they are only hints to a callee's proxy that may but need not be followed. While a callee's preferences are conveyed to the SIP proxy in the REGISTER message, caller preferences only apply to a certain call and hence should be passed in the INVITE message for this particular call. There was significant interest in the group to take this up as an MMUSIC work item.

Steven Donovan introduced the various SIP issues that came up on the mailing list since the last IETF. SIP session timers are found to be needed to allow removal of per-call state in stateful proxies in special cases of call termination (e.g. no BYE sent, BYE lost, endpoint crashed). A calling endpoint would include a timout for the call state in its INVITE message and subsequently extend this timeout if it is about to expire before the call terminates. There was substantial discussion but no final conclusion could be reached and so this issue will be taken to the mailing list.

A second issue is the proposal to add a new method to SIP called "INFO" to allow carrying ISUP payloads transparently across an IP network. This provoked controversial discussion with very different viewpoints: Some considered this to make use of SIP as a transport; instead, SIP should be used to indicate the presence of a separate transport as defined by the SIGTRAN WG. Others felt that SIP delivering a bag of bits transparently through an IP network may cause interoperability problems at the edges (since different dialects of ISUP do exist); the gateways should rather (partially) interpret the contents of the ISUP messages (which may be required for some ISUP functions anyway) and transcode parts of the ISUP messages into SIP messages. Such an extension of SIP, however, might gradually turn SIP into a telephony-specific call/conference control protocol rather than a protocol for setup and teardown -- which would probably be the task of a different protocol. The issue was not resolved during the meeting and hence this discussion needs to be continued on the mailing list.

A third problem identified is how to allow for voice feedback from a (PSTN) gateway to be propagated to a SIP endpoint before the "200 OK" response is received. Various proposals have been made on the list which were discussed at the meeting. The one presented during the meeting was sending a 183 response to include a temporary SDP description of the media source so that media streams can start flowing. An alternative proposed on the list was a nested INVITE from the callee's side (more precisely: the entity initiating transmission of media streams prior to 200 OK) back to the caller to create a temporary second session used only for this (audible) feedback. No conclusion was reached during the meeting; discussion will continue to be discussed on the list.

Finally, a specific multipart encapsulation message format for SIP message bodies was proposed to include an SDP description, an ISUP message part, and e-commerce information -- all of which are optional. It was commonly found that no specific multipart format should be prescribed and rather the generic multipart message format should be used in order not to restrict future extensibility. This rather new item will also require further discussion on the mailing list.

Jonathan Lennox gave a brief presentation on the usage of SIP as transport for scripts of the Call Processing Language (CPL). In the meeting of the IPTEL WG a day earlier, it was found that it is not up to IPTEL to define how to carry CPL scripts in any possible transport but rather that the precise mechanism should be left up to the group responsible for designing the transport itself. This was primarily a heads up presentation for a possible new work item.

Finally, the working groups chairs proposed their view on how to deal with SIP-related issues in the context of the MMUSIC WG: generic SIP mechanisms as well as revision/extensions/corrections of the base SIP spec are supposed to be included in MMUSIC while applications of SIP (such as the PINT profile) are out of scope. A borderline case constitutes IP telepony and related specifications. In any case, the MMUSIC WG will decide on a per case basis in consultation with the ADs whether or not to take up certain tasks, but the aforementioned principles will serve as guidelines.

With respect to the future evolution of the Session Announcement Protocol (SAP), Mark pointed out that Colin Perkins from University College London (UCL) joined the team of editors.


SIP Caller Preferences
SIP Session Timer
CPL and CGI Transport in SIP REGISTER Payloads