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