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
- 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
- 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.
- 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.
- 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?
- 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.
- Eric again noted that these aren’t questions for MMUSIC.
- 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.
- Eric didn’t disagree with that, however he believes the SDP should look different when sending one versus two sources.
- Jonathan countered that this wasn’t the case for SAP (or Mbone) usage of SDP.
- 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.
- 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”.
- Flemming said it would end up being a longer discussion than that once we open it up.
- Mary said that we should have some air-time on it and it is relevant to how we should interpret an “m= line”.
- 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.
- Mary then asked that the RTCWeb chairs schedule a virtual interim (for RTCWeb) to talk about the “no plan” draft.
- Bernard Adoba requested that too.
- 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:
- Bernard
Adoba objected and stated that the way this was being handled was
fairly outrageously egregious and not appropriate under IETF
procedures.
- Flemming asked Bernard to explain further.
- Bernard clarified that it looked like a predetermined effort to prevent somebody from presenting at the IETF.
- Mary agreed and noted it was unfortunate that there were not any Area Directors on the call.
- Bernard said we were almost guaranteed to get an appeal now.
- 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.
- Randall Jessup was equally confused as to why this was an issue for this meeting.
- 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”.
- Flemming said that the MMUSIC group cannot make that decision; it is a decision for the RTCWeb WG.
- Mary and Bernard said it absolutely is a decision that belongs in MMUSIC.
- 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.
- 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.
- Cullen thought Bernard was being disruptive to the process and asked Bernard to provide more detail on what the problem is.
- 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.
- 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.
- 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.
- 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.
- Bernard agreed.
- Justin Uberti suggested we stopped arguing and just give Emil 10 minutes to present at this point.
- Flemming agreed with that proposal if people thought that would move us forward
- 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
- 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).
- 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.
- 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.
- Jonathan said he believes Emil simply views this as out of scope for MMUSIC.
- 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.
- 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.
- Emil disagrees with that assertion.
- 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).
- Justin asked how we would know which video tag would go where if we had two video tags.
- Emil asked if we are talking about RTCWeb ?
- Bernard replied this was handled by the API proposal.
- 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.
- Jonathan said that nobody knows because people don’t agree on what the SDP semantics are. Jonathan believes that:
- 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.
- 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.
- 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.
- Jonathan noted there would be different answers to the offer.
- 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.
- Jonathan said there is a distinction at the RTP level though
- Cullen agreed but noted this is not what Emil asked.
- Jonathan agreed, but said he probably should have.
- Cullen agreed and noted that the draft needs to evolve to have a more productive discussion.
- 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”.
- Eric said the question is how to render them; should they be switched or rendered at the same time ?
- Bernard said that’s handled in the API.
- 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.
- Emil said MMUSIC could leave that to other types of signaling.
- Flemming said that it’s not obvious that we can do that.
- Adam was concerned about interoperability with legacy applications.
- Emil
thought it was the only proposal that would work with legacy
applications; keep to a single stream when talking to a legacy app.
- Adam said there are existing video conferencing implementations that use multiple “m= lines”.
- 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
?
- 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.
- Eric Rescorla asked if we were going to define 3 mechanisms ?
- 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).
- Bernard (?) believes it could influence CLUE.
- Mary believes this could apply to CLUE, but no decision has been made in CLUE.
- Flemming stated that part of the reason for doing the work in MMUSIC is that it should apply beyond RTCWeb.
- Paul Kyzivat believes either of the plans could work for CLUE. However, for interoperability, we all have to make a consistent choice.
- 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 ?
- Jonathan said yes and no. For basic functionality, you don’t need anything beyond the basic RTP flows themselves.
- Eric Rescorla questioned that.
- 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.
- 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.
- 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.
- 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:
- Large
number (over 100) arbitrary sources where simple PT demuxing is
insufficient. Also not sufficient to break into separate “m= line” for
each resolution
- 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”
- Adding/removing streams without signaling glare.
- Some way of working with legacy devices. Basic functionality.
- Avoid unnecessary port allocation. 100 streams and 20 millisecond ICE pacing results in 2 second of delay
- Simple binding of MST to SDP; can match streams
- Support for RTC, FEC, simulcast when crammed into single RTP session
- 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?
- 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.
- Ekr: no way for receiver to say "send stream #1 with this codec, #2 with this"?
- 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?
- 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.
- 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?
- 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.
- Flemming: and for more general case need some demuxing to do something similar?
- Justin: have not considered yet non-datachannel non-RTP yet
- Christer: how to separate data channel is separate question that we need to sort out in bundle or somewhere else anyway
- 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.
- Paul: still causes glare from signaling perspective; one offer wins, other needs to re-transmit later.
- Justin: sure, other strategy for glare handling.
- Paul: both back off, but one goes first. This doesn’t reduce possibility for glare.
- Justin: glare becomes non-issue, since you can react immediately.
- Adam: reducing size of the atoms.
- Paul: doesn’t still reduce glare
- 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
- Paul: this allows JSEP to diverge from semantics of o/a
- Justin: makes JSEP less constrained of requirements of o/a
[1:12:05]
- Cullen: important part is what changes is that since you’re always doing 1-way media with plan-B, that reduces the glare issue
- 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.
- Jonathan: one way is to look at probability of SSRC collision
- Justin: that probability is exceedingly small
- Jonathan:
atoms are small especially in SIP context, JSEP is not working on atoms
either. How to translate glare issues to JSEP API calls?
- 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.
- 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?
- 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.
- Cullen: if there is no remote SSRC, that means that you don’t want to receive it?
- Justin: if offer is plan B aware, yes
[1:22:30]
- Flemming: same question for data channel; is there similar concept like remote SSRC for controlling that?
- Justin: handled through applications signaling or data channel protocol
- Richard: how about bandwidth? Any thought how to signal and aggregate that? Other attributes associated with the whole m-line.
- 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.
- Paul: how about priority for sender side? Sender may know which is more important
- 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
- Justin: did review Suhas’ document and came up with small set of attributes where this applies. It’s in the draft.
- Richard: do need to followup on the bandwidth. Some applications want and need more control
- Jonathan: source level bw attributes would be reasonable; need to cover it
- 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?
- Justin: property is on MST, if property is set, it’s split out on own m-line
- Mo: would we prohibit content attribute from being source level attribute?
- 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?
- 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.
- Cullen: the second offer can’t be sent before the final, not provisional, answer is sent?
- Justin: you could include sources you are advertising in PR-answer. Offerer can’t respond before the answer.
- 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?
- Justin: no case of clipping. Answerer wont send media until streams have been turned on. No race for media & signaling.
- Randall: but the person who hits answer button will be clipped?
- Justin: can be handled through UI
- 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.
- Justin: doesn’t match the behavior we’ve been seeing. Should be able to get signaling in hundreds of milliseconds.
- Cullen: it’s RTT through signaling servers. Can be substantial latency.
- Randall: there’s also chance for packet loss
- 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.
- Randall: Different from clipping on answer issue.
- Justin: There is still an issue with conferences though; need 3-way handshake.
- Mo: Is 3-way handshake always required ?
- 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.
- Flemming: Need to move the discussion along. Concern has been expressed and we need to dig into more detail.
- Justin: Still don’t think this is just a Plan B issue.
- 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.
- 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.
- Jonathan Lennox: not a problem if also bundle-lines are dropped.
- 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.
- Cullen, for his use case, disagreeing.
- Discussion on how SSRC attributes can and should be used for indicating what one is willing to receive.
- Paul: something else for context is needed in multi-stream case.
- 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.
- 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..
- Adam: that's orthogonal to plan A/B; we're not trying to choose either plan as such but on a more general approach.
- Justin agrees.
- Cullen: can easily add priority attribute to plan A and they're equal.
- 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.
- Martin: plan B has no "extra" RTT because it always has the extra RTT.
- Justin: only in initial setup.
- Martin: not relevant point for comparison.
- 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]
- Adam: There are other ways to solve this with plans.
- Justin:
painful with “m= lines” since they are ordered. Makes solutions more
complicated. Not problem with plan B since SSRCs are not ordered.
- 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.
- Adam: legacy interop with plan B adds more complexity.
- Cullen: JavaScript in plan B needs to know if it's talking to legacy device.
- Ekr: in both cases you lose some m-lines.
- Cullen: bundle can be added easily and is something that has been wanted for long time.
- 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.
- Adam: Plan A is simpler as code changes.
- 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?
- Cullen: using msid.
[2:19:50]
- Emil: if plan A devices gets SSRC that doesn't match with m-line, what does it do?
- Adam: currently ignores, but we can define behavior.
- Cullen: you need unique payload types or RTP header extension to handle this.
- 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.
- Cullen: seems like a non-issue.
- Various comments and discussion on whether there is real issue here.
[2:26:45]
- Flemming: Is there a fundamental issue here?
- Adam: No - syntactic complaint.
- Flemming: How big of a deal is this ?
- Justin and Adam discussed further whether this is an issue or not.
Cullen: Let’s agree that the two proposals are identical here:
- Martin:
one aspect where not identical: FEC in some implementation uses same
SSRC as the stream it repairs, can't do with plan B.
- Jonathan: with bundle you have different SSRCs.
- Mo: updating this and never seen same SSRCs on repair streams.
- Martin: aware of one.
- Cullen: likewise.
- Paul: becomes a codec issue. (Moving on)
Works without bundle: Plan A requires, plan B not, but can benefit. Details well discussed.
- Cullen: Plan A works without bundle (just regular Offer/Answer).
- 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.
- 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.
- Paul agrees we need more detail before we can evaluate.
- 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) ?
- Martin: depends on adoption of Plan B.
- Jonathan: at Boston interim there was discussion of adding “m= lines” with partial updates.
- Paul: seems like you need to know if you're talking to 3264 devices before you know if you can use JSEP.
- Ari: something to clarify in the drafts.
- Paul: agreement on there is difference in interworking?
- 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):
- 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).
- Cullen: you do like you do with SIP today.
- 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?
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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