Minutes of the Meeting: MMUSIC Working Group at IETF 97
The MMUSIC working group met at IETF #97 in Seoul, South Korea on Wednesday, November 16, 2016 from 11:10 to 12:10.
The meeting was chaired by Flemming Andreasen and Bo Burman.
Suhas Nandakumar, Brian Rosen and the chairs took notes, and Jonathan Lennox acted as Jabber relay.
The meeting was broadcast live and recorded by the Meetecho team. The recording is available at:
Below is the final agenda with links to the relevant sub-sections below:
11:10-11:15 Introduction and Status Update (15 mins, Chairs)
11:15 - 11:25 Bundle (10 mins, Cullen Jennings)
11:25-12:10 ICE-related Issues (35 mins, Christer Holmberg)
The chairs presented their slides with the agenda and an update about the activities since the last meeting.
Cullen Jennings suggested an action item to move data from JSEP into Bundle - an agenda item to discuss that was added
Martin Thomson asked to close issues on the RFC 4572 update as agreed on the list
WG Status comments:
RTSP NAT is still in Auth48 - author approval is all that is needed at this point. The chairs were asked to ping the authors on AUTH48 approval [Action: Chairs].
4566bis is currently not listed as an RTCWeb dependency and hence has not been a priority for MMUSIC, however RTCWeb believes 4566bis indeed is an RTCWeb dependency:
4572-update is currently listed as an indirect RTCWeb Dependency for RTCWeb. With the recent changes to 4572-update, this will now be a direct dependency.
The RTCWeb JSEP draft (https://www.ietf.org/id/draft-ietf-rtcweb-jsep-17.txt) includes some text (in Section 6) around how to handle RTP packet processing and associate them with the right media description. Cullen has discussed this with a few folks already and believes the bulk of this text (with some modifications) should move to the bundle draft. Cullen wanted to give people a heads-up in this meeting.
Cullen will issue a pull request on the bundle draft (and the JSEP draft) with those proposed changes and send them to the mailing list(s) for review [Action: Cullen].
Christer presented his slides, which cover issues that have been raised on the mailing list.
Default Candidate in SDP Answer
The issue is around the offerer and answerer using different transports for their default candidates: RFC 3264 Offer/Answer does not allow for different transports in the Offer and Answer.
Christer's suggestion is to remove the requirement to include the default candidate in the c/m- line of the SDP answer.
Several people initially indicated support for this, however subsequent discussion made it less clear:
Jonathan Lennox proposed a slightly modified solution. The details will need to be written up and sent to the list for discussion.
Conclusion: Jonathan Lennox to write-up modified solution proposal and send it to the list for discussion. [Action: Jonathan]
Non-Supported Transport in m- line
The issue is around the answerer not supporting the transport in the m- line of the offer SDP, yet the answerer does support the transport in one or more of the corresponding ICE candidates.
Christer had two alternative suggestions for consideration.
Discussion indicated that most people favored the second option ("allow answerer to include transport in c/m- line even if it doesn't support it"), while noting the following:
The chairs issued a consensus call which indicated a strong consensus for option 2.
Conclusion: Move forward with option 2 and confirm on the list [Action: Christer]
Transport Switch and O/A
Consider two endpoints negotiating a media session using both UDP- and TCP-based candidates.
Christer believes the following clarifications are needed:
Jonathan Lennox: Don't believe the question in the bullet point under 2 is valid. Can only happen with update before nomination.
Further discussion had to be cut short since the meeting was ending and hence a conclusion was not reached in the meeting.
Christer will send the text proposal to the mailing list for further discussion [Action: Christer]
The meeting ran out of time and the presentation had to be skipped.
The chairs noted that we should probably ask for more than a 1 hour slot in the future since we seem to be short on time even with just a few agenda items.