IRC log of webrtc on 2013-11-12

Timestamps are in UTC.

00:12:30 [jesup]
jesup has joined #webrtc
00:13:26 [adam]
adam has joined #webrtc
00:26:49 [jib]
jib has joined #webrtc
00:31:58 [adam]
adam has joined #webrtc
00:33:39 [hta]
hta has joined #webrtc
00:37:19 [tao]
tao has joined #webrtc
00:39:27 [stefanh]
stefanh has joined #webrtc
00:39:49 [elagerway]
elagerway has joined #webrtc
00:42:29 [tcai]
tcai has joined #webrtc
00:42:40 [Marcus_Altman__]
Marcus_Altman__ has joined #webrtc
00:47:14 [stefanh]
Agenda draft
00:48:51 [fluffy]
fluffy has joined #webrtc
00:51:09 [jib]
jib has left #webrtc
00:52:06 [Marcus_Altman__]
Marcus_Altman__ has joined #webrtc
00:52:14 [Takahiro_]
Takahiro_ has joined #webrtc
00:52:38 [ekr]
ekr has joined #webrtc
00:52:39 [dom]
dom has joined #webrtc
00:53:02 [burn]
burn has joined #webrtc
00:53:37 [DanS]
DanS has joined #webrtc
00:53:50 [stefanh]
00:54:21 [jinkyu_seong]
jinkyu_seong has joined #webrtc
00:54:32 [jesup]
jesup has joined #webrtc
00:54:51 [AndyF]
AndyF has joined #webrtc
00:55:06 [jib]
jib has joined #webrtc
00:55:54 [mreavy]
mreavy has joined #webrtc
00:56:33 [juberti]
juberti has joined #webrtc
00:58:35 [rbarnes]
rbarnes has joined #webrtc
00:58:58 [adambe]
adambe has joined #webrtc
00:59:25 [kotakagi]
kotakagi has joined #webrtc
00:59:37 [stephane]
stephane has joined #webrtc
00:59:55 [dom]
01:00:11 [Zakim]
Zakim has joined #webrtc
01:00:17 [dom]
Zakim, this is WebRTC
01:00:17 [Zakim]
ok, dom; that matches UW_WebRTC()7:00PM
01:00:27 [dom]
Zakim, who's on the call?
01:00:27 [Zakim]
On the phone I see +1.267.934.aaaa, +
01:00:30 [hta]
zakim should be in the call now.
01:00:38 [dom]
Chair: stefanh, hta
01:01:23 [jib]
zakim, I am aaaa
01:01:23 [Zakim]
+jib; got it
01:02:03 [fluffy]
01:03:13 [silvia]
silvia has joined #webrtc
01:03:25 [silvia1]
silvia1 has joined #webrtc
01:03:25 [christer]
christer has joined #webrtc
01:03:29 [hta]
01:03:37 [DanD]
DanD has joined #webrtc
01:05:40 [ekr]
Please do not get me started on voting methods
01:05:54 [ekr]
Just search for the words "condorcet cycle"
01:05:58 [burn]
01:06:08 [yahui]
yahui has joined #webrtc
01:06:16 [Tony]
Tony has joined #Webrtc
01:06:45 [ijongcheol]
ijongcheol has joined #webrtc
01:06:53 [jesup]
My email message about the DataChannel stuff:
01:06:58 [dom]
"createDataChannel(), section 5.1.2"
01:08:07 [juberti]
burn: invalidStateError for closed(), as for other methods
01:10:10 [juberti]
burn: what should limits on max retransmits be?
01:10:24 [juberti]
ekr: doesn't SCTP have some built-in smaller limit
01:10:57 [juberti]
martin: any positive number is fine
01:11:20 [juberti]
ekr: limit numbers can only shrink implementation limits, not increase. impl not required to do anything more.
01:12:39 [ekr]
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 [trackbot]
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]
juberti: what should app do if it wants the defaults?
01:12:52 [silvia]
silvia has joined #webrtc
01:13:20 [juberti]
jesup: set the channel as reliable?
01:13:49 [juberti]
jesup: app developer does nothing
01:14:01 [dom_proj]
dom_proj has joined #webrtc
01:14:03 [juberti]
the default is reliable.
01:14:30 [juberti]
martin: can't set max retransmits and max retransmit time.
01:14:37 [juberti]
results in a syntaxerror, is this correct?
01:14:41 [juberti]
burn: yes
01:15:31 [juberti]
juberti: if you want unreliable, set maxretransmits to zero
01:15:37 [martin_]
martin_ has joined #webrtc
01:16:00 [juberti]
jesup: yes. and if you want something else, you can set that directly.
01:16:17 [juberti]
ekr: how do you tell if the sctp channel drops out?
01:16:35 [juberti]
ekr: how do you know sctp stack gave up on sending?
01:16:44 [juberti]
martin: let me check.
01:17:04 [ekr]
action martin to determine whether there is some value of maxRetransmits that is effectively "reliable"
01:17:05 [trackbot]
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 [juberti]
martin: <looking at SCTP spec to understand what SCTP does here>
01:17:28 [kodonog]
kodonog has joined #webrtc
01:17:49 [juberti]
derf: there are some max retransmit limits in SCTP
01:19:18 [juberti]
moving on
01:19:47 [juberti]
burn: if protocol attribute isn't right, throw syntaxerror and bail out. Is this detailed enough?
01:20:21 [juberti]
adambe: this is trying to be like websockets
01:20:48 [juberti]
jesup: we just updated the ietf specs to include the IANA registry for these things
01:20:58 [yusuke]
yusuke has joined #webrtc
01:21:36 [BY]
BY has joined #WebRTC
01:21:45 [juberti]
burn: what should happen if you set the wrong protocol?
01:22:16 [juberti]
jesup: nothing is being done with this value except being passed through to the other side
01:22:29 [juberti]
juberti: so what validation will the webrtc impl do?
01:22:39 [juberti]
jesup: none, really, aside from checking DOMString
01:22:48 [juberti]
hta: is this utf-8, or utf-16?
01:23:14 [juberti]
jesup: there are no requirements.
01:23:38 [martin_]
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.
01:23:39 [juberti]
cullen: is this utf-8, or a bag of bits?
01:24:45 [juberti]
jesup: foobar is an acceptable
01:24:53 [juberti]
01:25:09 [martin_]
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 [juberti]
cullen: since there is no practical checking, we should just remove this text.
01:25:57 [juberti]
burn: if id is already taken, throw exception and bail out
01:26:56 [juberti]
burn: this only happens for a non-negotiated channel, or reusing an id from an already negotiated channel
01:27:14 [juberti]
jesup: agree
01:27:21 [juberti]
martin: invalid-state error?
01:27:30 [dom]
01:27:40 [robin]
robin has joined #webrtc
01:27:49 [juberti]
hta: invalid-state already exists; channel is in invalid state
01:29:01 [juberti]
hta: resource-in-use seems pretty good
01:29:08 [juberti]
jesup: agree
01:29:09 [martin_]
BTW, SyntaxError is totally inappropriate for what was described. It talks specifically about strings.
01:30:39 [juberti]
juberti: this means we need to revisit maxretransmittime, maxretransmits
01:31:03 [juberti]
martin: could be not-supported errors
01:31:32 [Zakim]
01:32:13 [JimBarnett]
JimBarnett has joined #webrtc
01:32:32 [juberti]
martin: leaving this open to editorial discussion
01:32:36 [martin_]
It's the chicken's way out
01:32:44 [juberti]
burn: tentatively not-supported
01:32:51 [juberti]
burn: moving on, section 5.2
01:34:04 [juberti]
burn: what should happen if we get a channel open request from the other side and a failure occurs?
01:34:46 [juberti]
jesup: i don't see any need for that
01:35:12 [martin_]
BTW, the quoted text doesn't read very well here.
01:36:19 [dom]
"NetworkError" seems to be the right one for this case
01:36:29 [juberti]
jesup: dtls could go down, sctp could go down,
01:36:41 [juberti]
jesup: but app couldn't do much about this
01:38:07 [juberti]
juberti: would this trigger on ICE failure?
01:38:21 [juberti]
juberti: no, because ICE could be restarted by app
01:38:57 [juberti]
martin: that makes sense; DTLS or SCTP error would propagate upwards and result in this
01:39:05 [dom]
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 [juberti]
jesup: agreement on "NetworkError" for this case
01:39:22 [juberti]
burn: 5.2.1 - binaryType
01:39:33 [juberti]
jesup: should be like websockets
01:40:09 [juberti]
dom: websockets doesn't use strings?
01:40:26 [dom]
-> Web Sockets Editors draft uses enum
01:40:26 [juberti]
not sure i got that right
01:40:33 [LeiWANG]
LeiWANG has joined #webrtc
01:40:55 [dom]
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 [juberti]
burn: websockets uses enums, checking will automatically be done for us. agreed.
01:41:31 [juberti]
burn: protocol attrib. 5.2.1.
01:41:48 [juberti]
jesup: as previously discussed.
01:41:58 [juberti]
jesup: i.e. no checking needed.
01:42:10 [juberti]
burn: send, section 5.2.2.
01:42:39 [juberti]
burn: send might not work if channel was created by remote peer in negotiated form.
01:42:49 [GANG]
GANG has joined #webrtc
01:44:21 [jeromemarcon]
jeromemarcon has joined #webrtc
01:44:38 [juberti]
jesup: to receive data on a negotiated channel, both sides need to install a negotiated channel
01:44:47 [juberti]
martin: not sure about that
01:44:56 [juberti]
martin: we'll figure it out
01:45:32 [juberti]
burn: if channel is still 'connecting', throw invalid state and fail
01:46:09 [kotakagi_]
kotakagi_ has joined #webrtc
01:46:48 [juberti]
jesup: do you need to wait for onopen?
01:47:00 [juberti]
jesup: that's what websockets does
01:47:37 [juberti]
juberti: wouldn't we want to do the same
01:47:50 [juberti]
burn: keep the way it is then?
01:47:57 [stephane_]
stephane_ has joined #webrtc
01:47:58 [juberti]
room: yes
01:48:19 [juberti]
burn: attempts to send when buffer is full should lead to close with error
01:48:39 [juberti]
jesup: that's copied from websockets
01:49:42 [juberti]
Zakim, who's noisy
01:49:42 [Zakim]
I don't understand 'who's noisy', juberti
01:49:46 [martin_]
It's NetworkError
01:49:50 [juberti]
Zakim, who is noisy
01:49:50 [Zakim]
I don't understand 'who is noisy', juberti
01:49:53 [yimin]
yimin has joined #webrtc
01:50:03 [jeromemarco]
jeromemarco has joined #webrtc
01:50:10 [juberti]
Zakim, who is making noise
01:50:10 [Zakim]
I don't understand 'who is making noise', juberti
01:50:54 [juberti]
martin: text needs to be revised
01:50:56 [martin_]
The conclusion was to remove the e.g
01:51:01 [juberti]
burn: can someone please summarize what
01:51:12 [martin_]
If the data can't be sent, NetworkError and close the channel.
01:52:07 [richt]
richt has joined #webrtc
01:52:15 [juberti]
burn: when does error occur?
01:52:27 [martin_]
errors need to be reported asynchronously from send()
01:52:45 [martin_]
NetworkError event that is
01:53:02 [juberti]
martin: from onerror on datachannel
01:53:03 [dom]
use "fire an error event", as is done in websockets
01:53:32 [juberti]
pthatcher: is there a state transition on the data channel?
01:54:06 [juberti]
juberti: do we get an onerror and a statechange callback
01:54:17 [dom]
Zakim, who's noisy?
01:54:18 [juberti]
martin: let's have a look
01:54:25 [dom]
Zakim, who's on the call?
01:54:25 [Zakim]
On the phone I see jib, +, Jim_Barnett
01:54:28 [Zakim]
dom, listening for 10 seconds I could not identify any sounds
01:54:38 [dom]
Zakim, mute jib
01:54:38 [Zakim]
jib should now be muted
01:54:40 [dom]
Zakim, mute JimBarnett
01:54:40 [Zakim]
Jim_Barnett should now be muted
01:55:07 [martin_]
action: adambe to clarify whether RTCdatachannel close and error events are mutually exclusive or whether error + close is possible
01:55:08 [trackbot]
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_]
Tony_ has joined #Webrtc
01:55:40 [juberti]
juberti: error type is NetworkError in onerror
01:55:47 [juberti]
room: agreed
01:55:56 [juberti]
burn: createDTMFSender, 6.1.1
01:56:29 [richt_]
richt_ has joined #webrtc
01:56:29 [juberti]
burn: if track argument isn't in RTCPeerConnection's localstreams, throw invalidMediaStreamTrackError
01:56:32 [martin_]
hta: that should be an invalidargumenterror exception, if there is such a thing
01:57:11 [dom]
01:57:16 [dom]
"The object does not support the operation or argument. "
01:57:19 [Tony]
Tony has joined #Webrtc
01:57:30 [martin_]
adambe: "InvalidAccessError"
01:57:47 [juberti]
cullen: what about "invalidparametererror"?
01:57:53 [juberti]
martin: there is none
01:57:59 [juberti]
hta: let's add one
01:58:23 [juberti]
burn: let's propose this to the DOM folks. adambe to handle this.
01:58:41 [juberti]
burn: insert DTMF, section 6.2.2
01:59:15 [juberti]
burn: error for things outside of configured ranges
01:59:31 [juberti]
cullen: may I suggest, invalidparametererror
01:59:52 [TZH]
TZH has joined #webrtc
02:00:32 [martin_]
02:01:00 [juberti]
juberti: what should happen if the other side doesn't support dtmf?
02:01:57 [juberti]
actually, that is indicated in the .canInsertDTMF property
02:02:11 [dom]
-> Vibration API truncates too long patterns
02:03:39 [juberti]
burn: throw notsupported
02:03:56 [juberti]
cullen: that seems weird - should it be invalid parameter?
02:05:14 [juberti]
burn: glad we are reviewing all of these. this is really iuseful
02:05:31 [juberti]
juberti: but our thinking seems to be evolving, so we may need to revisit our earlier choices
02:05:37 [dom]
(I'm still not sure what the benefit is to throw instead of just clamping the values)
02:05:39 [juberti]
burn: yeah, agreed
02:05:44 [jib]
For illegal values, can't we use SyntaxError here? It is a string after all
02:06:40 [ywu]
ywu has joined #webrtc
02:06:54 [juberti]
burn: back to these choices
02:06:55 [jib]
zakim, unmute ji
02:06:55 [Zakim]
'ji' is ambiguous, jib
02:07:02 [jib]
zakim, unmute jib
02:07:02 [Zakim]
jib should no longer be muted
02:07:42 [juberti]
jib, i think some of these values aren't strings.
02:07:58 [jib]
insertDTMF() takes a string, no?
02:08:16 [juberti]
hta: no-dtmf-support is corner case, shouldn't result in an error
02:08:38 [juberti]
jib - duration isn't a string
02:08:58 [taocai]
taocai has joined #webrtc
02:09:29 [juberti]
burn: values outside allowed ranges leads to not-supported exception
02:09:59 [Tony]
Tony has joined #Webrtc
02:10:11 [juberti]
dom: what do we get by throwing an exception?
02:10:42 [dom]
NotSupportedError is "The operation is not supported. "
02:11:54 [juberti]
action: burn to talk to dom about whether we should clamp or throw exception for invalid params to insertDTMF.
02:11:54 [trackbot]
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 [jib]
How about: sender.insertDTMF("215-x"); -> SyntaxError (in string), and sender.insertDTMF("123", -1); -> NotSupportedError ?
02:12:17 [juberti]
juberti: createDTMFSender fails if other side doesn't support DTMF.
02:12:28 [martin_]
jib, I think that sounds perfectly reasonable
02:12:45 [martin_]
though InvalidAccessError seems more in fitting with the descriptions
02:12:45 [juberti]
juberti: if that goes away in mid-call, canSendDTMF reports that value, but there is no exception thrown.
02:12:57 [martin_]
for the latter (-1 intertone gap)
02:12:57 [dom]
NotSupportedError seems appropriate (the insertDTMF operation is not supported)
02:13:03 [juberti]
juberti: hta says this is a corner case.
02:14:06 [TZH_]
TZH_ has joined #webrtc
02:15:56 [juberti]
juberti: forget everything i said before.
02:16:26 [juberti]
juberti: new agreement: createDTMFSender doesn't do any checking on remote DTMF capability.
02:16:48 [juberti]
juberti: insertDTMF _does_ check remote DTMF support, and that the MST is still valid, and the parameters are good.
02:16:52 [rbarnes]
where are we in the agenda?
02:16:55 [GangL]
GangL has joined #webrtc
02:17:02 [juberti]
if any are not good, throw not-supported exception.
02:18:37 [juberti]
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]
silvia has joined #webrtc
02:18:55 [juberti]
cullen: we should say anything less than 0-9, *, # should be treated as no DTMF support
02:19:10 [juberti]
burn: stats model, 7.1.
02:20:00 [juberti]
burn: what should happen if you call getStats with an invalid selector (currently only MSTs are valid as selector)
02:20:09 [juberti]
hta: invalidargumentexception
02:20:43 [juberti]
burn: list of supported values is indicated by the enumerated type. see webidl
02:21:01 [juberti]
burn: delete note in the spec about other selectors
02:21:09 [juberti]
burn: getstats, 7.2.1
02:22:15 [juberti]
hta: getStats shouldn't throw if we call it after close().
02:22:27 [juberti]
cullen: we should have an explicit note in the spec about this.
02:23:21 [juberti]
jan-ivar: should close() also be valid here?
02:23:26 [juberti]
ekr: yes, idempotent.
02:23:27 [martin_]
If we're overriding general guidance, we should always have a note, so close() should have some specific text too.
02:23:34 [Tony]
Tony has joined #Webrtc
02:24:32 [dom]
the notion of "invalid selector" is not defined
02:24:51 [dom]
it should at least be clarified here what we mean
02:25:12 [juberti]
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 [juberti]
burn: i prefer everything being explicit, easier for the developer
02:26:02 [ekr]
it's not easier for the developer
02:26:39 [ekr]
issue: should we refactor the generic guidance on error handling out of the spec
02:26:39 [trackbot]
Created ISSUE-3 - Should we refactor the generic guidance on error handling out of the spec. Please complete additional details at <>.
02:26:46 [juberti]
burn: let's discuss this later
02:27:29 [Travis]
Travis has joined #webrtc
02:27:49 [juberti]
stefanh: use invalidparameter/illegalargument for getStats with invalid selector
02:27:54 [juberti]
hta: agreed
02:28:10 [juberti]
burn: RTCStats dictionary, 7.5
02:28:14 [ekr]
02:28:21 [juberti]
martin: The text is correct.
02:28:29 [juberti]
burn: What should the app do?
02:28:43 [juberti]
martin: It should ignore any unknown values. Just like any other dictionary.
02:29:13 [martin_]
if (isUnknown(stats)) { window.close(); }
02:29:32 [dom]
"MUST" is not appropriate here; MUST in this spec should only apply to things relevant to User Agents, not to applications
02:29:48 [juberti]
while (isUnknown(stats)) { alert("not known!"); }
02:30:41 [dom]
02:31:39 [juberti]
juberti: move to skip identity discussion, since we don't have a working impl yet
02:32:08 [juberti]
ekr: let's not use that as an excuse to dump identity because we don't have as spec.
02:32:23 [juberti]
ekr: we have identity later.
02:32:35 [juberti]
hta: let's move on
02:33:25 [frodek]
frodek has joined #webrtc
02:34:16 [jehoochen__]
jehoochen__ has joined #webrtc
02:37:34 [yusuke]
yusuke has joined #webrtc
02:38:27 [ijongcheol]
ijongcheol has joined #webrtc
02:39:45 [yusuke_]
yusuke_ has joined #webrtc
02:46:06 [hiroki]
hiroki has joined #webrtc
02:49:34 [Takahiro]
Takahiro has joined #webrtc
02:54:59 [rbarnes]
rbarnes has joined #webrtc
02:55:26 [trackbot]
trackbot has joined #webrtc
02:56:26 [hiroki]
hiroki has joined #webrtc
03:01:43 [lgombos]
lgombos has joined #webrtc
03:02:33 [silvia]
silvia has joined #webrtc
03:02:42 [silvia1]
silvia1 has joined #webrtc
03:05:15 [juberti]
juberti: moving on to unannounced ssrc handling
03:05:37 [juberti]
hta: a=msid identifies streams/tracks consistently.
03:05:50 [juberti]
hta: what about non-webrtc endpoints, which don't send a=msid?
03:06:04 [juberti]
hta: they still expect sync/grouping
03:06:14 [juberti]
hta: behavior needs to be predictable
03:06:35 [minami]
minami has joined #webrtc
03:07:48 [juberti]
predictable = media plays out when it arrives.
03:08:17 [juberti]
and media with a single CNAME should be synchronized (not 100% clear, see LS)
03:09:06 [juberti]
proposals for handling: all incoming media in one MS, each in its own MS, group in MS based on CNAME
03:10:13 [juberti]
cullen: what do you get if you get multiple SSRCs?
03:10:17 [juberti]
hta: multiple tracks.
03:11:39 [juberti]
hta: cname identifies sync context; exact language in 3550 is iffy
03:12:51 [juberti]
hta: same JS should result in same CNAME
03:13:07 [juberti]
hta: moving track from one stream to another when there are different CNAMEs is hard
03:13:48 [juberti]
martin: 2 streams - one with A and B, one with B and C - do they have same CNAMEs
03:13:55 [ywu]
ywu has joined #webrtc
03:14:16 [juberti]
martin: jonathan means they have clocks that advance at same rate
03:14:24 [burn]
burn has joined #webrtc
03:14:43 [juberti]
cullen: lipsync existed long before LS was invented
03:14:48 [burn]
For the minutes, I believe this topic of interoperability with non-WebRTC endpoints is out of scope for this group.
03:15:12 [Tony]
Tony has joined #Webrtc
03:15:38 [juberti]
I think we need to know what happens at the API level
03:16:16 [burn]
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 [juberti]
So we make msid as mandatory to use?
03:17:14 [burn]
Once the scope includes non-WebRTC there is no longer any natural boundary for the scope.
03:17:50 [ekr]
burn: uh, it's toally news to me that interop isn't important
03:17:59 [ekr]
or ins cope
03:18:01 [ekr]
in scope
03:18:08 [dom]
03:18:14 [richt]
richt has joined #webrtc
03:18:25 [dom]
ekr, the question burn is raising is on interop with legacy devices (rather than with other browsers)
03:18:33 [Tony_]
Tony_ has joined #Webrtc
03:18:37 [ekr]
dom, yes, I understand that. I totally disagree that it's not in scope
03:18:56 [juberti]
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 [juberti]
cullen: can we move a MST to another MS when RTCP arrives?
03:20:01 [juberti]
ekr: yuck
03:20:05 [dom]
(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 [ekr]
dom, yes, I don't think that's acceptbale
03:20:30 [juberti]
hta: we need to either stuff in default group, or in its own
03:20:37 [burn]
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 [juberti]
hta: if we like what's in the document, we're finished.
03:21:00 [ekr]
burn, well we've already agreed to a bunch of such changes, such as for bundle-only
03:21:34 [juberti]
(which is one MST per MS)
03:21:42 [ijongcheol]
ijongcheol has joined #webrtc
03:22:05 [juberti]
pthatcher: we can expose CNAME and then let app group as needed
03:22:27 [burn]
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 [ekr]
burn, I said "bundle only"
03:22:43 [juberti]
jesup: so this will be the case for a single audio and video stream?
03:22:56 [Tony]
Tony has joined #Webrtc
03:23:04 [juberti]
jesup: app developer probably won't be expecting this
03:23:23 [juberti]
cullen: it's not clear how you move this stuff around, the default should be a single MS
03:23:41 [juberti]
juberti: agree
03:24:56 [juberti]
juberti: do we really need an API for this?
03:24:57 [burn]
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 [dom]
no you won't, burn
03:26:07 [juberti]
juberti: I think we should stuff everything into a single MS
03:26:10 [richt_]
richt_ has joined #webrtc
03:26:10 [burn]
dom, :)
03:26:44 [juberti]
juberti: unless you set a=msid.
03:26:58 [juberti]
martin: the browser won't sync things that are totally out of sync anyway.
03:27:24 [juberti]
hta: suggestion is that all un-MSIDed SSRCS create tracks in a single default MSID
03:28:32 [juberti]
cullen: is CNAME part of stats?
03:29:22 [juberti]
juberti: not currently
03:29:44 [juberti]
hta: that is the full proposal.
03:31:38 [Tony]
Tony has joined #Webrtc
03:32:00 [juberti]
cullen: is there a real problem with adding a CNAME property>
03:33:20 [frodek]
frodek has joined #webrtc
03:33:32 [juberti]
cullen: what does a gateway need to do?
03:33:48 [juberti]
juberti: add 2 MSIDs: ms1 t1, and ms1 t2 or ms2 t1
03:33:57 [juberti]
cullen: how do you demux without the a=ssrc values?
03:34:02 [AndyF]
AndyF has joined #webrtc
03:34:16 [juberti]
juberti: you're not BUNDLing, because legacy, so you can demux by 5-tuple
03:34:28 [kodonog]
kodonog has joined #webrtc
03:34:56 [juberti]
adam: what happens if you get an invalid a=msid line
03:35:04 [juberti]
hta: then you have an illegal SDP
03:35:11 [juberti]
hta: what should you do with an illegal SDP?
03:36:01 [juberti]
hta: and there is a line needed for msid-semantic WMS.
03:36:22 [ekr]
juberti: will this show up on the screen?
03:36:38 [ekr]
or maybe hta:
03:36:48 [ekr]
I am now in complete control of hta's screen
03:37:28 [juberti]
pthatcher: should there be a default MSID?
03:37:31 [martin_]
martin: generate a default msid and it's all good
03:37:39 [juberti]
martin: no, generate one.
03:37:48 [juberti]
ekr: should be cryptographically random
03:37:54 [juberti]
juberti: and we're done.
03:38:21 [martin_]
yeah, 500bits of entropy
03:38:28 [Leon]
Leon has joined #webrtc
03:38:38 [stephane]
stephane has joined #webrtc
03:38:50 [juberti]
juberti: new topic: data channel
03:39:02 [juberti]
jesup: new drafts, etc, etc
03:39:20 [juberti]
jesup: open issue from IETF: max msg size
03:39:26 [dom]
Topic: data channel
03:39:43 [juberti]
jesup: various proposals to set max msg size
03:40:03 [juberti]
jesup: would prefer to stay with something like websockets
03:40:16 [juberti]
jesup: where there is no specified max
03:41:20 [juberti]
jesup: websockets has no streaming interface. you get a blob that plops out.
03:41:52 [juberti]
cullen: how should file transfer stuff work then?
03:42:26 [juberti]
ekr: i can figure out how to chew up memory and cpu in js in other ways no problem.
03:43:00 [AndyF_]
AndyF_ has joined #webrtc
03:43:07 [mchampion]
mchampion has joined #webrtc
03:43:13 [silvia]
silvia has joined #webrtc
03:43:37 [juberti]
dom - we reconnected to the room
03:44:03 [juberti]
03:44:05 [jeff]
jeff has joined #webrtc
03:44:41 [juberti]
jesup: as long as you don't run out of RAM, you should be able to send.
03:44:51 [juberti]
cullen: how do i write code to this.
03:45:05 [juberti]
jesup: get blob from user, send blob. comes out the other end as a blob. done.
03:45:15 [silvia]
silvia has joined #webrtc
03:45:42 [dom]
q+ stefanh
03:45:45 [juberti]
cullen: how does this work on a 2 GB video file.
03:45:56 [juberti]
jesup: works if you have enough RAM.
03:46:27 [wyh_]
wyh_ has joined #webrtc
03:47:01 [chris]
chris has joined #webrtc
03:47:09 [juberti]
jesup: i don't recommend this except for simple cases. real apps should do chunking.
03:47:41 [silvia]
silvia has joined #webrtc
03:47:46 [juberti]
cullen: i'd like some certain minimum blob size that would work.
03:48:30 [juberti]
ekr: i don't care what the number is. I just want feedback.
03:48:43 [silvia1]
silvia1 has joined #webrtc
03:49:18 [juberti]
jesup: firefox supports sending 2 GB chunks in websockets.
03:49:40 [juberti]
pthatcher: any real app is going to use chunks. for a progress bar.
03:49:54 [stefanh]
03:49:58 [ekr]
pthatcher, i don't disagree
03:50:14 [ekr]
but that doesn't mean we shouldn't have tood API semantics
03:50:38 [Zakim]
- +
03:51:47 [fluffy]
03:51:49 [silvia]
silvia has joined #webrtc
03:52:31 [juberti]
juberti: can we defer this? seems like a big hairy issue
03:52:51 [fluffy]
we can't hear you
03:52:55 [fluffy]
it was really bad break up
03:53:00 [fluffy]
that sounds better
03:53:09 [juberti]
ekr: we agreed to defer it in IETF to here
03:53:11 [JimBarnett]
I don't hear anything on Zakim
03:53:16 [juberti]
juberti: so this overall API seems non-ideal. i want a real streams interface
03:53:51 [juberti]
jesup: so you could take that to W3C and solve this for Websockets and datachannels
03:54:35 [juberti]
ekr: websockets is mainly a replacement for comet, so this issue isn't as critical there.
03:54:45 [juberti]
harald, can you dial Zakim?
03:56:07 [Zakim]
+ +
03:56:45 [ywu]
ywu has joined #webrtc
03:56:57 [juberti]
juberti: if you try to send too much, you get "data channel is now dead"
03:57:26 [ekr]
03:57:35 [ekr]
though perhaps juberti feels the same way
03:58:22 [juberti]
yeah, lost the plot there
03:59:50 [juberti]
jesup: if receiving side gets a too big message, it will fire onerror with data-too-large
04:00:38 [juberti]
juberti: does this teardown and propagate to sender?
04:01:03 [juberti]
someone: no, just for the individual packet
04:02:00 [juberti]
jesup: app can discuss over the channel to figure out how to get back on track
04:03:08 [juberti]
cullen: example: any packet < 10 KB, must be delivered
04:03:25 [juberti]
juberti: 64 KB
04:03:32 [ekr]
ekr: 640kb should be enough
04:06:45 [juberti]
juberti: probably not reasonable to expect that any size thing can be sent
04:07:16 [juberti]
juberti: should have some minimum, but implementations can impose a maximum
04:07:57 [juberti]
jesup: we're going to be intentionally diverging from websockets.
04:09:29 [fluffy]
we did not hear that
04:09:36 [juberti]
jesup: and we need some way to communicate "closed with error" back to the other side
04:09:51 [martin_]
issue: requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases
04:09:51 [trackbot]
Created ISSUE-4 - Requiring that negotiated channels be created on the receiver before any data can be received is problematic for some use cases. Please complete additional details at <>.
04:10:33 [Zakim]
04:11:46 [yusuke]
yusuke has joined #webrtc
04:12:15 [Zakim]
04:12:25 [ijongcheol]
ijongcheol has joined #webrtc
04:29:11 [ijongcheol]
ijongcheol has joined #webrtc
04:47:48 [silvia]
silvia has joined #webrtc
05:03:53 [kotakagi]
kotakagi has joined #webrtc
05:07:46 [jehoochen__]
jehoochen__ has joined #webrtc
05:11:06 [yusuke]
yusuke has joined #webrtc
05:18:49 [silvia1]
silvia1 has joined #webrtc
05:22:49 [Takahiro]
Takahiro has joined #webrtc
05:23:45 [yusuke_]
yusuke_ has joined #webrtc
05:25:17 [ijongcheol]
ijongcheol has joined #webrtc
05:32:56 [stefanh]
stefanh has joined #webrtc
05:38:00 [mreavy]
mreavy has joined #webrtc
05:38:06 [robin]
robin has joined #webrtc
05:38:44 [frodek]
frodek has joined #webrtc
05:40:53 [juberti]
juberti has joined #webrtc
05:41:31 [ekr]
ekr has joined #webrtc
05:42:34 [dom]
dom has joined #webrtc
05:42:42 [silvia]
silvia has joined #webrtc
05:43:52 [hta]
hta has joined #webrtc
05:44:09 [dom_proj]
dom_proj has joined #webrtc
05:44:23 [silvia1]
silvia1 has joined #webrtc
05:45:27 [Zakim]
05:46:04 [kotakagi]
kotakagi has joined #webrtc
05:47:50 [adambe]
adambe has joined #webrtc
05:49:14 [kodonog]
kodonog has joined #webrtc
05:50:11 [fluffy]
fluffy has joined #webrtc
05:50:37 [jinkyu_seong]
jinkyu_seong has joined #webrtc
05:50:51 [Zakim]
05:51:04 [rbarnes]
rbarnes has joined #webrtc
05:51:16 [fluffy]
scribe fluffy me
05:51:22 [fluffy]
scribe nic fluffy
05:51:43 [fluffy]
Data channel discussion proposal
05:51:47 [dom]
scribenick: fluffy
05:51:55 [fluffy]
Define a min support size that works on order of 64 k
05:52:14 [fluffy]
add a read only attribute of how much your side can receive
05:52:22 [fluffy]
read only attribute of how much other side can read
05:52:36 [rbarnes_]
rbarnes_ has joined #webrtc
05:52:40 [fluffy]
IETF protocol would cause these attributes to be set shortly after channel got opened
05:53:12 [fluffy]
IETF could do this with new message or piggy back on open messages
05:53:36 [DanD]
DanD has joined #webrtc
05:53:54 [fluffy]
Randal and Peter T are ok with this
05:54:00 [fluffy]
Martin seems OK with this
05:54:09 [ijongcheol]
ijongcheol has joined #webrtc
05:54:38 [fluffy]
the attributes would probably be on the DataChannel
05:55:02 [fluffy]
would throw exception JS tries to send something larger than allowed size
05:55:10 [burn]
burn has joined #webrtc
05:55:43 [fluffy]
05:56:29 [fluffy]
chairs suggest some interim meeting (or call) to sort out what we might have in version 1
05:56:46 [jeromemarcon]
jeromemarcon has joined #webrtc
05:56:46 [taocai]
taocai has joined #webrtc
05:57:07 [fluffy]
Justin: the scope of API is a w3c decision and don't need to much
05:57:13 [yahui]
yahui has joined #webrtc
05:57:40 [JimBarnett]
JimBarnett has joined #webrtc
05:58:16 [rbarnes_]
scribenick fluffy
05:58:36 [ken]
ken has joined #webrtc
05:58:37 [fluffy]
need a list of topics that are in
05:59:42 [stephane]
stephane has joined #webrtc
05:59:53 [fluffy]
question is phone call in december or meeting in January
06:00:03 [rbarnes_]
rbarnes_ has joined #webrtc
06:00:18 [Marcus_Altman_]
Marcus_Altman_ has joined #webrtc
06:01:44 [fluffy]
dan - not sure we need a prioritization on items in order. In practice the group self selects to not do any more as people stop writing stuff
06:02:02 [dom]
s/ - /:/
06:02:19 [fluffy]
Juntin: prefer to have a done by time x
06:02:29 [fluffy]
06:03:12 [fluffy]
???: If we don't get this right, we don't get good features. So should drive it from that
06:03:48 [fluffy]
dom: issues is identity a current feature or next feature
06:03:49 [richt]
richt has joined #webrtc
06:04:13 [fluffy]
justin: not trying to pick on nay feature, but we should make a list of all the features that need to happen and see what needs to be done
06:04:27 [fluffy]
… if we say that is the min we need to do, still working at a bunch of time ahead of us
06:04:37 [fluffy]
… partial offer / answer perhaps we don't do that
06:04:47 [fluffy]
… not picking on anything specific
06:05:11 [fluffy]
… but if we want to finish in 2014, we are going to need to drop some stuff that we are going to really wish we had
06:05:32 [fluffy]
ekr: not really prioritization ordering in that people vote with their feet
06:05:41 [fluffy]
jstin: need people to make list and we can review
06:05:59 [fluffy]
hta: chairs need to be part of it
06:07:11 [fluffy]
hta: propose we ask list about a call on dec 11
06:07:41 [AndyF_]
AndyF_ has joined #webRTC
06:07:54 [Leon]
Leon has joined #webrtc
06:08:02 [fluffy]
???: upper side is a pox on the industry
06:08:10 [fluffy]
chairs: will do usual to sett up time and day
06:08:17 [dom]
s/???: upper side is a pox on the industry//
06:09:27 [dom]
Topic: Transport Control
06:09:42 [ekr]
??? wrt upper side is Adam
06:10:04 [dom]
stefanh: [slide 2]
06:10:07 [rbarnes]
link to slides?
06:10:12 [dom]
... ["Background"]
06:10:32 [DanD]
DanD has joined #webrtc
06:10:47 [dom]
-> Stefan's slides
06:11:01 [dom]
stefanh: I'm proposing an API modelled on the DTMF handler for control
06:11:07 [dom]
... [slide 3] links to the proposal
06:11:15 [jehoochen__]
jehoochen__ has joined #webrtc
06:11:31 [dom]
... [slide 4] shows a proposed addition to RTCPeerConnection with a getMediaTrackTransmissionController method
06:11:40 [dom]
juberti: this is for send and receive, or only send?
06:11:45 [dom]
stefanh: just "send"
06:12:13 [dom]
juberti: I was hoping you could could get this back when adding a stream to a peer connection
06:12:15 [kodonog]
kodonog has joined #webrtc
06:12:21 [dom]
s/could could/could/
06:12:24 [ekr]
new proposed name is doohickey
06:12:33 [Tony]
Tony has joined #Webrtc
06:13:16 [dom]
hta: when you don't want to control this, you can just ignore it
06:13:18 [stephane]
stephane has joined #webrtc
06:13:34 [dom]
juberti: if you make it a return value of addStream, you don't add a new API surface
06:13:45 [dom]
stefanh: FWIW, I agree with justin — it seems cleaner
06:14:17 [hta]
juberti: addstream gives you back the handlers for each track within the stream, or we remove addstream and switch to doing addtrack.
06:15:50 [hta]
martin: you don't know which stream tracks are part of.
06:16:34 [hta]
cullen: that would require that each track added has a list of contexts it is part of.
06:16:39 [dom]
stefanh: this may have been said, but all the tracks will have the same syncrhonization context anyway
06:16:54 [dom]
... so they could be reassembled by the application via out of band information
06:17:07 [dom]
adambe: I think streams are just complicating the transmission over the network
06:17:27 [dom]
... we have ids on the tracks, so we can always signal the composition of the streams
06:17:54 [dom]
martin: I'm glad you guys have finally seen the way
06:17:59 [hta]
martin: i have argued against this enough, I'm now good with it.
06:18:42 [hta]
martin: when you look at the track object, it has a list of the streams it is part of.
06:19:11 [hta]
randell: how do you know when you have all the tracks for the videostream?
06:20:04 [dom]
burn: if you do this, you don't even need msid anymore
06:20:13 [dom]
stefanh: you do need track id
06:20:17 [dom]
burn: yes, but not stream ids
06:20:50 [hta]
cullen: on the receiving side, you will have callbacks saying new tracks have arrived. and the sdp will still have the track/stream mapping.
06:21:39 [dom]
hta: we don't have a specific proposal for such a change; I think we need to focus on the proposal on the table
06:21:56 [dom]
... martin, if you want to take an action item to provide a concrete proposal...
06:22:09 [dom]
ACTION: martin to make proposal on moving away from addStream toward addTrack
06:22:09 [trackbot]
Created ACTION-102 - Make proposal on moving away from addstream toward addtrack [on Martin Thomson - due 2013-11-19].
06:22:26 [dom]
stefanh: [slide "new API"]
06:22:39 [dom]
... describes the proposes Transmission controller interface
06:23:00 [Tony_]
Tony_ has joined #Webrtc
06:23:04 [dom]
... it has a reference to the track, and a boolean "theNewThing"
06:23:21 [JimBarnett]
constraints can have boolean values
06:23:23 [dom]
juberti: any reason this is an attribute rather than a constraint (?)
06:24:15 [dom]
fluffy: the question is how much we do through contraints vs specific attributes
06:24:27 [dom]
juberti: I think we need to take one approach or the other
06:24:43 [dom]
... deciding constraint vs attribute should be done based on a well-defined set of criteria
06:25:32 [dom]
Jim: the definition of constraints accept boolean
06:25:55 [dom]
burn: you can, but keep in mind that the primary design of constraints is to allow for expressing preferences with possible fallbacks
06:26:07 [hta]
hta: the New Thing is going to trigger a negotiationneeded event when we flip it.
06:26:26 [dom]
juberti: realistically constraints have been used to work around WebIDL limitations of predefined names
06:26:46 [dom]
jesup: one of the questions is how you get values out of these
06:26:48 [hta]
randell: what about getting the values?
06:27:44 [hta]
hta: please check the newest constrainable inteface - there is an interface for getting the values.
06:28:07 [jib]
jib: +1
06:28:11 [jib]
dan: +1
06:28:12 [dom]
burn: constraints should not be used for every possible setting
06:28:19 [ekr]
Sorry, I overran the buffer
06:28:19 [dom]
... they are meant to express a preference
06:28:26 [hta]
ekr: when I want to stop RTP, I want to stop RTP - it's not something that interacts with other constraints.
06:28:37 [rbarnes]
ekr.constrain({ mandatory: { wordRatePerSecond: 2 } })
06:28:47 [dom]
jesup: constraints should be used only when we absolutely need
06:29:04 [derf]
rbarnes: Is that an upper bound or a lower bound?
06:29:10 [dom]
burn: I don't have an answer off-hand given the modifications made to constraints via the Constrainable interface
06:29:17 [derf]
Or is it like imageattr and he'll just ignore it?
06:29:32 [dom]
jib: for a constraint, you need to have a selection between multiple choices
06:29:50 [dom]
... the only place they make sense right now is for getUserMedia
06:30:03 [dom]
... I'm probably arguing against using them in PeerConnection
06:30:12 [dom]
... we should not replace dictionaries with constraints
06:30:25 [hta]
juberti: there are many examples of constraints in the spec that would not satisfy the criteria just laid out.
06:30:42 [dom]
burn: we decided yesterday all the constraints usage need to be reviewed
06:30:53 [dom]
... it may be that most or all usage is not justified
06:31:16 [silvia]
silvia has joined #webrtc
06:31:45 [hta]
juberti: if the answer is replacing constraints with dictionaries, then that may be fine.
06:32:05 [DanD]
DanD has joined #webrtc
06:32:22 [dom]
jib: constraints are good when you want fallback (?)
06:32:56 [dom]
... when I implemented the peerconnection settings, I found that we abused the mandatory/optional model (?)
06:33:32 [dom]
juberti: in your review, the transmission controller should or should not be using constraints?
06:33:32 [dom]
jib: no
06:33:52 [dom]
hta: let's focus on the current problem before branching in yet another discussion
06:34:51 [dom]
ekr: independently of the constraints/attribute question, we need to get to the bottom of theNewThing doohey thingy
06:35:01 [dom]
hta: we have agreement they should be bound to the track and @@@
06:35:57 [hta]
justin and cullen: we're proposing that there should be a similar doohickey on the receive side.
06:36:24 [dom]
stefanh: [slide "Initial constraints"]
06:36:35 [dom]
... (maybe settings rather than constraints :)
06:36:40 [dom]
... proposal is: priority and bitrate
06:37:23 [dom]
-> Resource Priorities API (WebPerf WG)
06:37:46 [silvia1]
silvia1 has joined #webrtc
06:38:16 [dom]
[the Resource Priorities API has 3 levels: "normal", "lazy-load", "postpone" FWIW]
06:38:17 [silvia2]
silvia2 has joined #webrtc
06:39:10 [hta]
martin: we need at least 4 priorities.
06:39:16 [silvia3]
silvia3 has joined #webrtc
06:39:33 [hta]
cullen: we need 3 priorities, these can be combined with the data types, which the scheduler knows, giving 9.
06:40:06 [hta]
martin: need to look at the line that shows which goes first.
06:40:38 [hta]
juberti: scavenger, low, high, highest. Making assumptions from the media type could be dangerous.
06:41:30 [hta]
stefan: bitrate.
06:41:34 [dom]
stefanh: for bitrate, I was suggesting a min-max value; maybe just a maximum value makes sense, although people have expressed the desire to express a min bitrate as well
06:41:56 [hta]
cullen: we need to be clear if there is a target, a max or a floor - on IP, the lowest bitrate is always zero.
06:42:15 [hta]
martin: a floor means that if we get below a certain floor, we should stop sending.
06:42:37 [hta]
martin: a floor on quality makes more sense than a floor on bitrate.
06:43:15 [hta]
juberti: we need a cap on the whole peerconnection, not necessarily on the individual track.
06:43:51 [hta]
martin: this is for use cases where the app knows something about the path.
06:44:33 [hta]
randell: the app may know which videos are more important for the application. we should give it the tools to say so.
06:45:16 [martin_]
I just dispensed with my action from before
06:45:57 [DanD]
06:45:59 [hta]
juberti: example: I want to stop sending video if the result is unusable; if the bandwidth comes back, I want video to resume.
06:46:32 [hta]
juberti: quality thresholds can give us some tools that the scheduler can use.
06:46:39 [fluffy]
06:46:57 [dom_proj_]
dom_proj_ has joined #webrtc
06:47:56 [dom]
dand: I agree with randell the application should be in control
06:47:59 [dom]
... it should be about expressing a desire, more than making it a hardset setting
06:48:16 [hta]
randell: the automated mechanism should be kept simple. COmplex stuff should be left to the application's hands.
06:48:43 [hta]
06:48:47 [hta]
ack DanD
06:48:49 [hta]
ack fluffy
06:49:10 [DanD]
06:49:30 [hta]
cullen: even if I'm on a 50 Mbit 4G connection, it's perfectly reasonable to say that I don't want to use more than 1 Mbit of that.
06:49:34 [fluffy]
06:50:55 [hta]
justin: if I send hires, lores and audio, I want to drop the hires then the lores when bandwidth disappears, and claw it back when it becomes available. With thresholds in quality, not bandwidth.
06:52:04 [Zakim]
- +
06:52:09 [dom]
fluffy: I think we should move away from bitrate specified as min/max
06:52:09 [dom]
hta: I've heard support for a max rate for bitrate as useful
06:52:15 [dom]
... and people arguing that setting a minimum quality level would be more useful
06:53:01 [dom]
... but that needs a definition of quality
06:53:10 [JimBarnett]
Zakim is silent
06:53:28 [ekr]
Quality? PSNR
06:54:20 [fluffy]
try again you are breaking up badly
06:54:42 [dom_proj]
dom_proj has joined #webrtc
06:55:16 [Zakim]
+ +
06:55:17 [stefanh]
I was saying that a min bitrate in combination with knowing the codec gives an estimate of the quality
06:55:23 [dom]
... and so we need a proposal from those that think this is a good idea
06:55:23 [dom]
... and if the application need to see information, this also needs a proposal
06:55:23 [dom]
stefanh: if you combine codec and bitrate, you get a pretty good indication of quality
06:55:30 [dom]
... so with a minimal bit rate you can actually get meaningful information
06:55:30 [dom]
Zakim, code?
06:55:30 [Zakim]
the conference code is 9782 (tel:+1.617.761.6200, dom
06:56:54 [hta]
juberti: difficulty of correlating QoS metrics - bandwidth is highly scene dependent.
06:57:47 [hta]
action jesup: resend to the list an earlier proposal on how to interact with tracks.
06:57:47 [trackbot]
Error finding 'jesup'. You can review and register nicknames at <>.
06:58:04 [hta]
action randell: resend to the list an earlier proposal on how to interact with tracks.
06:58:04 [trackbot]
Error finding 'randell'. You can review and register nicknames at <>.
06:59:49 [fluffy]
you are sounding ok now
07:00:11 [BY]
BY has joined #webrtc
07:00:24 [kodonog]
kodonog has joined #webrtc
07:00:36 [hta]
pthatcher: should you also be able to set codecs?
07:00:49 [hta]
stefhak: that should be added somewhere.
07:01:01 [burn]
action derf to get jesup to resend to the list an earlier proposal on how to interact with tracks
07:01:01 [trackbot]
Created ACTION-103 - Get jesup to resend to the list an earlier proposal on how to interact with tracks [on Timothy Terriberry - due 2013-11-19].
07:01:16 [dom_proj_]
dom_proj_ has joined #webrtc
07:01:20 [hta]
ekr: a number of the frobs on the doohickey will cause negotiationneeded.
07:01:25 [dom_]
dom_ has joined #webrtc
07:02:01 [dom_]
RRSAgent, pointer
07:02:01 [RRSAgent]
07:03:54 [hta]
adam: I want to call TheNewThing "suspend" (suspended?)
07:03:57 [jehoochen_]
jehoochen_ has joined #webrtc
07:04:50 [burn]
I like suspendend
07:04:52 [hta]
ekr, juberti: don't like paused, perhas inactive is ok.
07:05:01 [burn]
suspended, I mean
07:05:07 [ekr]
07:05:39 [hta]
adam: suspended has the same direction of the sign as muted.
07:05:46 [stefanh]
I could leave it up to the editors and move on
07:05:52 [stefanh]
name is not that important
07:06:45 [hta]
adam: at least 2 telco systems have suspend / resume that mean exactly this.
07:06:52 [stefanh]
did we ever conclude on receiver side "TheNewThing"?
07:07:35 [hta]
adam: I think we need suspended (TheNewThing) on the receive side.
07:08:58 [hta]
adam: the suspended bit on one side does not affect the suspended bit on the other side. these are controllers, not statuses.
07:09:35 [hta]
ekr: believe we need receiver side doohickey.
07:09:53 [hta]
juberti: do we need to set resolution on receive side?
07:10:07 [hta]
fluffy: we should be able to set max resolution, at least.
07:10:46 [hta]
stefan: do we want all this in the sdp?
07:11:26 [silvia]
silvia has joined #webrtc
07:11:33 [hta]
adam: the signalling is already defined for SDP. Stuff that will interoperate with us will expect to have this work.
07:12:05 [stefanh]
Think we need to close this now
07:12:14 [ken]
ken has joined #webrtc
07:13:09 [hta]
Robin Raymond: I think we should not add the receive-side doohickey. It adds a lot of complexity.
07:13:53 [hta]
cullen: I don't see why we want to signal this stuff (suspend for example) over a different channel than SDP.
07:14:37 [hta]
pthatcher: don't see that there's the same amount at receiver as at sender.
07:15:10 [stefanh]
Proposal: those wanting it develop a proposal for the reciever-side doohikey (including attributes)
07:15:58 [hta]
pthatcher: the receive doohickey, which controls SDP, is lower priority than the send doohickey, which controls stuff that happens locally.
07:16:31 [hta]
cullen: I think the priority is completely the opposite. The most important thing is that the receiver can ask to turn off.
07:16:48 [dom]
stefanh: while don't people develop a proposal for the receiver side offline so that we can move on
07:16:55 [dom]
07:16:59 [ekr]
it's going to be very hard to add doohickeys on the receive side later
07:17:19 [dom]
burn: you asked if I had some rules for constraints; I've sent a number of mail on this to the list
07:17:27 [dom]
... there are a number of edge cases
07:17:36 [dom]
... I'm happy to have that conversation again once we're ready for that
07:17:44 [dom]
... I want to take the time to explain it properly
07:18:03 [dom]
[coffee break]
07:18:07 [dom]
RRSAgent, draft minutes
07:18:07 [RRSAgent]
I have made the request to generate dom
07:18:42 [Tony]
Tony has joined #Webrtc
07:19:27 [Zakim]
07:21:01 [silvia1]
silvia1 has joined #webrtc
07:21:06 [ijongcheol]
ijongcheol has joined #webrtc
07:23:24 [Takahiro]
Takahiro has joined #webrtc
07:29:49 [maltman]
maltman has joined #webrtc
07:42:58 [ijongcheol]
ijongcheol has joined #webrtc
07:44:00 [dom]
dom has joined #webrtc
07:45:30 [rbarnes]
rbarnes has joined #webrtc
07:47:07 [richt]
richt has joined #webrtc
07:47:43 [ekr]
07:47:47 [ekr]
or rather harald is calling
07:49:46 [tony]
tony has joined #Webrtc
07:49:49 [rbarnes]
i will be your scribe for this session
07:49:54 [hta]
what was the topic?
07:50:04 [ekr]
scribenick: rbarnes
07:50:40 [rbarnes]
slide: statistics in webrtc
07:50:48 [rbarnes]
slide; Main API definition
07:51:03 [kotakagi]
kotakagi has joined #webrtc
07:51:33 [rbarnes]
slide: defining new stats items
07:52:14 [rbarnes]
slide: Stats defined
07:52:50 [stephane]
stephane has joined #webrtc
07:52:56 [rbarnes]
slide: implementation status
07:53:30 [rbarnes]
slide: issues found in practical usage
07:54:57 [rbarnes]
slide: issue: personally identifiable info
07:56:24 [rbarnes]
ekr: the way we've been doing this is to gradually add things in
07:56:53 [rbarnes]
slide: questions to address
07:56:55 [Zakim]
07:57:00 [fluffy]
07:57:58 [rbarnes]
fluffy: is it required to have a document for the stat?
07:58:01 [rbarnes]
hta: expert review
07:58:36 [rbarnes]
derf: [on an earlier slide] the standard you want for volume is EBU R128
07:58:48 [rbarnes]
hta: ... which practically requires a document for the expert to review
07:59:00 [rbarnes]
... part of the point of the expert review is to avoid duplication
07:59:22 [rbarnes]
ekr: standard should be for the stat to be (1) clear and (2) non-duplicative
07:59:36 [rbarnes]
... don't even really need a security review, we can catch that in implementation
07:59:43 [jib]
07:59:55 [rbarnes]
juberti: went to xrblock, they're defining a whole bunch of stats
08:00:15 [rbarnes]
... they could possibly tell us a best set of stats
08:00:30 [Takahiro]
Takahiro has joined #webrtc
08:00:48 [rbarnes]
... seems good to be able to get stats in other ways than peerconnection
08:00:57 [rbarnes]
... don't want all the stats, just stats for X
08:01:10 [rbarnes]
ekr: would be OK with many different objects having a stats surface
08:01:32 [stefanh]
note that the Media Source Extension doc extends the video element with stats (video related)
08:01:39 [rbarnes]
fluffy: i would view the IANA registry purely as a name conflict resolution thing
08:02:10 [rbarnes]
adam: e.g., you could have the same thing at different levels of aggregation
08:02:20 [rbarnes]
juberti: what are the main questions you would like to see answered?
08:02:23 [rbarnes]
hta: on the slide
08:02:59 [rbarnes]
fluffy: want to have the stats that are good to have, not the stats that are easy to compute
08:03:06 [rbarnes]
hta: add those that we know we need only
08:03:13 [fluffy]
08:03:16 [hta]
08:03:18 [rbarnes]
ack fluffy
08:03:25 [fluffy]
08:04:12 [rbarnes]
jib: how does the iana thing work?
08:04:34 [rbarnes]
hta: ietf tradition is that once the wg is finished, it goes away. so the iana exists to maintain things into the future
08:05:14 [rbarnes]
ekr: it's hard to make people implement constraints, because they can understand but ignore
08:05:46 [rbarnes]
jesup: would say all the stats are optional
08:05:54 [rbarnes]
... would like to hear the case for things being mandatory
08:05:56 [taocai]
taocai has joined #webrtc
08:06:08 [rbarnes]
juberti: applications will depend on them...
08:06:23 [rbarnes]
ekr: this sounds like a good argument for not having important stuff depend on stats
08:06:49 [rbarnes]
fluffy: clearly not all of them can be MTI
08:07:15 [rbarnes]
... but if they're optional, they might as well not exist
08:07:31 [ekr]
Actually, I have things not quite right for constraints: you can ignore optional and fail on mandatory
08:07:38 [rbarnes]
jesup: they're useful in debugging and collecting data, but if you don't get the data, you don't get the data
08:08:00 [rbarnes]
hta: use them for discovering trends in usage -- how long do people stay on calls, how often does it terminate b/c of an error
08:08:28 [rbarnes]
... would be sad if there were significant holes in coverage. could probably live with it if we could discover which stats are not present (so that we could factor them out)
08:08:51 [rbarnes]
jesup: we already have that case today, because firefox doesn't have all the stats google does
08:09:31 [rbarnes]
juberti: if we're going to put certain stats in the spec, people should implement them because they've been vetted, seen as important
08:09:42 [rbarnes]
... real-time apps are super hard to debug, need these stats to do it
08:10:04 [rbarnes]
... if we're going to be more conservative about which we specify, we should make them mandatory
08:10:17 [stefanh]
+1 to Justin
08:10:33 [rbarnes]
fluffy: when you look at individual stats, you'll probably get agreement from most people
08:10:47 [jib_]
jib_ has joined #webrtc
08:10:48 [rbarnes]
jesup: agree that we should look at which are mandatory, which are not
08:10:57 [jib_]
08:11:03 [burn]
ekr, what do you mean about constraints? optional and mandatory for constraints are regarding satisfaction of them by the browser, from the point of the JS developer -- they have nothing to do with which ones are supported by the browser
08:11:04 [rbarnes]
juberti: wouldn't bother putting it in the spec if it weren't worth implementing
08:11:27 [jib_]
jib_ has left #webrtc
08:11:33 [rbarnes]
... number of stats right now is not overwhelming
08:12:03 [rbarnes]
... 6 counters
08:12:10 [jib]
jib has joined #webrtc
08:12:19 [jib]
08:12:41 [rbarnes]
hta: would be good to get some input from people, especially those aware of ICE
08:12:51 [rbarnes]
ekr: we currently expose the state of every ICE candidate
08:13:23 [jib]
ekr means in privileged browser api only, not to content
08:14:01 [rbarnes]
fluffy: debugging something like hangouts does require automated feedback without user involvement
08:15:08 [rbarnes]
juberti: we could review what Chrome and Firefox implement, as a way of getting an idea of what to put in the document
08:15:16 [rbarnes]
ekr: justin and i could get together on that
08:15:25 [ekr]
action erescorl to meet with justin to review ICE stats and see which make sense in statistics
08:15:26 [trackbot]
Created ACTION-104 - Meet with justin to review ice stats and see which make sense in statistics [on Eric Rescorla - due 2013-11-19].
08:16:08 [rbarnes]
ekr: if the review indicates a need for more richness, we'll come back and figure that out
08:16:15 [rbarnes]
juberti: what about non-pc stats?
08:16:24 [rbarnes]
fluffy: the doohickies help with that
08:16:28 [rbarnes]
jesup: not with gUM
08:16:44 [rbarnes]
fluffy: never imagined there was utility to gUM stats
08:17:04 [rbarnes]
juberti: jitter frames, capture delay, stdev(delay)
08:17:40 [rbarnes]
... say you want to display a meter for voice to display the energy
08:18:16 [ekr]
for those of you on IRC: I said $(gum).vumeter(div)
08:18:41 [rbarnes]
adam: are we going to give freq bands so they can do spectrum?
08:18:54 [rbarnes]
juberti: lots of phone apps do VUmeter, and don't do spectral
08:19:06 [rbarnes]
jesup: lots of this can be done with web audio
08:19:18 [stefanh]
the Web Audio API enables you to do vu meter I think
08:19:27 [stefanh]
it interfaces to MediaStreamTrack
08:19:35 [by_]
by_ has joined #webrtc
08:19:59 [rbarnes]
fluffy: this falls in the category of easy things should be easy
08:20:02 [fluffy]
we can hear
08:20:17 [rbarnes]
stefanh: web audio enables you to display audio levels
08:20:59 [rbarnes]
juberti: i think some stats will not be computable via web audio, so we'll need the interface anyway
08:22:00 [rbarnes]
jesup: if there are any stats that are computationally non-trivial to compute, there's a good argument for not making them default
08:22:30 [rbarnes]
... do generally agree that we should have some stats available for tracks
08:22:44 [rbarnes]
rbarnes: tracks or doohickies
08:22:51 [rbarnes]
juberti: tracks for now
08:24:24 [maltman_]
maltman_ has joined #webrtc
08:24:44 [rbarnes]
???: no way to specify what selector you're getting. could we get stats for data streams?
08:25:10 [rbarnes]
martin_: why not just define a MIB?
08:25:17 [rbarnes]
hta: closing this topic
08:25:20 [jesup]
??? is jib
08:25:37 [jehoochen_]
jehoochen_ has joined #webrtc
08:25:49 [rbarnes]
juberti: what about gUM stats, any actions?
08:25:57 [rbarnes]
martin_: no, but data channels are interesting
08:26:09 [rbarnes]
hta: could you take an action to suggest some?
08:26:45 [rbarnes]
martin_: yes
08:27:11 [rbarnes]
scribenick: juberti
08:32:04 [juberti]
ekr: you want to me able to control the DTLS keys that are used
08:32:09 [juberti]
and cache them between sessions
08:32:18 [wyh_]
wyh_ has joined #webrtc
08:32:18 [juberti]
need to make sure they are scoped to identity to prevent supercookies
08:32:38 [juberti]
temporary keys can also be generated
08:33:17 [juberti]
or created via WebCrypto and shoved down into the PeerConnection via a new setDtlsKey method
08:33:41 [dom]
dom has joined #webrtc
08:33:57 [juberti]
The WebCrypto mechanism is much more flexible, allows application to choose its key length
08:34:05 [richt]
richt has joined #webrtc
08:34:17 [juberti]
and makes the state management super obvious, since app is doing it
08:34:40 [juberti]
better mechanism, but not without some flaws
08:35:04 [juberti]
passing in the public exponent is kind of gross
08:35:47 [juberti]
juberti: are you arguing for this new mechanism and APIs
08:35:52 [juberti]
ekr: yes
08:36:10 [juberti]
juberti: what is the implementation status on this?
08:36:12 [juberti]
ekr: barnes?
08:36:27 [juberti]
rbarnes: spec is pretty stable. not sure about implementation status.
08:37:09 [juberti]
cullen: we can go talk to sleevi.
08:37:19 [juberti]
juberti: can this be done in 2014?
08:37:26 [juberti]
ekr: we could retrofit this later.
08:37:54 [juberti]
ekr: would be nice to know about other side's keys, for key continuity
08:38:16 [juberti]
expose an array of arraybuffers, in DER form, with certificates or remote side.
08:39:14 [juberti]
juberti: where does one get these arraybuffers?
08:39:18 [juberti]
ekr: next slide
08:39:26 [juberti]
ekr: I give you, pc.remoteCertificates
08:39:55 [yusuke_]
yusuke_ has joined #webrtc
08:39:58 [juberti]
list can be parsed with WebCrypto
08:40:22 [juberti]
no claims about the browser's opinion of the certs
08:40:48 [juberti]
juberti: how do we deal with chains, when we also have fingerprint?
08:43:08 [jehoochen_]
jehoochen_ has joined #webrtc
08:44:17 [ekr]
" For DTLS, all m= sections MUST use the certificate for the identity
08:44:18 [ekr]
that has been specified for the PeerConnection; as a result, they
08:44:19 [ekr]
MUST all have the same [RFC4572]fingerprint value."
08:44:25 [yusuke__]
yusuke__ has joined #webrtc
08:46:43 [kodonog]
kodonog has joined #webrtc
08:47:03 [juberti]
juberti: so the fingerprint indicates that the cert is what you think, and the chain indicates whether you trust the identity from the cert
08:47:13 [juberti]
ekr: yes
08:48:06 [juberti]
juberti: how do you handle the case where there are two DTLS connections (with their own remote certs?)
08:48:17 [fluffy]
08:48:26 [juberti]
ekr: can this happen?
08:48:39 [juberti]
juberti: yes, if talking to legacy gateway
08:48:56 [juberti]
ekr: hmm, maybe we need to move this to the doohickey
08:49:07 [juberti]
pthatcher: what about data channels, they have no doohickey (yet)
08:49:19 [juberti]
martin: we can add the property to the doohickey and the data channels
08:49:38 [juberti]
martin: and duck type if necessary
08:50:40 [ekr]
hta, that would be fine with me as well
08:51:30 [rbarnes]
hta: sounds good to me
08:51:50 [juberti]
pthatcher: could we add a parameter to indicate which DTLS do we want to get the certificates from?
08:52:27 [dom_]
dom_ has joined #webrtc
08:52:29 [juberti]
if no parameter, only works if there is one dtls connection
08:52:57 [juberti]
hta: each object only has one DTLSContext
08:53:47 [juberti]
ekr: I like this since it gives us insight into DTLS and stuff
08:53:47 [hta]
s/each object/each object except for PC/
08:53:56 [ekr]
action erescorl come up with a proposal for exposing a transport/DTLS doohickey for each non-PC object
08:53:56 [trackbot]
Created ACTION-105 - Come up with a proposal for exposing a transport/dtls doohickey for each non-pc object [on Eric Rescorla - due 2013-11-19].
08:54:00 [juberti]
pthatcher: and other transport stuff
08:54:30 [juberti]
back to ekr
08:54:42 [juberti]
ekr: remote identity is directly observable
08:55:12 [juberti]
via new pc.peerIdentity
08:56:28 [juberti]
here's how it works
08:57:00 [juberti]
onidentityresult provides a RTCIdentity corresponding to the obtained identity (from remote)
08:57:15 [juberti]
rename peerIdentity to remoteIdentity to match remoteDescription
08:57:21 [juberti]
localIdentity contains own identity
08:58:41 [juberti]
pthatcher: can you have multiple remote identities
08:58:48 [juberti]
ekr: no; JSEP says only one identity
08:59:01 [juberti]
ekr: way too complicated to have more than one
08:59:52 [juberti]
moving on
09:00:18 [juberti]
a MessageChannel is needed for moving identity stuff around
09:00:22 [nsakai]
nsakai has joined #webrtc
09:00:58 [yusuke_]
yusuke_ has joined #webrtc
09:00:58 [juberti]
which needs a specific name. TBD, but proposing identityMessageChannel
09:02:06 [juberti]
hta: does each PeerConnection have its own MessageChannel?
09:02:09 [juberti]
ekr: yes
09:02:20 [juberti]
ekr: otherwise not necessarily safe
09:03:08 [ekr]
action ekr: generate a single monolithic description of who sends what on identity
09:03:08 [trackbot]
Created ACTION-106 - Generate a single monolithic description of who sends what on identity [on Eric Rescorla - due 2013-11-19].
09:03:45 [juberti]
ekr: noaccess and peerIdentity
09:04:20 [juberti]
Can't attach MediaStreams that are isolated to PeerConnections (or other undesirable sinks)
09:04:23 [nsakai]
nsakai has left #webrtc
09:04:38 [juberti]
martin suggested that instead when things were nonpermitted they generated silence or blackness
09:04:43 [dom_proj]
dom_proj has joined #webrtc
09:05:03 [juberti]
martin suggests you can always glue things together however you want
09:05:12 [jesup]
09:05:34 [juberti]
stefanh: do streams get marked, or tracks?
09:05:41 [juberti]
martin: tracks
09:06:19 [juberti]
jesup: a few questions about black/silence
09:06:34 [juberti]
jesup: what info is leaked through these aforementioned black frames?
09:06:56 [juberti]
jesup: does this leak more than passing nothing?
09:07:10 [juberti]
ekr: here's the upside
09:07:27 [juberti]
ekr: allows JS to get a noaccess stream with no permissions/prompting
09:07:44 [juberti]
can be pushed into video tag, usable for hair check etc
09:08:25 [juberti]
martin: browser can control how much info gets let through
09:09:34 [juberti]
ekr: you could use this for checking all cameras
09:09:40 [jmr]
jmr has joined #webrtc
09:09:43 [juberti]
jesup: do something, camera will come on, no permission
09:10:49 [juberti]
ekr: hence more creepy
09:11:53 [juberti]
juberti: this seems hard to explain to a user
09:12:16 [juberti]
juberti: cam comes on, no permissions, but they we need to give permissions to start sending the video
09:12:50 [juberti]
someone (sorry): this could be an implementation decision
09:13:07 [dom]
[so to clarify, we're trying to figure out if we can make a reasonable UI that would make the noaccess feature realistically usable, right?]
09:13:10 [juberti]
rbarnes: I think we want a common permissions model across apps
09:13:20 [ekr]
dom: well, sort of.
09:13:22 [juberti]
(and browsers)
09:13:22 [stefanh]
09:13:31 [silvia]
silvia has joined #webrtc
09:14:04 [dom]
[I don't think we should spend ages discussing specific UI ideas directly; figuring out whether the feature is realistic sounds relevant though]
09:14:51 [juberti]
ekr: main thing this gives you is in-content device selection.
09:15:13 [juberti]
ekr: do we care about this? if not, we can do something else.
09:15:42 [juberti]
if we don't do this, user has no way to make an informed choice on this.
09:16:15 [stefanh]
we could have the browser display info (thumbnail) in browser chrome
09:16:47 [juberti]
We can't have two prompts - too complicated - so any device selection must be done either in chrome or when user gives access to all devices.
09:17:28 [juberti]
FF UI asks you to pick a camera, but you can't change it later.
09:18:26 [juberti]
pthatcher: doorhanger could indicate the available cameras.
09:19:00 [juberti]
martin: example of plugin dialog in firefox
09:19:42 [juberti]
jesup: not so sure. so in hair check scenario, what happens?
09:19:48 [jib]
jib has joined #webrtc
09:20:09 [juberti]
martin: protected from sampling by noaccess stuff
09:20:24 [juberti]
ekr: secure from design, but not necess from UX
09:21:25 [dom_proj_]
dom_proj_ has joined #webrtc
09:21:28 [juberti]
juberti: this seems dangerous. if we make a mistake, we will be very unhappy.
09:21:50 [dom_]
dom_ has joined #webrtc
09:23:33 [juberti]
jesup: people won't expect the camera light to come on?
09:24:05 [juberti]
pthatcher: when user is prompted
09:24:41 [juberti]
pthatcher: they can get an allow/deny dialog, plus a preview button that would let the page display the video without granting access
09:25:09 [juberti]
jesup: can we have promotions from preview to allow?
09:25:42 [Zakim]
09:25:44 [juberti]
juberti: i still think this is hard for users to understand
09:26:09 [stefanh]
agree to juberti
09:26:26 [hta]
action martin: drive discussion with ekr and pthatcher about permissions model (brainstorm)
09:26:26 [trackbot]
Created ACTION-107 - Drive discussion with ekr and pthatcher about permissions model (brainstorm) [on Martin Thomson - due 2013-11-19].
09:27:02 [juberti]
dom: working on setting up testing meeting
09:27:24 [juberti]
if you are interested, now is a good time to get involved
09:28:00 [juberti]
ekr: testing this stuff is kind of tricky, hard to verify audio and video, needs permissions bypass
09:28:23 [juberti]
dom: want to avoid duplication of effort
09:28:31 [juberti]
google is working on avoiding test harness
09:28:46 [juberti]
<-- forget what i just wrote
09:29:17 [juberti]
google wants to cooperate on test harness
09:29:22 [ekr]
google would rather not test?
09:29:37 [juberti]
juberti: no, just too tired to write properly
09:29:53 [juberti]
hta: google folks are working on incorporating w3c tests into google tests
09:30:01 [juberti]
not sure which harness will run where
09:30:08 [juberti]
but that is the purpose of the work
09:30:29 [juberti]
if we promise to make tests and make sure they continue working, we want them to run on our bot system
09:30:58 [juberti]
if we can get together and figure out how to make the same tests work on moz and chrome, that would be a Good Thing.
09:31:37 [juberti]
ekr: we should include NATs as part of this
09:31:52 [juberti]
juberti: sure. but how far do we go on this? do we test Chrome's proxy detection?
09:33:16 [juberti]
juberti: we have a bunch of testing facilities that make this all easier. we just want to make sure the w3c tests work in our test rig.
09:33:41 [juberti]
ekr: that's the only thing that makes sense.
09:33:51 [juberti]
cullen: sipit interop testing coming up on monday.
09:34:01 [dom]
ACTION: Dom to coordinate testing questions before a dedicated meeting
09:34:01 [trackbot]
Created ACTION-108 - Coordinate testing questions before a dedicated meeting [on Dominique Hazaël-Massieux - due 2013-11-19].
09:34:07 [ijongcheol]
ijongcheol has joined #webrtc
09:34:09 [juberti]
not automated, alas, but very in-depth
09:34:13 [stephane_]
stephane_ has joined #webrtc
09:37:30 [juberti]
hta: we covered a lot of things over the past two days
09:38:05 [juberti]
and recorded a lot of new actions
09:38:21 [juberti]
and uncovered a lot of new issues
09:38:29 [juberti]
but the flow here was not what we wanted
09:38:46 [juberti]
the interactions in a satellite meeting was not good.
09:38:49 [jmr]
09:40:10 [juberti]
there were various scheduling difficulties that led to this, but we are sorry about the experience.
09:40:11 [Zakim]
09:40:56 [juberti]
stefanh: i want to apologize to everyone who traveled here
09:41:23 [juberti]
dom: this all works better when things are all in the same place
09:41:30 [yusuke_]
yusuke_ has joined #webrtc
09:41:52 [juberti]
jesup: when we did the interim meeting connecting to Stockholk, things were much better; because connectivity was much better.
09:43:53 [fluffy]
fluffy has left #webrtc
09:44:30 [juberti]
we will do better next time.
09:44:44 [Zakim]
- +
09:44:46 [Zakim]
UW_WebRTC()7:00PM has ended
09:44:46 [Zakim]
Attendees were +1.267.934.aaaa, +, jib, Jim_Barnett, +, +
09:52:41 [ken_]
ken_ has joined #webrtc
09:54:35 [ken]
ken has joined #webrtc
09:56:15 [silvia]
silvia has joined #webrtc
09:59:17 [adam]
adam has joined #webrtc
10:02:56 [frodek]
frodek has joined #webrtc
10:03:00 [frodek]
frodek has left #webrtc
10:15:45 [silvia]
silvia has joined #webrtc
10:21:59 [ken]
ken has joined #webrtc
10:22:38 [ken]
ken has joined #webrtc
10:31:04 [ken_]
ken_ has joined #webrtc
10:37:11 [ken]
ken has joined #webrtc
10:55:46 [silvia1]
silvia1 has joined #webrtc
11:37:43 [ken]
ken has joined #webrtc
12:38:13 [ken]
ken has joined #webrtc
13:32:53 [chris]
chris has joined #webrtc
13:38:43 [ken]
ken has joined #webrtc
14:27:18 [lgombos]
lgombos has joined #webrtc
14:39:13 [ken]
ken has joined #webrtc
15:04:38 [Josh_Soref]
Josh_Soref has joined #webrtc
15:08:47 [ken]
ken has joined #webrtc
15:08:52 [timeless]
timeless has joined #webrtc
15:10:32 [lgombos]
lgombos has joined #webrtc
15:39:29 [ken_]
ken_ has joined #webrtc
15:40:17 [lgombos]
lgombos has joined #webrtc
15:55:26 [ken]
ken has joined #webrtc
16:05:21 [fluffy]
fluffy has joined #webrtc
16:21:56 [mreavy]
mreavy has joined #webrtc
16:24:51 [Zakim]
Zakim has left #webrtc
16:54:45 [ken]
ken has joined #webrtc
17:25:16 [ken]
ken has joined #webrtc
17:39:05 [lgombos]
lgombos has joined #webrtc
17:46:56 [lim]
lim has joined #webrtc
17:48:02 [lim]
lim has left #webrtc
18:26:32 [jesup]
jesup has joined #webrtc
18:53:54 [hta]
hta has joined #webrtc
19:18:40 [jib]
jib has joined #webrtc
19:30:34 [ken]
ken has joined #webrtc
19:33:16 [adam]
adam has joined #webrtc
20:01:31 [hta]
hta has joined #webrtc
20:14:45 [lgombos]
lgombos has joined #webrtc
20:31:04 [ken]
ken has joined #webrtc
20:49:32 [feross]
feross has joined #webrtc
21:31:35 [ken]
ken has joined #webrtc
22:15:17 [lgombos_]
lgombos_ has joined #webrtc
22:15:27 [lgombos]
lgombos has joined #webrtc
22:25:53 [lim]
lim has joined #webrtc
22:32:04 [ken]
ken has joined #webrtc
23:13:18 [ken]
ken has joined #webrtc
23:13:48 [silvia]
silvia has joined #webrtc
23:17:16 [ken]
ken has joined #webrtc
23:22:23 [feross]
feross has joined #webrtc
23:38:11 [silvia1]
silvia1 has joined #webrtc