Web Real-Time Communications Working Group Teleconference

27 May 2016



See also: IRC log


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
HTA, Stefan


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

PR 662 Calling receiver.track.stop()

<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

PR 675 Turn on/off sending CN/DTX

<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

PR 646 RTCRtpEncodingParameters attributes

<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

Issue 650 mimeType clarifications

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


PR 666 addTransceiver/addTrack async

<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

Issue 571 Populating sender/receiver at creation time

<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

Issue 583 Difference of behavior for addTransceiver/addTrack

<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

Issue 585 Transceiver.stop and negotiation

<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

Issue 568 addStream() / addStream event behavior

<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

Issue 548

<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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/06/01 07:42:04 $