W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2016

[minutes] May 27 Virtual Interim

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>
Message-ID: <574C2732.2080704@w3.org>
Hi all,

The minutes of the the WebRTC WG call on May 27 are available at:
and copied as text below.

Please send suggested corrections to the list.



       Web Real-Time Communications Working Group Teleconference

27 May 2016


      [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


          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



     * [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
         8. [12]Issue 583 Difference of behavior for
         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

   -s0L4sawBeYKLcuD344LU7QY/edit?usp=sharing Meeting Slide Deck



   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()

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

   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

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


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

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

   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
   ... but you can't necessarily use these in any combination

   Peter: how much a burden would it be to require support of all

   bernard: probably not a burden for a given codec
   ... but the real question is whether to have it in the list of

   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
   ... 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
   ... 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!
Received on Monday, 30 May 2016 11:42:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC