NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Eve Schooler <schooler@cs.caltech.edu>
Ruth Lang <rlang@sri.com>
Mark Handley <mjh@isi.edu>
Allison Mankin <mankin@isi.edu>
Allyn Romanow <allyn@eng.sun.com>
General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail
The demand for Internet multimedia teleconferencing has arrived, yet an infrastructure to support this demand is barely in place. Multimedia session control, defined as the management and coordination of multiple sessions and their multiple users in multiple media (e.g., audio, video), is one component of the infrastructure. The Multiparty Multimedia Session Control Working Group is chartered to design and specify a protocol to perform these functions.
The protocol will provide negotiation for session membership, underlying communication topology and media configuration. In particular, the protocol will support a user initiating a multimedia multiparty session with other users (``calling'' other users) over the Internet by allowing a teleconferencing application on one workstation to explicitly rendezvous with teleconferencing applications running on remote workstations. Defining a standard protocol will enable session-level interoperability between different teleconferencing implementations.
The focus of the working group is to design a session agreement protocol that supports tightly-controlled conferences in addition to the loosely-controlled ones currently carried on the MBone. Loosely-controlled sessions have little to no interaction among members, thus limiting their ability to provide security or coordination of session attributes (e.g., quality-of-service options for time-critical media, floor control for media flows). Users may learn of loosely-controlled sessions using the ``sd'' utility or other out of band mechanisms (e.g., e-mail, WWW). However, there is clearly also a need for more tightly-controlled sessions that provide mechanisms for directly contacting other users to initiate a conference and for negotiating conference parameters such as membership, media encodings and encryption keys. In addition, these sessions should support renegotiation during a session, for example, to add or delete members or change the media encoding.
The main goal of the working group will be to specify the session control protocol for use within teleconferencing software over the Internet. The working group will focus on the aspects of the session control problem that are well understood, while keeping an eye on evolving research issues. Toward this end, the working group has made an inventory of existing conferencing systems and their session control protocols. The working group will document the requirements of the existing prototypes as a basis for the protocol development. The working group will iteratively refine the protocol based on implementation and operational experience.
Furthermore, the working group will coordinate with other efforts related to multimedia conferencing, such as directory services for cataloging users and conferences, the RTP and RTCP protocols developed by the Audio/Video Transport Working Group, resource reservation and management at the network level, and schemes for multicast address allocation.
Goals and Milestones:
· SDP: Session Description Protocol
· A real-time stream control protocol (RTSP')
· Real Time Streaming Protocol (RTSP)
· SAP: Session Announcement Protocol
· SIP: Session Initiation Protocol
· Specification of Security in SAP Using Public Key Algorithms
Minutes of the Multiparty Multimedia Session Control (MMUSIC) Working Group
The Multiparty Multimedia Session Control Working Group (MMUSIC) met for two sessions on April 8th and 9th at the 38th IETF. These notes, prepared by Ruth Lang, summarize the presentations given and recount issues raised and their resolution, if any, during these presentations. An on-line copy of the minutes and the accompanying slides are available from the MMUSIC archive area ftp://ftp.isi.edu/confctrl/minutes in the files ietf.4.97 and slides.4.97.(tar, tar.Z}. Individual slide presentations can be obtained from the directory slides.4.97.
Mark Handley reiterated the Working Group last call placed for the Session Description Protocol (SDP) and offered his time in sidebar meetings to discuss any open issues. See the slides sdp.ps.
Rob Lanphier and Anup Rao discussed the current status and open issues of the Real Time Streaming Protocol (RTSP). They reviewed changes made since our last meeting in December including the merger of the original RTSP (Lanphier/Rao) and RTSP' (Schulzrinne), the maintenance of the HTTP orientation of RTSP', and the simplification of the protocol's state machine. See the slides rtsp.ps.
The results of open issue discussions were as follows:
· Use of two HTTP mechanisms (cookies for managing core RTSP Server State and PEP, an option negotiation method as a replacement for the current "Require" field) was discussed. The former was discouraged as it provides too broad of a solution (i.e., overkill) for the RTSP server. For the latter, the issue of PEP maturity with respect to the timeframe for forwarding RTSP to Proposed Draft was questioned. Further deliberation on this topic will occur on the mailing list in light of gaining a better knowledge of PEP.
· A speed field whose application implies fluctuating bandwidth usage during a session is encouraged as long as appropriate warnings about its potential misuse are included.
· The use of absolute URIs (cf relative URIs) in the Request-URI message to reference content is strongly encouraged.
Further discussion will occur on the mailing list regarding the control of multiple streams. It is encouraged, however, that a single stream transmitted to n destinations be broken up into n separate sessions.
Sending data to a destination that is not the control source was OKed for client-defined multicast address, given inclusion of appropriate cautionary statement, and is discouraged (for now) for client-defined unicast address.
A more detailed account of these issues may be found at http://www.real.com/prognet/rt/memphis.html.
Mark Handley presented the Session Announcement Protocol open issues including:
· Use of a UUID versus IPv4 address for message id + source addr (the latter is currently specified). The recent availability of an I-D describing UUIDs will seed well-thought discussion on this topic on the mailing list.
· Expansion of the current set of payload type fields. Although this adds flexibility (i.e., being able to convey other than SDP payloads), in practice it does not permit the presumption that the multicast address allocation scheme implemented by sdr -- currently, the most widely-used tool for advertising MBone-based sessions -- is being used. The more general issue of separating and documenting this address allocation mechanism arose. Although this work is needed, the downside of addressing it in the context of the current SAP is that redesign of the current mechanism and SAP protocol would be required, thus slowing-down progress of an already widely-used protocol to Experimental Standard status.
· Elimination of key identifiers for encryption as they serve as hints to the bad guys. The group supports this move.
Mark also presented a proposal to the group to progress the current SAP, with its security issues intact, to be an Experimental Standard. With the movement of the SAP Security I-D to Proposed Standard, SAP or a revision thereof would also then be forwarded to Proposed Standard. This was met with agreement with the exception of a plea for documentation of the current address allocation mechanism. Mark encouraged that this be brought to the attention of the Transport Services Area Directors. See the slides sap.ps.
Colin Perkins presented an overview of and open issues for the I-D "Specification of Security in SAP Using Public Key Algorithms," a.k.a., "SAP Security." See the accompanying slides sap_security.ps. SAP itself provides authentication hooks, and this document attempts to define mechanisms that can be put on those hooks. Open issues include whether the key ID field in the SAP header is required: it is felt that this could move into a specific authentication block as both PGP and PKCS#7 have key ID fields. Discussion of the need to define a standard privacy header, and whether the simple public key format defined in the document (simplified form of PKCS#7) or full PKCS#7 (or both) should be used was deferred to discussion on the mailing list.
Joerg Ott presented "Panel-style Conferencing with H.323 based on H.332" which describes the use of H.332 for loosely coupled conferences -- a protocol that can be used to create IETF/MBone-interoperable sessions. Use of SDP, SAP, and RTP are keys to this interoperability. Open issues presented include: SDP/SAP does not permit dynamic changes to conference parameters as H.332 does; the potential for "floor request" implosions (a Join request on the H.332 side which would allow the participant to generate content); and the integration of data protocols -- T.120 style vs SRM style application protocols -- different applications and application protocol styles. Joerg will circulate the H.332 specification to the mailing list to encourage further discussion. See the slides h332over.{ppt, ps}.
Mark Handley presented the changes and open issues related to the Session Invitation Protocol (SIP). Changes include: "capabilities" method was changed to "options" to align with RTSP, sequence numbers were removed from the "path" field, and the "path" field was changed to "via" to align with RTSP and HTTP (but the semantics are different so this change is questionable). Mark noted that the invitation of an RTSP server into a conference needs explanation in the document. Time was spent discussing the relationship between SIP and H.323 sessions. Advantages of SIP were pointed out and discussions about H.323's shortcomings ensued. The general notion of SIP providing a more lightweight mechanism and a different model were what justified its independent existence but further study and discussion on this is needed. It is proposed by Mark that further implementation experience be gained to aid the "shakedown" process of this proposal (e.g., continued inclusion or exclusion of some HTTP headers which have added complexity to the protocol). See the slides sip.ps.
Joerg Ott presented early results from a MERCI project on the "Development of a Gateway for SIP/SCCP and H.323 Interaction." Use of SIP alone created a set-up mismatch which necessitated some string pulling by the project team and creation of a situation where the H.323 conference could be assumed established while the SIP-based side was not yet established. Introduction of SCCP to establish a "control" conference aided this transition and created a workable model. Mark Handley questioned what changes to SIP would make this call model more compatible? Discussion will occur on the mailing list on this. See the slides merci-gw.{ppt, ps}.