-> https://www.w3.org/wiki/images/3/36/W3C-TPAC-WebComm-BA.PPTX Shijun & Bernard's slides

-> https://www.w3.org/wiki/images/3/3b/Webrtc-next-steps-v1.pptx Cullen's slides

Frode: we would like a way to improve scalability of bridge-less video conference

Alex: I think it's purely an implementation issue

Cullen: I think the API could provide ways to give hints that you need to optimize for that use case

Alex: isn't that already covered by the spec?

Cullen: maybe, not sure

Harald: What big things are we overlooking?
... the big thing about WebRTC compared to other Web protocols is the shift to P2P
... we have huge holes in that story
... one is set up
... another is IoT type of interactions
... we kind of assume end points that can handle many protocols
... but we could imagine end points that work on peer-to-peer mode in an IoT world

Alex: what would be missing in this view?

Carsten: note the IRTF has a group dedicated to that topic

Cullen: we have a headless firefox appliance that serves as a IoT endpoint for sensor communication

Harald: Linux is the simplest way to run a system, and the browser the simplest to program it?

Stefan: something I hear from my company is that we're missing ways to give more flexibility on real-time, allowing more retransmission

@@@: you mentioned in your description the need to enable background operation for WebRTC communications

scribe: ideally, this would enable to keep the audio running while pausing the video
... having that would be interesting to minimize the disruption
... this would be similar to what is enabled by service worker
... with a headless background mode, this could be connected to the IoT world where camera / audio is less needed

Harald: the incoming call problem
... holding a connection open just in case someone wants to send you something
... if there was a way to hooking into another mechanism that would allow to that

Cullen: Web Push sounds about like what we need

DanD: this provides a work around
... Push sends a notification, from which you could then start a session
... ideally you would want to send connection information at the time where the call is made

DanB: there could be a preliminary presence check, then a setup call push

DanD: but this comes with interesting security & privacy aspects

@@@: but push is server / client, does it apply to P2P ?

Dom: Push is to enable the set up of the call mediated by the server

DanD: at the moment, WebRTC only enables P2P in a very limited way as Harald described

Harald: there have been discussions around rendez vous based on distributed registry

DanD: the problem is discovery

Boaz: does WebRTC enable local P2P connection without going through the Internet?

Cullen: one use case is emergency services where local WIFI exists but no backbone connection

DanD: broadcast/multicast could be exposed at the API level, but the security implications can be difficult

AdamB: in practice, the server is only a convenient rendez-vous mechanism
... any rendez-vous mechanism could be used

JIB: a P2P data channel is very cheap

Boaz: in Web Bluetooth, they're talking about making the Web browser a virtual bluetooth device

@@@1: there is some commonality with what was discussed around hash tables for server less connection

scribe: this might have relationship with Mozilla's FlyWeb

Boaz: it might be worth bringing this up with the Web Bluetooth group
... e.G. data channels over bluetooth

TimP: some of these approaches don't work well with the offer / answer model

JIB: this is an opportunity to clean up the API
... createO/A, setL/RD feels outdated
... e.g. a P2P with a default datachannel
... that would enable automatic signalling

Cullen: the P2P distributed hashtables requires specific network level access that is not available to Web browsers
... we would need to find the right narrow subset needed to enable this kind of connectivity

Dom: would there be interest in a workshop to go further into these topics?

DanD: would this be around WebRTC only? or broaader? only audio/video comm

dom: good question; might need to be broader

DanB: I wonder if we need to hear more from broadcasters in how well WebRTC help them in their use cases

Andrew: there are also use cases in healthcare, emergency that we need to look at

Randell: live streaming is another use case: a user live streams to a server which then broadcasts
... that's a peer-connection to a server - maybe nothing new

Cullen: re push-to-talk, one missing thing is rapid play back
... playing an RTP stream faster

DanD: sending hints for congestion control, in general indication to the transports level
... like the priority API
... allowing the developers to express the needs of the application

Dom: so do we need to talk more?

Cullen: I think a workshop is an excellent idea to give the opportunity for people to put their ideas down
... but the timing is a big question
... is it a near term thing?
... in particular, are browser vendors in a position to look at even more requirements?

DanD: there is no question we can get a long list of ideas
... but we need to close the lid on the 1st version

AdamB: thinking again about the discovery use case
... does it need to be part of WebRTC?
... if so, the pipeline issue is somewhat different

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/SDP /data/
No ScribeNick specified.  Guessing ScribeNick: dom
Inferring Scribes: dom

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: AdamB Alex Andrew Boaz Carsten Cullen DanB DanD Frode Harald JIB Randell Stefan TimP barryleiba dom
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 21 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/21-webcomms-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report