CURRENT MEETING REPORT

Reported by Eve Schooler,

Minutes of the Multiparty Multimedia Session Control Working Group (MMUSIC)

MMUSIC met during two sessions at the 35th IETF, both of which were multicast. A summary of each of the talks given and a report of any follow-up action items follows. An on-line copy of these minutes and the accompanying PostScript slides are available from ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.96 and slides.3.96.{tar, tar.Z}. These notes were prepared by Ruth Lang.

Mark Handley (UCL) gave a presentation and solicited additional input on open issues on the Session Description Protocol (sdp.3.96.ps). The issues reviewed include expression of RTP profiles and payload types, format lists, format groups, and a proposed change to the "media" and "connection" lines which allow more general expression of connection topologies and media relationships (e.g., for layered encodings). Sufficient input was received to resolve some of the issues, but discussion will continue on the mailing list on others. Specifically, RTP profiles will be expressed on the "protocol" line of the description (i.e., rtp/profile); supporting dynamic RTP payload types was left as an open issue dependent on further discussions in AVT regarding the definition of a registration mechanism for them; the idea of re-introducing format groups was discouraged in favor of retaining explicit descriptions of a group of encodings; and changes to the "media2 and "connection" lines were left as an open issue. A revised Internet draft will be issued soon and the goal of issuing "last call" before the next IETF meeting was set.

Mark Handley (UCL) gave a presentation on the design goals and issues for a Session Directory Announcement Protocol (SDAP) (sdap.3.96.ps). This protocol was originally envisioned to only support wide-area multicast of SDP packets, but has been divided into a wide-area (server to server) and local-area (client to server) portions. The division was made to facilitate a segregation between session directory management and maintenance functions (e.g., multicast address allocation) and user-oriented functions (e.g., instantiating tools). It was noted that the Service Location Protocol could provide a means to locate directory servers, but lacked support for asynchronous update. Mark has proposed to write an Internet-Draft describing SDAP for review and discussion before the next IETF.

Mark Handley (UCL) provided an overview of the motivations for the creation of the Internet Multimedia Conferencing Architecture document (confarch.3.96.ps). This document describes the "big picture" which is driving the development of the MMUSIC protocols, and the relationship among the protocols in terms of a conference lifecycle. Allison Mankin (Transport Area Chair) encouraged that 1) the document be made an Informational RFC with note that the document is intended to change, and 2) MMUSIC formally ask the Security Area for a formal consultation. Additional comments received included an encouragement that this document be used to note the relationship between MMUSIC and the ITU work on session control, and that the document should provide descriptions of yet unchartered (by MMUSIC) technical challenges.

Ross Finlayson (Live Networks) gave a presentation aimed at motivating more general thinking about the use of the MBONE as a general groupware framework (groupware.3.96/1-10.ps). Some ideas Ross suggested for further thought include: developing a way to share more than just media (i.e., workspace sharing), a generalization in how sessions are managed (e.g., multiple directories), use of object inheritance models in describing sessions, supporting additional persistence models in describing sessions (e.g., personal directories). Some discussion centered around the use of multiple directories and their similarity to net news. No action items followed from this presentation.

Rob Williams (Microsoft) and Eve Schooler (Cal Tech) each gave presentations on the topic of User Location [(uls.3.96.ps) and (userdir.3.96.ps) respectively]. Rob's presentation described a service that has been developed at Microsoft for which an MMUSIC Internet-Draft has been created. This User Location Service provides a means for users to build a common directory of information regarding the running applications that can be used for collaboration. The User Location Service I-D describes the client-side protocol for add/delete/refresh/query operations to a database of tagged records. Rob outlined several issues that the Internet-Draft does not yet cover; examples include defining identifiers for common schema elements, integration with DNS (seen as way to find User Location Servers), and security. Eve provided an overview of a multicast-based user directory she has developed. Goals of the effort are to enable a simple method for registering user communities, combine dynamic and static approaches of session management, and take advantage of other user information on "closeness" to bound scope of media relations for sessions. This user directory employs an announce/listen paradigm - everyone using same multicast addr/port is loosely bound; the scope of reception of the user announcement also defines the scope of reception of the session itself. Eve has implemented a prototype which will be released with the next release of MMCC. No specific action items were generated as a result of these two talks. It was later identified by the chairs that this topic is of interest to the working group and that a more thorough review of the problem area and options for providing such a service (e.g., based on already-developed Internet protocols) was needed and will be scheduled as an agenda item for the next IETF.

Eve Schooler (Cal Tech) presented the motivations for and specifics of the Session Invitation Protocol (SIP) (sip.3.96.ps). This protocol is targeted to complement the advertisement mechanism provided by tools such as sd and sdr by enabling the joining of users (as compared to users joining a session address). It can be used in the context of both tightly- and loosely-controlled sessions and is intended for transmission among peer user agents (or proxies for them). SIP uses SDP as a means of describing the sessions for which an invitation is being issues. It is meant to be conveyed over UDP and is therefore minimally stateful -- request/response pair messages are mandatory, but progress reports and acks are optional. Issues regarding the choice of transport mechanism of UDP as compared to TCP or remote procedure calls were discussed, and set-up delay imposed by timer-based retransmissions were discussed.

Henning Schulzrinne (Fokus GMD) presented the motivations for and specifics of the Simple Conference Invitation Protocol (SCIP) (scip.3.96.ps). This protocol is also aimed at complementing advertisement mechanisms but was developed with an eye towards supporting telephony functionality. The models and goals of the two protocols are similar, but SCIP can be contrasted with SIP by its use of TCP as a transport mechanism, leveraged use of HTTP and SMTP, and use of an alternate session description format (i.e., not SDP), etc. Some discussion on UDP vs TCP (T/TCP) vs RPC etc. occurred but no resolution was reached regarding a choice of a single transport mechanism for conveyance of an invitation protocol. It is expected that discussion of issues will be carried on the group's mailing list and an effort to resolve differences between these two approaches will be undertaken.

Carsten Bormann (Univ. Bremenn) provided an overview of the Simple Conference Control Protocol (SCCP) which is a protocol between conference control agents (horizontal) for orchestrating tightly-coupled conferences (sccp.3.96.ps). The protocol is intended to support managing a membership list including per-member capabilities, application/media sessions, floor control, and conductorship. It does not duplicate session advertisement or invitation functions and supports session control only. The protocol distinguishes protocol structure and protocol semantics (a document describing the latter was proposed as a complement to SCCP), and is intended to support bridging to T.120. Design goals for the protocol included simplicity and generality, but scalability to "large" groups (e.g., IETF broadcasts over the Mbone) was excluded. No discussion regarding the protocol occurred in the meeting due to lack of time. The draft document circulated informally to the mailing list will be revised and submitted as an Internet-draft.

Jim Toga (Intel) provided an overview of the ITU H.323 protocol and highlighted its ability to operate over the Internet (h323.3.96.ps). Specifically, H.323 supports having two (or more) H.323 terminals be interconnected by an IP cloud. It supports the establishment of tightly-controlled conferences which can be centralized (hub) or distributed (peer-to- peer). H.323 is based on family of ITU protocols and interoperability among them is important. Thus the standard contains many guidelines for interoperation via gateways. No discussion regarding H.323's use on the Internet and potential impact on protocols being developed by this group occurred due to lack of time. This will be carried on the mailing list.

Ed Ellesson (IBM) provided an overview of Internet Telephony and highlighted the impact on conference control as well as other IETF- and Internet-related areas (AVT, Integrated Services). Ed proposed questions such as whether solving issues regarding the lack of interoperability among the Internet Telephone tools was the purview of MMUSIC and pointed out that regardless, these tools in widespread use would have a significant impact on traffic congestion on the Internet. Ed offered to bring Internet phone vendors into the IETF for joint discussions on this issue. Discussion regarding the seemed mismatch between the bandwidth most Internet Telephone users have (e.g., 14.4 kb/sec) and the size of Internet protocols, whether the Internet should work to accommodate this type of traffic flow (vs emphasize its ability to carry multicast traffic), etc. occurred. No specific conclusions were reached in this meeting.