Minutes of the Meeting: MMUSIC Working Group at IETF 89

The MMUSIC working group met at IETF #89 in London, England on Monday March 3, 2014 from 9:00 to 11:30 and on Thursday March 6, 2014 from 9:00 to 11:30.

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

Markus Isomäki, Martin Thomson, and the chairs took notes on Monday.
Stephan Wenger, Adam Roach, and the chairs took notes on Thursday.

Jonathan Lennox acted as Jabber relay on Monday and 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, March 3, 2014

09:00-09:15        Introduction and Status Update

09:15-09:30        Happy Eyeballs Extension for ICE (15 mins)
Trickle ICE (30 mins)
ICE bis (30 mins)
Using Simulcast in RTP Sessions (30 mins)
SDP-based "SCTP over DTLS" data channel negotiation (15 mins)
MSRP over WebRTC data channels (15 mins)

Thursday, March 6, 2014

09:00-09:40        Multiplexing Negotiation Using SDP Port Numbers (40 mins)

09:40-10:10        A Framework for SDP Attributes when Multiplexing (30 mins)

10:10-10:30        The SDP Application Token Attribute (20 mins)
WebRTC MediaStream Identification in the SDP (20 mins)
SCTP-Based Media Transport in the SDP (20 mins)
Using Partial Offers and Partial Answers in a Multimedia Session (20 mins)

Introduction and Status Update

Chairs presented the slides

Thanks to Gonzalo for 4 years of AD service.


Agenda bashing: No comments


WG status: published one RFC, 4 drafts in the RFC editor queue, requested publication for 3 drafts. UDPTL draft getting ready for WGLC.


Happy Eyeballs Extension for ICE


Pål-Erik presented his slides 

Martin Thomson: Asking for clarification on the problem we are solving; are we trying to ensure consistent priority lists on both sides. Martin believes the algorithm proposed here will result in both peers having the same priority, which is what we want

Jonathan Lennox: Because of pair priority formula even if one side is insane we will get the same list on both sides.

Martin: Same concern as always; you are specifying a very particular algorithm. Seems that you can’t break anything with local preference. Hence it seems more appropriate to give advice and allow for implementations to make their own decisions based on the knowledge they have regarding their network etc. Algorithm here works, but is only one particular choice with certain properties. Some with something better should be allowed to deploy that.

Bernard Adoba: Agrees with Martin's comments. Deployed this 4-5 years and found they needed to play with the priorities in some cases, e.g., with tunneled candidates. If you pick an algorithm, there will always be scenarios where it's not optimal. Don't think we should standardize a particular algorithm.

Ari Keränen: If you do not know anything about the network, it’s good to have some common choice so that both ends do similar things

Martin: agree with Ari, if you don't do similar things on both ends, you won't get desired result (e.g. different ordering issue). That's not to say we need to specify a particular algorithm. The value in this draft is identifying the pitfalls and giving advice around how to deal with them.

Ari: Think it's more than an example. If you know the situation in the network you can do better than this algorithm. Therefore it should not be a MUST but having a SHOULD/RECOMMENDED as a fallback algorithm would be good idea. Maybe having more text about the cases where you know more about the situation makes sense (e.g., preferring tunnel candidates as Bernard explained).

Bernard: Some tunnels may be known to be OK, and hence you would change priorities on those.

Ari: and you mean type priority?

Bernard: yes

Jonathan: Sounds like we want a section with recommended principles; these are common pitfalls, etc. Here is an algorithm that does the right thing if you don't have anything better. Also Happy Eyeballs for web does something a bit different: you remember what worked the last time and do things based on that.

Ari: Should we have this kind of recommendation here too?

Jonathan: Most of what is here is flawed implementation stuff we are trying to deal with. Can consider MAY strength.

Ari: it’s OK if we only play with priorities but if we e.g., drop candidates then it doesn’t work

Jonathan agrees


Ari as chair: What do we want to with draft? All seem to agree that this is important and need to be fixed. But should this be separate or integral part of ICE bis? As the editor of ice-bis, would lean towards having a separate draft (happy eyeballs is getting somewhat lengthy)

 Pål-Erik: For now good to have as separate draft to pinpoint issues but in the end either way is OK.

Bernard: Depends on what you will say in ice-bis regarding address prioritization.

Ari: idea of ICE-bis was to have only small fixes and changes, this is getting a bit bigger than that

Bernard: Maybe should weaken the requirement in ICE-bis for certain kind of prioritization. Not a good idea to have ICE-bis saying something opposite of this draft. Then a separate draft would do.

 Flemming as chair:


Trickle ICE




Emil presented his slides  

Trickle ICE spec nearing completion; believe we can hit the milestone date on that one.

Additional open issue not in slides: how bundle could end up using different ports. Will cover in Trickle ICE for SIP.


Asking for reviewers.


Jonathan: Question on doing components in order: What happens when you don't have the same foundation for all components. For example distributed media case, or one fails. Effectively fall back to vanilla ICE? Need to say something about how to handle that.

Emil agrees.

Trickle ICE for SIP


Slide 23 (Any Trickle – Answer)

James Polk: Which 183 answer was received?

Emil: which ever; they’re identical

Martin: regarding PRACK/INFO hack; assuming that you are doing full trickle, the a=end-of-candidates is only possible if you have actually finished.  Doing the hack would actually require that you have candidates to send, or can you send an empty INFO?

Emil: If you do full trickle, you would send candidates in this. If not, empty INFO sounds possible. Good point, need to add that.

Jonathan: RFC5245 hack still works?

Emil: not necessarily; 5245 hack is that you sen 183 untill you  get connectivity checks, but you may not have sent any candidates.

Jonathan: 3/4 trickle with the option to trickle extra candidates to a peer that supports trickle (but not a plain 5245 implementation).

Emil: some (non-list) discussion before; basically idea would be to start doing half trickle that would work with 5245 agents, but still keep the option for adding additional candidates if turns out one supports trickle ICE. Should work since we keep end-of-candidates. Good idea and can add that.

Emil: All INFOs should contain all candidates. No need to worry about misordered or delayed INFOs or wait until 200 OK received for INFO before sending the next one. This has been suggested by Dale and will add that.

Jonathan: Have to make sure that you can always uniquely identify which candidates you have received before. Maybe priority comparison is good.

Emil: Chrome sends non-unique priorities. May be forbidden by 5245. Think you have to go for full string comparison

Jonathan: Would IP and transport port be sufficient? For example, if priority changes dynamically.

Emil: yes, should do

Emil: still individual draft. Is this the right way to go?

Flemming (chair): Double-checking with SIPCORE chairs that we are in the right WG with this doc. SIPCORE chairs (Paul and Adam) believe so (doesn't belong in SIPCORE and seems reasonable here).

Emil also notes that DISPATCH sent it here.


Martin: Are people actually planning to do this in their SIP stacks?

Emil: We will do this

Bernard: Think it's probably the best you can do. Not sure he would implement it, but that doesn’t mean anybody else shouldn’t.


Enrico Marocco: would really encourage people considering relaying or doing something from the browser to SIP world to do this. If you don’t plan to interface with Trickle agents you can ignore this, but otherwise unless you have something in between that does Trickle you seriously should consider this.

Flemming (chair):

Asking WG for interest in adoption of Trickle ICE SIP document. Clear consensus for adoption.



Adam Roach: Double check on "in no particular order"

Emil: order would mean semantics and that would be for usage specific spec.


Martin: The main reason to say “use mid" is you have just one way of doing this.

Emil: Didn't want to require use of "mid", but if it seems it's needed anyway (e.g. POF/PAN needs it) and people not concerned with it, then can require it. To remind everyone: mid is here just as a way to match particular fragment to an m-line in previous offer.


Adam: minimal we need is “this is something you get when taking any syntactically valid SDP and eliminating the lines you want to”. I also see that in future we may not want to use mid but leverage this. Making as open as “any order” would make it difficult.

Emil: you can’t do semantical processing with just this.

Adam: there are orders which fields are expected to appears. For example, finding “t= line”. So you want to stick with the order they’re conceivably found in SDP body.

Emil: worried of case where we’re looking for “the offer” that contained all this etc.

Martin: Increasing problem space is the problem. Need to have something that uniquely correlates it with what you’re modifying.

Emil: not necessarily modifying

Martin: modifying in very broad sense. Adam's concept is "this is just SDP with stuff taken out".  Interesting way of thinking but makes difficult to do things like “a= lines”; which comes last. And would you like to have c-line for certain m-line.

Emil: should that semantic be defined here?

Martin: want some general semantics to deal with the fragment.


Christer: Concerned about race conditions with UPDATE and having this refer to an old SDP

Emil: with Trickle ICE there would be sequence number that would help with that

Martin: 3264 doesn’t allow removing sections. Hopes that mid is a stable identifier, and if not, we could make it so. Suggesting that you don’t re-use m-lines; may need to say this in the draft.

Christer: good to describe these cases.


Chairs note various issue brought up now and not much text in draft. Need to see a bit more content before we can consider WG adoption.

Emil: agreed and all-open for additional authors for the fragment draft.


October 2014 seems like a reasonable deadline for Trickle ICE with SIP. And SDP fragment draft needs to be done together.


ICE bis


Ari presented his slides

Slide 2: (Aggressive nomination bug & Username fragment issue)

Emil: Having same priority in different candidates is problematic: if not already part of ice-bis, then we should add it. Ari agrees but believes this already exists as MUST but will have to check.

Justin (revisiting comment at the end of time-slot): with regular nomination you have discretion which pair to use. Would be nice to have this with aggressive too to avoid the extra RTT. Will do a proposal on the list.


Slide 3 (Connectivity Check Pacing)

Ari: decided that we need to update the value but the new value should be based on real-world experience and measurements. Google guys had measurements going, any news on that?

Justin: Experiments are on-going but have to get back with more details.

Ari: need something concrete before going to the transport guys with this.


Slide 4 (Connectivity Check Pacing Negotiation):

Typo on slide: Should be "higher" instead of "lower of the two"

Jonathan proposing that ice-pacing can have the answerer pick a value, that must be greater than or equal to the offered value

Ari agrees with change.

Emil: What if the value is absent? If we’re using RFC 5245 values does that mean 20ms?

Ari: Then for RTP you can use the formula from 5245 but otherwise you use the defaults from 5245 (i.e., 500 ms for non-RTP).

Jonathan: including the attribute would be mandatory unless you like the 5245 values

Ari: Seems we have agreement on proposed change, so will update draft accordingly.


Slide 5 ( (no-)need-to-understand ice-options)

Jonathan: Requires header in SIP would be the way to make the call fail. Might instead have a case where you fall back to 3264

Emil: Reiterates his concern expressed on the list. How the failure would happen?

Ari: you would act as if ICE wasn’t there at all

Jonathan: Maybe we need something equivalent to ice-mismatch for options (ice-unsupported-options)

Ari: based on the discussion options-optional seems useful, how about options-required?

Martin: reason for proposing was that we’ve seen behavior from ICE agents that was bad. Sending checks they shouldn’t do. Having way to say “don’t proceed” would be good. SIP-requires is right, probably don't need unsupported, can learn that by having tokens absent from ice-options in answer.

Ari: So options-required will leave out for now. Could have SDP draft saying that if -required kind of functionality is needed, the Requires header is the right way.


Slide 6 (SDP syntax for extensions)

Jonathan: do we have existing use of these and does that conform to this syntax?

Martin: yes and yes

Magnus Westerlund: Consider specified delimiter between extensions.

Martin: If VCHAR includes space we have a problem, but otherwise it's OK.

Ari: Need to check.

Jonathan: SDP grammar defines another construct, non-ws-string instead of VCHAR we may be able to use. But need to be at least *VCHAR.

General agreement with proposal (restrict syntax, but has to allow for multiple VCHARs; still need to verify if space is covered by VCHAR; if so need to change proposal)


Slide 7 (TURN candidates & privacy)

Justin: Don't think we need to do the port 9 thing here. Use the any address and port zero instead.

Jonathan: Have one concern with middleboxes and use of "any address", might apply QoS on INADDR_ANY. Should ask middlebox folks if that may be a problem.

Ted Hardie: Think that problem would solve itself quickly ;-)

Ari: will change the port to 0 and check with middlebox folks

Slide 8 (Multiple ICE agents)

Jonathan: Would you negotiate the pacing?

Ari: Yes, this would be use-case for the pacing negotiation

Jonathan: Still worried about setting connectivity check pacing value low initially, and then a lot more agents start up.

Martin: Covered this in draft (draft-thomson-mmusic-ice-webrtc-01). Don’t start with most aggressive pacing but you make room for extras.

Jonathan: Need to think about the context for this. Seems reasonable within a browser (potential hostile environment), but not so for a telephony gateway.

Ari: Agrees with point; need to clarify in the draft.


Ari: Is this issue important enough to work on

Tim Terriberry: Anywhere an untrusted third-party can create agents is where this should be used. So browser yes, but probably not a call centre.

Martin: can come up with text “if you think you should be doing something to protect for this, you should”. Just something more concrete.

Justin: Care about global ICE pacing for RTCWeb. Don't know if we need something fancier than that.

Martin: A global rate-cap seems reasonable; still have some concerns with pacing. Is probably worth having language dealing with that.

Justin: Believe the text can be fairly simple.

Ari: Currently feeling, as individual, that a fair amount of text is needed and seems to primarily apply to un-trusted agents.

Show of hands if this is an issue that should be addressed: more than 10 hands. Clear support.

Ari: Should this be a separate document?

Justin: The case where you have multiple ICE-agents that need global pacing you need to cover that in ICE-bis. The rate-limit stuff seems more like a WebRTC case. Not clear if a separate document or as part of WebRTC document.



Global rate-limit should be in ICE-bis

Rate-limit issue could probably be covered in RTCWeb document (discuss with RTCWeb chairs).


Slide 9 (Can/Will semantics of ice-options)

Cullen: Agree with the proposal. But no extra IANA fields needed for ice-options, that's what the definition is for.

Using Simulcast in RTP Sessions


Bo presented his slides


Slide 4:

Bernard: Disagrees that it is inherently complex. Believe we can do something much simpler per Bernard's mail to the list (on 11/28/13 - Simplifying draft-westerlund-avtcore-rtp-simulcast).

Bo: when it comes to supporting unified plan with simple media source you can’t separate simulcast versions

Bernard: grouping semantic can handle this

Bo: will have this later in the presentation

Slide 11 (Solution Requirements)

Roni: Why do you need to enumerate the potential configurations?

Bo: Need to name them

Bernard: Already have this ability in O/A


Slide 12 (Solution Goal 1: Support for Unified Plan)

Magnus: Looked at Bernard's mail to the list again. Don't believe you can express different quality levels in Bernard's proposal.

Bernard: Can express different frame rates today. May need to define a new group semantic. There might be a small set of extensions needed to do everything here, but it seems 90% of what is needed already exists, so shouldn't create a whole new framework as proposed here.

Paul Kyzivat: What is the intended relationship to CLUE?  Have use for simulcast in CLUE, but if you have to signal it in SDP, that's probably bad from a CLUE point of view.

Bo: Intended relationship to CLUE is to allow you to have something that allows you to do simulcast but without having to do everything else related to CLUE.

Paul: Everything that CLUE does could be broken

Cullen: For the RTCWeb use case they went with a single m-line.  Trying to reverse the decisions we've done in the past is not a good idea. Let's figure out what we need to do in the existing frameworks.

Stephan Wenger: Need more clarity on differentiating use cases for this work. Are we talking about different payload types?

Rob Hansen: CLUE doesn't stop the use of simulcast, you can ask for the same capture source with multiple encodings, which is effectively simulcast.  This seems like a cleaner way of doing things, and CLUE is more heavyweight.

Jonathan:  With this + CLUE, you might be able to describe an encoding that is always inherently simulcast.  So there is a bit of overlap, since CLUE gets simulcast capabilities almost accidentally, but it's largely complementary.

Magnus: can we ask for a consensus call on this point?

Jonathan: Seems reasonable it should work with unified plan unless it turns out to be too horrific. Let's see rest of proposal.

Roni: Is current proposal actually based on unified-plan? Aren't there different m-lines?

Magnus: Latest draft proposal uses m-line as source


Next Steps:



SDP-based "SCTP over DTLS" data channel negotiation and MSRP over WebRTC data channels



Keith presented his slides

Matthew Kaufman: Fully in favor of making everything as complicated as possible. Now have both an inband and external signaling mechanism (in RTCWeb)

Jonathan: If you have a JS-based implementation you could use this. The intention is not that the browser would implement this (would be done by the application and might be needed when interworking with a gateway).

Keith Drage: In a pure RTCWeb environment, you would probably not use this, but would be useful when you have e2e SDP negotiation.

Matthew: the browser would have to be aware of what streams are being created and destroyed

Ted Hardie: Foresees problems with 2 different negotiation models. Fundamentally cannot assume the JavaScript is doing the right thing, so need the browser to intermediate. Believe it will also be problematic in a WebRTC to GW use case too. If you are going to rely on any of this behavior, you will be in trouble. Need to go back to use cases and requirements.

Mary Barnes: Note that only this document was sent to MMUSIC by DISPATCH

Paul: either the browser is able to modify SDP or it is not.

Martin: yes, that is the state we are in

Cullen: Don't see a problem building a JS library for the browser. Think we fundamentally need something like this. If you are just browser-to-browser you can do out-of-band, but if you are not you need something like this.

Randall Jessup (relayed by Jonathan): how important is this? And I don't think that there are new security issues here.

Jonathan: as long as we have rules that doesn't allow for conflicting changes, it's OK

Matthew: Concern is poorly written JavaScript that modifies the SDP and causes the channel to be closed. Issue is that the browser deals with the SDP, and we now have an external mechanism that affects that. Brower has to raise an error if you send data over SCTP channel that was closed due to this.

Jonathan: maybe "MUST NOT parse" requirement on the browser

Matthew: the concern here is that this "external negotiation" isn't entirely external because the browser is expected to read the SDP

Paul: The issue really is that the browser understands "some SDP" but not "all SDP", so have to consider impact on the browser. Rationalizing this isn't as hard as I thought it would be; as long as the application follows the internal rules, including channel reservation, that's enough.

Harald: Don't really understand this. Another level of encapsulation. Why didn't we just add m-lines with special form of address?

Keith: Not sure; this is how Richard specified it (will need Richard to answer).

Harald: Will take that question to the list

Ted: It's not entirely clear where people believe that parsing of SDP and activity related to that is occurring. Is it in the browser or app? There seems to be different understandings of that and draft update should be very clear on that point in the next version.

Keith: Point taken. I have a similar concern with other rtcweb documents.

Randall (relayed by Jonathan): browsers should consider this to be entirely external. Agrees with Paul’s comments about external negotiation.

Jonathan: the use case we’re interested is when we relay. No consensus in CLUE but some interest. May want this capability.

Keith pushing for call around adoption noting that CLUE is at the point where they may need this too (will discuss further in this IETF).

Ari asking for document update addressing the concerns expressed and then we can have a call on the list if concerns seem to be addressed.


THURSDAY, March 6, 2014 (Buckingham), 09:00-11:30 (150 mins)


Note takers:

Jabber Relay:

Multiplexing Negotiation Using SDP Port Numbers (Christer Holmberg)


Christer presented his slides

Not much progress since Vancouver

No new issues; issues discussed today have all been raised/discussed before, but decisions not yet clear.

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

Text is trying to clarify what is meant by "identical codec configuration"

Cullen:Text is fine, but it's not enough by itself. This one only deals with the RTP part of the question.

CONSENSUS: Chairs ask for objections or disagreement; nobody disagrees with Christer's proposal.

Q13: How can we ensure a receiver will be able to associate received media packets, using the same PT value, with the correct m-line ?

CONCLUSION: Chair (Flemming) states: Agreement on Christer's proposal and document behavior in this documentl, however further discussion on the mechanism, including whether every single RTP packet with same "multiplexed" payload type (scope of the problem) will include this "receiver-id". Specific mechanism TBD as well.

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

Proposal: for STUN/DTLS/SRTP demux, at ref to RFC 5764; for first byte of packet:

CONSENSUS: Chair (Flemming) recaps:

A Framework for SDP Attributes when Multiplexing (Suhas Nandakumar)


Suhas presented his slides

Q1 - IMS Attributes for IPTV

Q2 - SDP Source Filters (RFC 4570) 

Multiplexing Streams with DSCP Markings

Dealing with Encapsulating Attributes

Next Steps

WebRTC MediaStream Identification in the SDP - MSID (Harald Alvestrand)


Harald presented his slides

msid-control (slide 2):

•        Mo: Wasn't clear in RTCWeb why msid-control was needed, but do understand a bit better know.

Overview of mechanism

Harald would like clarity (WG feedback) on:

CONSENSUS: Chair (Flemming) asks

The SDP Application Token Attribute - App ID (Roni Even)


Roni presented his slides

CONCLUSION: Chair (Flemming) summarizing next steps:

SCTP-Based Media Transport in the SDP (Salvatore Loretto)


Salvatore presented his slides


New text: at most one sctpmap attribute per DTLS/SCRP m-line

sctptmap attribute syntax -- are we missing anything we want?

"app" parameter -- currently "webrtc-DataChannel", could be "sctp-data-channel" or "data-channel"

"streams" parameter

CONSENSUS: Chairs (Flemming) asking WG if we are going to remove the streams parameter:

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



Adam presented his slides

Open issue in draft (sending another POF before getting PAN for the first POF)

Adam’s proposal: disallow

Adam asking for people to provide feedback on the document and in particular whether it’s on the right track.