Minutes of the Meeting: MMUSIC working group at IETF 81 ======================================================== The MMUSIC working group of the IETF met at IETF #81 in Quebec, Canada. The WG met on July 29, 2011 from 9 to 11.30. The meeting was chaired by Flemming Andreasen and Miguel A. Garcia. Stephan Wenger, Magnus Westerlund and the chairs took notes. Hadriel Kaplan acted as a jabber scribe. Introduction and Status Update (Chairs) ======================================== The chairs presented the agenda: http://www.ietf.org/proceedings/81/agenda/mmusic.htm No agenda bashing was needed. The chairs presented the status of the working group (see slides): http://www.ietf.org/proceedings/81/slides/mmusic-6.ppt Published RFCs since last IETF: ------------------------------- - RFC 6236: Image attributes negotiation in SDP - RFC 6336: IANA registry for ICE Options WGLC completed: --------------- - ICE TCP (draft-ietf-mmusic-ice-tcp-14) ICE TCP is ready for proto write-up (in progress) - RTSP 2.0 (draft-ietf-mmusic-rfc2327bis-27) Roy Yeu reviewed -27 and the authors have addressed his comments. The chairs recently finished reviewing RTSP 2.0 and the authors are in the process of addressing the resulting comments. Independent Submissions ----------------------- - RFC 6193 (IKE Descriptions in SDP) RFC 6193 is an Informational RFC that defines two new media formats for use with the "udp" protocol. Per RFC 4566, only Standards Track RFCs should register new media types under the "udp" protocol. The two media formats were erroneously registered as SDP attributes, and the RFC was published. The two erroneous attribute registrations have since been removed, however the media format registrations are now missing, and registering them with RFC 6193 being Informational would violate the process described in RFC 4288. A separate agenda item explores a path forward (see below). Progress of other work items ---------------------------- - Media loopback (draft-ietf-mmusic-media-loopback-15) Concerns about the lack of generality latching mechanism described in the current draft and overlap with ICE has been discussed on the mailing list. The authors recently suggested removing the latching mechanism from the loopback draft, and the chairs and ADs agree this is a good path forward. The authors can then decide if they want to pursue the latching mechanism separately. Hadriel Kaplan noted that documents are under the control of the WG, and asked whether this path forward has been discussed and agreed to by the WG. Flemming noted it was suggested by the authors on the mailing list recently and no further comments were received. Hadriel is not in favor of this and would like to ask further on the e-mail list that there is WG consensus on this path forward. The chairs will follow up on the mailing list and see if there are any other comments. - RFC 4566bis (draft-ietf-mmusic-rfc4566bis-03) Mostly done, should keep it open for a while in case some additional fixes are needed - RTSP NAT Traversal (draft-ietf-mmusic-rtsp-nat-10) and RTSP NAT Evaluation (draft-ietf-mmusic-rtsp-nat-evaluation-03) Mostly done, should request publication in August or right after RTSP 2.0 (RTSP 2.0 dependency) - SCTP Media in SDP (draft-ietf-mmusic-sctp-sdp-00) Status update later in this meeting - CS descriptions in SDP (draft-ietf-mmusic-sdp-cs-06) Draft was not updated for this meeting. Pending of addressing comments. Should go to WGLC after that. - SDP Media Capabilities Negotiation (draft-ietf-mmusic-sdp-media- capabilities-11) New version expected in September. Christian Groves asked further about the status of the draft noting that a dependency on this draft in ITU (Megaco/H.248), so would like to see it progress soon. There will be another ITU meeting at the end of November/December, but doesn't sound like it will be available in time for that. Andrew Allen noted that 3GPP has a dependency on this document as well (and icap too). The chairs plan on getting the document to WGLC in the fall of 2011. - IANA registration of 'image' media type in SDP, draft-salgueiro- mmusic-image-iana-registration-07 Document is in the AD-sponsored individual submission. Had a 4-week non-official review (WGLC) in the list, ended on July 15th. Protocol write-up for publication is pending. - DCCP UDP encapsulation for NAT traversal, draft-ietf-dccp-udpencap This is a DCCP work item. MMUSIC has been requested to review the SDP usage. SDP outside of MMUSIC: ---------------------- The chairs noted that there are documents outside of the MMUSIC WG that define SDP extensions, and we should have review of such drafts in MMUSIC (sort of expert review). The chairs are asking for volunteers to review such SDP-related drafts done outside of MMUSIC. The plan is to announce such drafts on the MMUSIC list, and the chairs encourage all the WG participants to take a look at them and send any comments on the SDP parts to the MMUSIC list and draft authors. Keith Drage noted there is an AVTEXT document that will need review fairly soon (just a heads-up). Current version of doc does not have the SDP in it, but the AVTEXT WG has agreed it's needed, so will be added in next version (and doc is getting ready for WGLC). John Elwell noted there is another document in SIPREC that will need review (draft-portman-siprec-protocol). It is currently an individual draft however it is expected to become a WG item at which point it will be sent to MMUSIC for comments. Moving RFC 6193 to proposed standard (Dan Wing) =============================================== Document: RFC 6193: Media description for IKE in SDP RFC 6193 defines a way of using SIP/SDP to bring up a VPN connection. As noted in the WG status above, RFC 6193 was published with incorrect IANA registrations and since it is an Informational document, it cannot register the media types that are defined in there. Dan presented three possible paths forward 1. Change the media types to be in the vendor tree. 2. Adopt RFC 6193(bis) as an MMUSIG WG item, make it Standards Track and register the media types that way. 3. Take the work to another standards body and handle it there. Dan noted that - Option 1 has the problem of not being backwards compatible with existing implementations. - Option 2 would need to be backwards compatible to satisfy existing implementations. A spirited discussion ensued - Magnus Westerlund suggested that IESG approval and AD sponsored were other possible paths forward - Robert Sparks (as AD) noted that IESG approval was already refused and the ADs want input from the community. The document has previously (pre-RFC) been suggested as a WG item, but was not accepted. Also, the document was published via the Independent Submission Track and hence did not receive a thorough IETF review. The IANA registration review process should have captured the problem and rejected it, however it did not. - Cullen Jennings was concerned around following proper process and believed we need to follow the RFC 4566 rules. Cullen suggested use of the vendor tree. - Eric Rescorla suggested that if we decide to solve this problem and assign the media types, then we should not do it by adopting it as a WG item and make it Standards Track, because that would signify something far more important. - Keith Drage noted that, since it as an Independent Submission, the document never went through IETF last call and that there is not IETF consensus around the document. Keith also noted that the document does not mention the registries it expects to appear in and that this needs to be fixed in general. - Shida Schubert noted the draft had been discussed in the group before (3-4 years ago) and not accepted. - Peiyu Yue noted that the Open IPTV Forum is also doing VPN based on SIP, albeit using a different mechanism. - Stephan Wenger suggested we should move on and ask for a WG hum. The chairs then asked the WG for a hum on whether there is interest in using SIP to initiate VPN connections, and if the group wants to adopt this document with consideration for existing RFC 6193 implementations: - There was no interest in the room for working on this topic or adopting the document, and a few were against it. - Option 2 above is thus not a path forward and hence the issue will need to be resolved outside of MMUSIC. Issues with current Bandwidth Modifiers in SDP (Magnus Westerlund) ================================================================== Document: draft-westerlund-avtcore-multistream-and-simulcast-00 Magnus noted there is an IPR disclosure related to the draft. - Hadriel Kaplan asked if we really need this work. Magnus noted this is an existing problem in IMS for example and that video conferencing represents a use case. - Jonathan Lennox thought that video represents a real use case for this due to potentially significant bandwidth variation for video (as opposed to audio). He also noted that there might be some overlapping IPR with something Lennox has (need to look further into). - Jonathan Lennox noted that it is currently describing things on a per m-line and we should consider multiplexing as well. - Charles Eckel suggested we probably want something a little more elaborate (beyond just the per m-line), but something like this seems important going forward, especially for video. - Christian Groves said that if we are introducing a new attribute to replace an existing one, then we need to consider interworking with legacy implementations (especially as we cross domain boundaries). Magnus agreed there needs to be a method to map it down, but Stephan Wenger was not sure this group needs to consider translation mechanisms. - Keith Drage noted that the problem will apply to 3GPP as well, however it has not really been discussed there yet. - Hadriel Kaplan suggested that 3GPP is the most likely customer for this, however we haven't heard from them on this yet, so maybe we should wait. Magnus responded that it is not just for 3GPP. Next steps: - Magnus will submit draft to MMUSIC for just the SDP portions. - Magnus is also asking people to send whatever requirements they have for this mechanism in general so can be addressed in the document (if there is anything needed beyond what is currently specified). The SDP 'trafficclass' Attribute (James Polk) ============================================= draft-polk-mmusic-traffic-class-for-sdp-02 James presented the major changes in his draft based on feedback in the last MMUSIC meeting. - Jonathan Lennox noted that he likes this new version better and that he thinks it is not just for transport-level stuff, but also for e.g. SBCs. Jonathan wanted to think more about multiplex-level as well and he will send some text on that. - Mikael Lundberg (?) thought it is getting to be pretty granular, and it is not clear it really should be (won't have separate DSCP for every single one of these). James responded that not all combinations will have a different DSCP and that DSCP mappings still need to be specified (TBD where, possibly in 4595bis) - Steve Botzko liked the new categorization better as well. Steve is more interested in knowing whether it is for example a staff meeting or customer meeting. James noted this gets more into the Identity area. - Paul Kyzivat asked how this would work with multiplex (e.g. for rtcweb where we would want audio and video to be treated differently). - Paul also suggested we need a structure for the vendor proprietary part of the name space to prevent accidental collisions. The chairs asked for a hum on whether there is interest in continuing work on this with possibility of adopting as WG item later: - There was general interest in working on it with nobody opposed. The chairs will discuss further with the ADs as to whether we can take it on as WG item later on. ICE Updated Offer Problematic (John Elwell) =========================================== draft-elwell-mmusic-ice-updated-offer-01 In a nutshell, can we get rid of the subsequent O/A exchange currently mandated by ICE ? - Dan Wing noted this will put a requirement on other devices, e.g. policy servers and SBCs, to actually understand and support ICE. John responded it is a fairly narrow class of devices that are impacted. - Keith Drage asked what would it mean for the ice-option tag? Would we be redefining it, or just continuing to use it with different semantics. John responded that we need further discussion on whether this departure from RFC 5245 needs to be signaled explicitly (and in a backwards compatible manner). - Christer Holmberg shared Keith's concern around the ice-option tag and backwards compatibility. - Hadriel Kaplan asked if the alternative v4/v6 proposal, draft- boucadair-mmusic-altc-02, which is going through the independent track publication, has anything to do with this? We may want to wait for rtcweb to progress a bit further to see if further ICE changes are needed. - Jonathan Lennox stated that some people have issues with ICE. The chairs asked for clarification on these issues, and Jonathan clarified that it's more what people do not like about ICE. - Bernard Adoba stated that there are no problems doing full ICE on servers. The problems people are experience with ICE are related to IPv6 and its transition scenarios (including NAT64) which seems to introduce new issues that are currently not well understood. Bernard recommended we start building an inventory of these problems. - Dan Wing noted there was a discussion at the Maastricht IETF about problems with ICE, however a resulting document was never published, maybe we should now. - Christer Holmberg agreed it would be good to collect issues with ICE in a document. Next steps: - Keep the ice-updated-offer document alive. - Continue discussion as part of a bigger ICE issue stemming from v4v6, rtcweb, that are yet to be understood. SDP attribute to signal parallax (Bert Greevenbosch) ==================================================== draft-greevenbosch-mmusic-parallax-attribute-01 Bert presented the updated parallax document - Stephan Wenger asked if this work has been discussed with the video standards group (e.g. MPEG). Bert responded that he personally has not. - Stephan then noted that MPEG currently has at least 2 sub-groups working on 3D with potentially competing or complementary solutions. We need to at least let them know about this work and have information exchange. There may be more requirements, etc. - Peiyu Yue said that 3D video coding work is ongoing in MPEG, but he was not aware of anything related to this draft. - Roni Even said the work may be of interest in CLUE as well. The chairs noted that it will be much faster and simpler if we can do informal relations with other groups (e.g. MPEG). The chairs then asked for a hum on WG interest in working on Parallax with possibility to adopt as WG item later. - There was significant interest and a few against (rough consensus). The chairs will discuss further with the ADs as to whether we can take it on as WG item later on. Signal 3D format in SDP (Bert Greevenbosch) =========================================== draft-greevenbosch-mmusic-signal-3d-format-01 Bert presented the updated 3D format document. - Jonathan Lennox asked if you are assuming the model is O/A rather than an announcement (the latter seems a more common use case)? Have you thought about how this works in an announcement model (can't negotiate), incl. where only a subset of users may actually support it? - Jonathan Lennox also noted that multiplexing may be an issue here again. Need to consider how that works (e.g. sending multiple streams in a single RTP session). - The chairs noted that socialization of this work with MPEG applies equally well (if not more) to this draft. Stephan Wenger said it applies even stronger in this case. - Stephan Wenger noted that are several ways of doing 3D, e.g. as individual 2D streams or as integrated 3D codecs doing interdimensional predictions. - Flemming Andreasen (as individual) expressed concerns around getting the requirements right. Does MMUSIC have the right expertise? Need to ensure coordination and review with relevant experts. The chairs then asked for a hum on WG interest in working on this - Strong consensus in the WG to keep working on it. - Authors need to socialize with MPEG (and other relevant standards orgs) to make sure we get requirements and framework right. Media level ice-options SDP attribute (Marc Petit-Huguenin) =========================================================== draft-petithuguenin-mmusic-ice-attributes-level-01 -00 presented in Prague. Some interest in draft. Is there a larger problem beyond just ice-options and need for a general solution - Gonzalo Camarillo said to discuss further in SPLICES since this is part of their charter. - Flemming Andreasen (as individual) agreed there probably is a larger problem, however it seems difficult to address that in a general way for existing attributes. For new attributes though, we should probably make sure to specify them both at the session- and media-level with rules for aggregation as part of that. Marc agreed. - Paul Kyzivat agreed as well. - Jonathan Lennox noted that the ICE spec has certain requirements on what happens if one receives an ICE option they don't understand. What does the draft suggest around this - any change? - John Elwell didn't think SPLICES is far enough along to decide on solution. The chairs then asked for a hum on WG interest in this topic. - The hum indicated little interest, but no opposition either. Robert Sparks suspected that lack of interest is because it's new, and SPLICES need to work more on problem as well. Robert suggested continuing working on it as an individual, building some momentum, and if it's still just a few people interested, talking to AD about AD sponsored. Gonzalo Camarillo also noted that if SPLICES decides to aggregate SDPs, then this issue must be solved. SCTP-Based Media Transport in SDP (Salvatore Loreto) ==================================================== draft-ietf-mmusic-sctp-sdp-00 Salvatore presented the first version of draft as a WG item. - Dan Wing noted that the mechanism seems to specify a re-INVITE, which John Elwell's presentation argued against. Gonzalo Camarillo responded that we are only sending the re-INVITE in certain scenarios and he does not believe it will be same as with ICE in general. - Hadriel Kaplan asked for real-world use case for using SCTP for media. Salvatore noted there was support for the draft on the mailing list. - Adam Roach noted that the draft doesn't support SCTP stream-oriented use cases currently. When we get to the use cases, we will presumably come up with stream-based use cases. Gonzalo was not clear on why streaming wouldn't be supported.