- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 30 May 2016 13:42:42 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hi all,
The minutes of the the WebRTC WG call on May 27 are available at:
https://www.w3.org/2016/05/27-webrtc-minutes.html
and copied as text below.
Please send suggested corrections to the list.
Thanks,
Dom
Web Real-Time Communications Working Group Teleconference
27 May 2016
[2]Agenda
[2] https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
See also: [3]IRC log
[3] http://www.w3.org/2016/05/27-webrtc-irc
Attendees
Present
AdamR, BernardA, Cullen, Harald, JanIvar, Shijun,
Stefan, TaylorB, Vivien, Dom, PeterT, EKR, AdamBe,
Jesup, Sherwim, Tim_Patton, Varun, Victor_Pascual,
Andy_Hutton, Emil_Ivov, Maire_Reavy
Regrets
Erik
Chair
HTA, Stefan
Scribe
Dom
Contents
* [4]Topics
1. [5]Welcome
2. [6]Agenda
3. [7]PR 662: Calling receiver.track.stop()
4. [8]PR 675 Turn on/off sending CN/DTX
5. [9]PR 646 RTCRtpEncodingParameters attributes
6. [10]Issue 650 mimeType clarifications
7. [11]Issue 571 Populating sender/receiver at creation
time
8. [12]Issue 583 Difference of behavior for
addTransceiver/addTrack
9. [13]Issue 585 Transceiver.stop and negotiation
10. [14]Issue 568 addStream() / addStream event behavior
11. [15]issue 548
12. [16]Conclusion
* [17]Summary of Action Items
* [18]Summary of Resolutions
__________________________________________________________
->
[19]https://docs.google.com/presentation/d/125hFryKyXQWmR13N_al
-s0L4sawBeYKLcuD344LU7QY/edit?usp=sharing Meeting Slide Deck
[19]
https://docs.google.com/presentation/d/125hFryKyXQWmR13N_al-s0L4sawBeYKLcuD344LU7QY/edit?usp=sharing
Welcome
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)
Agenda
HTA: we're planning to discuss 5 pull requests, and time
permitting, 5 open issues without attached pull requests
PR 662: Calling receiver.track.stop()
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
<vivien> [20]PR 662
[20] https://github.com/w3c/webrtc-pc/pull/662
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
PR 675 Turn on/off sending CN/DTX
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
<vivien> [21]PR 675
[21] https://github.com/w3c/webrtc-pc/pull/675
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> [22]PR 646
[22] https://github.com/w3c/webrtc-pc/pull/646
PR 646 RTCRtpEncodingParameters attributes
<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
Issue 650 mimeType clarifications
<vivien> [23]PR 650
[23] https://github.com/w3c/webrtc-pc/pull/650
<vivien> (slide 9)
Bernard: we have a mimeType attribute in CodecParameters and
CodecCapabilities
... is this the media type, the subtype, both?
<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 likely 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]
Topci: PR 666 addTransceiver/addTrack async
<vivien> [24]PR 666
[24] https://github.com/w3c/webrtc-pc/pull/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
Issue 571 Populating sender/receiver at creation time
<vivien> [25]Issue 571
[25] https://github.com/w3c/webrtc-pc/issues/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
Issue 583 Difference of behavior for addTransceiver/addTrack
<vivien> [26]Issue 583
[26] https://github.com/w3c/webrtc-pc/issues/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> [27]Issue 585
[27] https://github.com/w3c/webrtc-pc/issues/585
<vivien> (slide 15)
Issue 585 Transceiver.stop and negotiation
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
Issue 568 addStream() / addStream event behavior
<vivien> [28]Issue 568
[28] https://github.com/w3c/webrtc-pc/issues/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
issue 548
<vivien> [29]Issue 548 RTX RED FEC Handling:
[29] https://github.com/w3c/webrtc-pc/issues/548
<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
Conclusion
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!
Received on Monday, 30 May 2016 11:42:46 UTC