Minutes of the MMUSIC WG 46th IETF, Washington, DC Reported by Joerg Ott Notes taken by Tom Taylor The MMUSIC WG met once during the 46th IETF, for a two hour slot. The meeting was chaired by Joerg Ott. Some 150 participants attended the meeting. Revised MMUSIC Charter Joerg gave an overview of the tentative new charter of the Working Group. He noted that Ruth Lang, Eve Schooler, and Mark Handley have stepped down as co-chairs and thanked them for the years of great work together. Due to the re-organization of MMUSIC, the mailing list and archive location will change in the next months. Joerg then discussed the tentative work items for MMUSIC and outlined a deliverable schedule for the next 12 months to come. The development of a capability description framework as successor for the Session Description Protocol (SDP) will be the most important short-term work item. Another new work item will be the design of a local coordination mechanism for conferencing applications (the Message Bus). Further work items include collecting and documenting existing and emerging extensions to SDP (Session Description Protocol), documenting current practice SAP (Session Announcement Protocol) and moving a revised SAP spec ahead to Proposed Standard. The Real-time Streaming Protocol (RTSP, RFC 2326) will be revisited to be advanced to Draft Standard or revised as Proposed; a simple conference control protocol for tightly coupled sessions will be developed in the long term. Finally, Joerg announced that a WG Last Call shall be issued on the IETF Multimedia Conferencing Architecture I-D shortly after this IETF. With respect to SAP, an issue was raised whether a local access protocol to a site central SAP server would be in scope of MMUSIC. It was agreed that this is necessary for the specification of a complete system. HTTP was suggested as one possibility. The chair asked for volunteers to write up a document outlining possible alternatives for this task so that the working group can review these. It was also pointed out that, from the experience gained so far with SDP in the context of the AVT WG, not only extensions but also corrections may need to be applied to the current SDP spec. This discussion was postponed to the capability framework agenda item. Session Announcement Protocol (SAP) Version 2 Colin Perkins briefly discussed recent work on version 2 of the Session Announcement Protocol. Two drafts (02 and 03) have been submitted since the Oslo meeting. Draft 02 contains most of the changes: this draft clarifies the text describing the authentication procedure and specifies more exactly when session announcements are to be sent. Draft 03 has removed the references to directory sessions; instead, a separate draft will be submitted for the next meeting. Colin continues to explain the algorithm for calculating the announcement interval. It was noted that the RTCP timer reconsideration algorithms works slightly differently from the one of SAP and that it may be worthwhile to align SAP here. This will be considered further. Colin pointed out that the current SAP is ready for WG Last Call for Experimental RFC (rather than standards track because of the well-known scaling problems). A successor version of SAP should then be targeted at Proposed Standard. WG Last Call was agreed subject to the change to the reconsideration behavior noted above. Session Description Protocol (SDP) and Administrative Scoping Colin Perkins also introduced extensions to SDP to deal with administrative scoping. The problem is that a session description may contain administratively scoped multicast addresses (which are not globally unique); in this case, the receiver of an SDP message body cannot tell from the session description alone whether or not this address is valid in the particular scope zone. Colin proposed two possible solutions: as long as the session is announced with SAP, the announcement has to use the same scope zone as the session. If this is done, then everyone who receives the announcement will also be able to receive the media streams. However, Colin points out that relying on SAP is obviously not always suitable. An alternative would be to include a "scope identifier" in the session description. One possibility is to include the MZAP scope name (human readable, not unique though), using the MZAP zone identifier is another (the MZAP zone identifier is unique but may change over time). Colin considered the latter approach to be an acceptable solution for now. It was discussed whether this is a real issue that needs to be solved within SDP. Colin argues that at least for Mbone conferences (possibly announced on web pages) there is a potential need for such an attribute. It is tentatively agreed to inlucde the MZAP zone identifier in SDP, but investigations will continue. SIP/SDP Call Setup for Real-time Fax over IP (T.38) Glenn Parsons introduced the ITU-T protocol for real-time fax over IP: T.38 which can be described as demodulated and packetized T.30. It does use TCP or UDP (UDP optionally with FEC) for data transport, no RTP. Two call signaling protocols are being standardized for T.38: H.323 (T.38 Annex B and H.323 Annex D) as well as SIP/SDP (to become T.38 Annex D). T.38 Annex D uses SIP INVITE for establishing fax-only and fax/voice calls. A number of T.38-specific attributes are proposed to indicate capabilities of fax endpoints such as the maximum bit rate, MMR and JBIG transcoding, and the use of error correction as attributes. Two SDP extensions are to be registered with IANA: ("image/t38") as format type and "TCP" as transport protocol. For call signaling, call progress mappings to SIP are being defined as is DTMF carriage during a call. Comments are welcome with respect to all of the current work areas. Glenn noted that ITU-T SG8 plans to approve the document (with SDP extensions) in its February 2000 meeting. Sample call flows will be added as an appendix. Comments on the work should be sent to the mailing list, to the chair, or to Glenn and will be summarized and prepared as input to the ITU-T meeting by January, 19th, 2000. RTSP-based media control in MPEG-4 Andrea Basso presented on the issue of MPEG-4 stream control with RTSP, the aim being to understand how RTSP can be used to control MPEG-4 streams and which RTSP extensions may be necessary for this purpose. The particular issue discussed was how to initially retrieve a scene description from an RTSP server. The architecture of MPEG-4 comprises scene descriptions and elementary streams which are linked by object descriptors. Object descriptors can vary widely in size (and pariticularly those belonging to the initial scene description tend to be large) which raises the issue of reliable delivery from the media server to the client. Andrea proposed two possible solutions: two RTSP DESCRIBE message could be exchanged -- which, however, would require two round-trips before the description is available to the client. It was noted from the audience that both DESCRIBEs could be sent in a single message (which would require that an implementation uses the same URL for both, though). Alternatively, the content-type multipart (SDP, IOD) could be used to carry both session description and initial object descriptors in one message (and thus retrieve it in a single round-trip). Andrea solicited further feedback/input on methods for delivering the initial Object Descriptor. During a short discussion, it was pointed out that similar work has been presented in MMUSIC before, and the respective presenters agreed to join their efforts to develop a solution. An Internet Draft describing RTSP for MPEG-4 stream control will be made available within the next two months. The work is targeted to be completed by July 2000. Message Bus for Call Control Joerg Ott provided an update of the work on the Message Bus: the transport is deemed stable by now. An internal interoperability day in Bremen has led to a number of minor clarifications in the text as well a few minor technical fixes in the specification and has proven interoperability of three implementations: one from UCL in C, two from Bremen (C++ and Java). An optimization to reduce load is also included now: Mbus messages targeted at a single recipient may be sent via unicast (instead of multicast); the decision to use unicast is taken within the Mbus transport layer implementation and is transparent to the application. The revised Internet Drafts for requirements and transport will be submitted shortly. The Message Bus transport Internet Draft is targeted for Proposed Standard. Joerg also reviewed the concepts for Mbus message semantics and described the simple command naming scheme allowing for generic as well as protocol/tool-specific commands to be described without the risk of name clashes. He noted that protocol/media and tool-specific commands are defined for RTP, audio streams, and the Robust Audio Tool (RAT), respectively. Then he focused on Mbus commands for call control presenting a set of elements common to H.323, SIP, and ISDN and designed to be suitable for building gateways as well. (Protocol-specific messages are yet to be defined.) As an example, he presented a call setup message (conf.call-control.call) along with its parameters in more detail. Similar messages are defined for incoming call, accepting and rejecting calls, redirection, etc. as well as for event notifications (ringing, accepted, etc.). Using ladder diagrams Joerg described sample call flows with Mbus-controlled SIP engines on both sides of a call. Further call flows for other scenarios were shown as well. He noted that the first revision of the call semantics Internet Drafts are likely to be targeted for Experimental to gain more experience before a Standards Track document will be pursued. An issue was raised that the Message Bus commands for call control seem very similar to an API -- a seemingly similar work item was rejected by the Area Directors in the meeting of the SIP WG (SIP servlet API). The chair agreed to discuss this subject with the Area Directors. It was also noted that much more functionality as presented during the meeting (and specified in the draft so far) will be needed for e.g. call center applications. Joerg pointed out that further commands were already under investigation (such as conveying DTMF, controlling announcements, etc.) and there were more to come. Joerg also outlined a number of potential application scenarios for the Message Bus. The fundamental idea is that Mbus enables modular system design (with components exchangeable at run time) and allows independence of programming languages. The Mbus concept can be used to implement minimal browser plug-ins that use Mbus messages to talk to a powerful call control engine / conferencing system. Also, Mbus allows to create an open interface for remotely controlling stand-alone devices (such as IP telephone sets) from PCs/workstations. Many further areas of application are conceivable. In the future, work will need to move towards on completing the work for generic call control, defining specific control commands for SIP and H.323 (both of which are in progress). Those Mbus commands which use SDP right now for carrying media descriptions need to be revised to incorporate the new capability framework syntax. Finally, tool-specific commands should be defined for video applications, whiteboards, etc. and new areas of deployment could be investigated for the Message Bus. Capability Framework Joerg Ott presented the current status of the work on the capability framework. Capability negotiation is required for call and conference control among other areas, and is needed by / worked on in a number of working groups: MMUSIC, SIP, AVT, MEGACO, CONNEG, and possibly (much more limited) IPTEL and ENUM. The capability framework aims at providing a good solution for MEGACO, SIP, and MMUSIC, borrowing/re-using as much as possible from other work. Joerg continued to review the system model: he described the application and the component view of a call/conference situation. To provide the desired communication functionality (such as audio communication or shared viewing of transparencies) different configurations (applications used, protocols and parameters using within the applications) are conceivable at each endpoint involved. The intersection of capabilities (expressed by protocols and protocol parameters) supported by the endpoints defines the set of potential configurations to be used in the particular setting. Out of these potential configurations one or several actual configurations will be chosen for the communication tasks; these actual configurations constitute the session descriptions for the various media (as currently found in SDP). Today, a number of protocols make use of SDP to express capabilities. However, SDP was originally designed for session announcements rather than capability negotiation and does not make a distinction between potential and actual configurations. While SDP is simple, network efficient, and easily extensible within its scope (all properties that are desirable to keep), it is not designed to indicate alternatives, counts, or groupings of capabilities. Furthermore, SDP as a description language does not provide adequate means to address aspects such as redundancy coding or FEC. Joerg stated that a new capability framework needs to address all these asepcts as well as additional ones. Requirements (augmented durint the MMUSIC session) for negotiation include: - simple capability description and negotiation process - multiparty with dynamic membership - generality: semantics-ignorant negotiation - accommodate user preferences - simultaneous and mutually exclusive capabilities (combinations, quantities) - fix initial choice of a capability for the entire session (no later changes possible) - policies - negotiation restricted to one to one and a half round trips Requirements for the language: - expressiveness e.g. support for redundancy, FEC, layered encodings - efficiency -- concise, easy to parse - generality -- no semantics in base specification - extensible -- support naming and reuse of "profiles" - network-friendly -- compactness, firewall/NAT support - available within the next 18 months. Completing the presentation of the current capability framework Internet Draft, Joerg reviewed the major comments that the authors had received so far: it was noted that the relation between requirements, system model, and description language needs clarification, and a major concern was raised that the capability framework draft would duplicate work of the CONNEG WG. While the authors suggested that re-use of CONNEG work was a nice-to-have, comments from the audience urged that re-use wherever possible is rather a mandate -- particularly given the complexity of the issues, the potential similarity of requirements, and the goal to complete this work as quickly as possible. Finally, Joerg outlined the next steps to be taken (considering the comments received). Work items include defining syntax, types and parameters for media encodings (codecs) as well as redundancy, FEC, and interleaving schemes. Work on these aspects can draw from other sources inside and outside the IETF. Also, the negotiation model needs to be fixed: for the concrete negotiation model, it needs to be decided how far to reuse or adapt the CONNEG work, a syntax need to be specified, and special cases for capability negotiation need to be worked out (such as sending vs. receiving capabilities, symmetric vs. asymmetric capabilities). A general discussion followed on the implications of this work: an issue was raised that if this capability framework is intended as a replacement for SDP, this will have an impact on a lot of other protocols and deployed applications (which suggests further discussion on the list). Also, it was pointed out that (like in the MEGACO WG) two camps are likely to surface: one looking for a number of extensions to SDP to satisfy the immediate needs, another will want something similar to H.245. The chair argued that there is a need to make progress on this, that all requirements have to be reviewed carefully (in order not to overengineer a solution), and that, with respect to the two camps, the goal is to make neither of them too unhappy. It was pointed out the SDP specification needs revision to incorporate fixes. This raises the issue of which functionality will be added to SDP during this revision cycle and what will be done as part of the new work item. The chair argued that he would like to avoid feature creep in SDP and that SDP should be kept within its original scope as a pure description language. He also pointed out that a clear migration path from SDP towards the new work needs to be defined. The capability framework was accepted as a new work item. All requirements listed so far (and new ones to be found) will be reviewed carefully, and a solution as simple as possible will be developed. The authors agreed to investigate the CONNEG work again with the aim to re-use as much as possible and provide a revised capability draft by February 2000. Further discussion will take place on the list.