CURRENT_MEETING_REPORT_ Reported by Mark Handley/University College London Minutes of the Multiparty Multimedia Session Control Working Group (MMUSIC) An on-line copy of the minutes and the accompanying PostScript slides are available from ftp://ftp.isi.edu/confctrl/minutes in the files ietf.7.95 and slides.7.95.tar. The Multiparty Multimedia Session Control Working Group (MMUSIC) met for two sessions on July 17 and 18 at the 33rd IETF. Interworking With The ITU Carsten Bormann gave a presentation (slides.7.95.a) of the possibilities for interworking between the ITU T.120 family for multimedia conferencing and Internet-based approaches to conferencing. The ITU appears to be moving towards using RTP or an RTP-like protocol for media data streams, but it is unclear how the conference control functionality encompassed in the T.120 suite would be achieved over the wide area Internet. Initially the ITU seems to be interested only in LAN interoperability. Three interoperability scenarios were presented, and the implications examined: 1. T.120 terminal phones in to ``classical'' IETF multicast session 2. Internet protocols only used locally behind a gateway 3. Tight interworking with the illusion of homogeneity The issues where there are potential incompatibilities include: o Resource control o Addressing: use of multicast o Session setup: prescriptive session description vs. negotiated o Security: cryptography vs. link setup authentication The details of these interoperability scenarios are discussed in more detail in draft-bormann-mmusic-itu-interop-00.txt. This presentation was followed by a discussion of how the MMUSIC Working Group should relate to the T.120 work. The rough consensus was that the group should pay attention to the ITU work, and not needlessly replicate T.120's conference control functionality in an incompatible way. However, the opinion was expressed that the group's current emphasis on wide area scalable multicast-based conferencing was desirable, and that we shouldn't sacrifice the benefits of multicast based sessions to conform to the ITU tightly coupled model. No real conclusion was reached, except that a building-blocks approach was advocated. Vertical Control Protocols Joerg Ott gave a presentation (slides.7.95.b) of two vertical control protocols (control protocols between local applications and controllers) developed at TU Berlin: The LASSO Dictionary and the Conference Information and Request Protocol (CIRP). Unlike CCCP and the control architecture described by Henning Schulzrinne (see minutes.4.95), these consist of a central (for each participant) information store, and an access protocol to this data store. The dictionaries object store is an acyclic directed graph, which is sufficient to reflect T.120 conference data, as well as more loosely couple conferences. CIRP complements the dictionary and allows a more flexible asynchronous event triggered interaction style, but still requires a single conference controller per user. Work is currently in progress to unify the dictionary and CIRP. Changes Made To The Session Description Protocol Mark Handley presented the changes that have been made to the Session Description Protocol since the Danvers IETF (slides.7.95.c). The current version of the draft is available from http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.01.ps. The main changes are: o SDP is no longer a superset of the sd protocol. o The ``c'' fields have been split into channel and time fields. o Repeat time fields have been completely re-worked. o Origin fields have been completely re-worked, and now uniquely identify a session announcement. o Bandwidth fields have been reworked somewhat. o Media fields have been reworked somewhat. o The Session Description Protocol has been separated into a separate draft from the announcement protocol that carries it. In general, the changes attempt to make the protocol more generic and more widely applicable. A number of minor problems with the protocol or the description in the current draft were noted. All these changes are fairly minor, but the most significant are: o The ``o'' field allows spaces in the address. The ``c'' field does not. The incompatibility should be resolved. o For unicast, the existing ``c'' field may not be sufficient to identify whether the address is to send to or receive from or some other semantics. This should be investigated further. o
in ``o'' and ``c'' fields should probably be two fields: