Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes ==================================================================== Reported by Colin Perkins The MMUSIC working group met once at the 65th IETF meeting (Dallas, March 2006). Topics under discussion included the SDP Content Attribute, ICE, secure media stream setup, SDP for file transfer, RTSP, SIP for streaming media, QoS identification for preconditions, codec-specific parameters in SDP, use cases for session mobility and requirements for IPsec negotiation in SDP. The meeting was chaired by Joerg Ott and Colin Perkins and attended by some 130 participants. Introduction and progress report The chairs introduced the session and gave a brief status review. The group has had one RFC published since the last meeting (offer/answer examples -> RFC 4317) and has a further ten drafts in the RFC Editor queue (including, finally, draft-ietf-mmusic-sdp-new-26.txt). There is one open rechartering issue, on how to continue with the Internet Media Guide work, and discussion on that subject is ongoing with the authors and area directors. SDP Content Attribute draft-ietf-mmusic-sdp-media-content-02.txt Jani Hautakorpi presented the SDP Content Attribute draft. This version clarifies the usage with offer/answer, but otherwise has no changes from the previous version. The group seemed happy with the draft, which looks to be ready for working group last call. ICE draft-ietf-mmusic-ice-07.txt draft-ietf-mmusic-ice-tcp-00.txt Jonathan Rosenberg presented ICE, summarising changes since the previous version (see slides for details). There were some questions and comments: - Flemming Andreasen asked why the "a=ice-pwd" SDP attribute is session level only, rather than both session level and media level? It has to be shared across all candidates, but that doesn't necessarily imply it is a session level attribute. - Derek MacDonald asked for clarification if reliable 183 can work with "m=" lines that are set to inactive in the 180? Yes. - Magnus Westerlund asked if there is a way of saying "don't send early media" for a particular complete ICE exchange, since this option might be useful for RTSP. Jonathan didn't want to add this for SIP, but it can be added for RTSP in a separate draft if needed. - Magnus Westerlund noted that the current text regarding setting the RTP marker bit is audio-codec specific; this should be clarified. - Rohan Mahy asked for clarification of the 183 retransmit intervals for STUN reliability. - Magnus Westerlund asked if a change in the source address could trigger the RTP SSRC collision detection algorithm? It's not clear that this is an issue, since one can tell it is a change in address rather than a collision through the signalling exchanges. Steve Casner also noted that the wording on SSRC collision detection has changed in RFC 3550, and that may affect this. - Erkki Koivusalo reminded the group of issues with using MAPPED-ADDRESS rather than XOR-MAPPED-ADDRESS and with learning new candidates from connectivity checks, as discussed on the mailing list. Jonathan Rosenberg stated that he considered the draft ready for working group last call apart from minor details. It is expected that an updated draft will be submitted shortly after the meeting to address these, then a working group last call. Jonathan Rosenberg also presented changes to the ICE-TCP draft. This is a major update, due to the changes to STUN and also the recognition that simultaneous open broke the mechanisms in the previous draft, requiring a rework of the specification. There are no known open issues, and there was little discussion (indeed, it appears that few people have read the draft). Joerg Ott asked for volunteers to provide detailed review: Jason Fischel, Rohan Mahy and Francois Audet volunteered. Secure media stream setup draft-baugher-mmusic-sdp-dh-00.txt Mark Baugher presented a new draft on Diffie-Hellman exchanges for multimedia sessions. This adds the ability for sdescriptions to do a Diffie-Hellman key exchange (using a new session level "a=DH:" SDP attribute), providing perfect forward secrecy for media keys, and removing the need for secure transport of the SDP by using public key cryptography. This does not solve the "early media" problem with SIP key establishment, but does reduce the potential vulnerabilities of sending plain text keys and relying on secure SDP transport. Alan Johnston commented that he liked the idea better than the standard sdescriptions. He noted that person to person identification is a MUST, but the draft does not specify how the fingerprint is to be displayed. To ensure interoperability, and standard mechanism should be defined. Erik Rescorla wondered how to propose two different types of DH crypto? This can be done by putting both in the SDP. Cullen Jennings and Joerg Ott noted that there are numerous proposals for updating security negotiation for SRTP, and that this fits within that general space. Discussion of this in comparison with the other proposals should take place within the RAI area meeting. SDP for file transfer sessions draft-isomaki-sipping-file-transfer-01.txt draft-garcia-sipping-file-transfer-mech-00.txt Gonzalo Camarillo presented drafts on file transfer in the offer/answer model. The idea is to describe, using a set of new SDP attributes, the file to be transferred, and so allow MSRP sessions to be negotiated to transfer the file, e.g. as a part of a SIMPLE instant messaging system. Discussion centred on whether duplicating MIME headers in SDP is a good idea, and why content-indirection is not appropriate. There was a fair amount of requirements discussion, to understand why this is useful and to determine the correct home for the work (SIPPING or MMUSIC). There appears to be interest in the work, and it appears to make sense from an SDP perspective, so we should figure out the right home and proceed. RTSP draft-ietf-mmusic-rfc2326bis-12.txt draft-ietf-mmusic-rtsp-nat-04.txt draft-westerlund-mmusic-3gpp-sdp-rtsp-02.txt Magnus Westerlund presented RTSP/2.0, outlining open issues with the base specification. These include: the definition of non-interleaved TCP/RTP/AVP, the inclusion of 50 and 60 frames-per-second SMPTE time code formats, the format of error message bodies, the format of the URI list in 300 responses (multiple choices), whether the dest_addr should contain used addresses, should there be a scoped address for IPv6 multicast, use of unregistered media types in examples, should Expires also provide cache-control instructions, and proxy handling of Accept-Credentials. Details are provided in the slides. Regarding the SMPTE 50 and 60 FPS formats, Stephan Wenger volunteered to help with up a definition for the formats. Regarding the format of the error message body, Colin Perkins and Jonathan Rosenberg suggested stating that the format is HTML by default, with an Accept header being used to signal support for alternatives. Regarding the 200 response URI lists, Joerg Ott wondered why multiple Location headers couldn't be used? Regarding cache control, Colin Perkins noted that explicit specification is usually appropriate, rather than overloading the field, but Magnus doesn't want to diverge from HTTP behaviour more than necessary. Joerg Ott asked if live streams affect the cache behaviour? Not clear. Magnus noted that he hopes to resolve these open issues quickly, and is working with the TLS working group to review the TLS solution. Review of the draft was solicited to get it ready for working group last call: Stephan Wenger and Sean Sheedy volunteered to provide reviews. Magnus also briefly discussed the RTSP NAT traversal draft, noting that there have been no changes since the last meeting, and asking for help to complete the draft. SIP for Streaming Media draft-whitehead-mmusic-sip-for-streaming-media-00.txt Marie-Jose Montpetit presented a new draft on evaluating the use of SIP for streaming media applications. The aim here is to discuss whether it makes sense to use SIP as an alternative to RTSP to control streaming media, if the protocols might somehow be combined (e.g. with SIP for session initiation handing over to RTSP for control), or if the current separation is the best approach. There was considerable discussion on the requirements and use cases. It is clear that the idea of blended services is popular, but it is not at all clear that a combined is needed to achieve them. The authors were suggested to further consider use cases, looking how the existing pieces of protocol infrastructure can be combined to address those use cases, and where potential holes might lie, to come up with a better problem statement for further discussion. QoS Identification for Preconditions draft-polk-mmusic-qos-mechanism-identification-01.txt Gonzalo Camarillo briefly presented a new draft on QoS mechanism identification for use with preconditions. This adds a new attribute to identify which QoS mechanism is to be used to attempt to satisfy a QoS precondition. Flemming Andreasen agreed that this is a good idea, but asked if things like proxy-RSVP could be supported. The general consensus of the room was that this is conceptually a good idea, but not yet sufficiently baked to become a working group draft. Codec Specific Parameters draft-xu-mmusic-sdp-codec-param-01.txt Peili Xu updated the group of the codec specific parameters draft. This was discussed at the last meeting, where it was suggested to consider how existing mechanisms (SDP extensions, SDP grouping, SDPng) might be used. The draft now makes such a comparison. Adam Roach noted that it is much easier to use existing mechanisms, rather than defining a new SDP extension, since there is no deployment challenge. Colin Perkins supported this, noting that codec specific parameters could be supported using the SDP grouping mechanism. Colin also noted that implementations that require codec specific ptime are broken according to the RTP a/v profile (a point which Flemming Andreasen disputed somewhat, noting that there might be legitimate use cases for this). To summarise, it is not clear that there is a problem to solve here that cannot be solved using existing mechanisms. Further clarification of the problem is needed, before we consider defining SDP extensions. Use Cases for Session Mobility draft-komiya-mmusic-session-mobility-usecases-00.txt This presentation was dropped, due to lack of time. IPsec negotiation draft-saito-mmusic-ipsec-negotiation-req-02.txt This presentation was dropped, due to lack of time. - + -