2.7.7 Multiparty Multimedia Session Control (mmusic)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Ruth Lang <rlang@sri.com>
Eve Schooler <schooler@cs.caltech.edu>
Mark Handley <mjh@east.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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2326

PS

Real Time Streaming Protocol (RTSP)

RFC2327

PS

SDP: Session Description Protocol

Current Meeting Report

MMUSIC MINUTES, ORLANDO IETF
prepared by Mark Handley and Joerg Ott

MMUSIC met once at the Orlando IETF.
Internet Multimedia Conferencing Architecture

Mark Handley briefly reported on the (currently expired) I-D on the Conferencing Architecture -- this draft has been updated, and will be resubmitted to the I-D archive shortly after the IETF. The authors plan to issue WG last call on this for Informational RFC in January.

SAP and SAP Security

Mark Handley presented the status of SAP and the SAP security draft. The SAP and the SAP Security specifications have been merged into a single document. Two major issues arose with respect to the use of encryption within SAP:

- There has been disagreement between the authors on the use of public key encryption algorithms in a mode that effectively turns them into symmetric algorithms. The arguments for and against this were presented in the hope of getting consensus from the group. Little feedback was forthcoming.
- Also, there was the more fundamental issue of whether encryption of SAP announcements should be supported at all; the motivation for not supporting encryption would be to discourage people from misusing SAP to announce small private sessions to a potentially large audience; instead different mechanisms should be used. The following discussion showed various scenarios that would warrant keeping encryption of session announcements. The group consensus was to at least keep the use of symmetric encryption algorithms for now and to allow for future extensions to include other algorithms as well. [It was also pointed out that some key participants were not able to attend the meeting, and hence a follow up discussion on this second issue would be taken on the mailing list.]

SAP and IPv6

Colin Perkins presented a modified version of SAP that can support IPv6. SAP announcements containing IPv6 addresses are identified by taking one bit of the MT field to indicate the address type. The IPv6 SAP address to be used is defined in RFC2375: FF0X:0:0:0:0:0:2:7FFE with X being the four bit scope value as defined for IPv6. Along with various scopes, the proposal also defines bandwidth limitation for SAP traffic.

In his presentation, Colin also addressed the issue of supporting multiple payload types in SAP, to be identified by a MIME "Content-Type:" header at the start of the SAP payload ("application/sdp" would be used for SDP payloads but would also allow for non-SDP payload (e.g. SMIL). Such a mechanism would also be used to allow fragmentation of SDP announcements. On the other side, it adds complexity and might hinder interoperability. There was contentious discussion in the group on the tradeoff between flexibility and interoperability; no consensus was reached.

A general issue raised by Colin was how to allow joining e.g. multimedia streaming sessions from a web page. The proposal is to reference a SAP announcement (e.g. held in a local cache). The corresponding SAP URL could be composed of the announcement originator's source address and its locally assigned message id fields; e.g. "sap://128.16.64.45/1234". A number of people noted that most current implementations don't correctly fill in the appropriate SAP header fields, so there may be a deployment problem. Apart from this, the (little) feedback received was positive about the concept. No final decision was taken.

SIP

Mark Handley presented the changes to the SIP spec that were requested by the IESG. Besides a large number of purely editorial work to remove ambiguities in the specification, the changes include the following:

- The UDP backoff timers were changed to prevent SIP control messages from potentially causing congestion.
- The DNS lookup rules were changed: MX records were removed, SRV records are now optional (since they are defined as an experimental RFC while SIP is standards track).
- It was discussed whether IPv6 literal addresses should be supported in SIP URLs; as literal addresses seem to be unimportant no changes were made to the SIP spec.
- In the past, the SIP specification completely disallowed proxies to translate between the short and the long SIP representation or to change the message layout. This is now permitted unless message is authenticated.
- While earlier revisions of the SIP spec allowed arbitrary message formats to be signed, SIP now defines a canonical form to be used with authentication.
- Text was added to precisely define how SIP uses the HTTP basic and digest authentication mechanisms.
- The usage of SDP in order to set up asymmetric sessions was clarified.
- The use of the SIP Date field was restricted from allowing any valid HTTP date form to only the RFC 1123 form being allowed.

None of these changes were controversial. The group was asked whether they believe they need a new WG last call to review these changes. No-one wanted a new WG last call and so the revised document will be re-submitted to the IESG.

Reliability for SIP 1xx Responses

Jonathan Rosenberg presented an internet draft on SIP provisional response reliability. The problem stated is that provisional responses in SIP are not sent reliably and that this may cause difficulties for all state machines driven by 1XX responses, for signaling between gateways, for signaling transport, etc. The proposed solution is a SIP extension -- support of which is to be indicated by "org.ietf.sip.100rel" -- that defines ordering and reliability for provisional responses as follows: Provisional responses are extended to carry a sequence number (RSeq); they are acknowledged by the client retransmitting the original request with an acknowledgement number (RAck). Currently, reliability is based on a lock step mechanism for simplicity.

Jonathan identified various issues when this approach is used with proxies:

- Proxies may discard provisional responses; hence, end points depending on reliable transmission of 1XX responses must be able to request that proxies support 1XX reliability; a Proxy-Require header is needed to achieve this.
- Proxies themselves may generate provisional responses adding the need for hop by hop reliability.
- Forking proxies may receive responses from different branches where there is no absolute ordering; proxies must be able to merge these responses before forwarding upstream.

Finally, Jonathan pointed out a variety of issues to be discussed. A window size larger than one could be used to achieve better throughput with SIP (at the cost of additional complexity); in conjunction with this, SIP might need to incorporate congestion control mechanisms and may use selective acknowledgements to confirm reception of multiple responses. The potentially most important issue with the 100rel proposal is the isomorphism of SIP requests: formerly, the quadruple (To, From, CallID, CSeq) uniquely identified a request which is no longer true.

There was a significant amount of discussion in the group, but no consensus was reached on the technical conclusions to be drawn from this proposal. However, there did seem to be resonable consensus that the problem is worth looking at. Further discussion will take place on the mailing list.

SIP CGI

Jonathan Rosenberg presented an internet draft on SIP CGI. The motivation for this proposal is the need to program SIP servers to perform proxying, redirection, forking of calls, modify headers, perform various kinds of searches, etc. The idea behind the proposal is to separate the program logic from the SIP server functionality. In particular, the program logic could be provided by third parties and work with many SIP server implementations. Such a "definition language" would be targeted at system administrators rather than end users. The requirements presented include flexibility, simplicity, and independence of programming languages. The proposal presented is to use CGI which is supposed to match the aforementioned requirements and is well-established technology. Benefits of the approach taken were presented as were the differences between SIP CGI and HTTP CGI. Also, some details of the operation in conjunction with SIP protocol operation were outlined. The group felt that the separation between SIP server and program logic is basically a good idea, but there was consensus that defining this is not a work item to be pursued in the MMUSIC WG.

MPEG-4 and RTSP/SDP

Paul Christ presented work on RTSP-based stream control for MPEG-4. MPEG-4 does not provide a simple scheme for Application Signaling for media stream control in version 1; rather, the mechanisms available from MPEG-4 version are very complex, with many types of streams, many possible levels of indirection, and a tight coupling of control interactions and scene syntax and semantics. As an alternative that may be considered within the IETF (and will also be fed into the ISO development of version 2), a control scheme based upon RTSP and SDP is proposed to provide the minimum required media stream control functionality to support simple client-server applications. This would require an SDP syntax that allows to describe MPEG-4 objects (initially); also, an appropriate update mechanism would be needed to convey changes to the object descriptors within a streaming session. Furthermore, some additions to RTSP would be necessary to provide enhanced interaction capabilities.

There was little feedback from the group and hence no decisions were taken whether or not to address this further within the scope of MMUSIC.

Message Bus (Mbus)

Joerg Ott presented an update to the message bus, which had been discussed at the previous IETF. The major changes include a modification in the addressing concept -- turning fixed address quadrupels into tagged tuple sets -- and a significant extension of the semantics specifications (which have not yet been turned in as an Internet Draft). Joerg reported that they are now two implementations available and that also prototypes of media and control tools running Mbus emerge. Work is being continued on further semantics definitions for building gateways, local capability exchange, and to provide hooks for easily integrating policies for local decisions in MBus-based systems.

There was significant discussion about whether this should be modified to permit wide-area operation (currently it's purely intended for local coordination). The authors are reluctant to turn it into a general purpose conference control protocol since the perceive functionality and semantics for local coordination to be different.

Finally, it has not yet been decided whether this should be an MMUSIC work item or not. The authors propose to pursue this work further and provide an update at the next IETF when more experience is gained and the proposal is more complete and then revisit the issue how (if at all) to deal with the Mbus as a work item in the IETF.

Slides

None received.