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:

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

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

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

• draft-ietf-mmusic-msid-02 and
• draft-ietf-mmusic-sctp-sdp-05

need review and list feedback.

msid draft

• Roni Even and Paul Kyzivat committed to reviewing the new version (-02) and make sure it aligns (consider app-token and simulcast from Magnus as part of that).

sctp-sdp draft

• Eric Rescorla (Ekr), Paul Kyzivat and Roni Even will review the draft.

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

draft-even-mmusic-application-token-01

Roni presented his slides

Roni noted:

• Document not yet stable or entirely in-line with today's presentation (there has been some list discussion and slides reflect that)
• Expect a new version next week

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.

• Lennox: Wrote the SSRC draft, not sure he sees how they are the same here.
• Perkins: Thought it specified collision handling
• Lennox: This is much more dynamic.
• Perkins: OK; should still look at.

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.

• SDP: Who cares
• RTCP: Ugly
• RTP: Please don't mess with that.

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?

• Roni: No.

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

• Roni: Think we also need app-id

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)

draft-nandakumar-mmusic-sdp-mux-attributes-05

Suhas presented his slides

Q1: PT Reuse

Harald: slide 4 example is forbidden by bundle spec:

• Suhas/Lennox: Why? Mistake in slide (first rtpmap should be 97, not 98)

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

• Suhas: Just want to make sure there is no issue.

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 ?

• Cullen: Think it's not.
• Magnus: Think it works fine.

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?

• Suhas: yes, Christer said that.

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)

draft-ietf-mmusic-rfc5245bis-00

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.

• Ari: may cause issues e.g., if one reserves buffer space for usernames up to 512 characters. Easy to fix in a backward compatible way if bis implementations send only up to 255 characters.

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

• Takes a little while to churn the Chrome base; hoping to be able to present more solid data by next IETF.

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 that a lot of the bundle complexity may be for nothing if we don't need all the spacing.
• To find susceptible NATs consider going to the gaming forums and look for NATs that people don't like.

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.

Extensibility

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)

draft-thomson-mmusic-ice-webrtc-01

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.

• Martin doesn't think so (believes draft is correct)

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 ?

• Martin: Rate limiting definitely needs to be handled in ice-bis. Interaction between multiple ICE agents needs to be specified somewhere.
• Ari: Please propose some text for ice-bis.

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

• Martin: No.
• Lennox: Also, it's hard for an attacker to do something with multiple browsers.

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

draft-reddy-mmusic-ice-happy-eyeballs-03

Pål-Erik presented his slides

Martin: What is intent with the document ?

• Pal-Erik: Make it fair for IPv4 and IPv6 address selection. Could be part of ice-bis

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 ?

• Pal-Erik believes it works.

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?

• Pal-Erik: Believe so.

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)

draft-martinsen-mmusic-malice-00

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)

draft-reddy-mmusic-ice-best-interface-pcp-00

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.

• Dan: Network can automatically update as information changes (don't have to ask yourself).

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

• Dan: Upper bandwidth limit and lifetime limit associated with a request. Currently there’s no way of cancelling within the time limit.

Lennox: Is PCP seeing substantial deployment at this point ?

• Dan: Some for PCP but none for this extension. There is a document in RTCWeb describing the value. Vendors making Carrier Grade NATs are interested/supporting. Can be implemented entirely in user-space.

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

• Dan: Probably informational.

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

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

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)?

• Christer's proposal is "no".
• Adam Roach: Believe this is correct.
• Jonathan Lennox: Worried about 3PCC cases. Christer clarified it is within a dialog. Lennox is ok then.
• Justin: Take back to trickle ICE; If giving out 0.0.0.0 address then have to make sure different ports are used.
• Christer clarifying that proposal only applies to non-zero ports.
• Paul Kyzivat: 3PCC is where something can go wrong, but agree to bite the bullet. If doing 3PCC here, will have to do Invite-Replaces
• Cullen: Agrees with what Paul said.

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?

• Christer's proposal: Use port zero.

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.

• Flemming (as individual) asking for clarification on RFC 3264 restriction; does it mean we have to update 3264 or the bundle extension simply defines different behavior ? Christer believes that requires further discussion.
• Adam: 3264 restriction is not not an issue; it's a feature that makes the proposal work (the fact that we know vanilla 3264 implementations will not reply with anything but port zero).

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.

• Cullen: Believe it would not update 3264.
• Lennox: Media forwarding by intermediaries should work (second issue on slide 5)
• Lennox: New question: Why not answer with a port zero ?
• Martin Thomson: The second issue seems like a pathological case.
• Adam: Once you get to bundle, the chances of things working smoothly through intermediaries without bundle support are pretty slim, so shouldn't be overly concerned about these corner cases with existing intermediaries.
• Bernard Adoba agrees.

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"

Q8b:

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.

• Roni would like to look at 3264bis in general.
• Adam suggested it's a process question that the authors, chairs and Ads should resolve.
  

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

Q8c:

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.

• Bernard: Does this imply that with simulcast, all the encoding have to use a different payload type ?
• Lennox: Depends on the codec. Could also depend on the resolution; if resolution is max resolution then no issue. However if you need to actually negotiate and agree on them, then you may need to have different payload types.
• Bernard: So seems most of the simulcast and layered encoding stuff can be done with a single payload type.
• Adam: Believes the proposal is roughly correct (good enough for an initial proposal at least).
• Randall Jessup: Seems reasonable. Not sure about H.264 parameter set though; needs to be looked into.
• Lennox: May need to think about rtcp-based feedback parameters. May also be an issue with Opus codec.
• Adam: Should have a mechanical rule for dealing with all of this (don't try to optimize for specific corner cases; use additional payload types instead and live with it for those cases).
• Christer agrees with Adam
• Lennox: This should go into Suhas’ mix draft
• Suhas agrees.

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.

• Justin: Shouldn't say anything about which specific protocols can be demultiplexed. This spec should say it depends on the protocol.
• Bernard agrees with Justin.
• Kyzivat: This spec should not enumerate cases that are allowed, but somewhere there has to be a specification (for a given protocol) that says how it's used. Maybe need a registry of some sort where the information can be found.
• Lennox: Needs to be specified somewhere. It's not just RTP, and it's not just RTCWeb. There has to be something that says how to demultiplex somewhere, and we have to be able to find it.
• Hadriel Kaplan: Have to say it somewhere or we get confusion. Applies at multiple layers too (media itself as well as signaling indication). Have to say something somewhere.
• Colin Perkins: Assuming we will allow more than RTP bundling, then this spec needs to state that. Text suggestion: "The specification for anything other than RTP has to be describe how it can be (de)multiplexed with RTP and anything else that might be multiplexed with it".
• Magnus: Agrees with Colin. Also note that demultiplexing is actually done on DTLS.
• Adam: Agrees with Colin and Magnus.

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)

draft-roach-mmusic-pof-pan-01

Adam presented his slides

• Flemming (as individual):  There are other session level attributes than a=group. Scope can be large dealing with everything and keep it small as applicable only to RTCWeb.
• Adam: Must be able to quickly add and remove streams at the bare minimum. The problem with the group is that is it syntactic problem and not semantic.
• Flemming: But still there are other session attributes
• Adam: Anything other than group should need a  full O/A.
• Flemning: If we can be clear on expectations and use-cases then it would help make progress faster.
• Harald: 2 cases , a=group, a=msid. In both cases, the semantics are declarative and there is no possibility of glare on these attributes
• Adam: possible solutions: Limit solution to bundle groups only; change group syntax for PO/PA only; redefine grouping mechanism to avoid session level attributes

Handling Groups (Open Issue 1)

Second option (slide 5):

• Lennox: Is the context the most recent full O/A and partial O/A
• Adam: We need to nail that down
• Lennox: Need to add the group semantics as well in suboption B.

Third option (slide 6)

• Martin: Slide says it's not backwards compatible. Martin thinks it could be made to be backwards compatible.
• Adam: Look forward to formal text on it
• Lennox: Could add some additional information in RFC5888 that can be used for correlation in both Full O/A and Partial O/A. Not quite sure what it would look like.
•  Adam: Add a phantom iD in the group line that identifies
• Martin: That might lead to null pointer exceptions
• Christer: Thinking of the same thing on adding dummy mid. Not sure of inter-op. Dont like listing all the MIDs in the m=line

Open Issue 1 Example (slide 7)

• Roni: Abc can appear in more than one group
• Adam: Keep adding till you make it unique
• Lennox: 2 groups identical semantic and membership is something wrong. Concern is if 2 groups has same but one mid attribute and you then drop the one m=line.
• Martin: The one situation that makes sense is when 2 Partial Offers modifying the group are in flight in some way causes it. What we need here is an identifier. We need to figure out how to make 5888 better.
• Flemming suggesting the "group" special handling here is the wrong problem to look at and that we really need to look at session-level attributes more generally.
• Adam doesn't necessarily disagree, however we must avoid bi-directional glare for the bundle group use; this is an absolute requirement/foundational use case that we must support (base minimum). It must work without any kind of glare (meaning both sides must be able to add to the group simultaneously). We may find additional use cases that have to be supported, but this one absolutely must work.

• Christer: If all we care about are bundle groups, then isn't the first solution easier?
• Adam thinks we need to support other group types
• Christer: First approach can be extended to other group types
• Adam doesn't think it will work
• Lennox: What if you set an m= line to zero in a partial offer and the other side references that m=line as part of his group ?

• Martin: Just sent another suggestion to the list.:

a=groupid:g1

a=group:FOO a b c

a=groupid:g2

a=group:FOO b c

m=blah ...

a=mid:a

a=add-group:FOO g1

m=blah ...

a=mid:b

a=add-group:FOO g1

a=add-group:FOO g2

m=blah ...

a=mid:c

a=add-group:FOO g1

a=add-group:FOO g2

• Adam agrees it might work.
• Harald: If you define the msid semantic then you have all the identifiers you need, with an identifier for the group
• Martin suggests to Harald to respond to Martin's proposal on list

Issue 1a: New Groups

• Martin: If you had an identifier, you wouldn't need this. Adam agrees Martin's suggestion sounds cleaner
• Lennox: Martin's proposal has some other nice properties.

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

Open Issue 2: Multiple Changes

• Lennox: Hangouts model is good use case for this. Have two things that change at the same time (one goes big, one goes small).
• Christer: Should also not allow any changes that impact other media descriptions. So cannot change the media port for example, since that would affect other media descriptions in the bundle group.
• Adam agrees with Chrster

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

• Lennox can't think of a use case, but it makes him nervous to have this restriction.
• Christer supports Adam's recommendation.
• Cullen: Agree, stay simple (alternative will get very complicated).
• Justin: Agree – keep it simple.

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.

• Flemming (as individual) stating there might be a small race, unless we can guarantee in-order delivery.
• Kyzivat agrees there might be a race.
• Adam asking for a ladder-diagram illustrating the race.

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

• Jonathan: Can allow this if the Partial Offer contains all of the m lines in the BUNDLE
• Adam: too complicated
• Christer: Asking for a use case if we actually wanted to do this.
• Lennox: Partial offer in the middle of doing ICE; what port do you put ? Original port from offer or current ICE port ?
• Christer: Do we really need to send partial offer/answers during ICE ? Lennox saying we could have ICE restart where it might be relevant. Christer countering that do we really need this for ICE restart ?
• Lennox: Doesn't like that one part of the state machine blocks another part of the state machine.
• Adam: Tends to agree with Lennox' point, but not sure.
• Cullen: Not clear there will be a conflict in the situation – slightly confused about the problem Lennox is alluding to.
• Lennox: Consider use case where we start out on 3G and now WiFi comes up and we want to add video to the call. Will be doing ICE and add media stream.
• Harald: Please keep it simple. Don't change the port in a partial offer/answer.
• Cullen: ICE is a bit vague on when you send an updated offer; what is being done today will work fine for partial offer/answer too.
• Martin: Not sure he sees the problem Lennox is describing. Suggest Lennox thinks further about it, and re-raises if still believe to be an issue.

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

• Martin: Quite comfortable with the idea of randomness and doesn't get complicated by 3PCC. Can probably do with less than 202 bits. Base64 should suffice. 120 bits of randomness should be fine.
• Christer: Bringing up Justin's use case with 100 m-lines. The SDP will get big with these long MIDs. Suggest we reconsider prefix-based solution instead.
• Lennox: The offer selects its prefix and the answer must have a different prefix.
• Cullen: Just pick one that works and ask for WG agreement.
• Martin: 120 bits would require 19 characters which is not that much in the grand scheme of SDP.
• Christer: Not just about length, also about length of comparison.
• Kyzivat: With prefix-based and collision, can also just try another round with different prefixes.

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.

• For the next version, be clear on scope and use cases to frame technical discussions going forward.

Using Simulcast in RTP Sessions (Magnus Westerlund)

draft-westerlund-avtcore-rtp-simulcast-03

Magnus presented his slides

• Flemming asking why capability negotiation was not considered ?
• Magnus has not really looked at in detail.
• Roni: Agree should look at capability negotiation.
• Bernard: Let's not get into technical solution detail right now but start with understanding the problem Magnus is trying to address.
• Harald: Concerned; seems like a complex mechanism and overkill for a first iteration.

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

• Bernard: This line is basically saying I'm doing one of them, but in practice you should be able to switch in more or less real-time. If this suggests that you would have to signal such a change first, then that's problematic.
• Cullen: Bernard raises an important point. Two different types of operation

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.

• Kyzivat: Trying to reconcile with what CLUE is doing. Think what is being proposed here would conflict with what CLUE is doing (not sure though).

Slide 19

• Lennox: Seems to have some problem as ANAT (backwards compatibility issues); have no way of saying we only want to do this if answerer supports simulcast.
• Martin: bundle-only is the solution to the negotiation issue. The initial exchange would set the stage for whether it is supported. Putting a lot of complexity into the config-id parameter, which is a bit of a concern.

• Jonathan: Can't represent bandwidth for different subsets of m lines
• Roni: But also can't represent bandwidth for an individual flow represented by a single m line
• Roni: Want to use unified plan?  solution is simpler with separate m lines
• Magnus: But then outside unified plan
• Justin: How would a WebRTC client indicate what it wants to receive in an initial offer?
• Magnus: The mechanism really allows an offerer to indicate that it can send multiple streams, which does make sense for WebRTC clients.
• Justin: It makes no sense to indicate simulcast reception capability
• Magnus: The receive capability is really for a mixer
• Justin: Just let the answerer pick from what is available in the offer rather than this complex negotiation

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 ?

• Adam stated it is not a requirement for RTCWeb 1.0
• Cullen (as RTCWeb chair) indicated it is not urgent, however a follow-up discussion may be needed (need consensus in RTCWeb)