00:12:30 jesup has joined #webrtc 00:13:26 adam has joined #webrtc 00:26:49 jib has joined #webrtc 00:31:58 adam has joined #webrtc 00:33:39 hta has joined #webrtc 00:37:19 tao has joined #webrtc 00:39:27 stefanh has joined #webrtc 00:39:49 elagerway has joined #webrtc 00:42:29 tcai has joined #webrtc 00:42:40 Marcus_Altman__ has joined #webrtc 00:47:14 Agenda draft http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013#Tuesday 00:48:51 fluffy has joined #webrtc 00:51:09 jib has left #webrtc 00:52:06 Marcus_Altman__ has joined #webrtc 00:52:14 Takahiro_ has joined #webrtc 00:52:38 ekr has joined #webrtc 00:52:39 dom has joined #webrtc 00:53:02 burn has joined #webrtc 00:53:37 DanS has joined #webrtc 00:53:50 http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013#Tuesday 00:54:21 jinkyu_seong has joined #webrtc 00:54:32 jesup has joined #webrtc 00:54:51 AndyF has joined #webrtc 00:55:06 jib has joined #webrtc 00:55:54 mreavy has joined #webrtc 00:56:33 juberti has joined #webrtc 00:58:35 rbarnes has joined #webrtc 00:58:58 adambe has joined #webrtc 00:59:25 kotakagi has joined #webrtc 00:59:37 stephane has joined #webrtc 00:59:55 Agenda: http://www.w3.org/2011/04/webrtc/wiki/November_11_-_November_12_2013#Tuesday 01:00:11 Zakim has joined #webrtc 01:00:17 Zakim, this is WebRTC 01:00:17 ok, dom; that matches UW_WebRTC()7:00PM 01:00:27 Zakim, who's on the call? 01:00:27 On the phone I see +1.267.934.aaaa, +46.8.50.51.aabb 01:00:30 zakim should be in the call now. 01:00:38 Chair: stefanh, hta 01:01:23 zakim, I am aaaa 01:01:23 +jib; got it 01:02:03 http://en.wikipedia.org/wiki/Condorcet_voting 01:03:13 silvia has joined #webrtc 01:03:25 silvia1 has joined #webrtc 01:03:25 christer has joined #webrtc 01:03:29 scribenick:juberti 01:03:37 DanD has joined #webrtc 01:05:40 Please do not get me started on voting methods 01:05:54 Just search for the words "condorcet cycle" 01:05:58 http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html 01:06:08 yahui has joined #webrtc 01:06:16 Tony has joined #Webrtc 01:06:45 ijongcheol has joined #webrtc 01:06:53 My email message about the DataChannel stuff: http://www.w3.org/mid/5281767C.7010101@jesup.org 01:06:58 "createDataChannel(), section 5.1.2" 01:08:07 burn: invalidStateError for closed(), as for other methods 01:10:10 burn: what should limits on max retransmits be? 01:10:24 ekr: doesn't SCTP have some built-in smaller limit 01:10:57 martin: any positive number is fine 01:11:20 ekr: limit numbers can only shrink implementation limits, not increase. impl not required to do anything more. 01:12:39 action adambe: modify the maxRetransmitTime and maxRetransmits text to say that the max values do not require the implementation to go over its internal builtins 01:12:39 Created ACTION-98 - Modify the maxretransmittime and maxretransmits text to say that the max values do not require the implementation to go over its internal builtins [on Adam Bergkvist - due 2013-11-19]. 01:12:45 juberti: what should app do if it wants the defaults? 01:12:52 silvia has joined #webrtc 01:13:20 jesup: set the channel as reliable? 01:13:49 jesup: app developer does nothing 01:14:01 dom_proj has joined #webrtc 01:14:03 the default is reliable. 01:14:30 martin: can't set max retransmits and max retransmit time. 01:14:37 results in a syntaxerror, is this correct? 01:14:41 burn: yes 01:15:31 juberti: if you want unreliable, set maxretransmits to zero 01:15:37 martin_ has joined #webrtc 01:16:00 jesup: yes. and if you want something else, you can set that directly. 01:16:17 ekr: how do you tell if the sctp channel drops out? 01:16:35 ekr: how do you know sctp stack gave up on sending? 01:16:44 martin: let me check. 01:17:04 action martin to determine whether there is some value of maxRetransmits that is effectively "reliable" 01:17:05 Created ACTION-99 - Determine whether there is some value of maxretransmits that is effectively "reliable" [on Martin Thomson - due 2013-11-19]. 01:17:07 martin: 01:17:28 kodonog has joined #webrtc 01:17:49 derf: there are some max retransmit limits in SCTP 01:19:18 moving on 01:19:47 burn: if protocol attribute isn't right, throw syntaxerror and bail out. Is this detailed enough? 01:20:21 adambe: this is trying to be like websockets 01:20:48 jesup: we just updated the ietf specs to include the IANA registry for these things 01:20:58 yusuke has joined #webrtc 01:21:36 BY has joined #WebRTC 01:21:45 burn: what should happen if you set the wrong protocol? 01:22:16 jesup: nothing is being done with this value except being passed through to the other side 01:22:29 juberti: so what validation will the webrtc impl do? 01:22:39 jesup: none, really, aside from checking DOMString 01:22:48 hta: is this utf-8, or utf-16? 01:23:14 jesup: there are no requirements. 01:23:38 RFC 4960 defines limits to the number of retransmissions. This would correspond to the limits that the implementation provides on retransmission. This would produce a practical upper limit in the number of retransmissions. Two values are recommended: 5 for the path, 10 for the association. Since we have only a single path, the former (5) would apply by default. http://tools.ietf.org/html/rfc4960#section-15 01:23:39 cullen: is this utf-8, or a bag of bits? 01:24:45 jesup: foobar is an acceptable 01:24:53 value 01:25:09 I am going to recommend that this be left to implementations. If they want to be super-reliable, then they can set higher values for Path.Max.Retrans, but there is no obligation to support a specific minimum. 01:25:23 cullen: since there is no practical checking, we should just remove this text. 01:25:57 burn: if id is already taken, throw exception and bail out 01:26:56 burn: this only happens for a non-negotiated channel, or reusing an id from an already negotiated channel 01:27:14 jesup: agree 01:27:21 martin: invalid-state error? 01:27:30 http://www.w3.org/TR/dom/#error-names-0 01:27:40 robin has joined #webrtc 01:27:49 hta: invalid-state already exists; channel is in invalid state 01:29:01 hta: resource-in-use seems pretty good 01:29:08 jesup: agree 01:29:09 BTW, SyntaxError is totally inappropriate for what was described. It talks specifically about strings. 01:30:39 juberti: this means we need to revisit maxretransmittime, maxretransmits 01:31:03 martin: could be not-supported errors 01:31:32 +Jim_Barnett 01:32:13 JimBarnett has joined #webrtc 01:32:32 martin: leaving this open to editorial discussion 01:32:36 It's the chicken's way out 01:32:44 burn: tentatively not-supported 01:32:51 burn: moving on, section 5.2 01:34:04 burn: what should happen if we get a channel open request from the other side and a failure occurs? 01:34:46 jesup: i don't see any need for that 01:35:12 BTW, the quoted text doesn't read very well here. 01:36:19 "NetworkError" seems to be the right one for this case 01:36:29 jesup: dtls could go down, sctp could go down, 01:36:41 jesup: but app couldn't do much about this 01:38:07 juberti: would this trigger on ICE failure? 01:38:21 juberti: no, because ICE could be restarted by app 01:38:57 martin: that makes sense; DTLS or SCTP error would propagate upwards and result in this 01:39:05 re binaryType, the Web Sockets spec has switched to an enum for it, which we should probably do as well; in case, invalid values will raise TypeError 01:39:13 jesup: agreement on "NetworkError" for this case 01:39:22 burn: 5.2.1 - binaryType 01:39:33 jesup: should be like websockets 01:40:09 dom: websockets doesn't use strings? 01:40:26 -> http://dev.w3.org/html5/websockets/#the-websocket-interface Web Sockets Editors draft uses enum 01:40:26 not sure i got that right 01:40:33 LeiWANG has joined #webrtc 01:40:55 s/websockets doesn't use strings?/websockets now uses enum; we should do the same and get error handling for free from WebIDL/ 01:41:07 burn: websockets uses enums, checking will automatically be done for us. agreed. 01:41:31 burn: protocol attrib. 5.2.1. 01:41:48 jesup: as previously discussed. 01:41:58 jesup: i.e. no checking needed. 01:42:10 burn: send, section 5.2.2. 01:42:39 burn: send might not work if channel was created by remote peer in negotiated form. 01:42:49 GANG has joined #webrtc 01:44:21 jeromemarcon has joined #webrtc 01:44:38 jesup: to receive data on a negotiated channel, both sides need to install a negotiated channel 01:44:47 martin: not sure about that 01:44:56 martin: we'll figure it out 01:45:32 burn: if channel is still 'connecting', throw invalid state and fail 01:46:09 kotakagi_ has joined #webrtc 01:46:48 jesup: do you need to wait for onopen? 01:47:00 jesup: that's what websockets does 01:47:37 juberti: wouldn't we want to do the same 01:47:50 burn: keep the way it is then? 01:47:57 stephane_ has joined #webrtc 01:47:58 room: yes 01:48:19 burn: attempts to send when buffer is full should lead to close with error 01:48:39 jesup: that's copied from websockets 01:49:42 Zakim, who's noisy 01:49:42 I don't understand 'who's noisy', juberti 01:49:46 It's NetworkError 01:49:50 Zakim, who is noisy 01:49:50 I don't understand 'who is noisy', juberti 01:49:53 yimin has joined #webrtc 01:50:03 jeromemarco has joined #webrtc 01:50:10 Zakim, who is making noise 01:50:10 I don't understand 'who is making noise', juberti 01:50:54 martin: text needs to be revised 01:50:56 The conclusion was to remove the e.g 01:51:01 burn: can someone please summarize what 01:51:12 If the data can't be sent, NetworkError and close the channel. 01:52:07 richt has joined #webrtc 01:52:15 burn: when does error occur? 01:52:27 errors need to be reported asynchronously from send() 01:52:45 NetworkError event that is 01:53:02 martin: from onerror on datachannel 01:53:03 use "fire an error event", as is done in websockets 01:53:32 pthatcher: is there a state transition on the data channel? 01:54:06 juberti: do we get an onerror and a statechange callback 01:54:17 Zakim, who's noisy? 01:54:18 martin: let's have a look 01:54:25 Zakim, who's on the call? 01:54:25 On the phone I see jib, +46.8.50.51.aabb, Jim_Barnett 01:54:28 dom, listening for 10 seconds I could not identify any sounds 01:54:38 Zakim, mute jib 01:54:38 jib should now be muted 01:54:40 Zakim, mute JimBarnett 01:54:40 Jim_Barnett should now be muted 01:55:07 action: adambe to clarify whether RTCdatachannel close and error events are mutually exclusive or whether error + close is possible 01:55:08 Created ACTION-100 - Clarify whether rtcdatachannel close and error events are mutually exclusive or whether error + close is possible [on Adam Bergkvist - due 2013-11-19]. 01:55:29 Tony_ has joined #Webrtc 01:55:40 juberti: error type is NetworkError in onerror 01:55:47 room: agreed 01:55:56 burn: createDTMFSender, 6.1.1 01:56:29 richt_ has joined #webrtc 01:56:29 burn: if track argument isn't in RTCPeerConnection's localstreams, throw invalidMediaStreamTrackError 01:56:32 hta: that should be an invalidargumenterror exception, if there is such a thing 01:57:11 "InvalidAccessError" 01:57:16 "The object does not support the operation or argument. " 01:57:19 Tony has joined #Webrtc 01:57:30 adambe: "InvalidAccessError" 01:57:47 cullen: what about "invalidparametererror"? 01:57:53 martin: there is none 01:57:59 hta: let's add one 01:58:23 burn: let's propose this to the DOM folks. adambe to handle this. 01:58:41 burn: insert DTMF, section 6.2.2 01:59:15 burn: error for things outside of configured ranges 01:59:31 cullen: may I suggest, invalidparametererror 01:59:52 TZH has joined #webrtc 02:00:32 http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0005.html 02:01:00 juberti: what should happen if the other side doesn't support dtmf? 02:01:57 actually, that is indicated in the .canInsertDTMF property 02:02:11 -> http://dev.w3.org/2009/dap/vibration/ Vibration API truncates too long patterns 02:03:39 burn: throw notsupported 02:03:56 cullen: that seems weird - should it be invalid parameter? 02:05:14 burn: glad we are reviewing all of these. this is really iuseful 02:05:31 juberti: but our thinking seems to be evolving, so we may need to revisit our earlier choices 02:05:37 (I'm still not sure what the benefit is to throw instead of just clamping the values) 02:05:39 burn: yeah, agreed 02:05:44 For illegal values, can't we use SyntaxError here? It is a string after all 02:06:40 ywu has joined #webrtc 02:06:54 burn: back to these choices 02:06:55 zakim, unmute ji 02:06:55 'ji' is ambiguous, jib 02:07:02 zakim, unmute jib 02:07:02 jib should no longer be muted 02:07:42 jib, i think some of these values aren't strings. 02:07:58 insertDTMF() takes a string, no? 02:08:16 hta: no-dtmf-support is corner case, shouldn't result in an error 02:08:38 jib - duration isn't a string 02:08:58 taocai has joined #webrtc 02:09:29 burn: values outside allowed ranges leads to not-supported exception 02:09:59 Tony has joined #Webrtc 02:10:11 dom: what do we get by throwing an exception? 02:10:42 NotSupportedError is "The operation is not supported. " 02:11:54 action: burn to talk to dom about whether we should clamp or throw exception for invalid params to insertDTMF. 02:11:54 Created ACTION-101 - Talk to dom about whether we should clamp or throw exception for invalid params to insertdtmf. [on Daniel Burnett - due 2013-11-19]. 02:12:04 How about: sender.insertDTMF("215-x"); -> SyntaxError (in string), and sender.insertDTMF("123", -1); -> NotSupportedError ? 02:12:17 juberti: createDTMFSender fails if other side doesn't support DTMF. 02:12:28 jib, I think that sounds perfectly reasonable 02:12:45 though InvalidAccessError seems more in fitting with the descriptions 02:12:45 juberti: if that goes away in mid-call, canSendDTMF reports that value, but there is no exception thrown. 02:12:57 for the latter (-1 intertone gap) 02:12:57 NotSupportedError seems appropriate (the insertDTMF operation is not supported) 02:13:03 juberti: hta says this is a corner case. 02:14:06 TZH_ has joined #webrtc 02:15:56 juberti: forget everything i said before. 02:16:26 juberti: new agreement: createDTMFSender doesn't do any checking on remote DTMF capability. 02:16:48 juberti: insertDTMF _does_ check remote DTMF support, and that the MST is still valid, and the parameters are good. 02:16:52 where are we in the agenda? 02:16:55 GangL has joined #webrtc 02:17:02 if any are not good, throw not-supported exception. 02:18:37 juberti: so everything results in an exception, except for the edge case of remote side supports X-Y, and we send a Z. 02:18:39 silvia has joined #webrtc 02:18:55 cullen: we should say anything less than 0-9, *, # should be treated as no DTMF support 02:19:10 burn: stats model, 7.1. 02:20:00 burn: what should happen if you call getStats with an invalid selector (currently only MSTs are valid as selector) 02:20:09 hta: invalidargumentexception 02:20:43 burn: list of supported values is indicated by the enumerated type. see webidl 02:21:01 burn: delete note in the spec about other selectors 02:21:09 burn: getstats, 7.2.1 02:22:15 hta: getStats shouldn't throw if we call it after close(). 02:22:27 cullen: we should have an explicit note in the spec about this. 02:23:21 jan-ivar: should close() also be valid here? 02:23:26 ekr: yes, idempotent. 02:23:27 If we're overriding general guidance, we should always have a note, so close() should have some specific text too. 02:23:34 Tony has joined #Webrtc 02:24:32 the notion of "invalid selector" is not defined 02:24:51 it should at least be clarified here what we mean 02:25:12 ekr: prologue about invalid states is gross, we should have a general guidance and then list exceptions, instead of doing this on a method by method basis 02:25:44 burn: i prefer everything being explicit, easier for the developer 02:26:02 it's not easier for the developer 02:26:39 issue: should we refactor the generic guidance on error handling out of the spec 02:26:39 Created ISSUE-3 - Should we refactor the generic guidance on error handling out of the spec. Please complete additional details at . 02:26:46 burn: let's discuss this later 02:27:29 Travis has joined #webrtc 02:27:49 stefanh: use invalidparameter/illegalargument for getStats with invalid selector 02:27:54 hta: agreed 02:28:10 burn: RTCStats dictionary, 7.5 02:28:14 https://www.w3.org/2011/04/webrtc/track/issues/3 02:28:21 martin: The text is correct. 02:28:29 burn: What should the app do? 02:28:43 martin: It should ignore any unknown values. Just like any other dictionary. 02:29:13 if (isUnknown(stats)) { window.close(); } 02:29:32 "MUST" is not appropriate here; MUST in this spec should only apply to things relevant to User Agents, not to applications 02:29:48 while (isUnknown(stats)) { alert("not known!"); } 02:30:41 +1 02:31:39 juberti: move to skip identity discussion, since we don't have a working impl yet 02:32:08 ekr: let's not use that as an excuse to dump identity because we don't have as spec. 02:32:23 ekr: we have identity later. 02:32:35 hta: let's move on 02:33:25 frodek has joined #webrtc 02:34:16 jehoochen__ has joined #webrtc 02:37:34 yusuke has joined #webrtc 02:38:27 ijongcheol has joined #webrtc 02:39:45 yusuke_ has joined #webrtc 02:46:06 hiroki has joined #webrtc 02:49:34 Takahiro has joined #webrtc 02:54:59 rbarnes has joined #webrtc 02:55:26 trackbot has joined #webrtc 02:56:26 hiroki has joined #webrtc 03:01:43 lgombos has joined #webrtc 03:02:33 silvia has joined #webrtc 03:02:42 silvia1 has joined #webrtc 03:05:15 juberti: moving on to unannounced ssrc handling 03:05:37 hta: a=msid identifies streams/tracks consistently. 03:05:50 hta: what about non-webrtc endpoints, which don't send a=msid? 03:06:04 hta: they still expect sync/grouping 03:06:14 hta: behavior needs to be predictable 03:06:35 minami has joined #webrtc 03:07:48 predictable = media plays out when it arrives. 03:08:17 and media with a single CNAME should be synchronized (not 100% clear, see LS) 03:09:06 proposals for handling: all incoming media in one MS, each in its own MS, group in MS based on CNAME 03:10:13 cullen: what do you get if you get multiple SSRCs? 03:10:17 hta: multiple tracks. 03:11:39 hta: cname identifies sync context; exact language in 3550 is iffy 03:12:51 hta: same JS should result in same CNAME 03:13:07 hta: moving track from one stream to another when there are different CNAMEs is hard 03:13:48 martin: 2 streams - one with A and B, one with B and C - do they have same CNAMEs 03:13:55 ywu has joined #webrtc 03:14:16 martin: jonathan means they have clocks that advance at same rate 03:14:24 burn has joined #webrtc 03:14:43 cullen: lipsync existed long before LS was invented 03:14:48 For the minutes, I believe this topic of interoperability with non-WebRTC endpoints is out of scope for this group. 03:15:12 Tony has joined #Webrtc 03:15:38 I think we need to know what happens at the API level 03:16:16 juberti, what happens at the API level is that you talk to a WebRTC endpoint. The other side has to implement the APIs as described. 03:17:06 So we make msid as mandatory to use? 03:17:14 Once the scope includes non-WebRTC there is no longer any natural boundary for the scope. 03:17:50 burn: uh, it's toally news to me that interop isn't important 03:17:59 or ins cope 03:18:01 in scope 03:18:08 s/burn:/burn,/ 03:18:14 richt has joined #webrtc 03:18:25 ekr, the question burn is raising is on interop with legacy devices (rather than with other browsers) 03:18:33 Tony_ has joined #Webrtc 03:18:37 dom, yes, I understand that. I totally disagree that it's not in scope 03:18:56 hta: we don't know where to stick a new track without its CNAME. ANd we don't have CNAME in SDP always. 03:19:57 cullen: can we move a MST to another MS when RTCP arrives? 03:20:01 ekr: yuck 03:20:05 (I guess there is a question of whether there is a need for interoperable behavior in this space or it can be left to implementors to determine the best course of action) 03:20:19 dom, yes, I don't think that's acceptbale 03:20:30 hta: we need to either stuff in default group, or in its own 03:20:37 I don't want to see API changes just for non-WebRTC endpoints, because, again, there is no limit to the scope of changes that might be necessary. 03:20:58 hta: if we like what's in the document, we're finished. 03:21:00 burn, well we've already agreed to a bunch of such changes, such as for bundle-only 03:21:34 (which is one MST per MS) 03:21:42 ijongcheol has joined #webrtc 03:22:05 pthatcher: we can expose CNAME and then let app group as needed 03:22:27 ekr, that's not true. BUNDLE is not about legacy interop. It is very specifically about efficient firewall traversal which is directly relevant for WebRTC only communications 03:22:36 burn, I said "bundle only" 03:22:43 jesup: so this will be the case for a single audio and video stream? 03:22:56 Tony has joined #Webrtc 03:23:04 jesup: app developer probably won't be expecting this 03:23:23 cullen: it's not clear how you move this stuff around, the default should be a single MS 03:23:41 juberti: agree 03:24:56 juberti: do we really need an API for this? 03:24:57 Record this for posterity -- we will regret this scope creep. I will attempt to refrain from saying "I told you so" a year from now. 03:25:12 no you won't, burn 03:26:07 juberti: I think we should stuff everything into a single MS 03:26:10 richt_ has joined #webrtc 03:26:10 dom, :) 03:26:44 juberti: unless you set a=msid. 03:26:58 martin: the browser won't sync things that are totally out of sync anyway. 03:27:24 hta: suggestion is that all un-MSIDed SSRCS create tracks in a single default MSID 03:28:32 cullen: is CNAME part of stats? 03:29:22 juberti: not currently 03:29:44 hta: that is the full proposal. 03:31:38 Tony has joined #Webrtc 03:32:00 cullen: is there a real problem with adding a CNAME property> 03:33:20 frodek has joined #webrtc 03:33:32 cullen: what does a gateway need to do? 03:33:48 juberti: add 2 MSIDs: ms1 t1, and ms1 t2 or ms2 t1 03:33:57 cullen: how do you demux without the a=ssrc values? 03:34:02 AndyF has joined #webrtc 03:34:16 juberti: you're not BUNDLing, because legacy, so you can demux by 5-tuple 03:34:28 kodonog has joined #webrtc 03:34:56 adam: what happens if you get an invalid a=msid line 03:35:04 hta: then you have an illegal SDP 03:35:11 hta: what should you do with an illegal SDP? 03:36:01 hta: and there is a line needed for msid-semantic WMS. 03:36:22 juberti: will this show up on the screen? 03:36:38 or maybe hta: 03:36:48 I am now in complete control of hta's screen 03:37:28 pthatcher: should there be a default MSID? 03:37:31 martin: generate a default msid and it's all good 03:37:39 martin: no, generate one. 03:37:48 ekr: should be cryptographically random 03:37:54 juberti: and we're done. 03:38:21 yeah, 500bits of entropy 03:38:28 Leon has joined #webrtc 03:38:38 stephane has joined #webrtc 03:38:50 juberti: new topic: data channel 03:39:02 jesup: new drafts, etc, etc 03:39:20 jesup: open issue from IETF: max msg size 03:39:26 Topic: data channel 03:39:43 jesup: various proposals to set max msg size 03:40:03 jesup: would prefer to stay with something like websockets 03:40:16 jesup: where there is no specified max 03:41:20 jesup: websockets has no streaming interface. you get a blob that plops out. 03:41:52