IRC log of webrtc on 2012-10-29

Timestamps are in UTC.

07:37:17 [RRSAgent]
RRSAgent has joined #webrtc
07:37:17 [RRSAgent]
logging to
07:37:19 [trackbot]
RRSAgent, make logs world
07:37:19 [Zakim]
Zakim has joined #webrtc
07:37:21 [trackbot]
Zakim, this will be RTC
07:37:21 [Zakim]
ok, trackbot, I see UW_Web RTC()3:00AM already started
07:37:22 [trackbot]
Meeting: Web Real-Time Communications Working Group Teleconference
07:37:22 [trackbot]
Date: 29 October 2012
07:37:53 [stefanh]
zakim, call rhone_1
07:37:53 [Zakim]
ok, stefanh; the call is being made
07:38:34 [Zakim]
- +44.190.881.aaaa
07:38:36 [Zakim]
UW_Web RTC()3:00AM has ended
07:38:36 [Zakim]
Attendees were +44.190.881.aaaa
07:39:06 [stefanh]
zakim, call Rhone_1
07:39:06 [Zakim]
ok, stefanh; the call is being made
07:39:07 [Zakim]
UW_Web RTC()3:00AM has now started
07:39:08 [Zakim]
07:39:38 [stefanh]
zakim, who is on
07:39:38 [Zakim]
I don't understand 'who is on', stefanh
07:39:53 [Zakim]
+ +44.190.881.aaaa
07:39:53 [stefanh]
zakim, who is on the phone
07:39:53 [Zakim]
I don't understand 'who is on the phone', stefanh
07:40:11 [Hidetoshi]
Hidetoshi has joined #webrtc
07:40:12 [hta]
zakim, who is on?
07:40:12 [Zakim]
I don't understand your question, hta.
07:40:21 [stefanh]
zakim, who is on the phone?
07:40:21 [Zakim]
On the phone I see Rhone_1, +44.190.881.aaaa
07:42:00 [anant]
anant has joined #webrtc
07:42:01 [gmandyam]
gmandyam has joined #webrtc
07:42:32 [frodek]
frodek has joined #webrtc
07:42:57 [AndyHutton]
Andy Hutton is on the phone
07:43:45 [richt]
richt has joined #webrtc
07:46:07 [burn]
burn has joined #webrtc
07:46:32 [fluffy]
fluffy has joined #webrtc
07:46:44 [martin]
martin has joined #webrtc
07:47:08 [ekr]
ekr has joined #webrtc
07:47:19 [tomoyuki]
tomoyuki has joined #webrtc
07:47:23 [adambe]
adambe has joined #webrtc
07:47:40 [SungOk_You_]
SungOk_You_ has joined #webrtc
07:47:43 [kotakagi]
kotakagi has joined #webrtc
07:47:43 [adambe]
hta: the best use of face-to-face time is to be specific
07:48:06 [adambe]
...: people pay more attention campared to mailing lists
07:48:16 [adambe]
... we've tried to make the agenda specific
07:48:41 [adambe]
... we might go with presenters proposal
07:49:07 [adambe]
... there also be discussions
07:50:06 [adambe]
... we should record off-topic topics and move them to the AOB session
07:50:15 [dom]
dom has joined #webrtc
07:50:23 [adambe]
stefanh: fist session is about API functionality we haven't addressed yet
07:50:41 [adambe]
... this might be the least concrete item on the agenda
07:50:42 [dom]
RRSAgent, pointer?
07:50:42 [RRSAgent]
07:50:53 [adambe]
... what de we need to do now and what can we postpone
07:50:56 [dom]
Topic: API functionalities missing in PeerConnection API
07:51:16 [adambe]
... API topics
07:51:27 [adambe]
... width, hegiht sent over a PeerConnection
07:51:33 [dom]
i/<adambe> hta:/scribenick: adambe
07:51:35 [adambe]
... priority
07:51:43 [adambe]
... is media flowing?
07:51:44 [dom]
Zakim, who's on the phone?
07:51:44 [Zakim]
On the phone I see Rhone_1, +44.190.881.aaaa
07:51:52 [adambe]
... how much bandwith is used
07:52:00 [adambe]
... how much can be used
07:52:08 [adambe]
... how to reject media streams
07:52:13 [adambe]
... echo control
07:52:21 [adambe]
... one thing missing on the slides
07:52:28 [adambe]
... should we support security descriptions
07:52:52 [dom]
Present+ adambe, hta, stefanh, derf, burn, dan_druta, richt, anant, dom, juberti, jim, matthew, ekr, fluffy
07:52:53 [matthew]
matthew has joined #webrtc
07:52:58 [adambe]
(a use case is presented)
07:53:16 [adambe]
... one peer sends video with two different resolutions to two other peers
07:53:23 [adambe]
... are people ok with this?
07:53:30 [adambe]
fluffy: we should support this
07:53:48 [adambe]
burn: you're showing the entrence and the consumer side
07:53:51 [adambe]
stefanh: yes
07:54:36 [adambe]
hta: there are multiple ways to achive this reuslt
07:54:51 [adambe]
... first question is.. do we need to support this?
07:54:59 [adambe]
... the answer is yes
07:55:05 [adambe]
... then how should we solve it
07:55:14 [adambe]
stefanh: this is the most difficult slide in my deck
07:55:33 [adambe]
... application knows about the receiving side
07:55:50 [adambe]
... or the receiving side could tell the sender
07:56:03 [DanD]
DanD has joined #webrtc
07:56:03 [adambe]
... third possibilty is that the app isn't involved
07:56:39 [fluffy]
07:56:41 [fluffy]
07:56:50 [ekr]
07:56:52 [adambe]
matthew: even if the receiver is involved the sender needs to be involved
07:57:09 [adambe]
justin: there needs to be some higher limit
07:57:26 [adambe]
matthew: there might be a lot of contstraints
07:57:38 [dom]
ack fluffy
07:57:49 [adambe]
fluffy: this is one of the reasons we need constraints
07:58:05 [adambe]
stefanh: we shouldn't modify the sdp unless we have very good reasons
07:58:06 [juberti]
juberti has joined #webrtc
07:58:17 [dom]
ack ekr
07:58:18 [adambe]
hta: we currently don't use a speakers queue
07:58:44 [adambe]
ekr: what do we expect to happen if the receiver asks for a different aspect ratio
07:58:58 [adambe]
... should the PeerConnection rescale
07:59:01 [adambe]
07:59:32 [adambe]
justin: the sender might need to chose the closest thing
08:00:11 [adambe]
hta: we want people to separate the case where you really require something compared to the case where you really can't live without something
08:00:24 [matthew]
side comment: generally we either need to fully specify the SDP the is used to negotiate things like this OR we need contraints. unfortunately when there's contraints, we *also* need to fully specify the SDP that flows between them... unless we choose to have it *only* be an API issue ("direct manipulation" vs. "constraint setting")
08:00:47 [adambe]
hta: is the sending app or sending PeerConnection informe
08:01:15 [adambe]
08:01:53 [dom]
Present+ Magnus
08:02:37 [adambe]
justin: information about the consumer dimensions could be sent as a session description
08:03:08 [adambe]
fluffy: the connection to the video tag is interesting
08:03:30 [adambe]
... would it be reasonable to adjust the send size to the consumer size?
08:03:49 [adambe]
... this was a driver for renegotiation callback
08:04:39 [DanD]
DanD has joined #webrtc
08:04:44 [adambe]
martin: you don't have the consumer in the initial negotiation
08:04:52 [adambe]
fluffy: it's not always true
08:05:00 [dan_romascanu]
dan_romascanu has joined #webrtc
08:05:08 [Jim_Barnett]
Jim_Barnett has joined #webrtc
08:05:39 [Bo_Chen]
Bo_Chen has joined #WebRTC
08:05:58 [adambe]
derf: css also impacts this
08:06:16 [Bo_Chen]
Bo_Chen has left #webrtc
08:06:19 [adambe]
fluffy: a video tag might be specified with a size or not
08:07:08 [adambe]
stefanh: there could be several video tags that wants to affect the sender side
08:07:26 [adambe]
hta: there's a ultimate fallback video size
08:07:45 [adambe]
burn: smart browsers might behave differently
08:08:30 [adambe]
matthew: smart browser decisions must be overidden if the developer wants to do something else
08:09:28 [adambe]
burn: if we have an API then the browser must take input from the API into account... otherwise the browser can do its magic
08:09:36 [adambe]
stefanh: what is the conclusion?
08:10:22 [adambe]
... the receiving side can influence, but we also need an API to let the developer tweak
08:11:13 [adambe]
ekr: do we want information from the receiver to bubble back all the way to the camera on the sender side?
08:11:38 [gape]
gape has joined #webrtc
08:12:14 [adambe]
burn: a browser can use any valid value in a contraint range
08:12:38 [adambe]
matthew: if several consumers (local, remote).. who wins?
08:13:24 [kensaku]
kensaku has joined #webrtc
08:14:17 [adambe]
ekr: some constrains are enforced when set and some constrains seems to be enforced continiously
08:14:17 [kensaku]
kensaku has left #webrtc
08:14:47 [dom]
dom has joined #webrtc
08:14:53 [kensaku_]
kensaku_ has joined #webrtc
08:15:09 [adambe]
burn: we might need a constraints that says "do not change video size"
08:15:59 [adambe]
stefanh: recap on proposed conclusion
08:16:26 [adambe]
... receiving side as driver with an API for the app to influence
08:16:37 [adambe]
matthew: there's two ways to implement this
08:17:26 [adambe]
fluffy: we don't know if we'll use RTCP or SDP to negotiate video size
08:17:54 [adambe]
matthew: even if we go with RTCP we need an API to influence how the browser should behave
08:18:10 [adambe]
stefanh: let's move on
08:18:27 [adambe]
... next slide
08:18:47 [adambe]
... if the receiver detaches a stream from the consumer.. what should happen,
08:18:49 [adambe]
08:19:20 [adambe]
ekr: what if sender offers something that the receiver doesn't want?
08:19:28 [adambe]
stefanh: we'll get to that in a later slide
08:20:42 [adambe]
fluffy: we have two operations.. mute (undetectable from the sender side) and to say "don't send me packets"
08:22:01 [adambe]
justin: how do you say that I only want a subset of the offered set of streams
08:22:21 [adambe]
... we don't have a good way to express that today
08:23:07 [adambe]
stefanh: next slide
08:23:19 [adambe]
... requeseting a certain bandwith
08:23:37 [adambe]
... there's an IETF draft talking about this
08:24:28 [adambe]
DanD: I propose a priority param to addStream()
08:25:58 [adambe]
... we can discuss how the priority information should be handeled but we should decide on a mechanism to specify the intent
08:26:40 [sakih]
sakih has joined #webrtc
08:26:44 [adambe]
stefanh: addStream() is only called once per stream, it's a problem
08:27:07 [adambe]
DanD: we're the right group to specify the priority intent
08:27:19 [adambe]
burn: intent means it might not happen
08:27:27 [martin]
hmm...s/constraint/intent/g ?
08:27:39 [ekr]
08:27:42 [ekr]
08:27:50 [martin]
that works too
08:28:15 [matthew]
there's a difference between "preferences" and "absolute limits"
08:28:35 [matthew]
i "prefer" 720P, but there's no way i ever want >2560 horizontal pixels
08:28:45 [burn]
no, constraint != intent
08:28:56 [adambe]
DanD: at least the browser sholud be able to say that I marked you packets in a certain way
08:29:22 [burn]
intent == hint, discussions about hints lead to a decision to support both mandatory and optional constraints
08:29:25 [matthew]
if you just go with direct manipulation then the API only has "settings", and the difference between "constraint" and "preference" is JS code
08:30:17 [matthew]
but the moment you let the two ends talk to each other via possibly-unmodified SDP blobs then you need places on the monster where it can be poked with a stick
08:30:18 [adambe]
Göran: we should describe this case in more detail
08:31:41 [adambe]
... can the network trust the diff-serv code points set by the app
08:31:53 [adambe]
fluffy: in some environment you can't
08:32:09 [adambe]
... they might provide information
08:32:17 [adambe]
... but a separate request is needed to verify
08:32:43 [DanD]
DanD has joined #webrtc
08:32:50 [adambe]
Göran: we need more discussion around use cases
08:34:04 [adambe]
fluffy: I think this should be a topic for the AoB section
08:34:17 [adambe]
(people agree)
08:34:32 [yahui]
yahui has joined #webrtc
08:34:53 [dom]
dom has joined #webrtc
08:34:53 [adambe]
hta: new topic - Security for Qos flow labels
08:35:48 [adambe]
ekr: there might be two API surfaces needed: tie constraints to media flow, (missed the other one)
08:36:19 [adambe]
DanD: I wan't a request that should be handeled by the trusted environment
08:36:50 [BoHu_ChinaUnicom]
BoHu_ChinaUnicom has joined #webrtc
08:37:15 [npdoty]
npdoty has joined #webrtc
08:37:45 [adambe]
matthew: even if diff-serv cps isn't supported a system may enforce priority anyhow (we need to support this case as well)
08:38:49 [adambe]
hta: new topic for AoB - Control of the DSCP interface
08:39:00 [adambe]
stefanh: next slide
08:39:03 [Suresh]
Suresh has joined #webrtc
08:39:08 [adambe]
... other side of the same coin
08:39:22 [adambe]
... feedback on bw..
08:39:57 [adambe]
martin: I thin we need generic feedback on constraints set
08:40:16 [sakkuru_]
sakkuru_ has joined #webrtc
08:40:28 [adambe]
... there might be existing mechanisms
08:40:39 [adambe]
... for others we might need to add something
08:41:31 [adambe]
matthew: e.g., if video has highter priority over slides, the app might want to know if the slides can't be sent at all
08:42:13 [dom]
dom has joined #webrtc
08:42:27 [adambe]
stefanh: next slide
08:42:35 [adambe]
... sender side pause/resume
08:43:03 [adambe]
... we currently have enable/disable on MediaStreamTrack
08:43:11 [adambe]
... every consumer is affected
08:43:31 [adambe]
... we could have enabel/disable on PeerConnection
08:43:53 [adambe]
burn: we don't need that since you could clone media streams
08:44:10 [jmarcon]
jmarcon has joined #webrtc
08:44:18 [yahui]
yahui has joined #webrtc
08:45:08 [adambe]
hta: we implemented enable and disable as affecting the associasion between a stream and track
08:45:49 [yahui_]
yahui_ has joined #webrtc
08:45:59 [adambe]
stefanh: next topic, AGC
08:46:11 [adambe]
fluffy: the text on the slides looks good to me
08:47:25 [martin]
conclusion here was that we don't need to prioritize the agc/noise settings, it's not a preference, it's a setting
08:47:39 [martin]
it might also be necessary to change this on the fly
08:47:41 [adambe]
burn: what happens if you turn AGC on and it's not available
08:47:51 [adambe]
fluffy: it should be a on/off setting
08:47:55 [Wonsuk]
Wonsuk has joined #webrtc
08:48:05 [adambe]
derf: I hope there's a way to enumerate settings
08:48:10 [martin]
we need a way to enumerate settings, for sure
08:48:15 [adambe]
fluffy: we should require that
08:48:19 [cmills]
cmills has joined #webrtc
08:48:35 [juberti_]
juberti_ has joined #webrtc
08:48:52 [martin]
agc/noise is a property of a track
08:48:54 [adambe]
hta: AGC should be on track lever
08:49:02 [adambe]
08:49:09 [adambe]
stefanh: next topic
08:49:14 [adambe]
... rejecting streams
08:49:25 [adambe]
martin: we need to know if multiple streams are offered
08:49:42 [adambe]
... we need basic methods on the session description
08:50:10 [adambe]
derf: example: you offer me 10k streams.. how do I reject
08:51:41 [adambe]
DanD: it's not only if your device can do something.. there's also a question if your service can support this
08:52:18 [adambe]
martin: we need to know what you get before you can say what you want to accept
08:53:29 [adambe]
hta: if we have a mechanisms for the receiver to turn off a stream at any point.. would it be sufficient to turn it off rather than not accepting it?
08:53:53 [kotakagi]
kotakagi has joined #webrtc
08:53:57 [adambe]
matthew: it might be a resource question
08:54:15 [markus]
markus has joined #webrtc
08:54:54 [adambe]
ekr: I interpret it as: you set the remote description and you see what streams are offered
08:55:37 [adambe]
stefanh: is the sending app informed about a rejected streams
08:55:40 [adambe]
... ?
08:56:23 [adambe]
hta: if the use case for rejecting streams is to save resources then the sender needs to know
08:57:00 [adambe]
matthew: it's important how quickly can this be done
08:57:04 [Stephane]
Stephane has joined #webrtc
08:57:17 [adambe]
fluffy: can someone send a proposal to the list?
08:58:02 [dom_]
dom_ has joined #webrtc
09:00:54 [adambe]
(I missed to scribe a lot of stuff while I was talking)
09:01:05 [adambe]
stefanh: next thing - AEC
09:01:27 [adambe]
fluffy: one param you need is what's going to the speakers
09:01:39 [martin]
new issue that is related to this, and one that I will bring up later when we talk about this: SDP describes RTP sessions. The one m= section can have multiple tracks. How do we learn of these other than just waiting for arrival of packets on one of those?
09:02:18 [hta]
adambe said: I sent a proposal to the list with inbound and outbound streams as different objects, which might make this discussion easier; missed having feedback on that.
09:03:12 [matthew]
another issue that's related to the last slide and not yet decided (and different in different implementations) is what to offer/send before user consent on a sending device occurs. one approach is to say "recvonly" and change to "sendrecv" when the consent happens, the other is to say "sendrecv" and send muted audio + black video until consent is received. recvonly->sendrecv takes the extra round trip to enable.
09:03:17 [adambe]
(scribe is missing a lot of stuff here)
09:03:33 [adambe]
burn: why do we need API for this?
09:03:41 [adambe]
fluffy: you might want to turn it off
09:03:53 [adambe]
burn: could this be a browser control?
09:04:16 [adambe]
someone: music is a use case where you wan't to turn EC off
09:04:44 [adambe]
matthew: broadcast is also a use case where you want to turn AEC off
09:05:39 [adambe]
martin: if the browser and user wants differents things, the user setting should win
09:06:36 [adambe]
stefanh: final slide - SDES
09:06:52 [adambe]
... wait until RTCWeb has discussed this
09:06:54 [adambe]
ekr: yes
09:07:10 [adambe]
stefanh: that was easy
09:07:37 [adambe]
stefanh: summary slide
09:09:10 [adambe]
martin: you could get two different tracks - one with AEC and one without
09:10:34 [dsinger]
dsinger has joined #webrtc
09:11:53 [adambe]
hta: new AoB (MC TF) to topic - Multiple open of camera/mic?
09:12:24 [adambe]
martin: AGC, NR should be fairly simple
09:12:57 [adambe]
burn: rather than doing this right now we should sumarize what we have decided the last hour and update the summary
09:13:23 [adambe]
hta: there are things that needs to be discussed and some that just can be edited in
09:13:31 [adambe]
Acoustic Echo Cancellation
09:13:34 [DanD]
DanD has joined #webrtc
09:13:56 [adambe]
stefanh: we're 15 minutes before schedule
09:14:41 [tomoyuki]
tomoyuki has joined #webrtc
09:16:44 [anant]
anant has joined #webrtc
09:17:27 [markus]
coffee break
09:18:47 [juberti_]
juberti_ has joined #webrtc
09:19:42 [Hidetoshi]
Hidetoshi has left #webrtc
09:19:48 [kotakagi]
kotakagi has joined #webrtc
09:19:48 [hta]
hta has joined #webrtc
09:31:34 [tomoyuki]
tomoyuki has joined #webrtc
09:36:57 [tomoyuki]
tomoyuki has joined #webrtc
09:37:49 [dom]
dom has joined #webrtc
09:38:53 [Zakim]
09:39:11 [juberti_]
juberti_ has joined #webrtc
09:39:51 [hta]
zakim, who is on?
09:39:51 [Zakim]
I don't understand your question, hta.
09:39:57 [hta]
zakim, who is on the phone?
09:39:57 [Zakim]
On the phone I see +44.190.881.aaaa
09:40:01 [anant]
anant has joined #webrtc
09:40:51 [hta]
anyone remote actually here?
09:41:24 [stefanh]
zakim, call Rhone_1
09:41:24 [Zakim]
ok, stefanh; the call is being made
09:41:25 [Zakim]
09:41:41 [burn]
burn has joined #webrtc
09:43:49 [Stephane]
Stephane has joined #webrtc
09:49:24 [jinhong]
jinhong has joined #webrtc
09:50:10 [markus]
getting started, markus is the scribe
09:50:31 [markus]
topic - SDP
09:50:50 [markus]
fluffy showing slides
09:51:00 [Hidetoshi]
Hidetoshi has joined #webrtc
09:51:16 [Ruinan]
Ruinan has joined #webrtc
09:52:09 [markus]
issues: what SDP do createOffer and createAnswer create and how they can be manipulated before passing them back to the browser
09:52:41 [tomoyuki]
tomoyuki has joined #webrtc
09:53:01 [DanD]
DanD has joined #webrtc
09:53:46 [markus]
matthew: some changes are ok from SDP syntax perspective but not for the browser to act upon
09:53:49 [frodek]
frodek has joined #webrtc
09:54:27 [markus]
goals: clear definition of SDP and error handling rules
09:55:45 [adambe]
adambe has joined #webrtc
09:56:23 [markus]
how are new ICE candidates added to the set SDP
09:57:29 [markus]
Matthew: when I ask which SDP is in use is it the one I have set or can it be something slightly different?
09:58:09 [gmandyam]
gmandyam has joined #webrtc
09:58:20 [markus]
constraints: can be used to enable common use cases, but do not solve what can be changed
09:58:28 [nsakai]
nsakai has joined #webrtc
09:58:32 [dom]
s/topic - SDP/topic: SDP handling/
09:59:15 [markus]
burn: constraints can affect what SDP gets generated in the first place so it does not need to be modified anymore
09:59:41 [Zakim]
09:59:53 [Zakim]
- +44.190.881.aaaa
09:59:55 [Zakim]
UW_Web RTC()3:00AM has ended
09:59:55 [Zakim]
Attendees were Rhone_1, +44.190.881.aaaa
10:00:08 [markus]
(remote audio dropped)
10:00:21 [kotakagi]
kotakagi has joined #webrtc
10:00:31 [Zakim]
UW_Web RTC()3:00AM has now started
10:00:39 [Zakim]
+ +44.190.881.aaaa
10:00:40 [jinhong]
jinhong has joined #webrtc
10:01:05 [markus]
fluffy: the place to define SDP use is in the JSEP draft - latest draft has a start
10:01:40 [AndyHutton]
remote audio not working
10:02:03 [dom]
Zakim, call rhone_1
10:02:03 [Zakim]
ok, dom; the call is being made
10:02:05 [Zakim]
10:03:42 [markus]
matthew: state transitions need to be taken into account, can't call everything multiple times
10:05:45 [markus]
wbat ca
10:06:14 [matthew]
specifically, setRemoteDescription("answer") is restricted to only-call-once even though we are saying that enforcement of these transitions is up to the JS
10:06:15 [markus]
what can be changed between create* and setLocal/Remote
10:06:37 [markus]
use cases: remove codec, change bw limit etc.
10:07:05 [markus]
justin: enable/disable bundle is one case
10:07:42 [markus]
adam: rejecting audio, getting video - is that with munging SDP?
10:08:02 [markus]
fluffy: no, if we have explicit API then don't use SDP mungling
10:08:28 [markus]
matthew: have a detailed set of cases
10:09:18 [tomoyuki]
tomoyuki has joined #webrtc
10:09:28 [markus]
fluffy: grouping of cases:
10:10:40 [markus]
fluffy: don't do RTCP mux via settings, not SDP
10:11:00 [markus]
matthew: ptime for codecs
10:11:12 [markus]
matthew: want to fix it
10:12:26 [jmarcon]
jmarcon has joined #webrtc
10:12:37 [markus]
matthew: will take my cases to the list
10:14:04 [markus]
several people agree most things being discussed should be done via other mechanisms than changing SDP
10:14:55 [dsinger]
dsinger has joined #webrtc
10:15:10 [markus]
burn: nervous about limiting too much what in SDP can be modified
10:16:46 [markus]
fluffy: changing SDP on the way between browsers can be done flexibly, changing between create* and set* in the same browser more limited
10:17:16 [Bo_Chen]
Bo_Chen has joined #WebRTC
10:17:58 [markus]
justin: don't understand why there is big difference between different manipulation "loops"
10:19:37 [wseltzer]
wseltzer has joined #webrtc
10:20:00 [markus]
fluffy: positive list of what can be changed is needed, not the list of what can't be
10:20:47 [markus]
provide a list of changeable things that is *guaranteed* to work
10:21:11 [kensaku]
kensaku has joined #webrtc
10:21:17 [markus]
matthew: errors need to be specific on what is wrong
10:21:52 [sakkuru]
sakkuru has joined #webrtc
10:22:06 [markus]
argument over what the current spec (JSEP?) says...
10:23:26 [markus]
burn: many kinds of modifications will be needed before sending SDP out
10:23:44 [tlr]
tlr has joined #webrtc
10:23:55 [markus]
burn: what you send out does not match with what you set with setLocal?
10:24:14 [ekr]
who was speaking?
10:24:43 [stefanh]
stefanh has joined #webrtc
10:25:05 [markus]
matthew: jsep-02 has fixed the ice password issue
10:25:40 [markus]
fluffy: need to have the use cases that motivate changes
10:26:30 [markus]
justin: needs coming up in the future anyway...
10:27:40 [Wonsuk]
Wonsuk has joined #webrtc
10:27:44 [markus]
how much and what state does createOffer create? devices with HW codecs?
10:28:02 [matthew]
jsep-02 fixed the "createOffer is optional" language, though whether or not createOffer creates state is true or not is questionable
10:28:36 [tomoyuki]
tomoyuki has joined #webrtc
10:28:46 [Suresh]
Suresh has joined #webrtc
10:29:11 [ekr]
matthew: though, there's clearly an implication of that b/c of the validity window of the offer.
10:29:23 [ekr]
i.e. during the callback.
10:30:09 [matthew]
10:31:00 [markus]
martin: set down the list of things that MUST be possible to change
10:31:12 [markus]
burn: is everything else MUST reject?
10:31:25 [markus]
people have different interpretations...
10:33:13 [markus]
explicit list of things that MUST be changeable, explicit list of things that MUST not be changed and what falls in between the browser need to explicitly error report if it won't support it
10:33:28 [martin]
there is a list of things that we MUST be able to change; there is a list of things that MUST NOT be able to change, which trigger an error; everything else the browser MUST either accept or reject with an error
10:33:35 [matthew]
silent failure is incompatible with the assert on the 2nd slide. either the browser fires an error (invalidating the assert) or it is lying to you in order to make that assert.
10:34:20 [markus]
the above three comments (markus, martin, matthew) try to record the consensus in the meeting
10:35:58 [hsivonen]
hsivonen has joined #webrtc
10:36:10 [markus]
AndyHutton: Configuration/settings? how do they relate to the MUST, MUST NOT, ...
10:36:44 [markus]
fluffy: start with the list of use cases to get the MUST-be-changeable list
10:37:39 [Milan_Patel]
Milan_Patel has joined #webrtc
10:37:56 [markus]
matthew: listing MUST-items...
10:38:24 [markus]
cullen taking notes...
10:38:58 [markus]
adam: we will have APIs for some of these things anyway
10:39:17 [Jim_Barnett]
Jim_Barnett has joined #webrtc
10:40:44 [kotakagi]
kotakagi has joined #webrtc
10:40:56 [kotakagi2]
kotakagi2 has joined #webrtc
10:41:40 [markus]
fluffy: if we have an API to control what createO/A gives, is that not enough, do we still need to change SDP for those "features"
10:41:59 [markus]
justin, matthew: there may be cases where SDP change is still needed
10:43:11 [markus]
fluffy: use cases are still not clear
10:45:03 [markus]
burn: do not worry about MUST-list anymore because anything on the MUST NOT list can still work...
10:46:52 [markus]
still sensing consensus on having three lists: 1. MUST be changeable, 2. MUST NOT be changeable, 3. (default) Browser MUST give an error if it does not support it
10:47:34 [markus]
fluffy: next issue
10:47:51 [markus]
when can two different video flows use the same m-line
10:48:38 [markus]
Proposal: all codec parameters are the same, "content-label" is the same, are in same MediaStream
10:50:57 [Stephane]
Stephane has joined #webrtc
10:51:04 [markus]
(hta, fluffy, martin debate the details)
10:54:14 [markus]
next: How does createOffer know to offer receiveOnly flow?
10:55:11 [markus]
want to receive video but don't have video camera
10:57:20 [kotakagi]
kotakagi has joined #webrtc
10:57:46 [markus]
justin has a proposal, mind to write it down here?
10:59:56 [markus]
matthew: can you put "send" in SDP before getting user consent?
11:02:17 [markus]
or do you first have to use receiveOnly and add sendReceive on a separate O/A
11:07:21 [markus]
ekr: how do we correlate multiple offered video m-lines to the multiple video streams the answerer has
11:10:06 [Milan_Patel]
Milan_Patel has joined #webrtc
11:12:42 [markus]
next topic: how does createOffer decide to offer a data channel?
11:13:44 [markus]
should OfferToExchangeData constraint be added?
11:14:35 [markus]
matthew: data is a great idea, but SCTP is horrible.
11:14:53 [markus]
fluffy: take this to the IETF
11:15:05 [markus]
tim: SCTP was decided in Feb
11:15:50 [Wonsuk]
Wonsuk has left #webrtc
11:15:56 [ekr]
matthew: how do you really feel about SCTP?
11:16:30 [dsinger]
dsinger has joined #webrtc
11:17:15 [markus]
DanD: data is easy within a single app, but trapezoid between two apps is more difficult
11:18:04 [markus]
martin: issues could come also if the other device running the "same" app has constraints
11:22:35 [juberti_]
juberti_ has joined #webrtc
11:22:40 [markus]
consensus: don't add this constraint
11:22:49 [markus]
next: DTMF
11:23:06 [markus]
will be discussed tomorrow with a proposal
11:23:35 [markus]
next: How long is SDP from createOffer/Answer valid?
11:24:18 [markus]
matthew: 90 seconds would be an ultimate timeout
11:25:16 [markus]
use case: the SDP is sent to the server for modification
11:27:07 [markus]
should it be valid beyond the duration of the callback function
11:27:38 [markus]
ice candidates etc. time out in matter of 10s of seconds
11:28:54 [markus]
hta: time-to-live for the session description?
11:31:13 [markus]
matthew: can createOffer be called again after getting the modified SDP back from the server?
11:32:54 [markus]
matthew: proposes that createAnswer is valid only for the duration of callback and no longer
11:36:06 [markus]
consensus: it must be valid at least for the duration of the callback function
11:36:42 [markus]
AP ekr to take follow-up to the list
11:37:25 [markus]
slides about rollback and error handling left for now
11:37:50 [Zakim]
- +44.190.881.aaaa
11:37:51 [markus]
(now lunch break until 1:30)
11:47:28 [tomoyuki]
tomoyuki has joined #webrtc
11:50:08 [kensaku]
kensaku has joined #webrtc
12:19:38 [Dini_Martini]
Dini_Martini has joined #webrtc
12:25:15 [Zakim]
+ +44.190.881.aabb
12:26:31 [Zakim]
+ +30210818aacc
12:29:24 [anant]
anant has joined #webrtc
12:34:18 [gmandyam]
gmandyam has joined #webrtc
12:36:22 [tomoyuki]
tomoyuki has joined #webrtc
12:37:35 [hta]
hta has joined #webrtc
12:38:05 [Hidetoshi]
Hidetoshi has joined #webrtc
12:39:20 [stefanh]
stefanh has joined #webrtc
12:40:29 [Daisuke]
Daisuke has joined #webrtc
12:41:00 [jinhong]
jinhong has joined #webrtc
12:41:16 [kotakagi]
kotakagi has joined #webrtc
12:41:34 [juberti]
juberti has joined #webrtc
12:41:50 [juberti_]
juberti_ has joined #webrtc
12:42:22 [dom]
Topic: Implementation status
12:42:54 [fluffy]
fluffy has joined #webrtc
12:43:05 [fluffy]
Cullen is scribing
12:43:15 [fluffy]
HTA is presenting what crhom is oging
12:43:16 [fluffy]
12:43:24 [matthew]
matthew has joined #webrtc
12:43:43 [burn]
burn has joined #webrtc
12:43:52 [fluffy]
TURN and opus are scheduled to be in M24 all going well
12:44:00 [dsinger]
dsinger has joined #webrtc
12:44:19 [martin]
martin has joined #webrtc
12:44:48 [fluffy]
s/crhom is oging/ chrome is doing /
12:44:56 [fluffy]
DTMF is waiting on this group
12:45:05 [markus]
markus has joined #webrtc
12:45:05 [sungok_you_]
sungok_you_ has joined #webrtc
12:45:38 [fluffy]
Anant has a demo of firefox
12:46:32 [frodek]
frodek has joined #webrtc
12:46:45 [fluffy]
THe demo allows login, gives a list of users, then you can call one of the other users
12:47:35 [fluffy]
Have getusermedia, have peerConnection,
12:47:48 [fluffy]
expectation to not have behind a flag in firefox 19
12:48:03 [fluffy]
currently in firefox 18 in nightly builds behind a flag
12:48:25 [fluffy]
have a fairly complete version of the DataChannel
12:48:43 [fluffy]
showed cool file sharing with drag and drop using DataChannel
12:49:18 [fluffy]
12:49:22 [fluffy]
ICE but no TURN
12:49:39 [fluffy]
prototype of Identity working
12:49:58 [fluffy]
Doing desktop first, then working on mobile
12:50:07 [fluffy]
VP8, opus, and G.711 as codecs
12:50:33 [ekr]
ekr has joined #webrtc
12:51:28 [kensaku]
kensaku has joined #webrtc
12:51:29 [fluffy]
HTA: There was a test web even 2 days ago
12:51:55 [fluffy]
dom: The idea of these is to get lots people to develop and contribute test cases
12:52:02 [fluffy]
… presentation ofn theory of testing
12:52:16 [fluffy]
… Event led to 44 test cases
12:52:54 [dom]
12:53:33 [fluffy]
(wow, I did not realize you said 404 - that is great )
12:54:40 [nsakai]
nsakai has joined #webrtc
12:55:14 [dom]
Topic: General error handling principles
12:56:14 [npdoty]
npdoty has joined #webrtc
12:57:45 [Hidetoshi]
Hidetoshi has joined #webrtc
13:00:04 [Zakim]
13:00:19 [dom]
Zakim, call Rhone_1
13:00:19 [Zakim]
ok, dom; the call is being made
13:00:21 [Zakim]
13:01:02 [sakkuru]
sakkuru has joined #webrtc
13:02:06 [Suresh]
Suresh has joined #webrtc
13:04:21 [sakkuru]
sakkuru has joined #webrtc
13:06:26 [Ruinan_]
Ruinan_ has joined #webrtc
13:07:12 [dan_romascanu]
dan_romascanu has joined #webrtc
13:07:31 [tpacbot]
tpacbot has joined #webrtc
13:12:56 [fluffy]
So decided that invalid_state will be a callback no exception
13:14:10 [dom]
-> Error Types defined in DOM 4
13:14:13 [fluffy]
Decided that for SDP, will add a sdpLineNumber
13:14:19 [Suresh]
Can someone provide the link to Mozilla presentation one error handling?
13:14:40 [AndroUser]
AndroUser has joined #webrtc
13:14:44 [Suresh]
Suresh has joined #webrtc
13:15:07 [Suresh]
can someone provide the link to Mozilla presentation on error handling?
13:22:38 [jmarcon]
jmarcon has joined #webrtc
13:23:51 [gjh]
gjh has joined #webrtc
13:27:16 [fluffy]
decided all errors callbacks will not be optional
13:27:31 [dom]
Topic: Call flows Walk-through
13:31:15 [adambe]
adambe has joined #webrtc
13:31:39 [tomoyuki]
tomoyuki has joined #webrtc
13:34:46 [AndroUser2]
AndroUser2 has joined #webrtc
13:35:46 [kotakagi]
kotakagi has joined #webrtc
13:50:08 [Hidetoshi]
Hidetoshi has joined #webrtc
13:51:05 [adambe]
adambe has joined #webrtc
13:51:24 [jeff]
jeff has joined #webrtc
13:57:24 [burn]
burn has joined #webrtc
13:58:08 [Wonsuk]
Wonsuk has joined #webrtc
14:07:20 [kensaku]
kensaku has joined #webrtc
14:10:09 [jyp]
jyp has joined #webrtc
14:17:56 [sakkuru]
sakkuru has joined #webrtc
14:20:00 [kotakagi]
kotakagi has joined #webrtc
14:31:30 [tomoyuki]
tomoyuki has joined #webrtc
14:31:35 [burn]
burn has joined #webrtc
14:32:45 [martin]
juberti: presenting on states
14:33:18 [fluffy]
fluffy has joined #webrtc
14:33:22 [dom]
Topic: State machines
14:33:57 [npdoty]
npdoty has left #webrtc
14:34:52 [jmarcon]
jmarcon has joined #webrtc
14:35:51 [martin]
martin: does back to gathering happen for moving from "relay" to "all"?
14:36:06 [martin]
juberti: you probably already have all the necessary candidates
14:36:30 [dom]
i/<martin> juberti:/ScribeNick: martin
14:37:26 [martin]
matthew: is there any way to remove candidates?
14:37:37 [martin]
juberti: ice restart
14:38:48 [gmandyam]
gmandyam has joined #webrtc
14:39:47 [martin]
ekr: can we have multiple components with one completed and the other one with no candidates
14:40:02 [martin]
juberti: we are in checking until all components have resolved
14:41:02 [martin]
fluffy: checking encompasses frozen
14:42:14 [martin]
matthew: restart doesn't affect active flows
14:42:21 [martin]
juberti: yes
14:43:23 [martin]
matthew: why not just describe each of the states as they relate to the underlying states
14:43:41 [martin]
fluffy: this is part of what I prepared for the last call on this topic and we rejected that
14:45:04 [tpacbot]
tpacbot has joined #webrtc
14:45:26 [martin]
hta: there is no harm in playing audio while video is failing and restarting
14:45:37 [tomoyuki]
tomoyuki has joined #webrtc
14:45:50 [martin]
hta: is there any difference betwen connected and completed?
14:47:24 [martin]
juberti: middleboxes might require the updated offer that would be triggered from the completed transition
14:49:06 [tpacbot]
tpacbot has joined #webrtc
14:52:07 [martin]
martin: is this application driven or not, can the browser add new candidates and contine?
14:52:29 [martin]
juberti: restart is required by RFC 5245
14:52:42 [martin]
fluffy: the application is going to need to be involved
14:52:58 [martin]
juberti: if you get a new NIC (e.g. WiFi) you might just trickle that
14:53:24 [martin]
hta: transitions to starting are tied to user actions
14:54:42 [martin]
martin: how does the new WiFi candidate fit into this?
14:55:08 [martin]
juberti: that would trigger a transition to connected
14:56:00 [ekr]
ekr has joined #webrtc
14:56:01 [martin]
fluffy: there is an implication that disconnected might transition to failed, in the case where you were connected and you disconnect then something failed
14:57:21 [tpacbot]
tpacbot has joined #webrtc
14:57:42 [martin]
juberti: proposes changing name of "starting" to "noo"
14:59:20 [tpacbot]
tpacbot has joined #webrtc
15:01:02 [hta]
IceConnectState -> IceConnectionState
15:01:07 [martin]
juberti: remove onicegatheringchange, and provide just onicecandidate to fire when the gathering state is changed
15:01:42 [tpacbot]
tpacbot has joined #webrtc
15:01:53 [martin]
derf: propose to rename iceConnectState to iceConnectionState or something
15:02:03 [tpacbot]
tpacbot has joined #webrtc
15:02:19 [martin]
* missed the name conclusion
15:02:57 [tpacbot]
tpacbot has joined #webrtc
15:04:23 [martin]
ekr: is this same as the other state machine, just with the states merged?
15:04:28 [martin]
juberti: yes
15:04:48 [hta]
martin, name conclusion was to use IceConnectedState rather than IceConnectState (I think - my ears are going)
15:06:18 [martin]
matthew: set...(answer) can't be done twice?
15:06:33 [martin]
matthew: why isn't createOffer and createAnswer shown on the diagram?
15:08:14 [martin]
juberti: once you set...(answer), you may have removed some critical state for the offer, which invalidates some of the answers
15:08:39 [dom]
RRSAgent, draft minutes
15:08:39 [RRSAgent]
I have made the request to generate dom
15:08:56 [martin]
fluffy: createOffer is where some of the reservations are made, but not all of them
15:09:47 [martin]
juberti: this is just setLocal and setRemote
15:11:16 [martin]
martin: where is rejected?
15:11:31 [martin]
hta: if you do setLocal and never get an answer, what happens?
15:12:13 [martin]
fluffy: you did setLocal(offer) and you decided to reject it, so you setLocal again?
15:12:35 [martin]
ekr: there needs to be a line from SentOffer back to Stable
15:12:58 [ekr]
there actually is one such edge, but it's already labeled setremote(Answer)
15:13:02 [martin]
hta: glare happens too
15:13:29 [martin]
fluffy: the signaling layer needs to handle some glare, but rollback is needed
15:13:37 [Hidetoshi]
Hidetoshi has joined #webrtc
15:14:49 [martin]
matthew: I'd be ok with this if it included rollback and some indication on where the reservations are made
15:15:12 [martin]
Moving to the Rollback Proposal
15:15:21 [martin]
Topic: Rollback Proposal
15:16:40 [Wonsuk]
Wonsuk has joined #webrtc
15:18:12 [kensaku]
kensaku has joined #webrtc
15:18:59 [kensaku]
kensaku has joined #webrtc
15:19:35 [martin]
juberti: proposes setRemoteDescription(null)
15:20:14 [kensaku_]
kensaku_ has joined #webrtc
15:20:17 [martin]
hta: likes this
15:20:18 [jeff]
jeff has joined #webrtc
15:20:53 [martin]
ekr: there is no way to get null from the other side, you require an explicit signaling message for this purpose
15:21:30 [martin]
ekr: if you had a specific message that said rollback then you could do this
15:21:46 [martin]
juberti: we could define a new type of rollback
15:22:22 [martin]
ekr: null would make it hard to generate an application that just stuffs the output from the peer into the API
15:22:48 [martin]
matthew/stefanh: what API call actually generates the "rollback"
15:23:03 [martin]
juberti: constraint of rollback
15:23:13 [martin]
ekr: how do you get out of setRemote(offer) state?
15:23:52 [kensaku]
kensaku has joined #webrtc
15:24:02 [martin]
matthew: need to handle glare cases where it's a server imperative
15:24:54 [martin]
matthew: both sides decide to send an offer
15:25:03 [martin]
juberti: setLocalDescription(null) might work
15:25:30 [Hidetoshi]
Hidetoshi has joined #webrtc
15:26:53 [martin]
matthew: createOffer and createAnswer need to be here
15:27:41 [kensaku]
kensaku has joined #webrtc
15:28:22 [martin]
derf: you need to be able to use the same null for both setRemote and setLocal
15:28:28 [martin]
general agreement
15:29:00 [martin]
martin: if you set(offer) and set(pranswer) those can mask the previous states
15:29:59 [martin]
adambe: null is more likely to be as a result of a programming error
15:30:11 [martin]
juberti: but you don't need to build a factory function to build it
15:30:34 [martin]
ekr: an RTCSessionDescription can at least be passed over the wire
15:31:34 [martin]
matthew: what could generate the rollback? nothing
15:32:40 [martin]
stefanh: fluffy and justin to draft a proposal, matthew will comment
15:32:55 [martin]
Topic: Schtats
15:34:44 [tpacbot]
tpacbot has joined #webrtc
15:35:02 [dom]
Topic: Stats
15:35:14 [kotakagi]
kotakagi has joined #webrtc
15:36:14 [martin]
martin: choice is immutable or copy
15:36:29 [martin]
hta: we needed snapshots
15:37:14 [martin]
matthew: why have local and remote when we can make those names or part thereof
15:37:26 [martin]
matthew: suggests OIDs for the names
15:38:46 [martin]
hta: the timestamps are different for local and remote
15:39:06 [fluffy]
fluffy has joined #webrtc
15:39:09 [martin]
matthew: we are reinventing something that has been done many times
15:39:15 [martin]
hta: this is far simpler
15:44:05 [martin]
juberti: I don't think we need arbitrary hierarchy depth, but there might be some depth
15:47:27 [martin]
derf: you also have to prevent stats disclosure for streams that are secured against the application
15:48:11 [martin]
juberti: do you have an example of what these would look like? a JSON structure seems to be more useful
15:48:16 [martin]
hta: not sure
15:49:18 [martin]
fluffy: the ICE thing is probably a good example to work through in a couple of the different proposals for this
15:50:02 [martin]
matthew: having dictionaries and lists would be easier to access in javascript than having to build names with dots etc...
15:50:15 [martin]
anant: any this would be enumerable
15:50:40 [jeff]
jeff has joined #webrtc
15:50:43 [martin]
matthew: and then you can get more hierarchy
15:50:52 [martin]
hta: I think that hierarchy is a bad idea
15:51:26 [martin]
hta: different applications have different perspectives on what they want from data and a hierarchy presupposes things, which make it easier to come from some perspectives and more difficult for others
15:53:05 [martin]
matthew: you already have an implied structure by the names
15:54:04 [martin]
DanD: I'm more interested in aggregation, there is no way to associate multiple PeerConnections
15:55:24 [martin]
hta: you might be able to add things together and pre-aggregation might be a bad idea
15:56:39 [martin]
hta: aggregation can cause information loss
15:58:16 [martin]
fluffy: an interesting statistic is how many bytes are ICE using, or the same for RTP
15:59:24 [martin]
ekr: it seems like a hierarchy with strings for that
16:00:36 [martin]
hta: ICE is a good candidate for first example, which should reveal issues
16:01:27 [martin]
hta: for multi-value attributes, people prefer sequences rather than .n
16:02:11 [martin]
juberti: some values can't be shown as a total
16:02:19 [martin]
hta: some values are instantaneous
16:02:56 [martin]
stefanh: indexDB?
16:03:13 [martin]
hta: indexDB was quite difficult to implement
16:04:50 [martin]
jimb: why not provide a set of values that are immutable and provide a shim on the top
16:08:19 [martin]
gorane: we agree that it is immutable
16:08:51 [martin]
martin: no, the stats that the browser maintains, but the object that we get may or may not be
16:09:09 [martin]
gorane: are we harmonizing with something?
16:09:38 [martin]
*: nothing relevant, libjingle has some, SIP products tend to
16:10:16 [martin]
hta: are sip mibs worth looking at
16:10:27 [martin]
fluffy: there may be some lessons to be learned
16:11:13 [martin]
hta: will work out how to describe ICE
16:11:50 [martin]
Topic: back to Error Handling from SDP
16:14:13 [martin]
juberti: we shouldn't allow stuff to be added
16:14:24 [martin]
matthew: ignoring is not as simple as is made out
16:14:40 [martin]
juberti: local descriptions should not include stuff you don't support, remote may do
16:15:46 [martin]
matthew: you might have aserver that produces common SDP that might be understood by some number of browsers
16:16:18 [martin]
juberti: you can't offer stuff that you can't support
16:18:10 [martin]
ekr: there might be browsers that enter the requisite state without the attribute and others that require the attribute to be present
16:19:03 [martin]
* discussion on whether we use offer/answer or local/remote
16:19:42 [martin]
matthew: how do we know when extensions are not being supported?
16:20:39 [martin]
matthew: learning what was supported is useful
16:21:20 [martin]
fluffy: that might just be useful for debugging
16:26:16 [martin]
anant: suggests that the browser report the SDP that it applied
16:26:25 [martin]
fluffy: skeptical that this is possible
16:28:19 [martin]
gorane: we should assume that we are going to need something along these lines, but as we understand the problems we can build them
16:28:58 [Wonsuk]
Wonsuk has left #webrtc
16:31:29 [Zakim]
- +44.190.881.aabb
16:33:17 [dom]
Zakim, who's on the call?
16:33:17 [Zakim]
On the phone I see Rhone_1, +30210818aacc
16:37:10 [Jim_Barnett]
Jim_Barnett has joined #webrtc
16:38:01 [hta]
hta has joined #webrtc
16:44:07 [jeff]
jeff has joined #webrtc
16:45:32 [Zakim]
- +30210818aacc
16:48:39 [Zakim]
16:48:40 [Zakim]
UW_Web RTC()3:00AM has ended
16:48:40 [Zakim]
Attendees were +44.190.881.aaaa, Rhone_1, +44.190.881.aabb, +30210818aacc
16:54:37 [chrisg]
chrisg has joined #webrtc
16:58:37 [AndyHutton]
AndyHutton has left #webrtc
17:06:35 [nsakai]
nsakai has joined #webrtc
17:11:58 [jeff]
jeff has joined #webrtc
17:16:10 [hta]
hta has joined #webrtc
17:33:56 [juberti]
juberti has joined #webrtc
17:38:26 [ekr]
ekr has joined #webrtc
17:49:30 [ekr]
ekr has joined #webrtc
18:00:42 [trackbot]
trackbot has joined #webrtc