Draft Minutes of the Multiparty Multimedia Session Control (MMUSIC) Working Group ================================================================================= Reported by Jörg Ott Notes by Colin Perkins The MMUSIC WG met once at the 68th IETF. The meeting was chaired by Colin Perkins, Jean-Francois Mule, and Jörg Ott. The meeting was attended by some 120 participants. 1. WG Status ------------ Jörg Ott reviewed the working group status. Since the last IETF, three RFCs were published: RFC4585 (SDP for the BFCP), RFC4756 (FEC grouping syntax for SDP), and RFC4796 (media content identification in SDP). The SDPng transition document is still with the RFC editor but will most likely be withdrawn (as SDPng will not proceed as a standards track document). One Internet Draft (draft-ietf-mmusic-securityprecondition-03.txt) is currently with the IESG; a revised I-D is needed. draft-ietf-mmusic-connectivity-precon-02.txt is essentially done and just waits for ICE to progress. The two capability negotiation documents draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt and draft-ietf-mmusic-sdp-capability-negotiation-05.txt have progressed well (see agenda item below). The drafts related to Internet Media Guides (IMGs) are basically dead due to lack of interest. They may be published as individual efforts but will be removed from the charter. A presently open issue is the fate of RTSP 2.0. There has been significant effort until a while ago, leaving a well-advanced specification which, nevertheless, requires a lot of work to completion. The chairs have pursued putting together a review team to further the work. Three individuals already expressed their interest; additional volunteers are solicited. The review team will be formed in April 2007. As future directions for the working group, the WG chairs outline the foremost need to finish ICE followed by the media capability negotiation. This priority also governed the WG meeting in Prague. The WG will then be rechartered. 2. ICE ------ draft-ietf-mmusic-ice-14.txt draft-ietf-mmusic-ice-tcp-03.txt Jonathan Rosenberg started presenting draft -14 of ICE (see the slides for the details). Jonathan briefly reviewed the changes since -13 He then went on to discuss a recently identified bug (slide 15). Jonathan proposed a simple tie-breaker rule as an easy fix. Concerns were raised concerning using the "ufrag" as suggested by Jonathan. Discussion arose whether one should use a timer which was considered expensive by some. A tag or cookie could be used to make tie breaking explicit. It was agreed to add a new attribute to the STUN request, indicating whether a node is the controller plus a tie breaker. Further discussion concerned whether aggressive mode should be dropped. It was decided to keep it address the (otherwise legitimate) concern that ICE might incur too much delay. It was also noted that aggressive mode may be run for some checks but not for others. Jonathan discussed the interactions between ICE and ANAT (RFC4091). ANAT allows an offerer and an answerer to choose whether to use IPv4 or IPv6 addresses for a media stream. Similar functionality is achieved by ICE when feeding both IPv4 and IPv6 address candidates into the ICE connectivity checks. This is a clear overlap in functionality for which clear rules should be specified. Jonathan identified five alternatives and sketched their respective mode operation): 1) ANAT alone 2) ICE alone (deprecate ANAT) 3) ICE+ANAT 4) SDP capability negotiation (deprecate ANAT) 5) SDP capability negotiation + ICE Jonathan argued that dynamically determining connectivity is better than statically configuring/negotiating addresses. ICE includes the ANAT functionality and should supersede it. Some discussion took place with pros and cons raised concerning the use of ANAT and ICE, with tentatively more people in favor of ANAT. In favor of ANAT, it was argued that this would be more lightweight than all of ICE and that you not need ICE if you had an all-IPv6 deployment. Counter-arguments included that one can never be sure about the deployment scenario (ruling out IPv6-only in the near term) and that thus ICE needs to be implemented anyway. Doing ANAT now and ICE anyway would just increase the burden. The issue of backwards compatibility in case of deprecating ANAT was also raised, but no real ANAT deployments were known, so this was considered a non-issue. While most of the discussion circlered around ANAT vs. ICE, one voice was also raised in favor of SDP capability negotiation. Generally, the group was eager to obtain a decision right away. A hum revealed very rough consensus on option 2). Counting hands revealed 12 for and 5 against this prooposal. Of those 5, none wanted ANAT alone (option 1), 2 were in favor of ICE+ANAT (option 3), and 1 voted for SDP capability negotiation (option 4). Because of the limited number of views, another show of hands was asked, revealing that 12 further people did not believe to have sufficient information at this point to make a decision. Since the matter was considered urgent, it was agreed to return to this decision on Friday during the SIPPING WG meeting and definitely take the decision then. Jonathan also addressed ICE-TCP for which he had two open issues to address. For issue 1 (who sends the ClientHello with TLS), he suggested to define new attributes and add to ICE TCP to be explicit. This was supported. For issue 2 (use of connection resumption with TLS), he considered this not really an issue as this would work without any explicit language in the draft; it should only be pointed out that resumption gets used as for regular TCP. An issue was raised about STUN and TLS: does one first uprade TCP to TLS and then run STUN or first run STUN and then initiate TLS. Do the STUN keepalives run inside or outside TLS? Could one use TCP keepalives? Does one need application level keepalives? This needs resolution and was taken as an open issue to the list. For the changes to ICE< Jonathan committed to do everything except the ANAT part right away and include the latter after its resolution. Additional meeting time was allocated for the Friday SIPPING WG meeting. Follow-up as part of the SIPPING WG meeting on Friday (23 March). During this additional meeting, further discussion ensued. There was rough consensus to use ICE alone for future address type selection and deprecate the use of ANAT in the future. 3. ICE-lite ----------- draft-rescorla-mmusic-ice-lite-00.txt Eric Rescorla presented his approach to ICE lite which may be used by devices that can be sure that have a public IP address and want to use ICE but not bother about actively performing all the ICE maintenance functions. The ICE lite document is supposed to provide an overview of the operation and pinpoint all that an implementer has to do in a way that the implementer does not have to understand all of ICE. The major issue to be decided is whether such a document shall (a) replicate the text from ICE (once ICE is done) or (b) provide only pointers to the corresponding section in the ICE document. During the subsequent discussion both these alternatives were supported by multiple participants. It was found that truly normative language should only be provided in a single document. ICE lite behvior will thus be part of the basic ICE spec but ICE lite will point out what the relevant pieces are. It was questioned what the actual value-add of such a document would be. Finally, it was suggested to defer ICE lite until ICE itself is done. Given the variety of different opinions it was found to worry about ICE itself first and come back to ICE lite once ICE is done. 4. SDP Capability Negotiation ----------------------------- draft-ietf-mmusic-sdp-capability-negotiation-05.txt draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt Flemming Andreasen presented the status of the SDP capability negotiation work. He started by giving an IPR notice from Cisco (see slides and the IPR section on the IETF web site). A design team has worked since the last IETF, holding weekly conference calls. The original single capability negotiation document was split into one for the requirements and one on the proposed base solution. (A further document defining media capabilities will be discussed seperately by Roni Even). The requirements document stabilized quickly and is essentially done. Flemming went on to present the core capability negotiation mechanism for which there are no known open issues. One aspect worhtwhile discussion came up in the design team: a base SDP spec defines a set of attributes. What should the extensions support: 1) adding attributes, 2) deleting attributes, and/or 3) modifying attributes (see the slides for some background information). Flemming outlined three alternative solutions (see slides) and suggested to go with solution 3: providing explicit syntax to add or remove attributes. This stipulated quite some discussions. Some were concerned about complexity (do you need anything than adding?) but counter examples were given where this would be useful. Colin Perkins noted that the complexity does not result from the add/delete/replace part but rather from supporting potential configurations in the first place. Other people found this not to be too complex. It was pointed out that receiving and interpreting received capabilities will probably be straightforward, but that generating efficient representations may not. While some did not consider this to be an issue, others pointed out that the previous version of the draft seemed ok but adding delete/replace felt bad. It was also stated that this addition dramatically reduced human readability. Further speakers wanted to see good reasons for delete/replace as it seemed rather theoretical. It was also pointed out that this may come too late for those interested only in best-effort RTP (which was commented to appear, again, somewhat shortsighted. To ensure readability, a model description should be included explaining the terminology used. NOT INCLUDED: - hadriel kaplan: much improved in version 5. - colin suggested, if you don't want to support delete, then pretend you don't support any of this. that's a bad idea. better to make it a new version. - this won't get through sbcs. the answer picked has the new transport: some sbcs will complain that the answer doesn't match the offer (i.e. the offer is rtp, but the answer is srtp, and the sbc notices and shuts things down because of the changed transport...). hard to fix :-( For the next steps, the general feeling is that the documents are on the right track. But better motivation (i.e., use cases) shall be given for replace/delete and it should be made clear that an implementation can actually generate such SDP. Henning Schulzrinne suggested talking to implementers and is concerned about mixing syntactic and semantic representation in a single document. He suggested multipart MIME which was found not to be backwards compatible, however. Francois Audet was concerned that this solution was not addressing what they were trying to solve for Best error SRTP. Joerg Ott pointed out that SDP has a history of point solutions making it a mess; longer term thinking is needed. It was agreed to have an ad-hoc discussion on Tuesday night of interested parties to continue discussing the issues raised above. 10. Wrap-up The meeting was adjourned. The following items on the agenda could not be addressed due to time constraints. 4. SDP Media Capability Negotiation draft-ietf-mmusic-sdp-media-capabilities-01.txt 5. Signaling media decoding dependency in SDP draft-schierl-mmusic-layered-codec-03.txt 6. Source-Specific Media Attributes in SDP draft-lennox-mmusic-sdp-source-attributes-00.txt 7. The 'MSR' Bandwidth modifier in SDP draft-hdesinen-mmusic-oa-send-bw-attr-02.txt 8. Media Description for IKE in SDP draft-saito-mmusic-sdp-ike-00.txt 9. Configuring DiffServ for SDP established media draft-polk-mmusic-dscp-attribute-01.txt The chairs felt that the above items -- ICE and SDP capability negotiation -- were urgent to address and deserved all the time necessary to move ahead on them.