Editor's Note: These minutes have not been edited. Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes from the 38th IETF Memphis, Tennessee April 8-9, 1997 Chairs Mark Handley, mjh@isi.edu Ruth Lang, rlang@sri.com Eve Schooler, schooler@cs.caltech.edu 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 The minutes and 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 WG 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) were discussed. The former was discouraged as it provided 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 the this topic will occur on the mailing list in light of gaining a better knowledge of PEP. - A speed field whose application would imply fluctuating bandwidth usage during a session was encouraged as long as appropriate warnings about its potential misuse were included. - The use of absolute URIs (cf relative URIs) in the Request-URI message to reference content was strongly encouraged. - Further discussion will occur on the mailing list regarding the control of multiple streams. It was 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 oked given inclusion of appropriate cautionary statement, and was 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 vs 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. This move was supported by the group. 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" aka "SAP Security." See the accompanying slides sap_security.ps. SAP itself provides authentication hooks; this document attempts to define mechanisms that can be put on those hooks. Open issues included whether the key id field in the SAP header was required: it was 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 described 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 included: 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 included: "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 was 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 some 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}.