Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes ==================================================================== Reported by Colin Perkins The MMUSIC working group met twice at the 66th IETF meeting (Montréal, July 2006). Topics under discussion included ICE, SIP for streaming media, RTSP bitrate header, SIP preconditions for media privacy, SDP capability negotiation, signalling media decoding dependency in SDP, SDP security descriptions extensions for IPsec, and SDP offer/answer to file transfer sessions. The meeting was chaired by Jörg Ott, Colin Perkins and Jean-François Mulé, and attended by some 120 participants. Introduction and progress report The chairs introduced the session and gave a brief status review. The group has had two RFCs published since the last meeting (RFC 4473 and RFC 4435 on the IMG requirements and framework), and has several more drafts in the AUTH48 state, which should appear as RFCs soon (sdp-new, srcfilter, sdescriptions, sdp-bfcp, kmgmt, media-label and comedia-tls). The sdpng-trans draft is (still) in the RFC editor queue. The security preconditions, media content and FEC grouping drafts are with the ADs. The chairs drew attention to draft-levin-mmusic-xml-media-control-07.txt which is an individual submission to be published as informational after review by the group, describing a legacy XML-based media control scheme. Jean-François Mulé was welcomed as a new co-chair. ICE draft-ietf-mmusic-ice-09.txt draft-ietf-mmusic-ice-tcp-01.txt draft-matthews-mmusic-ice-eliminating-duplicates-00.txt Jonathan Rosenberg described ice-9, noting in passing its capability "of destroying the world as we know it", before moving on to a review of the changes since the -08 version of the draft, and a discussion of the open issues. Open issue #1: what happens if an SBC is in the path and not ICE aware? There was some discussion, initiated by Francois Audet, of how various scenarios might impact ICE processing, and some discussion on the need to document how SBCs can safely work with ICE. The general consensus was to keep the current approach, and consider the design of ICE-aware SBCs later. Open issue #5 "delay checks": limited discussion. Philip Matthews supported sticking with the current approach. Open issue #6 "STUN from TURN": general agreement that this topology is broken, and shouldn't be supported by ICE. Jean-François Mulé suggested it would be good to document which topologies don't work with ICE, as guidance to future system implementers. Open issue #2 "Pairing peer derived with other candidates": Philip Matthews expressed concern that this shows that one of the assumptions behind of ICE (that candidates only need to be peered with peer-derived candidates, not all candidates) isn't true, and wondered if there will be other cases where this is a problem. Cullen Jennings noted that this is a problem because there is no STUN server in the left-most inner realm in this scenario: he considers this a broken network design, and not something we should support. Much discussion around the issue of which topologies we wish to support, but no agreement. No resolution of this open issue. Open issue #8 "too complicated": Jonathan suggested a rewrite of the ICE specification to reduce complexity, changing the implementation style, not the basic operation. Tim Hall noted that this is how they implement ICE now, and that it works and is indeed simpler. Francois Audet agreed that a reduction in complexity is appealing, not noted the risks of a major rewrite to the specification at this late stage. Philip Zimmerman noted that many vendors say "we don't support ICE yet", and if this is due to the complexity, spending the effort here might be worthwhile. Philip Matthews described his alternative proposal to eliminate duplicate checks in ICE. There were many questions for clarification. Open discussion followed. Key points were as follows: - Francois Audet agreed in principle with the need to simplify, but saw little indication that the specification was converging on a stable version. This discourages developers, and we really need to agree a single stable proposal. Cullen Jennings agreed: he also doesn't want to wait for several more IETFs worth of discussion. - Robert Sparks, Jason Fischl, and Eric Rescorla strongly supported the need to simplify the specification, and to rework the document so that it makes sense to implementers instead of being written for the working group. If they had to make the choice, they would prefer simplifying the draft rather than keeping backwards compatibility with previous versions of ICE. - Tim Moore stated that they've implemented the Jonathan's initial "big idea" without any trouble, and that the result is compatible. That said, even with the simplification, this is a complex protocol, and he isn't sure the delay to simplify is worthwhile, since the result won't be enough simpler. - Rohan Mahy expressed the opinion that the goal of ICE is to make things more predictable, work more often, and be more optimal; in that order. He considers it counter-productive to go too far in terms of complexity for optimisation. Simpler is better. Tim Moore and Derek MacDonald agreed, also preferring simplification to optimisation. - Rohan Mahy noted that a use cases document saying, "these topologies are broken, these work" would be really useful. Jörg Ott summarised the impression of the discussion, noting that there was little support for further optimisation work, but conflicting views on how to simplify the protocol (indeed, to what extent this is just a presentation choice rather than an algorithmic difference). To move forward, Jonathan agreed to produce a revised draft by six weeks after the meeting, implementing his simplification proposal, which should be discussed in an interim teleconference. Philip Matthews and Eric Rescorla volunteered to help with the editing process. A strong hum backed this plan. An Evaluation of SIP for Streaming Media draft-whitehead-mmusic-sip-for-streaming-media-01.txt Marie-Jose Montpetit discussed use of SIP for streaming media, with an outline of the rationale for using SIP to signal RTSP sessions, the use cases, and the derived requirements. Dave Oran asked if the authors have considered MRCP for media control? Rohan Mahy agreed, noting similarities to the proposal, and suggesting the authors include MRCP in their requirements analysis. Bitrate header in RTSP draft-wei-mmusic-rtsp-bitrate-header-01.txt Kylin Wei outlined a proposal to add an RTSP bitrate header, to allow selection of transport bitrate. This aims to avoid the problem of big SDP session descriptions, when including many alternate streams, moving the complexity into RTSP instead. Colin Perkins noted Magnus Westerlund had sent an extensive rebuttal of this draft on the mailing list, and asked that these points be addressed. Discussion was moved to the list. Use of SIP Preconditions for Media Privacy draft-shacham-sip-media-privacy-02 Henning Schulzrinne briefly presented a draft on SIP preconditions for media privacy. The aim is to signal preferences, to get user agreement on whether a session can be recorded, as part of session establishment. Rohan Mahy asked what's to stop someone recording anyway? Clearly this cannot be enforced -- it's a fancy version of the "recording beep" used in some jurisdictions and conveys preferences only. Flemming Andreasen wondered why preconditions are the right tool here, rather than using some sort of header? Because it'll delay setup until the answerer agrees to the recording preference. Jonathan Rosenberg was of the opinion that this would be better suited to a header, and is not different from the other headers a system must consider when accepting a call. Mark Baugher noted that this may be legally dangerous without integrity protection, since a middlebox could modify to SDP to add or remove the precondition specifier. SDP Capability Negotiation draft-andreasen-mmusic-sdp-capability-negotiation-00.txt Flemming Andreasen presented a new draft on SDP capability negotiation. He reviewed the background to capability negotiation in SDP, and went on to discuss requirements: Req-10 "MUST be possible to indicate/negotiate alternative (combinations of) media formats on a per media stream basis: Jonathan Rosenberg, Rohan Mahy, Francois Audet and Roni Even expressed the opinion that this is a useful feature, but didn't show great enthusiasm. Jonathan noted that RFC 3264 does talk about this already, and wondered how much generality is needed: this is "a little bit ugly, but not broken". Not sure we need to put too much effort in here; we have a workable band-aid already. Req-20 "MUST be possible to indicate and negotiate alternative attribute values on a per media stream basis": Magnus Westerlund wondered why this is needed on a per-media stream basis, rather than describe capabilities in a more general fashion? Not clear that capability exchange should be done in SDP offer/answer at all; use a better protocol. John Elwell saw a need for alternates, but not sure about on a per-media level basis: what about session-level? Stephan Wenger noted that if you want to capture even a small amount of the power of H.245, you need this. Req-30: (as with req-20) Req-40: (no objections) Req-50: (no objections) Req-60: (people don't seem to think this is important) Req-70: (people don't seem to think this is important) Req-80 "MUST be backwards compatible with SIP and RTSP": Magnus Westerlund was not sure about the inclusion of RTSP, since there's no SDP negotiation in RTSP. Req-90: Steve Casner was not sure about the need to be backwards compatible for all protocols. It might be acceptable to have a solution for SIP with offer/answer, but not for all, to ease the constraints? Req-100: Both Magnus Westerlund and Jonathan Rosenberg expressed doubt that this is possible, thinking that at least 1.5 RTT will be needed. Req-110: (no objections) Req-120: Jonathan Rosenberg wondered how does this would work with early media? Req-130: (no objections) Req-140 "SHOULD be efficient in terms of message size": Jörg Ott was not sure this was important, given the size of existing SDP messages. Magnus Westerlund and Colin Perkins noted that caching and compression could be used to reduce the impact of message size. Tom Taylor noted that MEGACO specified a binary protocol for this reason, and is worried about message size. Others supported this concern: keep it small, if possible. Req-150: (no objections) Req-160: (no objections) In conclusion, Magnus Westerlund wondered about the implications of the work, since there is a claim to want to avoid the complexity of SDPng, yet the discussions are in that space. Jonathan Rosenberg expressed the opinion that backwards compatibility would kill SDPng, even if the full set of features it provides might be useful, and that we should do something simpler. He is unconvinced that more than profile negotiation is needed, though. Cullen noted that it's easier to do a blank-sheet solution, but we don't have a viable migration plan, so this will need to be an ugly incremental solution. To summarise: there is interest in this work, especially to solve the urgent security negotiation problem. We should move quickly. Signalling of media decoding dependency in SDP draft-schierl-mmusic-layered-codec-00.txt Thomas Schierl gave an overview of the draft on signalling dependencies for layered media codings, such as SVC. There was no discussion. Security Descriptions Extension for IPsec draft-saito-mmusic-ipsec-negotiation-req-02.txt draft-saito-mmusic-sdes-ipsec-00.txt Makoto Saito presented work on using sdescriptions as an alternative to IKE to negotiate IPsec keying material. Eric Rescorla was of the opinion that this idea is "fundamentally misguided": the reason IKE is complex is because people want to negotiate complex things, he doesn't see that this will simplify or provide useful synchronisation with the media session. Also the proposal you make requires deployment of S/MIME which is "less than total", limiting the viability of this proposal. Dan Wing proposed an alternative scheme, using a certificate fingerprint in SDP to bootstrap IKE setup. It would be useful if discussion of this alternative could occur on the list. SDP Offer/Answer Mechanism to Enable File Transfer draft-garcia-mmusic-file-transfer-mech-00.txt Miguel Garcia updated the group on a set of SDP attributes to allow file transfer sessions using MSRP. Steve Casner wondered if having all these as separate attributes a good approach, rather than defining a single new attribute? Not clear we need to use so much of the attribute space. There was some discussion of using content-indirection, but is was clarified that this is solving a different problem. There was general agreement that this is reasonable, and should become a working group item (subject to chartering). Multiple aggregated control URIs for RTSP draft-einarsson-mmusic-rtsp-macuri-00.txt Ingemar Johansson's presentation on multiple aggregate control URIs for RTSP was cancelled due to lack of time. Controlling FLUTE sessions with RTSP draft-lohmar-mmusic-rtsp-flute-00.txt Ingemar Johansson's presentation on controlling FLUTE with RTSP was also cancelled due to lack of time. - + -