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:

http://ietf89.conf.meetecho.com/index.php/Recorded_Sessions#MMUSIC

http://ietf89.conf.meetecho.com/index.php/Recorded_Sessions#MMUSIC_II

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)
09:30-10:00        Trickle ICE (30 mins)
10:00-10:30        ICE bis (30 mins)
10:30-11:00        Using Simulcast in RTP Sessions (30 mins)
11:00-11:15        SDP-based "SCTP over DTLS" data channel negotiation (15 mins)
11:15-11:30        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)
10:30-10:50        WebRTC MediaStream Identification in the SDP (20 mins)
10:50-11:10        SCTP-Based Media Transport in the SDP (20 mins)
11:10-11:30        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

Milestones

• Ten milestones left. Three at leas need reconsideration. Need to reschedule SCTP based media transport in SDP and SDP extensions to classifying traffic to a later date.  

• James Polk: need to address nits in the Traffic class draft but March/April is realistic date.
• In terms of priorities, no comments on suggested priority list from RTCWeb chairs so proceed with proposal per slide notes: Bundle + SDP multiplex, MSID, SCTP SDP, are urgent. Perhaps also app-token.

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

draft-reddy-mmusic-ice-happy-eyeballs-06

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:

• States that it seems there are no major concerns with algorithm at this point, but we don't want to mandate it (general nodding and no objections)
• States that there seems to be interest in continuing the work, but no clear decision around separate draft or part ice-bis (general nodding and no objections).

Trickle ICE

draft-ietf-mmusic-trickle-ice-01

draft-ivov-mmusic-trickle-ice-sip-01

draft-ivov-dispatch-sdpfrag-03

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.

application/sdpfrag

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

draft-ietf-mmusic-rfc5245bis-01

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.

Conclusion

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

draft-westerlund-avtcore-rtp-simulcast-03

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:

• Propose SDP solution based on the proposal to the mailing list
• Chairs asking for general feedback. Only comment is from Cullen: Looking forward to next version of the draft with the actual proposal; seems sort of like the right general direction.

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

draft-ejzak-dispatch-msrp-data-channel-00

draft-ejzak-mmusic-data-channel-sdpneg-00

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:

• Stephen Wenger
• Adam Roach
• Flemming Andreasen

Jabber Relay:

• Jonathan Lennox

Multiplexing Negotiation Using SDP Port Numbers (Christer Holmberg)

draft-ietf-mmusic-sdp-bundle-negotiation-05

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"

• This means the media type, subtype, and parameter must match  

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

• Christer’s proposal is for draft-ietf-mmusic-sdp-attributes to provide details on which SDP attribute values must be identical    

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 ?

• Suggest a "receiver-id" value (which might be the App ID)
• Remote peer puts this value in RTP sent towards party who inserted it          

• Adam Roach: Think this is a good idea. Already proposed in unified-plan

• Roni: Not only for this case. Can get RTP before SDP, so generally good idea.
• Cullen: Like this. In addition, Cullen believes the offerer should use unique payload types unless he runs out.

• Several people asking why ?
• Cullen: Note that it implies higher bw usage, and therefore should not require people to do this, unless you run out of payload types.

• Kyzivat: See how it works from offerer's perspective. Seems more problematic in the other direction. Have to demux in the other direction too (so need similar answerer procedures).
• Christer: Idea is to do it similarly in answer direction. Want to have a single mechanism. Paul says we'll see.
• Colin: Need to be careful about terminology and what we mean about demultiplex. If you use RTP you clearly demultiplex based on SSRC. Now we are adding another demultiplexing mechanism. Make sure we are clear on the demultiplexing hierarchy in the draft and have considered it carefully.
  Colin agrees with Cullen that unique payload types or signalled SSRCs would work too, and hence prohibiting an implementation from doing so seems strange. Bundle draft should allow for other demultiplex mechanisms per standard operation.
• Justin: Figured out all of this stuff in unified-plan; don’t' really want to rework all of that.  Enough complexity in bundle already; should have mechanism in separate draft.
• Lennox: Disagrees with "SHOULD" recommendation from Colin & Cullen. Don't want divergent code paths based on use case.
• Cullen: Can live with what is proposed here. Will need a normative dependency on the demux'ing mechanism. Do think that what we are doing here for basic audio results in bw increase for no particularly good reason.
• Further discussion on this: Cullen had misunderstood proposal. Idea is not to mandate use of same payload type. The proposal is simply to have demux mechanism as specified when do reuse the same payload type. Cullen is OK with that.
• Rescorla: Unified plan currently says the above (i.e. use separate payload types first), so seems aligned.
• Colin: +1 with Ekr
• Magnus: I think what we want is MUST implement, and don't care about MAY/SHOULD/MUST in terms of re-use            
• Justin: Understanding was not that every single packet would include include the demuxer, but there would be an option to have only some of the packets do so.
• Cullen: I don't necessarily like that, but I can go along with it, and would like us to come to a decision.
• Adam: We already decided this in Berlin.        
• Bernard: The right place to discuss app-id is in the app-id discussion.

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:

• 0 or 1: STUN
• 128-191: SRTP
• 20-63: DTLS              

• Justin: These values for STUN don't look right. STUN is the hight two bits.
• Christer: I'll fix that.
• For other media types, need to add means to demux.
• Paul Kyzivat: This is very messy. We should say that BUNDLE only works for the specific set of things that we've figured out how to do.
• Christer: Do we want to prevent new things in the future?
• Colin: Confusing different layers of demux here. This level of demux is really not in the scope of BUNDLE (SDP signaling demux is in scope, but transport demux is not). Should have a separate draft dealing with transport level demux. Will be a normative reference in bundle. As new transports are to be demuxed, new drafts may be needed.
• Chair (Flemming): Do you agree that the work for demuxing protocols is a normative dependency for BUNDLE?
• Colin: Yes.
• Cullen: We're demuxing DTLS from SRTP. If we look at the secured datagram protocols that we can use, that's kind of the only differentiation we need to make. Given that we don't invent a lot of UDP security protocols, let's describe this for the problem that we have. If someone comes up with something new, then we can make sure it fits inside these codings.
• Magnus Westerlund: I think I'm agreeing with Cullen. From the perspective of BUNDLE: "If you bundle things together, you MUST be able to unambiguously distinguish them. For SRTP and DTLS, use RFC 5764."
• Paul Kyzivat: I disagree with Cullen about this dealing only with security. All of this would work if all you had was SRTP and SCTP over UDP. I kind of agree with Colin, but this is more about m-lines, since the DTLS goes to one m-line, and the SRTP goes to others. I think we need a new document to talk about this. It's okay not to document it in BUNDLE.
• Harald: I agree with what's on the screen. You can't generalize this, because that turns into DPI. For some protocols, the application is setting the first byte. We should only concentrate on these three things.
• Colin reiterates suggestion to require the ability to demux, informative reference to document that tells how to do so.
• Magnus: RFC 5764 already does this. It's already done. Don't make it more complicated.
• [Several voices in favor of not creating a new draft]          

CONSENSUS: Chair (Flemming) recaps:

• Bundle should not describe transport-level demux, only signaling
• Bundle needs to call out that demux requires a transport demux specification for a particular set of transports to be demuxed.
• For STUN, SRTP and DTLS, RFC 5764 provides such a reference. If other protocols will use BUNDLE, they need to define the demux procedures.
• No disagreement in the room.

A Framework for SDP Attributes when Multiplexing (Suhas Nandakumar)

draft-ietf-mmusic-sdp-mux-attributes-01

Suhas presented his slides

Q1 - IMS Attributes for IPTV

• No comments. Proposal accepted (NORMAL category)

Q2 - SDP Source Filters (RFC 4570) 

• No comments. Proposal accepted (TRANSPORT category)

Multiplexing Streams with DSCP Markings

• This ties into the outcome of DART work. Suggest adding DiffServ guidance in the document.
• Paul Kyzivat: Is that kind of guidance really related to this draft? And isn't the table RTCWEB specific?
• Justin Uberti: We talked about this in TSV yesterday, and I don't think this is right.
• Cullen: I think DART will have the right answer here, and we shouldn't try to define this here.
• Magnus: I think you should outsource as much of this work to the documents that will come out of DART.
• Suhas: So, should we remove the discussion from the draft?
• Magnus: I'd have to read the section to make a concrete suggestion, but in general, you should have as little as possible in this draft.          
• Jonathan: Can't do this for TCP btw.

Dealing with Encapsulating Attributes

• Proposed: new category for "INHERIT", which means the behavior depends on the contained attributes.

• Example: ACAP attribute would be INHERIT, meaning it inherits the behavior of what it contains.          

• Lennox: Every configuration described with CapNeg (RFC 5939) must itself be consistent with bundle.
• Flemming (as individual): Has to work across bundled streams.
• Kyzivat: ??? [missed comment]
• Lennox: Seems primarily an answerer issue
• Flemming (as individual): Offerer issue too; have to make sure potential configurations allow for bundle.

Next Steps

• Complete reviews for unreviewed sections, CapNeg behavior, security sections.
• Lennox: Don't underestimate the scope of the payload type stuff.

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

draft-ietf-mmusic-msid-04

Harald presented his slides

msid-control (slide 2):

• Martin: Objection to adding msid-control mechanism to a WG draft without prior discussion.
• Cullen: Same issue as Martin.
• Magnus: I also think msid-control should be separate.
• Harald: It seemed to address a need, so I added it. Harald then asked the chairs for guidance on new text; do we always need separate draft.
• Chair (Flemming): It depends; WG drafts will respect the WG decisions. Let's hear more about the proposal and then decide what to do with it.

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

Overview of mechanism

• Martin: This seems like a good thing in general, and this is a good distinction. My objection is that we added this to the wrong document -  doesn't seem to be msid-specific in any way. And I think you ended up with the wrong name in your hurry to add this to a document.
• Cullen: Seems like msid only makes sense in WebRTC. This mechanism seems generally useful outside of WebRTC.
• Harald: That sounds reasonable.
• Jonathan: This actually makes sense without BUNDLE, in fact.
• Magnus: I agree with Jonathan. This should be independent from MSID.
• Mo: I thought the core issue was whether you could keep the same MSID or release it. If that weren't an issue, then you could release resources when you do a sendonly. So it seems tied to the use of MSID, since its primary purpose seems to be the ability to go back to the same MSID.
• Paul Kyzivat: What Jonathan said was the first thing in this discussion that made any sense to me, and I agree with him.
• Roni Even: I understand MSID to be potentially multiple RTP streams, not one RTP stream. So you're operating on multiple streams. So I don't know how this can be generalized.
• Justin: As I said yesterday in RTCWEB, I was thinking of this in term of media stream, since solving a specific problem seems easier. On the other hand, if we need to be able to disable half of an m-line in the general case, we probably want one mechanism. To Mo's point, I think there's a real distinction between whether you have paused a resource or released it (“a=sendonly”).
• Magnus: I think we still have the question of whether an m-line can be re-used in one direction.
• Hadriel: When talking about using this in general, I'm concerned. I don't understand what's wrong with the current use of “a=sendonly”.
• Harald: What we want to know is: if media packets start flowing again on the m-line, is it the same thing as before, or is it a new thing?
• Hadriel: So, we never really had this problem before in SIP, although we didn't really have complicated ways of managing m-lines. But there are so many ways to handle hold in SIP, and you're proposing to add a new one.
• Harald: Right. Is the cost of generalizing this worth the value? We could certainly define this as only scoped to MSID.
• Martin: One of the main reasons we're adding this is so, in WebRTC, when one side rejects a track, we can surface that on the other end as an event: "You were going to send stuff, and it's been rejected."          

Harald would like clarity (WG feedback) on:

• Is this mechanism needed
• Should this be a generic mechanism.
• Should this be a separate draft or not

CONSENSUS: Chair (Flemming) asks

• People in favor of keeping msid-control in msid draft currently: Nobody for, many against.
• Harald will take msid-control out of msid draft and resubmit.
• Harald will submit individual draft of msid-control including considerations around generic versus msid-specific mechanism.

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

draft-even-mmusic-application-token-02

Roni presented his slides

• Cullen (on slide 3): Elaborate on "can be chosen by either sender or receiver"

• Roni: See slide 4.

• Bernard: How far are we planning ongoing with these attributes ?

• Lennox: Pretty much as far as RFC 5576, plus stuff that should have been in 5576.

• Martin: This is way more complex than the problem statement requires (see Introduction statement). It may be solving a problem, but we should focus on the problem that requires a solution in unified plan.

• Roni: When we did the "a=ssrc" stuff, we should probably have added a layer of indirection. This essentially rectifies that. Can discuss scope further.

• Kyzivat: Was ok understanding until we got to the appId with payload type. The payload types you have to put in are the ones you receive, not the ones you send, so how do you do that ?

• Lennox: Have to think more about Paul's point.

• Lennox: To Martin's point about complexity. The goal was to use this in place of "a=ssrc", so that's why you see a scope similar to RFC 5576.
• Bernard: In response to Cullen. Document needs to describe when you turn this thing off; what is the algorithm (needs to be more about this in the document).

• Lennox: This is discussed already, but it could be clearer (suggestion: stop when it comes back in RTCP)      

• Suhas: Multiple streams under a given track considerations.

• Lennox: Haven't thought about exactly what attributes you put under recv-appId.

• Harald: This SDP slide scares me. If you have one mechanism used for six purposes, I'll eventually find that we need more than one, and will want to put more than one in a single packet. If we reduce the problem set to the one on the first slide, then all we need is a single identifier to provide correlation.

• Jonathan: The problem is that we invent simulcast and find that this doesn't address it, then we'll need to define another header extension for that; before you know it, we'll have several of these and the packets will be huge.
• Harald: But if we design this before we understand how it will be used for simulcast, then it will be wrong

• Magnus: We may want to make this more complicated to do things like tagging speakers.

• Mo: Sees Martin's point. A lot of people think of unified-plans correlator as to what app-id is. Unified-plan however doesn't get into a lot of the more complicated use cases such as FEC, simulcast, etc. This draft addresses all of these. So first order of business is whether we need to solve all of this:

• Roni: There is a need for a correlator.

• Martin: A lot of the stuff on slide 4 is designed to replicate the "a=ssrc" functionality at the point in time where you know the SSRC. However if you know the SSRC, you could just use RFC 5576 and forget about a lot of the complexity here.

• Roni: You can't assume you can know the SSRC, and you can't guarantee that the SSRC won't change. It was not a good choice in the first place.  
• Martin: Yes. SSRC has architectural issues.            

• Cullen: Always thought RFC 5576 was broken. Don't want to replicate/duplicate RFC 5576 functionality. Do need to solve simulcast, FEC, etc. solution. Probably do need the app-id part. There can then be other drafts for more detailed use cases to extend that. What we need is a correlating identifier, and that's this draft. And then if you want to use it to do things in the future, you do that in different drafts in the future.      

• Lennox: I don't think we need to define how all this works in the initial draft. I think we need to sketch out possibilities so we don't get the broader cases wrong. Once we understand the broader cases, I'm okay paring this mechaism down to the minimal case.

• Bernard: We need to decide whether this is a generic token, or whether it's used for one specific purpose. Could you have the same appId used for multiple SSRCs? (Probably not at the same time).
• Martin: We may be talking past each other. It sounds like we may just be trying to explore the space around this identifier. I'd like to see more thought around FEC, laying, simulcast. But the draft and slides don't go into enough detail around that.
• Roni: Here's an example of what we can't solve with SSRC (see slide: "Application token: SVC with FEC example").
• Roni: I think we want to define the generic token for mapping. After that, we can decide what else can be done with it.      

CONCLUSION: Chair (Flemming) summarizing next steps:

• Draft needs to be crisper on its problem statement. Try to layer it with the basic problem and then increasing scope gradually (FEC, simulcast, etc.)

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

draft-ietf-mmusic-sctp-sdp-06

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?

• EKR: I heard earlier in the week that maximum size would be sender-enforced.

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

• Martin: Doesn't SCTP negotiate number of streams? (If you're confused about that this is being discussed at this point in the meeting, you're only as lost as I am).
• Justin: I thought I saw a presentation saying that we're setting the streams always to 65 thousand.
• Paul: We need to be careful who "we" are. If I understand, as far as SCTP is concerned, when you set up the stack, there's some value that max streams is set to, and then it can be changed on the fly. And webrtc has set this value to 64k. Negotiating in SDP makes sense, although it might not make sense to change it in a reInvite. MMUSIC should not hardwire 64k in.
• Lennox: From the discussion in Berlin, I thought we'd settled on 64k. We don't seem to be informed by non-datachannel uses of SCTP, but then again, there may not be any.
• Christer: I think the max number of SCTP streams is what it is, but maybe I have constrained resources, and I only want to use max X number of datachannels. And that's something we should be negotiating.

"streams" parameter

• Justin: This negotiation seems unnecessary. We don't have this kind of thing for TCP, and it works fine.
• [Cullen as Jabber relay for ] Randall Jesup: The max number of streams is set to a large number per IETF 88. I'm okay setting to 64k or 64k-1. Argued for parameter at 88, but lost. Should verify with other applications of SCTP.
• Christian Groves: ??? [missed comment]
• Martin Thomson: (quotes text indicating that this is negotiated in-band). I'd rather remove this. For WebRTC, I'm happy saying "support and negotiate 64k-1 only". In this document, since SCTP handles this, we don't need to add a parameter.
• Matthew Kaufman: The more knobs you put in the SDP, the more things like RTCWEB will need to respect them in their API. If you set the SCTP parameters to only allow 1 channel, then trying to open 2 will need to generate an error, and that's just more work. There are a lot of things that keep coming up with having to send appId and not sending it all the time, and other complications that would have been avoided by not using RTP and not using SCTP over DTLS.
• EKR: The chance that datachannels are used outside RTCWEB is very low, so let's not spin wheels solving this. In terms of saving memory, if an implementation can't do this in a way that manages memory sensibly, it should have been implemented by someone else.

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

• Unanimous agreement to remove the parameter

• Paul Kyzivat: can we go back to talking about "app"? The parameter doesn't have any semantics, and "sctp datachannels" isn't an application; "webrtc" isn't an application. This is really a named convention for how this association will be used.
• Martin Thomson: My answer before was to call it "alpn" -- this already has a registry, defined semantics.          

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

draft-roach-mmusic-pof-pan-02

draft-roach-mmusic-groupid-00

Adam presented his slides

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

Adam’s proposal: disallow

• Lennox: Question is do we anticipate POF is an INVITE like offer or an UPDATE like offer.

• Adam: It would be more like UPDATE, i.e. response and interaction time is more machine-like than human-like.
• ACTION: Need to update draft to include considerations around expected (short) response times .

• Emil:So shouldn't add media streams with this mechanism then, because might require human intervention ?

• Adam: Good question. Have to think through that a bit more

• Christer: Agrees with Adam's proposal.
• Martin: Thought point was to allow concurrent partial updates as long as they are orthogonal

• Adam: In opposite directions.
• Martin: Still trying to understand problem here.  Why is it an issue to add one, then another one, etc. ?
• Adam: As long as we have ordering, guess that should work. Need to work through on the list.

• Matthew Kaufman: Part of the problem Matt has with this is that multiple different semantic layers are represented in SDP. One of the issues with Offer/Answer is you can’t issue a new Offer when one is outstanding. If not trying to change the media but want to do trickle-ICE, then have an issue.

• Adam: Trickle-ICE has a different way of dealing with this; not using the 3264 O/A state machine.
• Matt: OK. In general want to try to not get locked to the 3264 O/A state machine and its restrictions around when you send a new Offer.

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