14:58:22 <RRSAgent> RRSAgent has joined #webcomms
14:58:22 <RRSAgent> logging to http://www.w3.org/2016/09/21-webcomms-irc
14:58:25 <dom> -> https://www.w3.org/wiki/images/3/36/W3C-TPAC-WebComm-BA.PPTX Shijun & Bernard's slides
14:58:32 <dom> -> https://www.w3.org/wiki/images/3/3b/Webrtc-next-steps-v1.pptx Cullen's slides
14:58:50 <dom> Frode: we would like a way to improve scalability of bridge-less video conference
14:59:03 <dom> Alex: I think it's purely an implementation issue
14:59:18 <dom> Cullen: I think the API could provide ways to give hints that you need to optimize for that use case
14:59:26 <dom> Alex: isn't that already covered by the spec?
14:59:29 <dom> Cullen: maybe, not sure
14:59:46 <dom> Harald: What big things are we overlooking?
15:00:03 <dom> ... the big thing about WebRTC compared to other Web protocols is the shift to P2P
15:00:06 <dom> ... we have huge holes in that story
15:00:11 <dom> ... one is set up
15:00:17 <dom> ... another is IoT type of interactions
15:00:36 <dom> ... we kind of assume end points that can handle many protocols
15:00:56 <dom> ... but we could imagine end points that work on peer-to-peer mode in an IoT world
15:01:08 <dom> Alex: what would be missing in this view?
15:01:22 <dom> Carsten: note the IRTF has a group dedicated to that topic
15:01:54 <dom> Cullen: we have a headless firefox appliance that serves as a IoT endpoint for sensor communication
15:02:12 <dom> Harald: Linux is the simplest way to run a system, and the browser the simplest to program it?
15:03:06 <dom> Stefan: something I hear from my company is that we're missing ways to give more flexibility on real-time, allowing more retransmission
15:03:36 <dom> @@@: you mentioned in your description the need to enable background operation for WebRTC communications
15:03:58 <dom> ... ideally, this would enable to keep the audio running while pausing the video
15:04:12 <dom> ... having that would be interesting to minimize the disruption
15:04:21 <dom> ... this would be similar to what is enabled by service worker
15:04:39 <dom> ... with a headless background mode, this could be connected to the IoT world where camera / audio is less needed
15:05:26 <dom> Harald: the incoming call problem
15:05:39 <dom> ... holding a connection open just in case someone wants to send you something
15:06:00 <dom> ... if there was a way to hooking into another mechanism that would allow to that
15:06:12 <dom> Cullen: Web Push sounds about like what we need
15:06:27 <dom> DanD: this provides a work around
15:06:38 <dom> ... Push sends a notification, from which you could then start a session
15:06:59 <dom> ... ideally you would want to send connection information at the time where the call is made
15:07:29 <dom> DanB: there could be a preliminary presence check, then a setup call push
15:07:39 <barryleiba> barryleiba has joined #webcomms
15:08:11 <dom> DanD: but this comes with interesting security & privacy aspects
15:08:30 <dom> @@@: but push is server / client, does it apply to P2P ?
15:08:43 <dom> Dom: Push is to enable the set up of the call mediated by the server
15:09:03 <dom> DanD: at the moment, WebRTC only enables P2P in a very limited way as Harald described
15:09:17 <dom> Harald: there have been discussions around rendez vous based on distributed registry
15:09:38 <dom> DanD: the problem is discovery
15:09:59 <dom> Boaz: does WebRTC enable local P2P connection without going through the Internet?
15:10:14 <dom> Cullen: one use case is emergency services where local WIFI exists but no backbone connection
15:10:40 <dom> DanD: broadcast/multicast could be exposed at the API level, but the security implications can be difficult
15:11:04 <dom> AdamB: in practice, the server is only a convenient rendez-vous mechanism
15:11:11 <dom> ... any rendez-vous mechanism could be used
15:11:38 <dom> JIB: a P2P data channel is very cheap
15:11:55 <dom> Boaz: in Web Bluetooth, they're talking about making the Web browser a virtual bluetooth device
15:12:37 <dom> @@@1: there is some commonality with what was discussed around hash tables for server less connection
15:12:46 <dom> ... this might have relationship with Mozilla's FlyWeb
15:13:01 <dom> Boaz: it might be worth bringing this up with the Web Bluetooth group
15:13:12 <dom> ... e.G. data channels over bluetooth
15:13:28 <dom> TimP: some of these approaches don't work well with the offer / answer model
15:13:39 <dom> JIB: this is an opportunity to clean up the API
15:13:55 <dom> ... createO/A, setL/RD feels outdated
15:14:08 <dom> ... e.g. a P2P with a default SDP channel
15:14:15 <dom> s/SDP /data
15:14:33 <dom> ... that would enable automatic signalling
15:14:58 <dom> Cullen: the P2P distributed hashtables requires specific network level access that is not available to Web browsers
15:15:13 <dom> ... we would need to find the right narrow subset needed to enable this kind of connectivity
15:19:53 <dom> Dom: would there be interest in a workshop to go further into these topics?
15:20:09 <dom> DanD: would this be around WebRTC only? or broaader? only audio/video comm
15:20:17 <dom> dom: good question; might need to be broader
15:20:41 <dom> DanB: I wonder if we need to hear more from broadcasters in how well WebRTC help them in their use cases
15:21:05 <dom> Andrew: there are also use cases in healthcare, emergency that we need to look at
15:21:39 <dom> Randell: live streaming is another use case: a user live streams to a server which then broadcasts
15:21:48 <dom> ... that's a peer-connection to a server - maybe nothing new
15:22:04 <dom> Cullen: re push-to-talk, one missing thing is rapid play back
15:22:14 <dom> ... playing an RTP stream faster
15:23:24 <dom> DanD: sending hints for congestion control, in general indication to the transports level
15:23:29 <dom> ... like the priority API
15:23:41 <dom> ... allowing the developers to express the needs of the application
15:24:28 <dom> Dom: so do we need to talk more?
15:24:46 <dom> Cullen: I think a workshop is an excellent idea to give the opportunity for people to put their ideas down
15:24:53 <dom> ... but the timing is a big question
15:25:07 <dom> ... is it a near term thing?
15:25:28 <dom> ... in particular, are browser vendors in a position to look at even more requirements?
15:25:46 <dom> DanD: there is no question we can get a long list of ideas
15:25:57 <dom> ... but we need to close the lid on the 1st version
15:26:19 <dom> AdamB: thinking again about the discovery use case
15:26:27 <dom> ... does it need to be part of WebRTC?
15:26:37 <dom> ... if so, the pipeline issue is somewhat different
15:29:17 <dom> RRSAgent, draft minutes
15:29:17 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/21-webcomms-minutes.html dom
15:29:22 <dom> RRSAgent, make log public
15:33:40 <barryleiba> barryleiba has joined #webcomms
15:38:09 <dminor> dminor has left #webcomms
15:38:14 <kaorumaeda> kaorumaeda has joined #webcomms
16:08:04 <JonathanJ> JonathanJ has joined #webcomms
16:08:06 <JonathanJ> JonathanJ has joined #webcomms
16:12:43 <barryleiba> barryleiba has left #webcomms
16:51:33 <JonathanJ> JonathanJ has joined #webcomms
17:17:26 <JonathanJ> JonathanJ has joined #webcomms
17:18:01 <JonathanJ> JonathanJ has joined #webcomms
17:33:01 <JonathanJ1> JonathanJ1 has joined #webcomms
21:57:01 <JonathanJ> JonathanJ has joined #webcomms
21:58:09 <kaorumaeda> kaorumaeda has joined #webcomms
22:28:35 <kaorumaeda> kaorumaeda has joined #webcomms
22:35:29 <kaorumaeda_> kaorumaeda_ has joined #webcomms