IETF 78 Monday, July 26 2010 MMUSIC WG meeting notes Notes reported by Jean-Francois Mule About 40 people attended the IETF MMUSIC WG meeting. Tom Taylor and Jean-Francois Mule chaired the meeting. --- 1. WG Update - Chair presentation ===================================== Tom Taylor presented the WG update - see slides at http://www.ietf.org/proceedings/78/slides/mmusic-0.pdf for details. Comment re: Media Loopback draft (draft-ietf-mmusic-media-loopback-14.txt) Brian Rosen : we need this work to be done. Willing to find volunteers. Hadriel Kaplan : same, need an RFC status. Jean-Francois: close the open issues by listing them on the list. Additional comments were made related to the circuit-switched (CS) draft and whether it belongs to an ICE extension for nettypes or SDPcapneg. Hadriel added that CS is more capneg than ICE. Jonathan Lennox indicated that we should have a common solution to IPv4/IPv6 and CS. We scheduled an adhoc meeting right after the MMUSIC meeting concluded with the interested parties (Jonathan Lennox, Simo Veikkolainen , Roni Even , Tom Taylor and Jean-Francois Mule). Separate notes will be sent on the outcome. A bar Bof on IPv4-IPv6 and ICE was organized independently for Wednesday evening by Dan Wing to discuss the complexity of ICE and what to do about it. --- 2. RTSP 2.0 =============== draft-ietf-mmusic-rfc2326bis-24.txt Martin Stiemerling presented the list of issues closed in draft-23. See charts at http://www.ietf.org/proceedings/78/slides/mmusic-1.pdf for details. Comments: Based on comments from James Polk and Gonzalo Camarillo , the RTSP handling of 503 responses is related to the whole SIP overload related work and the SOC WG. There was consensus in the MMUSIC Working Group that while overload in SIP and RTSP are not the same, the RTSP authors should look at the SOC work to decide whether to change the text for the 503 response and overload handling in general. Tom Taylor thanked Magnus Westerlund and Martin for their work on getting RTSP/2.0 to this stage. The draft is close to final after the WGLC complete milestone and the comments that were addressed during WGLC. Pending resolution of the 503 issue, the work on RTSP 2.0 will conclude. --- 3. SDP Media Capabilities ============================ draft-ietf-mmusic-sdp-media-capabilities-10.txt Roni Even presented the updates. See charts at http://www.ietf.org/proceedings/78/slides/mmusic-3.pdf. More reviewers are required and a comment was made that some work at ETSI may generate interest from reviewers there. The plan is to issue WGLC on this update. --- 4. ICE TCP ============== draft-ietf-mmusic-ice-tcp and draft-lowekamp-mmusic-ice-tcp-framework. See charts at http://www.ietf.org/proceedings/78/slides/mmusic-2.pdf. Ari Keranen is the new editor for ICE TCP. He summarized the current status and proposed next steps. Jonathan Lennox commented that the good thing about all the methods you can use (NAT PMP, UPnP IGD, socks, etc.) is that they do not need to be supported on both sides. Therefore they should not all be mandatory to implement. Adam Roach commented that ICE is important as part of the IPv6 migration strategies and we should think about ways to insist on that (a MUST/SHOULD to include IPv6 addresses?). --- 5. Media Path Middleboxes ============================= draft-ietf-mmusic-media-path-middleboxes-03.txt This was not covered during the meeting. The authors have promised an update in the near future. --- 6. Traffic Classification of SDP ==================================== draft-polk-mmusic-service-class-for-sdp-00.txt James Polk presented his updates and proposals to indicate the type of media traffic inside SDP. See charts at http://www.ietf.org/proceedings/78/slides/mmusic-4.pdf. Jonathan Lennox commented that the proposed classes of traffic may lead to confusion. James clarified that they are part of RFC 4594 but that he would be open to define them better (or others in the draft). Tom Taylor pointed to ITU-T Recommendation F.700 as a document that may be useful to read. Based on a question from Roni Even, James clarified that using DSCP markings inside a domain is one option but there may be different policies per domain based on the traffic classes. Based on comments and questions from Roni Even, Colin Perkins , Dave Oran , Gonzalo Camarillo and others, it is important to: + clarify in the draft that there is no guarantee that this will work end-to-end + specify more clearly inside the document whether this is a receiver or sender capability or both. There was confusion on whether this draft is a way for the sender to indicate how the receiver should mark the packets when receiving them, or whether it is a sender capability (this is an indication of how the sender will mark packets when sending them). Some expressed comments that if this is a sender capability, the value is diminished except for middle boxes. + have use cases and requirements more clearly communicated in the draft. The meeting was adjourned an hour early.