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:

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_MMUSIC&chapter=chapter_1

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)

draft-ietf-mmusic-sdp-bundle-negotiation-36

11:25-12:10        ICE-related Issues (35 mins, Christer Holmberg)

draft-ietf-mmusic-ice-sip-sdp-10

draft-ietf-mmusic-trickle-ice-sip-05

Introduction and Status Update (Chairs)

The chairs presented their slides with the agenda and an update about the activities since the last meeting.

Agenda comments:

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].

RTCWeb Dependencies

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:

• There are RTCWeb documents that reference 4566bis currently. It was not immediately clear whether they truly needed to reference 4566bis or whether a 4566 reference would suffice. Cullen Jennings agreed to look further into whether 4566bis indeed is a dependency or not [Action: Cullen]
• Christian Groves noted that the data-channel-sdpneg draft might introduce a dependency due to the updated IANA registration procedures. Cullen confirmed that.
• The mux-attributes draft also references 4566bis now (introduced during IETF Last Call).
• Ted Hardie suggested a downref exception to deal with this issue.
• The Area Directors (Alissa Cooper and Ben Campbell) noted that mux-attributes has already been IETF Last Called and approved by the IESG. The ADs and Chairs will discuss further off-line on how to proceed [Action: Chairs, ADs]
• Cullen noted that 4566bis itself has a normative dependency on draft-iana-charset-reg-procedure, which will obsolete RFC 2978 but currently seems stalled. Cullen will send an e-mail to the MMUSIC list (incl. Ali Begen as 4566bis author) on the iana-charset draft reference and how 4566bis may be able to be a reference the existing RFC 2978 instead [Action: Cullen]

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.

Bundle (Cullen Jennings)

draft-ietf-mmusic-sdp-bundle-negotiation-36

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].

ICE-related Issues (Christer Holmberg)

ICE-SIP-SDP

draft-ietf-mmusic-ice-sip-sdp-10

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: Original mechanism was also to detect middle-boxes that muck with the SDP. This would break that. Also, BFCP case is a problem.
• Eric Rescorla (EKR): Does not believe anybody is actually doing anything with this mismatch check today. Anybody that feel otherwise should produce some strong evidence.
• Adam Roach: Change mismatch detection to check on all ICE candidates.

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:

• Backwards compatibility is important (incl. for the BFCP case)
• It needs to work in the general case (i.e. beyond RTCWeb)

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:

1. When an endpoint switches transport, it does not need to send an offer in order to align the m-line transport with the new transport
2. When an offer is sent for another reason, the m- line transport shall match the currently used transport

• What if offerer and answerer use different transports?

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]

Trickle-ICE-SIP

draft-ietf-mmusic-trickle-ice-sip-05

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.