Minutes of the Meeting: MMUSIC Working Group at IETF 88

The MMUSIC working group of the IETF met at IETF #88 in Vancouver, BC, Canada.

The MMUSIC WG met on Monday November 4, 2013 from 9:00 to 11:30 and on Thursday November 7, 2013 from 9:00 to 11:30.

The meeting was chaired by Flemming Andreasen and Ari Keränen.

Roni Even, Bo Burman and the chairs took notes on Monday.
Richard Ejzak, Suhas Nandakumar and the chairs took notes on Thursday.

Jonathan Lennox acted as Jabber relay on Monday, and Ted Hardie acted as Jabber relay on Thursday.

The meetings were broadcast live and recorded by the Meetecho team. The recordings of the sessions are available at the following URLs:



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


Monday, November 4, 2013

09:00-09:15        Introduction and Status Update

09:15-09:35        The Session Description Protocol (SDP) Application Token Attribute

09:35-09:55        A Framework for SDP Attributes when Multiplexing

09:55-10:25        Interactive Connectivity Establishment (ICE)

10:25-10:45        Using Interactive Connectivity Establishment (ICE) in Web Real-Time Communications (WebRTC)

10:45-11:00        Happy Eyeballs Extension for ICE

11:00-11:15   Meta-data Attribute signaLling with ICE

11:15-11:30   Improving ICE Interface Selection Using Port Control Protocol (PCP)
Flow Extension

Thursday, November 7, 2013

09:00-10:30        Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers

10:30-11:00        Using Partial Offers and Partial Answers in a Multimedia Session

11:00-11:30        Using Simulcast in RTP Sessions

Introduction and Status Update (Chairs)

The chairs presented their slides reviewing the status of the working group, including drafts currently being worked on. The chairs noted that

need review and list feedback.

msid draft


sctp-sdp draft

The Session Description Protocol (SDP) Application Token Attribute (Roni Even)


Roni presented his slides

Roni noted:


Colin Perkins: a=ssrc has same problems and specifies its own set of rules for resolving conflicts between SSRCs; should look at and see if we can reuse similar resolution here.

Kyzivat: How does this work when receiver hasn't received the SDP yet? Problem if the sender doesn’t know that the receiver did not see.

Lennox: You can send the appid information in every packet if you want.


Colin Perkins: Of course RTP and RTCP are unreliable. Packets may get dropped.

Lennox: Always possible to lose packets to render stream useless. Believe can construct in such a way that it works when the stream is otherwise usable.

Perkins: Can send these things to have high probability of success, but cannot guarantee success.

Lennox/Perkins: Discussion around assumptions being made. Lennox believes they are reasonable, but Colin believes they may not always hold nevertheless.

Colin: Comes down to implementation robustness; will have to be able to handle failure since not guaranteed reliable. Lennox agress.

Justin: Thought you would send for n seconds in the beginning to make more robust. Still not a guarantee that it works. If you only get one through, that is enough.

Roni: Can look at RTCP to see if there were packet loss and then decide.

Harald: Sending same information in 3 different ways makes things 3 times more complicated.

The fact that we are doing so much extensions to work around RTCP being not reliable implies that we are doing it wrong. Suggest solving the reliable RTCP problem instead; TMMBR/TMMBN is one example where RTCP is made to be reliable. Propose the model to repeat the message as often as needed. Suggest also to introduce a reliability mechanism for RTCP, which belongs in AVTEXT instead of MMUSIC.

Lennox: It's not like CNAME. Might be a better discussion for AVTEXT. Probably belongs there

Harald agrees it belongs in AVTEXT. Two issues here: Unreliable RTCP and use of header extension.

Justin: Is appid sometimes a replacement for msid?

Justin: Question around scope. How do you demultiplex things like RTX?

Justin: Now seems to go in a different direction than thought we agreed to in unified-plan.  Seems like scope has grown to have a different way of doing multiplexing.

Lennox: One app-id per m-line was original intent, but when looking more into it, not clear it works for every case.

Justin: Just trying to understand intent.

Lennox: Intent is to have a layer of indirection for SSRC and m-lines. Working through the details of how to do it.

Magnus: app-id solves certain set of problems, but there are scenarios where you cannot even assign app-id ahead of time. Still think this is probably worth doing.

Cullen: Not sure he understands Magnus' concern. Magnus clarified and Cullen countered it seems the scope is larger than he thought.

Roni: We will try to get a better document by next week.

Conclusion: The chairs stated we have heard several comments on scope. Please make sure to be very crisp on scope of problem to be addressed for next time around.

A Framework for SDP Attributes when Multiplexing (Suhas Nandakumar)


Suhas presented his slides

Q1: PT Reuse

Harald: slide 4 example is forbidden by bundle spec:


Magnus: Does not understand the problem. You are referring to media blocks, so what is the problem ?


Justin: Same payload type is being used for audio and video? Thought that was not allowed.

Suhas moving on to proposed solution to answer the questions (two proposals)


Colin: Though we discussed in last meeting and thought we had agreed that you can always reuse payload types if the configurations are identical, and the only issue was to define what we mean by "identical"

Suhas OK with that.


Justin: Does it create an issue to have rtcp-fb turned back for one line, but not the other ? Is that the same configuration or not ?


Colin: Part of the issue with the example is that only a portion of the SDP is shown. If you had the SSRCs included here as well, then not clear there's an issue.  Think we need to see more of the SDP to determine issue.

Magnus: Yes, there are cases where certain rtcp-fb does not make sense.



Q2: SSRC Repetition


Magnus: Invalid example in Example 1. Must have different SSRCs when using bundle.

Colin: What does example 2 mean ? Cannot mean they are different streams

Lennox: FEC group doesn’t' seem to be written correctly in the example (example 2).

Justin: Still having a hard time understanding this example (what are we trying to show). Too many errors here to come to a conclusion.

Cullen: What should we put in the draft here ?

Magnus: Needs to say that if the SSRC is the same across m-lines, it really needs to be the same stream on the wire.

Colin:  Agree, if it is not identical you cannot do it.

Martin: Need better examples as to why we need this. Didn't think Lennox's example were convincing. Why do you want to describe the same stream on multiple m-lines?

Ekr: If we were to do this, there is really no re-use.

Magnus: Main question is whether we need the FEC stream in a separate media description.

Jonathan: Agree with Colin.


Suhas proposal: Don't think we should allow SSRC to be repeated.


Q3: Mux RTP with Non-RTP




Q4: O/A vs Declarative SDP

Flemming (as individual): What do you understand with O/A vs declarative SDP? There can be declarative attributes in an O/A, and I do think we have to do that.

Colin: Is BUNDLE draft related only to O/A?

Jonathan: We need to define that.

Colin: Depends on how the BUNDLE spec defines it.

Discussion on what declarative SDP means and whether it's in scope for Bundle or not. Need discussion and clarification on that.

Interactive Connectivity Establishment (ICE) (Ari Keranen)


Ari presented his slides

ICE username fragment length


Martin: It's not actually a bug, just an inconsistency. Don't really care what we do here.

Justin: Will have impact on ICE bandwidth; username can be by far the biggest part of ICE packets. Should have a more realistic recommendation (SHOULD NOT be longer than x, e.g. 32 or 64). Can specify that new implementations must not send larger than x, but all must be able to receive according to old spec.

Cullen: Believe we wanted to allow for side-channel information originally, but doesn't seem like a good idea now. Supports Justin proposal.

Martin: Believe ~20-40 characters would be sufficient.

Ekr: Propose MUST NOT use more than 32 MUST accept 256.

Conclusion: Recommend shorter user-name (MUST NOT send more than 32 characters, MUST accept receiving up to 256).

Connectivity Check Pacing


Justin: Have experiment in Chrome to find out safe spacing. Preliminary data shows no difference between 20 ms spacing and no spacing at all (applies to both UDP and TCP).


Martin: Biggest concern now is number of packets and bandwidth used and that's what we should be thinking about (seems NAT binding spacing is no longer an issue)


Cullen: Would be good to bring it down from 20 ms, maybe to 5 ms. Not surprised that the numbers may change. Agrees this should be measurement driven. Very shocked to find that there is no impact with no spacing (based on code he's seen). Would be good to get some lab measurements for some well-known specific NATs.


Note: The above pacing discussion was for the purpose of not overloading NATs. The below moves into pacing for congestion control (slide 6).

Ekr: People will just use the lowest value allowed.

Cullen: Don't think transport ADs will be happy with different congestion control mechanisms for ICE than for other types of congestion. Also need to think about what level of traffic we consider to potentially induce congestion; the Internet has changed in the last 20 years.

Justin: Would like to see someone verify numbers. We will have numbers to share in the next couple of months.


Martin: Pacing is just one part of the solution. 20 ms is probably fine (comes out to ~65 kb per seconds which is equivalent to G.711).


Cullen: Believe we need something like this. Good idea to have O/A negotiation of pacing and pick the higher of the two.

Ari: OK, will include negotiation.




Martin: You must be able to bail out if you don’t know all extensions. Might want to have notion of mandatory extensions with negotiation support (if not supported, then reject). ice-options does not provide that.


Justin: Aggressive nomination is another use case to consider in terms of negotiation and ability to fallback.


Aggressive Nomination Bug


Martin: Would like to eliminate the attacker scenario regarding the aggressive nomination bug.

Justin: If you make sure you can decrypt the packet before you count it, then should not be an attack concern.

Martin: Use DTLS

Justin:  It would make sense to send more checks; use consent.

Ari: So use a combination of mechanisms. Will update text.


If you don't use secure data then keep sending at regular intervals.


Ekr: For this to actually happen, path 1 will have to be very broken. As long as you continue running checks it should succeed (keep retransmitting).


Updated Offer Proposal


No time for discussion; discuss further on mailing list

Using Interactive Connectivity Establishment (ICE) in Web Real-Time
Communications (WebRTC) (Martin Thomson)


Martin presented his slides

Cullen: The attack traffic seems to be 150 Kbps; not 3 Mbps. This is based on it being globally spaced. If that's not clear in the spec, then it's need to be fixed.

Martin: Not entirely clear in the spec.


Ekr: We just talked about lowering the spacing from 20 ms, at which point the bandwidth usage goes up. Seems like we have an issue, irrespective of what the actual bandwidth number above is. Could use circuit breakers as fallback.


Justin: 100 candidate pairs; is that global limit or is that per ICE agent ?


Option 1: Oops Hack

Martin believes this is the most workable short-term solution



Option 2: Hard Work

Ari: Talking about Ta or RTO? Think the two might have been confused.


Ekr: Think we should have a global cap. Solve DOS problem first, and then see how it works.


Martin: With global pacing, it's important to ensure no ICE agent can starve any other ICE agent.


Ari: Should some of this be covered in ice-bis ?


Paul: Will you do anything about competition between multiple browsers ?

Happy Eyeballs Extension for ICE (Pål-Erik Martinsen)


Pål-Erik presented his slides

Martin: What is intent with the document ?


Ari: Are you sure the mechanism works (sent mail to mailing list last night)? Have you implemented this (does it work for candidate pairs, not just candidates ?


Lennox: We need to make sensible recommendations in how we set peer reflexive candidate priorities. Two interesting cases.

  1. Works better if both sides support it.
  2. Works no worse if only side supports it.


Dan Wing: Purpose of document: Just want the ideas to go forward before 2020 (don't necessarily want to wait for ice-bis to finish before we get this problem solved).


Martin: Most of what this draft covers is covered by a SHOULD in 5245. Think it's worth doing; put a few extra steps in to ice-bis. The way forward might be to say in ICE bis how you prioritize. I don’t care about the algorithm.


Justin: Example shows server reflexive being prioritized over host candidate; is that really intended?


Ari: If this gets more complicated than a simple change to the priorities, in order to get out ICE bis before 2020, this should be an extension.


[didn’t capture Lennox /Martin ?]


Cullen: Another ordering option is based on latency. Should consider that as well. Jonathan's point around continuously learning and keep improving selection is another good observation. Suggest authors propose some changes to the text around candidate prioritization.

Martin: With aggressive nomination you might have some problem there.

Lennox: Draft is a lot better than the previous version.

Meta-data Attribute signaLling with ICE (Pål-Erik Martinsen)


Pål-Erik presented his slides

Magnus: Same security issues as with RSVP. Putting it into STUN/ICE doesn’t solve the issues. MMUSIC is not the right place. Should be BOF level.


Justin: Had a bunch of people asking about ad-hoc ways doing QoS. The idea of having something to talk to network is appealing. Not clear we need to have the network add stuff, but do need ways of enabling network to provide QoS for certain flows.


Martin Stiemerling (as Transport AD): There might be people that like this. Modifying STUN packets looks shaky to me. Think you are mixing things. Also think that this is much larger scope than MMUSIC. Get more community feedback and consider BOF level.


Shiva(?): See it as being useful when making distinction between cellular and WiFi interfaces.

Cullen: Don’t know what it’s useful for. As an authenticated way of transporting information to and from network nodes; maybe. What to use that information for is more unclear.


Conclusion: The chairs note that they see some some interest, but probably larger in scope. Get more community feedback and consider BOF.

Improving ICE Interface Selection Using Port Control Protocol (PCP)
Flow Extension (Dan Wing)


Dan presented his slides

Zahed Sarker: How long is information about network links valuable especially for cell-and Wifi-based networks ? Conditions and bandwidth change all the time.


Randall Jessup: So one request; multiple replies (as conditions change). When do replies stop ?


Lennox: Is PCP seeing substantial deployment at this point ?

Jonathan: What will the status of this proposal be for ICE (bis)?

Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers (Christer Holmberg)


Christer presented his slides noting there are open issues that have been discussed on the mailing list for quite a while. The following refers to each of these as Qx for Question number x:


Q6: Do we allow a shared address in an Offer, before the Answerer has indicated BUNDLE support in an Answer (associated with the dialog)?



Decision (stated by the chairs): Christer's proposal is accepted by the WG.



Q8: How do we ensure, before the Answerer has indicated BUNDLE support, that a ‘bundle-only’ m- line is only accepted if the Answerer supports BUNDLE?


ISSUE1: 3264 O/A says if Offer sends a m=line with port 0 the answerer must respond with port 0 as well. This needs changing the spec.

ISSUE2:  If port zero is specified then an intermediary may not route media correctly.

Solution for ISSUE2 is the Bundle Address Synchronization (BAS) should take care of updating the right port.


Q8a: PROPOSAL: Use port zero

– Once the Answerer has indicated support of BUNDLE, the BUNDLE address is assigned to ‘bundle-only’ m-lines in subsequent Offers (including the BAS offer)


Decision: Chair prodded room and calls WG agreement with "use port zero"




ISSUE: 3264 does not allow answering with a non-zero value to a zero value offer

SOLUTION: Need specification work


Decision: Flemming (chair) asking room for clarification on whether we see this as an update to 3264 in general or simply an extension.


Decision: Chair (Flemming) states that WG agrees that we "need specification work"; details of the work is TBD




ISSUE: Intermediaries will not route media correctly (until BAS Offer is sent)

SOLUTION: Will be taken care of by the BAS Offer


Decision: Chair (Flemming) states that WG agrees with the proposed solution. Also, it was pointed out that things may not work with existing intermediaries anyway.


Q9: What are the criteria for allowing usage of the same PT value within multiple m- lines?


Christer's PROPOSAL: Use proposal [see slides: page 6] as base – Continue work regarding details on individual SDP attributes etc.


Decision: Chair (Flemming) states the WG agrees with Christer's proposal


Q12: Scope of non-RTP media de-mux procedures in BUNDLE?

  1. RTP/RTCP + Data channel/SCTP
  2. None
  3. Others?

NOTE: BUNDLE itself does not restrict which media types can be multiplexed – the question is which media types will be covered by the base BUNDLE spec.




Decisions (chair states):

  1. Group agrees that we need generic procedures and guidelines but specifics for anything other than SRTP will be described in those other specifications.
  2. No decision at this time about data channel bundling but there is a strong assumption that it will be supported.

Using Partial Offers and Partial Answers in a Multimedia Session (Adam Roach)


Adam presented his slides


Handling Groups (Open Issue 1)


Second option (slide 5):


Third option (slide 6)

Open Issue 1 Example (slide 7)




a=group:FOO a b c


a=group:FOO b c

m=blah ...


a=add-group:FOO g1

m=blah ...


a=add-group:FOO g1

a=add-group:FOO g2

m=blah ...


a=add-group:FOO g1

a=add-group:FOO g2



Issue 1a: New Groups


Conclusion: Adam agrees with Martin's suggestion to the mailing list and we should pursue that.


Open Issue 2: Multiple Changes


Adam's Recommendation: Revise document to allow multiple media section changes in a single partial offer, but add strong warning about increased chance of glare. Nobody disagreed with that.



Open Issue 3:  Multiple Outstanding Offers

Adam's recommendation:    Keep as-is (only allow one outstanding partial offer at a time).


Conclusion: Follow Adam’s recommendation.


Open Issue 4: Overlapping media section “add” with one side rejecting the partial offer


Adam's Recommendation: Media lines are not sorted, are not applied to session while any partial offers (sent or received) are pending.


Ambiguity 1: Changing Bundle Port


Adam's Recommendation: Prohibit this. If the BUNDLE port needs to be changed, that’s cause for a full offer/answer.!



Ambiguity 2: Reordering

Adam's Recommendation: Clarify that in-order delivery of signaling messages is prerequisite for using this mechanism.

Clarification: Must be in-order and reliable (and also cover trickle-ICE).


Conclusion: General agreement on this in the room.


Bikeshed Color Choice 1: MIDs!

If there’s some way to own a prefix for creation of MIDs, we don’t need to worry about randomness!  – Have ideas? Send text.!


Next steps:         Chairs note that based on group feedback, it seems like the work is on the right track and ask group if anybody believes otherwise. Nobody indicated any disagreement.

Using Simulcast in RTP Sessions (Magnus Westerlund)


Magnus presented his slides


Slide 17: ("a=sim-send:b c:inactive")

  1. 3 different streams I can send and switching between them
  2. Want to send same stream in 3 different resolutions simultaneously.

We have to be very clear in our signaling which of the two we are talking about.


Slide 19

Slide 22 asks if the document is a good starting point for a WG item ?

Conclusion: Chairs summarized that the discussion shows we are not ready to go forward with the proposal.

Cullen noted that there are use cases for receiving different resolution versions of the same stream. Bernard stated it starts with the sender but does affect the browser since it might want to switch between different resolutions

Flemming (as chair) then asked about RTCWeb dependency on this work ?