See also: IRC log
Meeting Slide Deck (PDF version)
HTA: goal to make progress toward
CR, not add new features
... we expect to merge pull requests after the meeting and get
a new editors draft, probably in the course of next week
Cullen: to be clear, that next version is not expected to be ready to go to CR, right?
HTA: correct
... we need to close all open bugs before going to CR
EKR: I've been going through the
draft, finding plenty of editorial errors
... how should I address them? One big PR?
HTA: small PRs would be best (and they're better than comments)
HTA: we're planning to discuss 5 pull requests, and time permitting, 5 open issues without attached pull requests
<vivien> PR 662
Bernard: once you stop a track,
it is final, but the receiver itself is not stopped
... Stefan asked what happen if you clone a receiver.track
Bernard: in particular, if a source should stop when all tracks are stopped
hta: I think an implementation should be free to turn off the decoder (since it's not observable)
adambe: is calling stop on an incoming track the way to reject it? that's what the spec currently says
hta: no, it's no
bernard: the PR doesn't fix that
yet
... nobody is pushing for having an implicit
transceiver.stop(), that's what I was interested in hearing
<vivien> PR 675
Bernard: the proposal in the PR
is to add a frob to the encoding parameter that would turn
on/off voice activity detection
... it would not set the negotiation needed flag
... Two opinions sought: is this something we need to do? if it
is, is this the right way to do it?
EKR: my understanding is that this is the only way to do this
Bernard: that's pretty much the only practical way without renegotiation
Cullen: in terms of need, I think we already agreed we needed it e.g. for 911 calls
Cullen: so the main question is
whether this is the right place
... negotiating the codec doesn't say if CN is on or off, it
makes it available to turn on/off
EKR: if someone on the remote
side is saying "don't send CN or DTX", there is currently no
way to do that
... SDP is just informative here
... I think it has to be on the transceiver
HTA: I think it's a frob on the encoding parameter
EKR: fair enough
Jesup: I agree as well
Bernard: so consensus to do it, and do it sort of this way (but people should comment on the PR for the finer details)
EKR: I'm fine with this FWIW; I have no strong opinion on the naming
<jesup> Agree, we have consensus to move forward
Bernard: we need to clarify that this is more for DTX than CN, but seems like rough consensus
<vivien> PR 646
<vivien> (slide 8)
Bernard: this is to clarify some
aspects that were already in the spec but had caused
troubles
... if you call getParameters on a receiver, the only thing you
get back is fec and rtx
Peter: why not ssrc as
well?
... if they were negotiated in SDP
Bernard: Peter, could you comment
on the PR so that we fix it?
... proposal is otherwise to proceed with integrating this
Cullen: I think the proposal
makes sense
... I'll follow up with more specific questions on
maxBitrate
HTA: maxBitrate and maxFramerate don't cause negotiations, so the receiver wouldn't know about them
<vivien> Issue 650
<vivien> (slide 9)
Bernard: we have a mimeType
attribute in CodecParameters and CodecCapabilities
... is this the media type, the subtype, both?
<vivien> PR 648
<vivien> (slide 10)
Bernard: PR 648 proposes the
subtype (e.g. "opus")
... HTA is suggesting type/subtype
... the question is then if type is always going to be the same
as .kind
HTA: in the depth case, the most common encoding is VP8 (using the alpha channel)
Cullen: I think it would be very
unlikely that the IETF would allocate a new "depth" type
... it would thus be "video" or "image"
HTA: we've had all sort of
troubles with the separation of type and subtype in SDP
... I don't want to repeat the mistake
Bernard: so you're suggesting including both; any objection to that?
[none]
<vivien> PR 666
<vivien> (slide 11)
Bernard: addTransceiver and
addTrack create a transceiver with a dtls transport
... until the certificate is ready, should that attribute be
null?
... if not, should we a promise instead
... so far, support for having a null attribute
... there is already a case of a transport without a
certificate
... createOffer/createAnswer gives guarantee of having a cert
if needed
Taylor: yeah, we couldn't think
of a compelling reason to know when the certificate is
ready
... and you can get the equivalent by waiting for the
resolution of createOffer/createAnswer
... can anyone think of a compelling reason?
Cullen: not sure I fully understood the proposal
Taylor: the proposal is to not make the calls async
Bernard: and thus you could have null transport (if it's not ready yet)
<vivien> (slide 12)
Cullen: works for me
HTA: consensus
Bernard: PR 666 makes transport nullable and adds some text to that effect; please comment on the PR if needed
<vivien> Issue 571
<vivien> (slide 13)
AdamB: this is somewhat
related
... how do we signal that arrival of new information on
receiver
... we could add new events
... we can also look how far setLocal/RemoteDescription
fulflilment gets us
Bernard: when setLocal/setRemote returns, you're guaranteed to have a non-null transport attribute, and if not using mux, to have a non-null rtcpTransport
HTA: I think there is no
compelling reason to know exactly when stuff happens
... but we need to know when everything is ready
... and that's what the promise resolution gives us
<vivien> Issue 583
<vivien> (slide 14)
Adam: We don't allow to add
several times the same track with addTrack
... should addTransceiver allow it?
... people seem to support it as an advanced feature
... any other input on this?
HTA: what resolution are you proposing?
AdamBe: The resolution would be that adding the same track in addTransceiver is allowed
HTA: i.e. no change?
AdamBe: the spec already allows
it indeed
... As a side note, we should have a way to implement addTrack
in terms of addTransceiver
... addTransceiver + the restriction is basically addTrack — I
think we should investigate that
Peter: I think there are some differences still between the two (e.g. creation of a transceiver)
AdamBe: yeah, I guess it's more a question of someone taking a stab at it and see if it works
<vivien> Issue 585
<vivien> (slide 15)
AdamBe: the spec is light on how
Transceiver.stop() works; currently, it doesn't set the
negotiation needed flag
... Should it act right away or set the flag?
Bernard: can we do both? act right away locally, and set the negotiated needed flag to transmit remotely
@@@: that's what we had in mind when we wrote the text
Cullen: +1 to that
Bernard: we might need more text to explain this, but I think that's the right approach
HTA: Transceiver.stop rejects a m-line, right?
Bernard: right
<vivien> Issue 568
<vivien> (slide 16)
AdamBe: this concerns other
legacy APIs (addStream, getLocalStreams, removeStream,
etc)
... they are quite widely used, but have been removed from the
spec, which makes it hard for new implementations to work with
existing content
... we have descriptions of other legacy callback methods
... should we do the same for these?
... I would suggest something simpler than we initially had
imagined
Jan-Ivar: we implement addStream
on top of addTrack; we do not implement removeStream
... in Firefox
<vivien> (slide 17)
AdamBe: slide 17 describes what
the functions would look like
... the events (slide 18) are more tricky
Cullen: this feels like a
browser-decision, so I don't care much
... but if we have them in the spec, I think people will keep
using them
... if we plan on removing them, we should not add them
back
adambe: there has been a request to expose streams
peter: I think we already decided NOT to have them in the spec
<adamR> +1 on removal
<jib_> +1 on removal
<vivien> (slide 18)
peter: otherwise, we require them in the browser
EKR: agreed; we might want to write it up somewhere in a wiki, not in the spec
adambe: I'm fine with that
stefan: where does the request to have stream in the spec?
adambe: we had an issue raised recently on this
stefan: I'm +1 on not putting in the spec
hta: there is a question of having an event for new streams rather than tracks
adambe: you get the stream in the track event
hta: but then you have to keep track of streams - which is not hard
adambe: ok; then they're really really deprecated
<vivien> Issue 548 RTX RED FEC Handling:
<vivien> (slide 19)
Bernard: my understanding is that
today they're treated as codecs: they show up in the codecs
sequence
... you would get audio/rtx, audio/red, audio/ulpfec as mime
types
... but you can't necessarily use these in any combination
Peter: how much a burden would it be to require support of all combination?
bernard: probably not a burden
for a given codec
... but the real question is whether to have it in the list of
codecs
Peter: I think it's a valid question to ask where RTX should go in the list of parameters
<vivien> (slide 20)
Bernard: Robin Raymond is
proposing to put them as attributes of a codec instead
... this also makes it more elegant for parameters
Cullen: afaict RTX is mandatory
to implement for a WebRTC implementation, so we know it's
implemented, no need for a capability
... it makes sense not make it a codec (i.e remove it from the
list of codecs)
... not sure about what comes next
Bernard: I guess the first step is to know if there is support for changing the model and come with a better proposal
Cullen: I would want to see a use case to see what it's exposed at all
HTA: it can be turned off
Bernard: also, RED is not
mandatory to implement, so it needs to be discoverable
... not all FEC are mandatory
Cullen: makes sense to make them discoverable then indeed
HTA: there is also the need to control them
Cullen: but that's separate
Bernard: they show up in the
codec list, but reordering as no meaning
... the only thing you can do is to remove them from the
list
Peter: yes, it would prevent from being used
Bernard: as I understand it, RTX
shows up once in the capabilities list, but multiple times in
the parameters (once for each you're transmitting)
... although the spec doesn't say that in any detail
... My take away is that there is interest in exploring an
alternative; I'll bring something to the list
Peter: for FEC and RED, I'm not
so convinced it makes sense; RED is not a thing on a particular
codec
... FEC is yet another beast
... but it's an interesting idea for RTX
Bernard: yeah, it's a bit weird;
right now, there is no way to expose the combination of
capabilities that can be used
... you're configuring RED and FEC separately, but you can't
set that you're using them together
... that's probably true of SDP itself
HTA: we seem to have resolved most issues, with lack of conclusion on 548
Bernard: I heard interest on an
alternative proposal, with some belief that RTX needs to be
handled different from FEC / RED which I think is true
... we need a more concrete proposal in any case
... I think Robin has an idea, but he hasn't posted it yet
HTA: so we'll see a new proposal
on the subject
... on the rest, we have detected consensus and we'll ask the
PR/issue owners to take action
... thank you all for coming!
... and sorry for the logistics
... and thanks Cullen for fixing it!
trackbot, end meeting