MMUSIC WG virtual interim meeting June 17th, 2013

WebEx recording at: https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69199732&rKey=cac5fee577de08f8

Note taker: Alan Johnston and the MMUSIC chairs (Ari Keranen and Flemming Andreasen).

Agenda Bashing

http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-0.ppt

The Chairs first presented the originally circulated agenda, which did not include the “no plan” draft (http://tools.ietf.org/html/draft-ivov-rtcweb-noplan-00), as discussed previously on the MMUSIC mailing list and per guidance from the RTCWeb chairs. In lieu of comments received from some of the WG participants, and in particular the primary author of the “no plan” draft (Emil Ivov), the chairs then presented an alternative agenda proposal with a short placeholder for discussion of the “no plan” draft. The chairs asked the meeting participants for feedback on this while noting that it was unclear exactly what the “no plan” draft was asking of MMUSIC apart from a few clarifications on the use of “m= lines”.

Harald Alvestrand asked if the updated agenda was available on-line for people not able to view the WebEx session. The chairs said it currently was not but was now being uploaded.

Emil clarified that the he saw following aspects of his drafts as being relevant to MMUSIC and independent of RTCWeb:

- Use of a single “m= line” with multiple streams

- The idea of handling other signaling

  1. Cullen Jennings (as individual contributor) does not believe the current version of the “no plan” draft is clear enough for discussion, especially as it relates to the MMUSIC specific areas. The draft seems to propose something that is outside of SDP and hence outside the scope of MMUSIC. We have discussed “Plan A” versus “Plan B” for many months and agreed to have a meeting on that, and that is what this meeting should focus on. That is not to say that the “no plan” draft should never be discussed, however Cullen does not believe it is sufficiently evolved to discuss in today’s meeting  
  2. Emil clarified that he is asking for MMUSIC feedback on how to use “m= lines” for one versus multiple video streams. The “no plan” draft suggests the SDP looks the same regardless of the amount of streams and would like feedback from the MMUSIC group on that as input to further discussion on the “no plan” draft in RTCWeb. Emil is not looking to discuss the other signaling and protocol mechanisms used on top of that.  
  3. Cullen agreed the “m= line” clarification is a reasonable thing to discuss in MMUSIC, but he would rather not spend time in this meeting on that.
  4. Eric Rescorla stated that this is really an RTCWeb architecture question; should RTCWeb signaling be exclusively SDP or some mixture of SDP and application specific signaling?
  5. Emil agreed with that, however it is not a question for RTCWeb only. Emil has used the approach in existing implementations and with other protocols.
  6. Eric again noted that these aren’t questions for MMUSIC.
  7. Jonathan Lennox countered that the question here is clarifying the semantics of an SDP “m= line”; what does it really mean? For example, the way SAP used  SDP and the way SIP uses SDP represent two different models. People understand SDP in different ways, and clarifying these semantics is very much an MMUSIC problem.
  8. Eric didn’t disagree with that, however he believes the SDP should look different when sending one versus two sources.
  9. Jonathan countered that this wasn’t the case for SAP (or Mbone) usage of SDP.
  10. Randall Jessup noted that this is an issue that may need discussion in MMUSIC, but it doesn’t seem necessary to discuss here to make progress on the “Plan A” versus “Plan B” discussion. Randall suggested we could discuss the “m= line” semantics on the mailing list for now instead of in this meeting and inform RTCWeb that way.

Flemming (as chair) asked for any further opinions.

  1. Mary Barnes said we had already spent 10 minutes discussing whether we should discuss “no plan”, so why not just spend 10-15 minutes on “no plan”.
  2. Flemming said it would end up being a longer discussion than that once we open it up.
  3. Mary said that we should have some air-time on it and it is relevant to how we should interpret an “m= line”.
  4. Flemming agreed that the semantics of an “m= line” are not clear, however the “no plan” draft is about a lot of other things and it is unclear what the draft is asking of MMUSIC. The “m= line” semantics part is relevant to MMUSIC and we would welcome a draft specifically on that, but the rest of the current draft is not in the scope of MMUSIC.
  5. Mary then asked that the RTCWeb chairs schedule a virtual interim (for RTCWeb) to talk about the “no plan” draft.
  1. Bernard Adoba requested that too.
  2. Cullen said to send an e-mail requesting that to the RTCWeb mailing list and the chairs.

Flemming (as chair) then said that based on the discussion, we should not present the “no plan” draft in this meeting, but the “m= line” semantics issues should be brought up where relevant as part of the “Plan A” and “Plan B” discussions. Flemming reiterated that MMUSIC would welcome a draft on the “m-line” semantics issue going forward.

Flemming (as chair) then asked if anybody had any objections to proceeding that way in this meeting:

  1. Bernard Adoba objected and stated that the way this was being handled was fairly outrageously egregious and not appropriate under IETF procedures.
  2. Flemming asked Bernard to explain further.
  3. Bernard clarified that it looked like a predetermined effort to prevent somebody from presenting at the IETF.
  4. Mary agreed and noted it was unfortunate that there were not any Area Directors on the call.
  5. Bernard said we were almost guaranteed to get an appeal now.
  6. Cullen didn’t see it that way and asked for clarification on what the issue was; it seemed like it was a different subject for a different WG.
  7. Randall Jessup was equally confused as to why this was an issue for this meeting.
  8. Jonathan Lennox said it was because the point of “no plan” was that neither “Plan A” nor “Plan B” was necessary, and we can’t get consensus on either of those plans, if there are people that believe that we should do “no plan”.
  9. Flemming said that the MMUSIC group cannot make that decision; it is a decision for the RTCWeb WG.
  10. Mary and Bernard said it absolutely is a decision that belongs in MMUSIC.
  11. Cullen (as RTCWeb co-chair) pointed out that the RTCWeb WG had consensus that they would be using RFC 3264 style Offer/Answer for doing all of this. That decision could be changed, and the “no plan” draft would represent such a change, but that is currently not the consensus of the RTCWeb WG.
  12. Eric Rescorla said we could adjourn this meeting and schedule another one for deciding between “no plan”, “Plan A” or “Plan B”, since that is not what this meeting was called for.  
  13. Cullen thought Bernard was being disruptive to the process and asked Bernard to provide more detail on what the problem is.
  14. Bernard clarified that he believes people have mis-characterized “no plan” and it’s an attempt to shut down a proposal that has been brought to the IETF. Bernard sees people from two companies preventing other people from speaking, and that is inappropriate.

Flemming (as chair) noted that everybody on this call and on the mailing lists are free to speak, just like we are doing now. We had existing (“-00’) drafts for “Plan A” and “Plan B” prior to this meeting being scheduled and those drafts/plans have been discussed by MMUSIC previously. After this meeting was scheduled, the “no plan -00” draft was submitted to RTCWeb (not MMUSIC), and as noted previously, it is unclear what this draft wants from MMUSIC.

  1. Bernard countered that neither “Plan A” nor “Plan B” were submitted as MMUSIC drafts and hence this was a mis-characterization.

Flemming pointed out that there has been mailing list discussion on both the MMUSIC and RTCWeb mailing lists as to where the “no plan” draft discussion belongs. The guidance given was that the “no plan” discussions belong in RTCWeb. Based on that, Flemming does not understand what Bernard’s objection is and how he sees this as being outrageous and violating process.

  1. Mary stated that she agrees with Bernard. We have had discussions on the list and we have had several people asking to talk about “no plan”. The “no plan” draft may impact whether we need “Plan A” or “Plan B” at all. It will be up to RTCWeb to decide which solution coming out of the MMUSIC group they will want to use. Saying that we should not talk about “no plan” is a disservice to the community.
  2. Mo Zanaty said that instead of looking at plans holistically, we should rather pick them apart and look at the pieces that are relevant to MMUSIC. For example, what does it mean to have multi-stream RTP, multiplexed payload types, when is it appropriate to use source-level signalling, etc. Those are the issues we should focus on rather than adoption of entire plans.
  3. Bernard agreed.
  4. Justin Uberti suggested we stopped arguing and just give Emil 10 minutes to present at this point.
  5. Flemming agreed with that proposal if people thought that would move us forward
  6. Randall and Cullen were ok with that as well.  

The group agreed to spend 10 minutes on the “no plan” draft and updated the agenda accordingly. There was no further agenda bashing.

[0:18:45] Emil Ivov presented “Multiple RTP Flows in a Single Media Line” slides (“no plan”):

http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-1.pdf

Emil presented his slides discussing multiple streams in a single “m= line”.

Flemming asked Emil to summarize what it is he wants from MMUSIC.

Emil clarified that he is looking for

1) Whether it is ok for applications to send multiple streams in a single “m= line” (multiple simultaneous senders at the same time for a given “m= line”) .

2) Discovery mechanisms for determining capabilities so an application can determine if it can send multiple streams in a single “m= line”.

Mo Zanaty asked whether we would use currently defined SDP mechanisms where they exist, e.g. for FEC or retransmission stream

  1. Emil said the proposal does not prohibit anything. Depending on the FEC mechanism, you may want to indicate it, or you may not (depends on the FEC mechanism).
  2. Mo said the question is what does multi-stream RTP look like in SDP? Consider what layering, simulcast, FEC, and multi-source look like in SDP. The plans need to say something about that.
  3. Adam Roach agreed. We haven’t said anything about how to handle existing attributes. How do existing SDP constructs fit into this scheme? In the example shown in Emil’s slides, all the audio has been put together and we have lost the ability to talk about them individually; this is one of the key areas of difference between Plan A and Plan B.  
  4. Jonathan said he believes Emil simply views this as out of scope for MMUSIC.
  5. Bernard interprets it to say you don’t have to declare SSRCs (but you could if you wanted to). Emil clarified it’s not required.
  6. Mo Zanaty suggested the term “any plan” would be more descriptive for this than “no plan”.

Flemming (as chair) said the challenge is that we are supposed to come up with specifications that enable interoperable implementations, which means we are supposed to specify how things are going to work, and this proposal does not seem to do that; the details are left unspecified.

  1. Emil disagrees with that assertion.
  2. Emil’s question is whether it is ok to send multiple streams (clarified as multiple SSRCs simultaneously) per “m= line” in the SDP (per the example shown in the slides).
  3. Justin asked how we would know which video tag would go where if we had two video tags.
  1. Emil asked if we are talking about RTCWeb ?
  2. Bernard replied this was handled by the API proposal.
  1. Flemming said we are getting into a grey area in terms of the existing SDP specification. There is nothing in the SDP specification that prevents you from doing this.
  2. Jonathan said that nobody knows because people don’t agree on what the SDP semantics are. Jonathan believes that:
  1. Plan B seems to be based on the idea that Emil’s interpretation is correct, but we need additional SDP signaling to convey some of the semantics.
  2. Conversely, Emil’s proposal seems to say the additional signaling should not be in SDP. Other than that, “Plan B” and “no plan” assumptions seem fairly similar.
  1. Cullen disagrees with Jonathan. If we agree that the example SDP shown is an RFC 3264 Offer, then it’s clear from RFC 3264, that multiple different devices can send audio at the same time [to the same “m= line] to the offerer. The RFC 3264 offer/answer semantics of this are very clear and hence so is the answer to Emil’s question. More specifically, more than one stream can be sent to a given “m= line” per RFC 3264. 
  2. Jonathan noted there would be different answers to the offer.
  3. Cullen agreed but noted lack of clarity on this and other issues in the draft and on the mailing list. Again, if what is shown is an RFC 3264 Offer, then the answer to Emil’s question is clear per the above.
  4. Jonathan said there is a distinction at the RTP level though
  1. Cullen agreed but noted this is not what Emil asked.
  2. Jonathan agreed, but said he probably should have.
  3. Cullen agreed and noted that the draft needs to evolve to have a more productive discussion.
  1. Randall thought if you called into a mixer, then there is no reason the mixer could not send you multiple SSRCs for a “m= line”.
  2. Eric said the question is how to render them; should they be switched or rendered at the same time ?
  1. Bernard said that’s handled in the API.
  2. Flemming again noted that from an MMUSIC point of view, we need a mechanism in the context of SDP and Offer/Answer; APIs are not part of MMUSIC scope or solutions.
  3. Emil said MMUSIC could leave that to other types of signaling.
  4. Flemming said that it’s not obvious that we can do that.
  1. Adam was concerned about interoperability with legacy applications.
  1. Emil thought it was the only proposal that would work with legacy applications; keep to a single stream when talking to a legacy app.
  2. Adam said there are existing video conferencing implementations that use multiple “m= lines”.
  3. Bernard said most of those look more like “Plan B”, however others disagreed.

Flemming asked how the “no plan” proposal satisfies the requirements. We seem to be missing independent control/signaling mechanism for the various streams/sources in this proposal. Where does that control/signaling go ?

  1. Emil said it would go in a different mechanism. It could be in SDP or somewhere else. If we can agree that we can have multiple streams/sources in a “m= line”, then we can start defining the signaling mechanism. We can also define “Plan A” and “Plan B” and have the applications that want to use either mechanism do so.
  2. Eric Rescorla asked if we were going to define 3 mechanisms ?
  3. Emil said he’s only proposing we agree it’s ok to have a single RTP session with multiple SSRCs per “m= line”.

Keith Drage asked for clarification on the scope of the “no plan” proposal.

1) Does it preclude the existence of Plan A or B or both (Keith believes the answer is “no”).

2) Does the draft apply beyond RTCWeb (e.g. for CLUE).

  1. Bernard (?) believes it could influence CLUE.
  2. Mary believes this could apply to CLUE, but no decision has been made in CLUE.
  3. Flemming stated that part of the reason for doing the work in MMUSIC is that it should apply beyond RTCWeb.
  4. Paul Kyzivat believes either of the plans could work for CLUE. However, for interoperability, we all have to make a consistent choice.
  5. Richard Ejzak said he believes we still need to specify the missing things in some way. Doesn’t “no plan” mean specifying those things using something else that is not SDP ?  
  6. Jonathan said yes and no. For basic functionality, you don’t need anything beyond the basic RTP flows themselves.
  1. Eric Rescorla questioned that.
  2. Richard noted that it sounds like if two applications make the same assumptions, then it can work. However, that’s different from us specifying a means to negotiate a common understanding.
  3. Jonathan agreed with that. We do need some way of specifying the intended semantics, since very few existing implementations operate the way “no plan” describes today. The use of “max-ssrc” could be one way of establishing those semantics.
  1. Mo suggested we move to the “Plan A” and “Plan B” discussions to try and answer Emil’s original question.

Flemming noted we had now spent 20-25 minutes on “no plan” and asked Emil if we had covered his main point.

  1. Emil agreed and noted he wanted to make sure we had discussed the “m= line” semantics issue before discussing the different plan proposals in more detail.

[0:43:40] Justin Uberti presented “Plan B” slides:

http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-2.pdf

Justin went through his view of the requirements discussed in the previous meetings:

  1. Large number (over 100) arbitrary sources where simple PT demuxing is insufficient. Also not sufficient to break into separate “m= line” for each resolution
  2. Ability for receiver to control the number of sources it receives. “I want this stream to be on, this off, and for this I want this resolution and priority”
  3. Adding/removing streams without signaling glare.
  4. Some way of working with legacy devices. Basic functionality.
  5. Avoid unnecessary port allocation. 100 streams and 20 millisecond ICE pacing results in 2 second of delay
  6. Simple binding of MST to SDP; can match streams
  7. Support for RTC, FEC, simulcast when crammed into single RTP session
  8. Would be nice if plan is decoupled from Bundle; if finalizing bundle takes a while, allowing this being disassociated could be beneficial

Justin clarified what is meant by layered encoding and simulcast: with layered codec the on-the-wire codec may support multiple resolutions. On the other side one wants just single MST and best quality when that is rendered. There is need to signal dependency between streams. Same applies for simulcast: taking same MST and encoding with 2 different resolutions or codecs. Send hi-res and low-res version which may go over two different SSRCs and recipient chooses to show only one.

[00:51:33]

Justing presented features of Plan B. Each media type is own “m= line”. Multiple MSTs with same type over same “m= line”. Number of “m= lines” is number of media types: with audio call 1, video call 2, video with data 3. MST may have “.contenttype” property. If the property is set, that MST will be put on it’s own “m= line” with a=content and the type. Application can put e.g., presentation slides on separate “m= line” if needed for legacy.

When on the same “m= line”, a=ssrc attribute is used to bind set of SSRCs to “m= line” and msids. a=ssrc-group used with RTX and FEC flows. Also works with layered coding and simulcast but details need to be specified. a=remote-ssrc used to control which streams (resolution, RTX, FEC, etc.) are to be used.

[0:58:04]

Ekr(?): How to independently vary parameters on each m-line?

  1. Justin: all are sharing RTP session, all can use same RTP header extensions, SDES keys, etc. Sender can choose which things are used. Envelope negotiated provides parameters that is superset of all parameters.
  2. Ekr:  no way for receiver to say "send stream #1 with this codec, #2 with this"?
  3. Justin: in current plan B not possible

[00:59:33]

Demux using SSRCs. Legacy not defining SSRC values degrades nicely since they are on separate “m= lines”. Normal ICE across all m-lines (3 STUN & TURN ports). With BUNDLE down to 1 port.

[01:01:05]

Richard Ejzak: if peer does not signal SSRC, you can only play one stream at the time?

  1. Justin: one stream per “m= line”. But if you get different SSRCs, you could have a way to signal onAddStream event that means new MST and application figures out what to do with it. Not currently discussed in plan B.
  2. Jonathan: which could be turned into no-plan.

Justin: key thing what plan B provides what no-plan would need to figure out is grouping of things like repair and layered flows.

Flemming: what about non-RTP-based media flows?

  1. Justin: SCTP data channel case has defined behavior: if there’s new data channel coming in that has not been signalled before, that translates into new onDataChannel  event. In SDP you always just setup the envelope with the SCTP m-line. The datachannel stuff is done with inband protocol or external (to SDP) signaling.
  2. Flemming: and for more general case need some demuxing to do something similar?
  3. Justin: have not considered yet non-datachannel non-RTP yet
  4. Christer: how to separate data channel is separate question that we need to sort out in bundle or somewhere else anyway
  5. Jonathan: this is more about separating within single protocol than across protocols:RTP has SSRCs, data channel has channel IDs, any given m-line that has notion of lower-layer identifiers that needs to be defined. Some don’t, such as fax over TCP.

[1:06:50]

For adding/removing sources, new o/a exchange occurs. Source definition is declarative: here are sources I have available to send. The source receipt is part of the answer: you told me what you have available to send, here are the ones I want to receive. Always talking about sources other guy has, hence no glare. No new m-lines, no fight over m-line indexes.

  1. Paul: still causes glare from signaling perspective; one offer wins, other needs to re-transmit later.
  2. Justin: sure, other strategy for glare handling.
  3. Paul: both back off, but one goes first. This doesn’t reduce possibility for glare.
  4. Justin: glare becomes non-issue, since you can react immediately.
  5. Adam: reducing size of the atoms.
  6. Paul: doesn’t still reduce glare
  7. Justin: in SIP yes, in RTCWEB with non-SIP protocol carrying SDP could send partial update. Atom here is the individual source as opposed to set of m-lines
  8. Paul: this allows JSEP to diverge from semantics of o/a
  9. Justin: makes JSEP less constrained of requirements of o/a

[1:12:05]

  1. Cullen: important part is what changes is that since you’re always doing 1-way media with plan-B, that reduces the glare issue
  2. Justin: that helps, main thing is that new additions don’t compete for m-line indexes. I can try to send email on list on showing the details. Atoms are smaller and hence glare issues are pushed to the sideline.
  3. Jonathan: one way is to look at probability of SSRC collision
  4. Justin: that probability is exceedingly small
  5. Jonathan: atoms are small especially in SIP context, JSEP is not working on atoms either. How to translate glare issues to JSEP API calls?
  6. Paul: this discussion is making me uncomfortable about the relationship between JSEP and o/a. There are issues with o/a, but at least the issues are generally understood. JSEP is “loosely related” to o/a but is not the same, and hence has different set of rules how it works, but the rules are not clear.
  7. Justin: RTCWEB is waiting plan A/B decision before deciding the rules. How streams are handles needs to be documented by JSEP. Few ways to do it.

Flemming: running behind schedule. JSEP is important but should focus on MMUSIC issues and SDP o/a. Should do the comparison slide now?

  1. Justin: will go very quickly through examples; same as in the draft

[1:18:30]

Sample offer with 3 m-lines with audio and video, third video which has content property putting it into its own “m= line”. 3 audio sources in 1st “m= line”, 3 video sources, single slide source on 3rd “m= line”. msids would in real life be opaque identifiers but here friendly names for the purpose of understandability, not like this on wire. Slides supported with RTX. Center cam with 2 different resolutions. SSRC group used to indicate grouping.

Sample answer: just want to get main center mic, turn it on and leave others off. For main video: turn on 360p feed, priority is 1: more bandwidth for slides.

  1. Cullen: if there is no remote SSRC, that means that you don’t want to receive it?
  2. Justin: if offer is plan B aware, yes

[1:22:30]

  1. Flemming: same question for data channel; is there similar concept like remote SSRC for controlling that?
  2. Justin: handled through applications signaling or data channel protocol
  3. Richard: how about bandwidth? Any thought how to signal and aggregate that? Other attributes associated with the whole m-line.
  4. Justin: priority used for bandwidth allocation; very difficult for receiver to make decision on how to select bandwidth, but can indicate resolution. Sender can send sources with in line of priorities.
  5. Paul: how about priority for sender side? Sender may know which is more important
  6. Justin: sender can ignore values; receive will decide how to display so should know more how to prioritize

[1:25:40]

Mo: more important than one single parameter is how we will determine all different source level attributes that need to be available for applications

  1. Justin: did review Suhas’ document and came up with small set of attributes where this applies. It’s in the draft.
  2. Richard: do need to followup on the bandwidth. Some applications want and need more control
  3. Jonathan: source level bw attributes would be reasonable; need to cover it
  4. Adam: not specific to Plan A or Plan B

Mo: does content attribute need to be specifically called out? Or possible at the source level?

  1. Justin: property is on MST, if property is set, it’s split out on own m-line
  2. Mo: would we prohibit content attribute from being source level attribute?
  3. Jonathan: nothing wrong with having a=ssrc content attribute, just need to define one

[1:29:30]

Cullen: important difference between plan A & B, the one o/a established media from A to B, and that is followed by another o/a for media from B to A, correct?

  1. Justin: that’s correct; there is intractable problem that offer can’t decide which answer’s sources it wants before it sees them. You could have initial offer saying “please turn off these sources regardless of what they are” and do with 2-way handshake. Expectation for maximum flexibility is that you have o/a exchange and piggybacked in the initial answer would be new offer. 3-way handshake would complete in 1,5 RTT.
  2. Cullen: the second offer can’t be sent before the final, not provisional, answer is sent?
  3. Justin: you could include sources you are advertising in PR-answer. Offerer can’t respond before the answer.
  4. Randall: how extra o/a in the reverse direction impact beginning of call, clipping, and when initial answerer can send media and have it rendered by offerer?
  5. Justin: no case of clipping. Answerer wont send media until streams have been turned on. No race for media & signaling.
  6. Randall: but the person who hits answer button will be clipped?
  7. Justin: can be handled through UI
  8. Cullen: this is one of my main concerns. We tested this using BOSH. Experienced up to a second delay between the time user thinks he can talk and when he actually can without clipping. That’s huge amount of clipping.
  9. Justin: doesn’t match the behavior we’ve been seeing. Should be able to get signaling in hundreds of milliseconds.
  10. Cullen: it’s RTT through signaling servers. Can be substantial latency.
  11. Randall: there’s also chance for packet loss
  12. Justin: Not unique to Plan B. Can not answer with more “m= lines” than were offered. Will need second o/a exchange to add more.
  13. Randall: Different from clipping on answer issue.
  14. Justin: There is still an issue with conferences though; need 3-way handshake.
  15. Mo: Is 3-way handshake always required ?
  16. Justin: In simple case, you could do a single round-trip. Multi-stream and multi-screen case will require 3-way handshake; have to first see what streams are available.
  17. Flemming: Need to move the discussion along. Concern has been expressed and we need to dig into more detail.
  1. Justin: Still don’t think this is just a Plan B issue.
  2. Flemming: Plan A authors should address this as part of their presentation as well (1.5 RTT and potential for clipping as well as need for 3-way handshake).

[1:41:05] Adam Roach presented “A/B Testing” slides:

http://www.ietf.org/proceedings/interim/2013/06/17/mmusic/slides/slides-interim-2013-mmusic-3-3.pdf

Key point of Plan A: single m-line per RTP stream. Currently proposes separate “m= lines” for simulcast, layering (and maybe FEC). Demultiplexing based on SSRC, but initial identification, mapping to “m= lines”, of streams based on PT when a=ssrcs have not been yet received. This allows for 1 RTT instead of 1,5 RTT. Bundle-only attribute for “m= lines” that are not wanted if no bundling is done.

[1:43:50]

Simulcast grouping (Martin Thomson): same as proposed in plan B. Only difference: 1st lowest resolution one. Jonathan Lennox commented that this is mid grouping not SSRC grouping. Adam acknowledged that.

Adam continued explaining legacy (things using SDP outside of plan A/B realm) endpoint interop is achieved with bundle-only streams having having zero port in the offer and a=ssrc being not mandatory.

Skipped Plan B slides.

Differences summary: description on key different properties. Flemming asked to show Justin’s comparison slide side by side with the Plan A differences summary slide.

Jonathan Lennox: bundle-only should be part of bundle draft. Adam agreed, Ekr commented that once this is decided things should be folded into existing (JSEP, bundle, etc. drafts).

[1:47:35]

Justin Uberti: bundle-only similar to plan-B default line. Both plans require to do something for legacy to get full experience.

  1. Mo: Like the idea of being able to eliminate ports, but attributes on a zero-port m-line may be dropped by intermediaries, known middleboxes that do this -- but not arguing against bundle-only.
  2. Jonathan Lennox: not a problem if also bundle-lines are dropped.
  3. Christer: we’ve had this discussion before and should not have it again

Mo: agree with Justin that extra RTT is not a problem of A/B or demux but of source selection by offer.

  1. Cullen, for his use case, disagreeing.
  2. Discussion on how SSRC attributes can and should be used for indicating what one is willing to receive.  
  3. Paul: something else for context is needed in multi-stream case.
  4. Mo: we need to have option for both ways: to save half RTT or for full options.

[1:59:50]

Emil: How does plan A say "I want to receive any number of streams one can send to me". No way to say "unlimited"? Answerer can offer any number of streams.

  1. Cullen: Adam's plan represents a middle ground on this.

[2:02:10]

Justin going line by line the differences; "Comparison with Plan A".

Both support large number of arbitrary sources. Plan B supports resolution and priority for receiver control of sources, Plan A allows turning on/off with direction attributes..

  1. Adam: that's orthogonal to plan A/B; we're not trying to choose either plan as such but on a more general approach.
  2. Justin agrees.
  3. Cullen: can easily add priority attribute to plan A and they're equal.
  4. Justin: work for Plan A & B is roughly the same for receiver control of sources.

Glareless add (Justin): Plan B supports natively, Plan A uses one side as persistent offerer, and hence never has glare. Plan A would have additional half RTT where non-persistent offerer needs to send offer.

  1. Martin: plan B has no "extra" RTT because it always has the extra RTT.
  2. Justin: only in initial setup.
  3. Martin: not relevant point for comparison.
  4. Cullen: would like to see much more details how this works: both hit "add video" button at the same time. How all that is going to resolve in one RTT.

[2:12]

  1. Adam: There are other ways to solve this with plans.
  2. Justin: painful with “m= lines” since they are ordered. Makes solutions more complicated. Not problem with plan B since SSRCs are not ordered.
  3. Paul: only problem if you step away from RFC3264.

Legacy interoperability (Justin): both can interoperate with legacy. Bundle-only or default thing of plan B needs to be selected by the application manually.

  1. Adam: legacy interop with plan B adds more complexity.
  2. Cullen: JavaScript in plan B needs to know if it's talking to legacy device.
  3. Ekr: in both cases you lose some m-lines.
  4. Cullen: bundle can be added easily and is something that has been wanted for long time.
  5. Justin: can make legacy devices work with plan-B with simple signaling gateway or easily make them plan B capable too. RTP on the wire is the same.
  6. Adam: Plan A is simpler as code changes.
  7. Justin: bundle has turned out to be more complex than initially envisioned.

Avoidance of unnecessary ports (Justin): both can do, no essential difference.

Simple binding of track to SDP: for plan A not defined in the draft currently?

  1. Cullen: using msid.

[2:19:50]

  1. Emil: if plan A devices gets SSRC that doesn't match with m-line, what does it do?
  2. Adam: currently ignores, but we can define behavior.
  3. Cullen: you need unique payload types or RTP header extension to handle this.
  4. Cullen: as summary, similar in both plans.

Support for RTX, FEC, Simulcast: both do via SSRC signaling, difference: as now written, plan A has repair flows as own “m= lines”. Separate “m= lines” could get out of sync. Plan-B has hierarchy.

  1. Cullen: seems like a non-issue.
  2. Various comments and discussion on whether there is real issue here.

[2:26:45]

  1. Flemming: Is there a fundamental issue here?
  2. Adam: No - syntactic complaint.
  3. Flemming: How big of a deal is this ?
  4. Justin and Adam discussed further whether this is an issue or not.

Cullen: Let’s agree that the two proposals are identical here:

  1. Martin: one aspect where not identical: FEC in some implementation uses same SSRC as the stream it repairs, can't do with plan B.
  2. Jonathan: with bundle you have different SSRCs.
  3. Mo: updating this and never seen same SSRCs on repair streams.
  4. Martin: aware of one.
  5. Cullen: likewise.
  6. Paul: becomes a codec issue. (Moving on)

Works without bundle: Plan A requires, plan B not, but can benefit. Details well discussed.

  1. Cullen: Plan A works without bundle (just regular Offer/Answer).
  2. Adam: this is spec-dependency issue.

Justin: one more point: on wire-level plans look the same, single RTP session. Can convert between plans with signaling GW if needed.

  1. Jonathan: point to point call would be using few enough PTs so that you can do PT multiplex repair flow.

Cullen: with signaling GW tried to work out call flows where call is initiated from SIP side and SIP endpoint thinks it's doing 2-way handshake and signaling GW tries to map that to 4-way handshake. If GW is terminating media this works, but if not, it's not clear how it works. Plan B is not doing 3264 o/a. Mapping to 3264 would require good example before sold at going down with plan B approach.

  1. Paul agrees we need more detail before we can evaluate.
  2. Justin: can do plan B with single o/a.

Adam: only two differences are reliance on Bundle draft and how glare is dealt with.  All others are essentially identical.

Keith Drage: What do we mean by 3264 needs enhancing (as indicated by Paul and Cullen) ?

  1. Martin: depends on adoption of Plan B.
  2. Jonathan: at Boston interim there was discussion of adding “m= lines” with partial updates.
  3. Paul: seems like you need to know if you're talking to 3264 devices before you know if you can use JSEP.
  4. Ari: something to clarify in the drafts.
  5. Paul: agreement on there is difference in interworking?
  6. Adam: yes, also signaling GW needs to understand semantics of new attributes.

[2:41:10]

Adam: Differences summary slide (#10 in "A/B Testing" slides):

  1. In plan A m-line is the fundamental item on negotiation attributes, as opposed to promoting the a=ssrc as one of interest. The latter has problem that we need flag day after which "these are the things for which a=ssrc applies". You need manually put to registry for which this is allowed. This is substantial drawback.

Bernard: Plan A has serious backward compatibility issues with layered codecs since they require single session transport but don't use bundle. If you use multiple ports, it's not SST (using single port & RTP session for multiple layers).

  1. Cullen: you do like you do with SIP today.
  2. Bernard: SST is single m-line. Can't use multiple m-lines without bundle.

[2:44:40]

Discussion on SST and how it is implemented. Bernard to send more info to the mailing list.

[2:48:50:]

Mo: Is plan A trying to be prescriptive on not using of a=ssrc-level attributes or is any currently standardized SDP OK?

  1. Adam: not trying to say don't do it, but trying to avoid whole lot of work on how to define this.

Flemming: 5 minutes left. Final comments?

  1. Adam: Covered everything. We require bundle, and will help if needed to finish that work. Need discussion on how to deal with glare differences between A/B; work ways to improve. Changing atomicity of o/a for avoiding glare.
  2. Justin: didn't talk about plan A: to what extent parameters need to be same with “m= lines”. If everything is own “m= line”, what kind of complexity this imposes. Two different things in same media stream track. For simulcast stuff we have proposal how this works, but need more details how this is handled so that get single MST on input and output sides. Lastly, the wire stuff ending the same, 2-way vs 3-way handshake essentially same. Anything like SSRC collision handling is same with both plans. Main thing: plan B, unlike A, can do glare handling since it doesn't have to worry about ordering of m-lines.
  3. Flemming: From chairs' point of view, we're not close to consensus but need to make hard decision before too long. For both camps (or all three?): assuming your proposal is not the one making it, what are the top 3 things, in prioritized order, you would like the competing proposal to make sure to address. What can't you live with. If everybody can come to Berlin prepared for that with e-mail discussion or draft. People start to be prepared for painful decisions. We can't continue like this but need to make choices. If there are any other suggestions how to break this, we're all ears.
  4. Justin: Talked with Adam before meeting: believe there is room for finding solution that can make everyone happy. Will see what we can do. If we can come with one, like to avoid very long process with resolving that with rest of the WG.
  5. Flemming: Whole WG participates in the process. But lot of people would be relieved if plan A and B camps can come up with common proposal.
  6. Cullen: The clipping issue Randall raised is important to solve, incl. in a compromise proposal.

Meeting ended.

List of attendees:

Adam Roach

Alan Johnston

Andy Hutton

Ari Keranen

Bernard Adoba

Christer Holmberg

Cullen Jennings

Dan Romanascu

Emil Ivov

Eric Rescorla

Flemming Andreasen

Harald Alvestrand

Jeremy Fuller

John Leslie

Jonathan Lennox

Justin Uberti

Keith Drage

Maire Reavy

Mary Barnes

Martin Thomson

Mo Zanaty

Parthasarati R

Paul Kyzivat

Randall Jesup

Richard Ejzak

Stephan Wenger

Thomas Stach

Uwe Rauschenbach