Main.WebRTC History
Hide minor edits - Show changes to output
Changed line 4 from:
* Lorenzo presented ideas based on his [[Attach:WebRTC_FOMS2013.pfd"WebRTC slides" | "slides"]]
to:
* Lorenzo presented ideas based on his [[Attach:WebRTC_FOMS2013.pdf"WebRTC slides" | slides]]
Changed line 4 from:
* Lorenzo presented ideas based on his [attach:WebRTC_FOMS2013.pfd | slides]
to:
* Lorenzo presented ideas based on his [[Attach:WebRTC_FOMS2013.pfd"WebRTC slides" | "slides"]]
Changed line 4 from:
* Lorenzo presented ideas based on his slides
to:
* Lorenzo presented ideas based on his [attach:WebRTC_FOMS2013.pfd | slides]
Changed lines 1-53 from:
to:
!! WebRTC
* Moderated by Ami and Lorenzo
* Lorenzo presented ideas based on his slides
Feedback from the participants:
* jQuery-like WebRTC might or might not be of general interest
* the question of using a url-like is reasonable and there are demos
that are build around that idea; having an simple url will simplify
a throw away a lot of the flexibility
* writing a WebRTC application focusing only on streaming, make it
very simple to an implementor by referring to a simple URL scheme
Pain-points for WebRTC from the participants:
* Once a peer connection is rolled back, it is very difficult to
recover from that
* The spec has more than any other spec on the web (due to its
multi-layer structure)
* The surface provided by the WebRTC is very good
* Multi-party, multi-stream gets a bit crazy
* Compatibility between different versions of Chrome is a problem
* Chrome implementation is not fully compatible with the SDP
(it's unfortunate, nobody actual enjoys the SDP that is in WebRTC)
(maybe most of the people would have done it differently now?)
* API interface such that SDP wraps into proper objects and allows
the developers to not know anything about SDP
* There are a lot of very good SDP library -- SDP-transform
https://npmjs.org/package/sdp-transform ?
* It's a very good to go away from SDP, but because of JavaScript
objects it's not necessarily that you get what you want
* Work to get gstreamer working with this without going
through a browser
* There is someone implementing in WebKit GTK
WebRTC and text tracks?
* Captions in a video conference would be nice
* Having someone on the other side typing captions and transmitting,
can be done today easily
* Not really getting a lot of attention?
WebRTC states about other browsers:
* Firefox is working on it
* WebKit community does work around this area too (not Apple contributors,
the nix port which uses gstreamer and they're working on the WK infrastructure too)
* IE there seem to be indications (?)
Did the whole Cisco-thing help with the codec-related fight?
* It adds information and it forces certain questions to be asked, helpfull
to move things forward and toward a resolution
* It isn't a game changer, none of the actors have turned 180.
Anything interested that come out of TPAC related to WebRTC:
* conversation around tracks: is this the best we can do for an API?
* Moderated by Ami and Lorenzo
* Lorenzo presented ideas based on his slides
Feedback from the participants:
* jQuery-like WebRTC might or might not be of general interest
* the question of using a url-like is reasonable and there are demos
that are build around that idea; having an simple url will simplify
a throw away a lot of the flexibility
* writing a WebRTC application focusing only on streaming, make it
very simple to an implementor by referring to a simple URL scheme
Pain-points for WebRTC from the participants:
* Once a peer connection is rolled back, it is very difficult to
recover from that
* The spec has more than any other spec on the web (due to its
multi-layer structure)
* The surface provided by the WebRTC is very good
* Multi-party, multi-stream gets a bit crazy
* Compatibility between different versions of Chrome is a problem
* Chrome implementation is not fully compatible with the SDP
(it's unfortunate, nobody actual enjoys the SDP that is in WebRTC)
(maybe most of the people would have done it differently now?)
* API interface such that SDP wraps into proper objects and allows
the developers to not know anything about SDP
* There are a lot of very good SDP library -- SDP-transform
https://npmjs.org/package/sdp-transform ?
* It's a very good to go away from SDP, but because of JavaScript
objects it's not necessarily that you get what you want
* Work to get gstreamer working with this without going
through a browser
* There is someone implementing in WebKit GTK
WebRTC and text tracks?
* Captions in a video conference would be nice
* Having someone on the other side typing captions and transmitting,
can be done today easily
* Not really getting a lot of attention?
WebRTC states about other browsers:
* Firefox is working on it
* WebKit community does work around this area too (not Apple contributors,
the nix port which uses gstreamer and they're working on the WK infrastructure too)
* IE there seem to be indications (?)
Did the whole Cisco-thing help with the codec-related fight?
* It adds information and it forces certain questions to be asked, helpfull
to move things forward and toward a resolution
* It isn't a game changer, none of the actors have turned 180.
Anything interested that come out of TPAC related to WebRTC:
* conversation around tracks: is this the best we can do for an API?
October 04, 2013, at 12:27 AM
by - removed last year notes
Changed lines 1-47 from:
1. Harald intro on webrtc
Signalling goes through http/s. Audio and video data goes through P2P. Has applications that are much more far reaching than video calling. Video and audio have ability to stay local.
Data channel between browsers always available.
2. Tim: Let’s talk about open issues with the spec.
MS proposal intro. Redefines the APIs to much lower level. For instance, low level networking APIs to implement your own ICE stack instead of having it built into the browser.
Intro to W3C poll on MS CU-RTCWEB. No implementation of CU-RTCWEB presented yet.
Security is a number one concern for webrtc and this is a reason for ICE to be required with authentication.
Question: how easy is it to interop with something else than a browser?
It’s been accomplished and encouraged. (asterix for instance)
Back to open spec issues:
1. Stats
2. Flow control: No good way of doing back off on udp standardized. Normally, buffering is the method used but does not adapt to RTC.
Question: Why not SCTP congestion control? Because it buffers in the same way as TCP. New IETF group for congestion control is a result. This is an area where more participation is needed for simulations. RMCAT is needed.
.
Question: What happens to interop until CG is needed? Need to agree on a few common sense approaches.
Question: What is the status of the stats proposal? Being implemented in WK.
Resolution changes: chrome defaults to 640x480. FF also does 640x480. No way to change it,
3. Status:
Chrome: getUserMedia is available now. PeerConnection soon.
FF: getUserMedia available in FF18. PeerConneciton behind a flag. Spec called constraints is available. First patch to support it is now in WebKit. Draft for constraints is published and solve it for getUserMedia.
For firefox, there is a fingerprinting issue. Resolution of camera, combined with fonts and rest can help in tracking users. Question: what about limiting the rate of reporting failures?
4. Issues:
a. a sync calls vs sync calls. Chrome moving to async.
b. createAnswer(RTCSessionDescription) vs DOMString. Is there a reason for a SDP object? Harald: no, we should fix this.
c. setRemoteDescription / setLocalDescription string + type vs RTCSessionDescription
d. ICE: Firefox does not have trickle ICE, Chrome requires it.
3. Recording API.
API calls and container format needs to be speced out. Need help here!!!
to:
!! WebRTC
Added lines 1-47:
Notes from session:
1. Harald intro on webrtc
Signalling goes through http/s. Audio and video data goes through P2P. Has applications that are much more far reaching than video calling. Video and audio have ability to stay local.
Data channel between browsers always available.
2. Tim: Let’s talk about open issues with the spec.
MS proposal intro. Redefines the APIs to much lower level. For instance, low level networking APIs to implement your own ICE stack instead of having it built into the browser.
Intro to W3C poll on MS CU-RTCWEB. No implementation of CU-RTCWEB presented yet.
Security is a number one concern for webrtc and this is a reason for ICE to be required with authentication.
Question: how easy is it to interop with something else than a browser?
It’s been accomplished and encouraged. (asterix for instance)
Back to open spec issues:
1. Stats
2. Flow control: No good way of doing back off on udp standardized. Normally, buffering is the method used but does not adapt to RTC.
Question: Why not SCTP congestion control? Because it buffers in the same way as TCP. New IETF group for congestion control is a result. This is an area where more participation is needed for simulations. RMCAT is needed.
.
Question: What happens to interop until CG is needed? Need to agree on a few common sense approaches.
Question: What is the status of the stats proposal? Being implemented in WK.
Resolution changes: chrome defaults to 640x480. FF also does 640x480. No way to change it,
3. Status:
Chrome: getUserMedia is available now. PeerConnection soon.
FF: getUserMedia available in FF18. PeerConneciton behind a flag. Spec called constraints is available. First patch to support it is now in WebKit. Draft for constraints is published and solve it for getUserMedia.
For firefox, there is a fingerprinting issue. Resolution of camera, combined with fonts and rest can help in tracking users. Question: what about limiting the rate of reporting failures?
4. Issues:
a. a sync calls vs sync calls. Chrome moving to async.
b. createAnswer(RTCSessionDescription) vs DOMString. Is there a reason for a SDP object? Harald: no, we should fix this.
c. setRemoteDescription / setLocalDescription string + type vs RTCSessionDescription
d. ICE: Firefox does not have trickle ICE, Chrome requires it.
3. Recording API.
API calls and container format needs to be speced out. Need help here!!!
1. Harald intro on webrtc
Signalling goes through http/s. Audio and video data goes through P2P. Has applications that are much more far reaching than video calling. Video and audio have ability to stay local.
Data channel between browsers always available.
2. Tim: Let’s talk about open issues with the spec.
MS proposal intro. Redefines the APIs to much lower level. For instance, low level networking APIs to implement your own ICE stack instead of having it built into the browser.
Intro to W3C poll on MS CU-RTCWEB. No implementation of CU-RTCWEB presented yet.
Security is a number one concern for webrtc and this is a reason for ICE to be required with authentication.
Question: how easy is it to interop with something else than a browser?
It’s been accomplished and encouraged. (asterix for instance)
Back to open spec issues:
1. Stats
2. Flow control: No good way of doing back off on udp standardized. Normally, buffering is the method used but does not adapt to RTC.
Question: Why not SCTP congestion control? Because it buffers in the same way as TCP. New IETF group for congestion control is a result. This is an area where more participation is needed for simulations. RMCAT is needed.
.
Question: What happens to interop until CG is needed? Need to agree on a few common sense approaches.
Question: What is the status of the stats proposal? Being implemented in WK.
Resolution changes: chrome defaults to 640x480. FF also does 640x480. No way to change it,
3. Status:
Chrome: getUserMedia is available now. PeerConnection soon.
FF: getUserMedia available in FF18. PeerConneciton behind a flag. Spec called constraints is available. First patch to support it is now in WebKit. Draft for constraints is published and solve it for getUserMedia.
For firefox, there is a fingerprinting issue. Resolution of camera, combined with fonts and rest can help in tracking users. Question: what about limiting the rate of reporting failures?
4. Issues:
a. a sync calls vs sync calls. Chrome moving to async.
b. createAnswer(RTCSessionDescription) vs DOMString. Is there a reason for a SDP object? Harald: no, we should fix this.
c. setRemoteDescription / setLocalDescription string + type vs RTCSessionDescription
d. ICE: Firefox does not have trickle ICE, Chrome requires it.
3. Recording API.
API calls and container format needs to be speced out. Need help here!!!
