2.7.6 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98


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@mci.net>

Transport Area Advisor:

Allyn Romanow <allyn@mci.net>

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 Multiparty Multimedia Session Control (mmusic) Working Group


Mark Handley, mjh@isi.edu
Ruth Lang, rlang@sri.com
Joerg Ott, jo@tzi.org
Eve Schooler, schooler@cs.caltech.edu

The Multiparty Multimedia Session Control Working Group (MMUSIC) met for one session on March 31st at the 41st IETF. These notes, prepared by Eve Schooler, summarize the presentations given and recount issues raised and their resolution, if any, during these presentations. An on-line copy of these minutes and the accompanying slides are available from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.98 and slides.3.98.{tar, tar.Z}. Individual slide presentations can be obtained from the directory slides.3.98.


Mark Handley of USC/Information Sciences Institute gave a detailed overview of SIP status. See the accompanying slides sip.{ps,ppt}. In particular, he focused on an improved SIP security architecture and presented the outstanding issues that remain before SIP is to be advanced to Proposed Standard. As discussed at the DC IETF, the call-control functionality has been split from the base spec and was discussed later in the meeting.

Issues raised:

Once the SIP I-D freezes, an interoperability testing session is needed for SIP implementations.

II. SIP Call Control

Jonathan Lennox of Columbia University presented the latest call-control I-D on behalf of Henning Schulzrinne and Jonathan Rosenberg. See the accompanying slides sip-cc.ps. Much heated discussion ensued. Overall it was felt that the I-D introduced complex enough behavior, with functionality as yet untried, that (1) considerably more detail was needed in the I-D and (2) implementation experience was strongly requested.

The issues raised:

· Extensions to the Location header:

· Call-Dispostion:

· New headers Also, Replaces and Requested-by:

In terms of feature redundancy, what is the difference between an INVITE with an Also and Replaces (to myself), and a BYE with an Also of someone else? Although the former (INVITE with Replaces of self) is rather awkward, it is legal to do a blind transfer with this mechanism. However, we need to be careful (e.g., with PBX's) that there remains a single user in conference (imagine robot-to-robot 3rd party transfers).

In addition, there was general discussion about the distinction between various identifiers: the user, session, and call ids. In particular, the question was asked, what's the difference between a session and a call? Does a call refer to a single "leg" or INVITE, whereas session is the overall "object" among all users; or alternatively, is the call meant to cover the overall conference? In any event, clarification is needed.

· Open Issues:

Asked how a third-party requester should be informed of the progress and result of a request, people felt none of the proposed solutions were ideal (STATUS request, application/sip payload, 1xx responses). It was reiterated that more precise error message handling may help here.

· Examples:
A more palatable example other than telemarketing was requested :-) In discussing the issue of transitioning from a mesh to an MCU, one issue raised was if there is a method of notification of all parties on the calls for meshes.

III. SAP Security

Ian Brown from University College London reported that SAP security is nearly complete. The only major change since the last IETF meeting was making PGP support a MUST and S/MIME support a SHOULD. The draft currently references the old PGP standard (RFC 1991), which mandates RSA and IDEA support, both of which are encumbered algorithms. The solution is to use the new version of PGP, which will be slotted in as soon as possible; it mandates Cast, Triple-DES and Diffie-Hellman, all of which are considered unencumbered. The UCL implementation is almost done and eventually will support the latest version of PGP.

IV. Status of WG Documents

· SAP - Basically SAP is ready to become an Experimental Standard. Although it has clear long-term scaling issues, it is probably appropriate for the next 1 to 2 years. Within a couple month timeframe, the base spec will be merged with the SAP security spec.
· SDP - After resolving outstanding namespace issues between SDP, RTP, and MIME, SDP has been published as RFC 2327 and has advanced to Proposed Standard status. There is some interest in drafting a recommendation on SDP format parameters.
· RTSP - After being stalled on SDP-related issues, RTSP has been published as RFC 2326 and has been advanced to Proposed Standard status.
· SIP - The I-D is on the brink of being re-issued, and should advance to Propose Standard within 2-3 months.
· SAP security - Will be rolled into the SAP base spec.
· SIP security - The current SIP I-D now encompasses this work.
· SIP call-control - Still a fairly controversial topic. The natural home for this work was SIPTEL, but now that SIPTEL has become IPTEL, call control is no longer in the charter. For now, the work will carry on in the MMUSIC working group, but we will collect feedback on a long term home for it.
· Conference Architecture - This I-D is more or less done. We simply need to make sure that it is an accurate representation of what really exists now - as it was originally drafted a couple years ago.
· ITU Interoperability - A moving target! This draft has expired. If rewritten, should it aim to describe what goes in a gateway between MMUSIC and ITU protocols (H.323 and H.245)? The major concern is that we should not get into this business. One suggestion is to re-activate the I-D in IPTEL, if and when several gateway implementations have emerged. One Transport AD advised that such a document was not necessarily needed at this point. However, others thought an I-D that served to compare and contrast MMUSIC and ITU approaches might be useful.
· SCCP - The simple conference control protocol continues evolution as it undergoes implementation. We hope to re-issue the I-D before next IETF.
· The Agreement Protocol - An early I-D in the WG, which has since expired. It is closer in spirit to SCCP, in that it supports general mechanisms for closer coordination sessions with varying policies. There are no current plans to resurrect it, but there is sporadic interest in continuing the work. One related suggestion was to extend SDP to carry more complicated policy information.
· Conference or Coordination Bus - The idea that there exists a local coordination protocol among components on a single host (e.g., among media agents such as audio and video and shared workspaces, which might be used to implement voice-to-follow-video operation, or floor control, etc.). Is this a protocol the working group should take on?


Session Initiation Protocol

Attendees List

go to list