IRC log of webrtc on 2016-05-27

Timestamps are in UTC.

14:58:53 [RRSAgent]
RRSAgent has joined #webrtc
14:58:53 [RRSAgent]
logging to http://www.w3.org/2016/05/27-webrtc-irc
14:58:55 [trackbot]
RRSAgent, make logs world
14:58:55 [Zakim]
Zakim has joined #webrtc
14:58:57 [trackbot]
Zakim, this will be RTC
14:58:57 [Zakim]
ok, trackbot
14:58:58 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
14:58:58 [trackbot]
Date: 27 May 2016
15:01:15 [jib]
jib has joined #webrtc
15:01:22 [dom]
Agenda: https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:01:26 [dom]
Chair: HTA, Stefan
15:01:28 [vivien]
vivien has changed the topic to: https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:01:39 [dom]
Regrets: Erik
15:03:02 [stefanh]
stefanh has joined #webrtc
15:03:19 [dom]
Present+ AdamR, BernardA, Cullen, Harald, JanIvar, Shijun, Stefan, TaylorB, Vivien, Dom
15:03:40 [vivien]
Present+ PeterT
15:03:44 [dom]
Present+ EKR
15:04:18 [dom]
-> https://docs.google.com/presentation/d/125hFryKyXQWmR13N_al-s0L4sawBeYKLcuD344LU7QY/edit?usp=sharing Meeting Slide Deck
15:04:26 [adambe]
I get "This video call is full"
15:04:50 [vivien]
(we are 10 particiapnts conencted currently)
15:05:09 [vivien]
s/particiapnts conencted/participants connected/
15:06:34 [adamR]
hta1: I assume you’re post the new link in here, too?
15:06:50 [hta1]
https://hangouts.google.com/call/trp5t5vmmrb5tfzagzzevgx324e
15:06:50 [vr000m]
vr000m has joined #webrtc
15:07:07 [sherwinsim]
sherwinsim has joined #webrtc
15:08:37 [sherwinsim]
Do people have the updated links?
15:08:52 [hta1]
I hae updated the wiki. will send mail too.
15:09:01 [dom]
Present+ AdamBe
15:09:29 [jib]
jib has joined #webrtc
15:10:07 [hta1]
New link: https://hangouts.google.com/call/trp5t5vmmrb5tfzagzzevgx324e
15:11:03 [Bernard]
Bernard has joined #webrtc
15:11:11 [timpanton]
timpanton has joined #webrtc
15:11:16 [sherwinsim]
new link is full
15:11:18 [Bernard]
What is the link to the new Hangout?
15:11:25 [sherwinsim]
is there a live stream for pasive viewers?
15:11:30 [jesup]
jesup has joined #webrtc
15:11:49 [jesup]
is there a new link?
15:12:04 [timpanton]
That's full.
15:12:06 [Bernard]
I get a "full" error.
15:14:12 [timpanton]
We could use a Jitsi room - they run a public server that should scale a reasonable way up.
15:14:54 [Bernard]
https://jitsi.tools.ietf.org/webrtc
15:15:30 [hta1]
We follow Bernard.
15:16:02 [sherwinsim]
Seems to be much better
15:16:03 [vivien]
vivien has changed the topic to: ** New link https://jitsi.tools.ietf.org/webrtc ** https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:17:01 [adamR]
I can’t hear or see anything...
15:17:55 [jesup]
I was talking, but got no response (yes, i unmuted)
15:18:06 [jesup]
when I unmuted video, I could see myself
15:18:48 [adamR]
fluffy: you are muted
15:19:07 [jesup]
yet to hear or see anything
15:19:39 [adamR]
jesup: Apparently, jitsi doesn’t work with Firefox
15:19:53 [jesup]
wonderful... switching
15:20:04 [adambe]
fluffy: I see you talking but I can't hear you
15:20:36 [vivien]
vivien has changed the topic to: ** New link https://jitsi.tools.ietf.org/webrtc (Chrom* browser only sorry ) ** https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:22:07 [jesup]
adamR: sadface
15:23:16 [adamR]
jesup: Yeah. Emil mentioned some bug, althoughi don’t know which one.
15:24:49 [vivien]
dom, ok :(
15:25:06 [fluffy]
yes, I can get a webex if Dom can't
15:25:19 [fluffy]
working on it
15:26:04 [vivien]
vivien has changed the topic to: ** Moving to WebEx (call details pending) ** https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:26:35 [vivien]
** Moving to WebEx (call details pending) **
15:26:49 [fluffy]
cisco.webex.com/meet/fluffy
15:27:11 [fluffy]
Call-in toll-free number (US/Canada) +1-866-432-9903
15:27:17 [fluffy]
204 753 464
15:27:44 [jib]
jib has joined #webrtc
15:28:27 [hta1]
how do we join that rom the android webex client?
15:30:54 [vivien]
vivien has changed the topic to: Now on WebEx (cisco.webex.com/meet/fluffy or +1-866-432-9903 code 204 753 464) - https://www.w3.org/2011/04/webrtc/wiki/May_27_2016
15:30:55 [hta1]
found it - just use the access code
15:31:38 [dom]
ScribeNick: Dom
15:31:59 [dom]
Topic: Welcome
15:32:11 [dom]
HTA: goal to make progress toward CR, not add new features
15:32:34 [dom]
... we expect to merge pull requests after the meeting and get a new editors draft, probably in the course of next week
15:32:49 [dom]
Cullen: to be clear, that next version is not expected to be ready to go to CR, right?
15:32:51 [dom]
HTA: correct
15:33:04 [dom]
... we need to close all open bugs before going to CR
15:33:25 [dom]
EKR: I've been going through the draft, finding plenty of editorial errors
15:33:35 [dom]
... how should I address them? One big PR?
15:33:48 [dom]
HTA: small PRs would be best (and they're better than comments)
15:34:02 [dom]
Topic: Agenda
15:34:18 [dom]
HTA: we're planning to discuss 5 pull requests, and time permitting, 5 open issues without attached pull requests
15:34:42 [dom]
Topic: PR 662: Calling receiver.track.stop()
15:35:11 [dom]
Bernard: once you stop a track, it is final, but the receiver itself is not stopped
15:35:31 [dom]
... Stefan asked what happen if you clone a receiver.track
15:35:56 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/662 PR 662
15:36:19 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/27-webrtc-minutes.html vivien
15:36:24 [dom]
... in particular, if a source should stop when all tracks are stopped
15:36:37 [dom]
hta: I think an implementation should be free to turn off the decoder (since it's not observable)
15:36:57 [AndyH]
AndyH has joined #webrtc
15:36:57 [jib_]
jib_ has joined #webrtc
15:37:05 [dom]
adambe: is calling stop on an incoming track the way to reject it? that's what the spec currently says
15:37:08 [dom]
hta: no, it's no
15:37:17 [dom]
bernard: the PR doesn't fix that yet
15:37:38 [dom]
bernard: nobody is pushing for having an implicit transceiver.stop(), that's what I was interested in hearing
15:37:52 [dom]
Topic: PR 675 Turn on/off sending CN/DTX
15:38:21 [dom]
Bernard: the proposal in the PR is to add a frob to the encoding parameter that would turn on/off voice activity detection
15:38:32 [dom]
... it would not set the negotiation needed flag
15:38:47 [dom]
... Two opinions sought: is this something we need to do? if it is, is this the right way to do it?
15:38:54 [dom]
EKR: my understanding is that this is the only way to do this
15:39:06 [vivien]
present+ Jesup, Sherwim, Tim_Patton, Varun, Victor_Pascual, Andy_Hutton
15:39:10 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/27-webrtc-minutes.html vivien
15:39:22 [dom]
Bernard: that's pretty much the only practical way without renegotiation
15:39:35 [dom]
Cullen: in terms of need, I think we already agreed we needed it e.g. for 911 calls
15:39:44 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/675 PR 675
15:39:44 [dom]
... so the main question is whether this is the right place
15:40:33 [dom]
Cullen: negotiating the codec doesn't say if CN is on or off, it makes it available to turn on/off
15:40:50 [dom]
EKR: if someone on the remote side is saying "don't send CN or DTX", there is currently no way to do that
15:41:00 [dom]
... SDP is just informative here
15:41:15 [dom]
... I think it has to be on the transceiver
15:41:22 [dom]
HTA: I think it's a frob on the encoding parameter
15:41:25 [dom]
EKR: fair enough
15:41:29 [dom]
Jesup: I agree as well
15:41:58 [dom]
Bernard: so consensus to do it, and do it sort of this way (but people should comment on the PR for the finer details)
15:42:13 [vr000m_]
vr000m_ has joined #webrtc
15:42:18 [dom]
EKR: I'm fine with this FWIW; I have no strong opinion on the naming
15:42:29 [jesup]
Agree, we have consensus to move forward
15:42:33 [dom]
Bernard: we need to clarify that this is more for DTX than CN, but seems like rough consensus
15:42:40 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/646 PR 646
15:42:49 [dom]
Topic: PR 646 RTCRtpEncodingParameters attributes
15:43:06 [vivien]
(slide 8)
15:43:11 [dom]
Bernard: this is to clarify some aspects that were already in the spec but had caused troubles
15:43:41 [vivien]
present+ Emil_Ivov
15:44:14 [dom]
Bernard: if you call getParameters on a receiver, the only thing you get back is fec and rtx
15:44:29 [dom]
@@@: why not ssrc as well?
15:44:39 [dom]
... if they were negotiated in SDP
15:45:07 [dom]
Bernard: Peter, could you comment on the PR so that we fix it?
15:45:10 [dom]
s/@@@/Peter/
15:45:38 [dom]
Bernard: proposal is otherwise to proceed with integrating this
15:45:51 [dom]
Cullen: I think the proposal makes sense
15:46:09 [dom]
... I'll follow up with more specific questions on maxBitrate
15:46:43 [dom]
HTA: maxBitrate and maxFramerate don't cause negotiations, so the receiver wouldn't know about them
15:46:44 [jib]
jib has joined #webrtc
15:46:53 [dom]
Topic: Issue 650 mimeType clarifications
15:46:57 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/650 PR 650
15:47:05 [vivien]
(slide 9)
15:47:10 [dom]
Bernard: we have a mimeType attribute in CodecParameters and CodecCapabilities
15:47:17 [dom]
... is this the media type, the subtype, both?
15:47:29 [vivien]
(slide 10)
15:47:39 [dom]
... PR 648 proposes the subtype (e.g. "opus")
15:47:49 [dom]
... HTA is suggesting type/subtype
15:48:06 [dom]
... the question is then if type is always going to be the same as .kind
15:48:47 [dom]
HTA: in the depth case, the most common encoding is VP8 (using the alpha channel)
15:49:19 [dom]
Cullen: I think it would be very likely that the IETF would allocate a new "depth" type
15:49:25 [dom]
... it would thus be "video" or "image"
15:49:36 [mreavy]
mreavy has joined #webrtc
15:49:36 [dom]
HTA: we've had all sort of troubles with the separation of type and subtype in SDP
15:49:41 [dom]
... I don't want to repeat the mistake
15:49:53 [dom]
Bernard: so you're suggesting including both; any objection to that?
15:49:56 [dom]
[none]
15:50:14 [dom]
Topci: PR 666 addTransceiver/addTrack async
15:50:41 [vivien]
-> https://github.com/w3c/webrtc-pc/pull/666 PR 666
15:50:45 [vivien]
(slide 11)
15:50:49 [dom]
Bernard: addTransceiver and addTrack create a transceiver with a dtls transport
15:51:07 [dom]
... until the certificate is ready, should that attribute be null?
15:51:16 [dom]
... if not, should we a promise instead
15:51:44 [dom]
... so far, support for having a null attribute
15:52:06 [dom]
... there is already a case of a transport without a certificate
15:52:37 [dom]
... createOffer/createAnswer gives guarantee of having a cert if needed
15:52:54 [dom]
Taylor: yeah, we couldn't think of a compelling reason to know when the certificate is ready
15:53:10 [dom]
... and you can get the equivalent by waiting for the resolution of createOffer/createAnswer
15:53:18 [dom]
... can anyone think of a compelling reason?
15:53:25 [dom]
Cullen: not sure I fully understood the proposal
15:53:39 [jib_]
jib_ has joined #webrtc
15:53:39 [dom]
Taylor: the proposal is to not make the calls async
15:54:02 [dom]
Bernard: and thus you could have null transport (if it's not ready yet)
15:54:05 [vivien]
(slide 12)
15:54:05 [dom]
Cullen: works for me
15:54:15 [dom]
HTA: consensus
15:54:37 [dom]
Bernard: PR 666 makes transport nullable and adds some text to that effect; please comment on the PR if needed
15:55:10 [dom]
Topic: Issue 571 Populating sender/receiver at creation time
15:55:11 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/651 Issue 651
15:55:18 [vivien]
(slide 13)
15:55:19 [dom]
AdamB: this is somewhat related
15:55:42 [dom]
... how do we signal that arrival of new information on receiver
15:55:47 [dom]
... we could add new events
15:55:52 [vivien]
s/651/571/g
15:56:10 [dom]
... we can also look how far setLocal/RemoteDescription fulflilment gets us
15:57:03 [dom]
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
15:57:18 [dom]
HTA: I think there is no compelling reason to know exactly when stuff happens
15:57:27 [dom]
... but we need to know when everything is ready
15:57:35 [dom]
... and that's what the promise resolution gives us
15:58:03 [dom]
Topic: Issue 583 Difference of behavior for addTransceiver/addTrack
15:58:06 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/583 Issue 583
15:58:11 [vivien]
(slide 14)
15:58:13 [dom]
Adam: We don't allow to add several times the same track with addTrack
15:58:20 [dom]
... should addTransceiver allow it?
15:58:27 [dom]
... people seem to support it as an advanced feature
15:58:33 [dom]
... any other input on this?
15:58:50 [dom]
HTA: what resolution are you proposing?
15:59:17 [dom]
AdamBe: The resolution would be that adding the same track in addTransceiver is allowed
15:59:22 [dom]
HTA: i.e. no change?
15:59:37 [dom]
AdamBe: the spec already allows it indeed
15:59:56 [dom]
... As a side note, we should have a way to implement addTrack in terms of addTransceiver
16:00:16 [dom]
... addTransceiver + the restriction is basically addTrack — I think we should investigate that
16:00:55 [dom]
Peter: I think there are some differences still between the two (e.g. creation of a transceiver)
16:01:37 [vivien]
Present+ Maire_Reavy
16:01:40 [dom]
AdamBe: yeah, I guess it's more a question of someone taking a stab at it and see if it works
16:01:51 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/585 Issue 585
16:01:54 [vivien]
(slide 15)
16:01:58 [dom]
Topic: Issue 585 Transceiver.stop and negotiation
16:02:33 [dom]
AdamBe: the spec is light on how Transceiver.stop() works; currently, it doesn't set the negotiation needed flag
16:02:42 [dom]
... Should it act right away or set the flag?
16:02:57 [dom]
Bernard: can we do both? act right away locally, and set the negotiated needed flag to transmit remotely
16:03:10 [dom]
@@@: that's what we had in mind when we wrote the text
16:03:14 [dom]
Cullen: +1 to that
16:03:32 [dom]
Bernard: we might need more text to explain this, but I think that's the right approach
16:03:41 [dom]
HTA: Transceiver.stop rejects a m-line, right?
16:03:43 [dom]
Bernard: right
16:04:24 [dom]
Topic: addStream() / addStream event behavior
16:04:29 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/568 Issue 568
16:04:32 [vivien]
(slide 16)
16:04:45 [dom]
AdamBe: this concerns other legacy APIs (addStream, getLocalStreams, removeStream, etc)
16:04:54 [vivien]
s/addStream()/Issue 568 addStream()/
16:05:12 [dom]
... they are quite widely used, but have been removed from the spec, which makes it hard for new implementations to work with existing content
16:05:22 [dom]
... we have descriptions of other legacy callback methods
16:05:35 [dom]
... should we do the same for these?
16:06:27 [dom]
... I would suggest something simpler than we initially had imagined
16:06:39 [dom]
Jan-Ivar: we implement addStream on top of addTrack; we do not implement removeStream
16:06:43 [dom]
... in Firefox
16:07:04 [vivien]
(slide 17)
16:07:04 [dom]
AdamBe: slide 17 describes what the functions would look like
16:07:27 [dom]
... the events (slide 18) are more tricky
16:07:47 [dom]
Cullen: this feels like a browser-decision, so I don't care much
16:08:00 [dom]
... but if we have them in the spec, I think people will keep using them
16:08:12 [dom]
... if we plan on removing them, we should not add them back
16:08:34 [dom]
adambe: there has been a request to expose streams
16:08:44 [dom]
peter: I think we already decided NOT to have them in the spec
16:08:46 [adamR]
+1 on removal
16:09:07 [jib_]
+1 on removal
16:09:09 [vivien]
(slide 18)
16:09:09 [dom]
... otherwise, we require them in the browser
16:09:32 [dom]
EKR: agreed; we might want to write it up somewhere in a wiki, not in the spec
16:09:41 [dom]
adambe: I'm fine with that
16:09:50 [dom]
stefan: where does the request to have stream in the spec?
16:10:23 [dom]
adambe: we had an issue raised recently on this
16:10:29 [dom]
stefan: I'm +1 on not putting in the spec
16:10:42 [dom]
hta: there is a question of having an event for new streams rather than tracks
16:10:48 [dom]
adambe: you get the stream in the track event
16:10:58 [dom]
hta: but then you have to keep track of streams - which is not hard
16:11:05 [dom]
adambe: ok; then they're really really deprecated
16:11:11 [dom]
Topic: issue 548
16:11:24 [vivien]
-> https://github.com/w3c/webrtc-pc/issues/548 Issue 548
16:11:27 [dom]
s/548/548 RTX RED FEC Handling:
16:11:27 [vivien]
(slide 19)
16:11:55 [dom]
Bernard: my understanding is that today they're treated as codecs: they show up in the codecs sequence
16:12:37 [dom]
... you would get audio/rtx, audio/red, audio/ulpfec as mime types
16:13:07 [dom]
... but you can't necessarily use these in any combination
16:14:00 [dom]
@@@: how much a burden would it be to require support of all combination?
16:14:14 [dom]
bernard: probably not a burden for a given codec
16:14:37 [dom]
... but the real question is whether to have it in the list of codecs
16:14:44 [vivien]
s/@@@/Peter
16:15:18 [dom]
Peter: I think it's a valid question to ask where RTX should go in the list of parameters
16:15:21 [vivien]
(slide 20)
16:15:40 [dom]
Bernard: Robin Raymond is proposing to put them as attributes of a codec instead
16:16:08 [dom]
... this also makes it more elegant for parameters
16:17:05 [dom]
Cullen: afaict RTX is mandatory to implement for a WebRTC implementation, so we know it's implemented, no need for a capability
16:17:32 [dom]
... it makes sense not make it a codec (i.e remove it from the list of codecs)
16:17:36 [dom]
... not sure about what comes next
16:18:01 [dom]
Bernard: I guess the first step is to know if there is support for changing the model and come with a better proposal
16:18:16 [dom]
Cullen: I would want to see a use case to see what it's exposed at all
16:18:31 [dom]
HTA: it can be turned off
16:18:43 [dom]
Bernard: also, RED is not mandatory to implement, so it needs to be discoverable
16:18:55 [dom]
... not all FEC are mandatory
16:19:06 [dom]
Cullen: makes sense to make them discoverable then indeed
16:19:16 [dom]
HTA: there is also the need to control them
16:19:20 [dom]
Cullen: but that's separate
16:19:38 [dom]
Bernard: they show up in the codec list, but reordering as no meaning
16:19:52 [dom]
... the only thing you can do is to remove them from the list
16:20:02 [dom]
Peter: yes, it would prevent from being used
16:21:02 [dom]
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)
16:21:09 [dom]
... although the spec doesn't say that in any detail
16:21:29 [dom]
... My take away is that there is interest in exploring an alternative; I'll bring something to the list
16:22:00 [dom]
Peter: for FEC and RED, I'm not so convinced it makes sense; RED is not a thing on a particular codec
16:22:11 [dom]
... FEC is yet another beast
16:22:17 [dom]
... but it's an interesting idea for RTX
16:22:48 [dom]
Bernard: yeah, it's a bit weird; right now, there is no way to expose the combination of capabilities that can be used
16:23:14 [dom]
... you're configuring RED and FEC separately, but you can't set that you're using them together
16:23:21 [dom]
... that's probably true of SDP itself
16:23:55 [dom]
Topic: Conclusion
16:24:09 [dom]
HTA: we seem to have resolved most issues, with lack of conclusion on 548
16:24:39 [dom]
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
16:24:47 [dom]
... we need a more concrete proposal in any case
16:24:59 [dom]
... I think Robin has an idea, but he hasn't posted it yet
16:25:07 [dom]
HTA: so we'll see a new proposal on the subject
16:25:48 [dom]
HTA: on the rest, we have detected consensus and we'll ask the PR/issue owners to take action
16:26:04 [dom]
HTA: thank you all for coming!
16:26:14 [dom]
... and sorry for the logistics
16:26:18 [dom]
... and thanks Cullen for fixing it!
16:26:34 [dom]
trackbot, end meeting
16:26:34 [trackbot]
Zakim, list attendees
16:26:34 [Zakim]
As of this point the attendees have been AdamR, BernardA, Cullen, Harald, JanIvar, Shijun, Stefan, TaylorB, Vivien, Dom, PeterT, EKR, AdamBe, Jesup, Sherwim, Tim_Patton, Varun,
16:26:37 [Zakim]
... Victor_Pascual, Andy_Hutton, Emil_Ivov, Maire_Reavy
16:26:42 [trackbot]
RRSAgent, please draft minutes
16:26:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/05/27-webrtc-minutes.html trackbot
16:26:42 [stefanh]
thanks Dom for scribing!!