Minutes of the Meeting: MMUSIC Working Group at IETF 95

The MMUSIC working group met at IETF #95 in Buenos Aires, Argentina on Tuesday April 5, 2016 from 10:00 to 12:30.

The meeting was chaired by Flemming Andreasen and Bo Burman

Magnus Westerlund, Roni Even 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=IETF95_MMUSIC&chapter=chapter_1

Below is the final agenda with links to the relevant sub-sections below:

Tuesday, April 5, 2016 (Quebracho B), 10:00-12:30  (150 mins)

10:00-10:15 Introduction and Status Update (15 mins, Chairs)

10:15-10:45 Do we need mux-exclusive ? (30 mins, Christer Holmberg & Eric Rescorla)

        draft-ietf-mmusic-mux-exclusive-03

10:45-11:30 DTLS-SDP and multiple fingerprints (45 mins, Christer Holmberg)

        draft-ietf-mmusic-dtls-sdp-11
        draft-holmberg-mmusic-4572-update-01

11:30-11:50 IANA Registry Structure for SDP Attributes (20 mins, Christian Groves & Paul Kyzivat)

        draft-ietf-mmusic-rfc4566bis-16
        E-mail thread:        https://mailarchive.ietf.org/arch/msg/mmusic/m1cLR0BsgLNyEneoO5QZfdO1Fpc

Introduction and Status Update (Chairs)

The chairs presented their slides with the agenda and an update about activities since the last meeting, which generated the following comments:

• The chairs noted that MMUSIC was scheduled at the same time as TLS so a few people with interest in the agenda items were missing.
• Magnus Westerlund noted that RTSP 2.0 and NAT AUTH48 is going slow; it will likely be another month before finished.
• Christer Holmberg was asked what is holding up sctp-sdp draft and clarified it is waiting on the dtls-sdp draft.
• Christer also noted that Bundle has already passed WGLC

Do we need mux-exclusive ? (Christer Holmberg)

draft-ietf-mmusic-mux-exclusive-03

Christer presented his slides where he presented the current solution and various alternative solutions.

Current solution: rtcp-mux-exclusive [slide 4]

Jonathan Lennox: SDP has no way of indicating mandatory extensions. The only way of adding that now would be with a SIP option tag.

Alternative solution: ICE Option [slide 6]

Christer not really keen on this option; also not entirely clear how you deal with unsupported options in ICE.

Alternative solution: SDP 'rtcp' attribute [slide 7]

Christer's original suggestion

Alternative solution: Do mux only [slide 8]

Adam Roach: Think we will run into problems with Websockets systems that will go to regular SIP. Think something will get lost in that translation – don't believe you can do this.

Cullen Jennings:

• Don't agree with the assumption that we need a gateway to interwork between WebRTC and SIP; the whole premise of the work has been to enable interop without a gateway.
• Don't believe this solution is acceptable because it requires knowledge of whether endpoint is WebRTC endpoint or not.

Next Steps / Way Forward

A discussion about the different possible solutions ensued - the major comments are provided below:

Peter Thatcher: Should consider how easy it is to update the endpoints to support the a= solution we chose.

Cullen: How many people in the room are really clear on the problem ?

<not that many it seems>

Jonathan Lennox explains the problem:

1. Fundamental problem is SDP cannot indicate "mandatory" extension so we are always stuck with mandatory fallback (basic SDP does not have a way of rejecting a media line due to unsupported extensions)
2. People don't want to do mandatory fallback

Without mandatory fallback, then someone that doesn't do a=rtcp-mux will result in that RTCP will be sent to a port where the peer is not listening. This will eventually trigger RTP circuit breakers and stop media flowing after some time. What we want is either do rtcp-mux or reject the offer.

Cullen: So problem is we will send RTCP somewhere and it will be dropped on the floor. How much of a problem is that though ?

Lennox: Not clear it's really a problem.

Roni Even: It can happen today - not clear it's really a problem.

Harald Alvestrand (commenting on rtcp-mux-exclusive [slide 4]): Believe the part saying "Will not be implemented by future non-mux endpoints" is wrong). Believe we should stay with the current solution.

Cullen: So, there will be some RTCP dropped on the floor - not the end of the world.

Magnus Westerlund: Clarifying that media will not continue to flow (after the RTP circuit breaker trips)

Cullen: The issue is simply in error reporting. If rtcp-mux-exclusive was supported the media line would be rejected. Without it, media will not really work. So the difference is in the error reporting and the elegance with which it is handled.

Justin Uberti: Why do we need to add more garbage to SDP (like "rtcp-mux-exclusive") ? Endpoints will have to be updated - why can't we just use the "rtcp:0" solution [slide 7]

... Missing some discussion ... by Harald, Cullen and Jonathan.

Justin: Using port 0/9 looks like a better solution. That avoids adding more garbage to new users.

Roman Shpount: Don't like adding more garbage either.

Justin: One reason to adding an indicator is to enable a gateway to add a on path function to gateway between mux and non-mux. Think a port 0 is simpler and does not require adding more attributes.

<more discussion between Justin and Roman, including if “a=rtcp” could be skipped when used in a context of ICE, but that is not allowed by "a=rtcp-mux" in RFC 5761>

Cullen: We are signaling "I am doing a subset of SDP...". It is critical we signal this somehow. The question is how we signal it. Not sure whether we used "rtcp:0" to mean something else already (e.g. hold). We will need to check carefully.  

Peter Ford: Support "rtcp:0"

Paul Kyzivat: Thinks "rtcp:0" is better than rtcp-mux-exclusive.

Jonathan Lennox: What happens in implementations with port 0? Some send to port 0, rather than interpreting as special value.

Andy Hutton: The rtcp-mux-exclusive is clearly the most clean solution. The 0 port in a=rtcp looks like more dangerous.

Harald: No strong opinion as long as we don't do implicit - have to signal this.

Justin: Port 9 cannot be used as that indicates trickle ICE prior to any trickle candidate is being sent.

At this point, the chairs asked for hums on the following:

Should the solution include explicit signaling ?

• There was strong consensus to have a signaled solution.

Is there anybody that cannot live with either "rtcp:0" or "rtcp-mux-exclusive" ?

• Nobody objected to either solution

Do you prefer "rtcp=0" or "rtcp-mux exclusive ?

• "rtcp=0": A somewhat weak hum plus 4 people in the Jabber room
• "rtcp-mux-exclusive": A medium hum plus 1 person in the Jabber room
• Overall, the result was inconclusive between the two. Furthermore, a couple of key stakeholders in the (mailing list) discussion were not able to attend due to the TLS session conflict
• Most people agreed that it is more important to have an expedient way forward than which one it is

Conclusion

• There will be a signaled solution
• The solution will be either "rtcp=0" or "rtcp-mux-exclusive"
• Christer will discuss further with the missing stakeholders and report to the group afterwards.
• Based on this, the chairs will try to find a consensus way forward, which will be discussed further on the mailing list.

DTLS-SDP and multiple fingerprints (Christer Holmberg)

draft-ietf-mmusic-dtls-sdp-11

draft-holmberg-mmusic-4572-update-01

Christer presented his slides

Jonathan Lennox: Multiple fingerprints - at least one fingerprint per hash function that one support must be matched, because you don't want a downgrade attack.

Roman: Another use case is connecting multiple devices through one offer by the signalling. Thus an offer may contain multiple fingerprints that all will not match.

Cullen: Normally we require that one uses the strongest hash that matches. And that needs to be one that you consider strong. Requiring that all hash functions match appears too strong.

Roman has sent an email to the list with his views.

Christian Grooves: Do we have an interaction with PERC use cases for multiple fingerprints?

Jonathan: Not in the current design proposals, as there is only one participant DTLS association with the KMF not one with each MDD and KMF.

The chairs asked for hums on the following:

Should the WG take on this work ?

• Strong hum in favor of adopting the draft (nobody opposed) - incl. Jabber room.

Should we adopt draft-holmberg-mmusic-4572-update-01 as starting point for this work ?

• Strong hum in favor of adopting the draft (nobody opposed) - incl. Jabber room

Roman: Can we join the documents between the DTLS-SDP?

• Christer: No
• Jonathan: Prefer not as 4572 applies also to TLS.

Conclusion:

• A new work item will be created and draft-holmberg-mmusic-4572-update-01 will be adopted as a WG draft for this (subject to mailing list verification and AD approval)

IANA Registry Structure for SDP Attributes (Christian Groves & Paul Kyzivat)

draft-ietf-mmusic-rfc4566bis-16

E-mail thread:        https://mailarchive.ietf.org/arch/msg/mmusic/m1cLR0BsgLNyEneoO5QZfdO1Fpc

Christian presented his slides

Cullen: RFC 4572 is a good example. It updates the base spec, and a chain does exist.

Flemming (as individual): It would be good if the registry indicated if there are MUX considerations.

Paul Kyzivat: It is a slippery slope, as we first had only had session and media level, then we added source level. Then DSCA which is like session. There is a difference between registries with stable documents, as the information is available in the doc. This is different for First come, first served, then you need all the information.

Flemming (individual): It is a question of personal preference, but we should have basic info available.

Cullen: No strong opinion, but have you talked to IANA about what they think?

Roni: What is the purpose of the registry ?

Christian: Would people be okay with basic collapse and then allow multiple references?

Flemming (individual) supports being more explicit, so including DCSA would be a preference.

Cullen: Encourage to have reasonable information available.

Jonathan: There will never be enough information to implement the attribute, so one only need to find what is needed.

Alissa Cooper: Don't forget the original purpose of avoiding collisions.

Chairs: Do talk to IANA. Take the conclusion to list.

Paul, the current structure of different table for different usage is a mess. This will become worse.

Alissa: IANA works for us, the WG decides, i.e. we need to let IANA know what we would like them to do.

Cullen: DSCA is another level. Collapsing into a single table is a good idea. The open question is what additional information should be included. Ask IANA what input and experience on expanding the information that is provided.

Flemming (individual): Wants additional levels, but is okay with three columns.

Ben: Use the role to keep it simple, but not simpler than is needed. But don't replicate all information.

Roman: Single table with no levels, simplest solution is best.

Jonathan: No more additional levels than the three shown in Issue #3 slide.

Ben (individual): No reason to take away information that is already there, unless it causes pain. Check if we need to include the full table, or only restructuring instructions.

Conclusion:

• Chairs: No objections to proceed with the structure shown on Slide 8 (Issue #3). To be confirmed on list.