11 ms·

WebRTC is now a W3C and IETF standard

645 points by kaycebasques 6y ago

kaycebasques 6y ago
Aside: I've heard about web platform tests, but I never realized that it could be a viable alternative to MDN for representing browser compatibility information. In this case they have a pretty good collection of tests [1] that give you a picture of overall WebRTC compatibility. Of course MDN is still the gold standard and we on web.dev will always link there as our default choice when they do a good job representing browser compatibility data, but in this case they don't seem to have a good table representing the state of WebRTC at large [2] (happy to update the article if it's just an oversight on my part and they do have a good browser compat table somewhere that I missed). Specifically, it seems like the WebRTC API page [3] should have a list of the browser compatibility of each of the interfaces that are mentioned on the page. [1] https://wpt.fyi/results/webrtc?label=experimental&label=master&aligned https://wpt.fyi/results/webrtc?label=experimental&label=mast... [2] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API [3] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API Disclosure: I edited the web.dev announcement
Sean-Der 6y ago
This is so exciting. WebRTC is our best hope to have video interop between platforms. I love that it works outside web browsers, compeitors like WebTransport assume a 100% browser world. Or you have protocols like RTMP/SRT... that will never make it into the browser. WebRTC might be our best bet to establish P2P connectivity between all languages/platforms. Would love to get rid of the single point of falure in Pub/Sub systems. WebRTC also feels like a great path towards easy cloud-agnostic code. You can use lots of different languages, and not dependent on SDKs/Servers. * https://github.com/aiortc/aiortc https://github.com/aiortc/aiortc (Python) * GStreamer’s webrtcbin (C) * https://github.com/shinyoshiaki/werift-webrtc https://github.com/shinyoshiaki/werift-webrtc (Typescript) * https://github.com/pion/webrtc https://github.com/pion/webrtc (Golang) * https://github.com/webrtc-rs/webrtc https://github.com/webrtc-rs/webrtc (Rust) * https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded) * https://webrtc.googlesource.com/src/ https://webrtc.googlesource.com/src/ (C++) * https://github.com/rawrtc/rawrtc https://github.com/rawrtc/rawrtc (C++) ---- Then you have a couple that aren't Open Source. But proves it is possible for these platforms also. * Shiguredo (Erlang) * |pipe| (Java) ---- If you are new to WebRTC I have been working on making it more accessible https://webrtcforthecurious.com https://webrtcforthecurious.com. I am currently pretty tied up with Pion so haven't been able to make much progress lately.
- api 6y ago
  WebRTC is also a decent P2P data protocol, and to have a P2P protocol like that enshrined in IETF standards means that P2P is now considered a "normal" thing on the Internet. This in turn means that symmetric NAT will be considered sort of broken, which it should be as it is horrible for anything P2P or any novel protocol for that matter. Of course IPv6 is the ultimate long term solution.
  - taf2 6y ago
    "Of course IPv6 is the ultimate long term solution." I feel like this is similar to "We'll have nuclear fusion in the next 30 years." :) However if you look at the graph from google - https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html maybe it'll be here sooner than we think...
    - api 6y ago
      Nuclear fusion may be closer than you think too. We've been developing better and better superconductors that could yield more compact and more powerful electromagnets, which is a major bottleneck to making it practical. ITER is huge and fabulously expensive, but it's intended to be more of an experiment/testbed that happens to maybe generate some power. It's not intended to be a practical reactor.
    - LinuxBender 6y ago
      It would be nice if they broke that chart down by AS numbers, as I suspect much of that is the mobile carriers. Here is some data [1] looks like about 27k AS numbers comprise all of the ipv6 usage. I stand corrected, looks like mostly mobile and Amazon for the US and then the rest is several other countries that are primarily using ipv6. [1] - https://www.cidr-report.org/v6/as2.0/#Aggs https://www.cidr-report.org/v6/as2.0/#Aggs
    - solarkraft 6y ago
      Side note: Try browsing the internet v6-only. It's pretty eye opening.
viktorcode 6y ago
> WebRTC implementations are required to support both Google's free-to-use VP8 video codec and H.264 for processing video. I understand that backwards compatibility is very important, but this adds to technical debt.
- Sean-Der 6y ago
  It is pretty nice to have both! For beefier machines VP8 works great, and you don't need to worry about cost. For IoT/Embedded space you usually just get H264 (from a hardware encoder). If we didn't have both I think it would shut out a lot of interesting use cases.
- dane-pgp 6y ago
  I don't know if people remember the fraught Codec War of 2014, but the choice of VP8 and H.264 both being "Mandatory To Implement" was the compromise that the IETF reached, despite much opposition from both sides.[0] As often happens with wars, though, the outcome in 2014 wasn't enough to permanently settle the matter, and there was a further outbreak of fighting later between VP9 and HEVC. More recently, some are saying[1] that the Codec Wars are back, with the arrival of AV1 as a contender. [0] https://bloggeek.me/winners-losers-webrtc-video-mti/ https://bloggeek.me/winners-losers-webrtc-video-mti/ [1] https://bloggeek.me/av1-vs-hevc-webrtc-codec/ https://bloggeek.me/av1-vs-hevc-webrtc-codec/
- userbinator 6y ago
  IMHO it would've been better if they specified some clearly out-of-patent and also simple-to-implement codec like H.261 or MPEG-1 as a minimal requrement.
aerovistae 6y ago
I have tried using this API and found it incredibly technical and complex. Personally I find the PeerJS library an excellent wrapper rendering it useable. Hopefully over time it will become more accessible.
- afavour 6y ago
  I think that what it's doing is sufficiently complex that the API is always going to be difficult. As long as abstractions like PeerJS exist I'm OK with that.
- kaycebasques 6y ago
  Any specific problems you recall?
- amelius 6y ago
  The main achievement of the technology is to work around the shortcomings of other technologies. Complex might be the wrong word as it's not rocket science; convoluted sounds better.
- throw_m239339 6y ago
  > I have tried using this API and found it incredibly technical and complex. It is meant to be relatively low level. It's like WebGL, in order to draw a simple square on the canvas it takes likes 50 lines of code just to bind attributes to buffers and stuff, link, compile your shaders and execute the program on the GPU. It takes 3 lines with Three.js. You are probably not meant to use it directly if you don't know the domain, but use a library. So I'd argue that if every single WebAPI was like that, the web would have been a failure. At the same time, it's also a great playground if you INTEND to learn some things that can be useful OUTSIDE the browser. For instance, WebGL knowledge can be directly transferred to any OPENGL application, because the API is similar to C or C++ version of it.
  - kwindla 6y ago
    I think the comparison to WebGL is apt. It's also worth adding that scaling WebRTC -- both to calls with more than a few participants, and to large numbers of users on a service -- is still a bit of a specialized undertaking. Partly because it's intended to be a really, really flexible API, the abstractions are pretty leaky. You end up learning a lot about video codecs, UDP and RTP networking, and browser implementation details as you build out WebRTC applications! (I'm the cofounder Daily.co of a YC company that tries to make WebRTC "just a few lines of code" for common use cases, and to be the best possible application-level APIs and global infrastructure for advanced developers.)
ocdtrekkie 6y ago
Probably an issue that should've gotten addressed ahead of standardization, IMHO: https://github.com/w3c/webappsec-csp/issues/92 https://github.com/w3c/webappsec-csp/issues/92
chovybizzass 6y ago
i always stayed away from WebRTC because of that tunnel thing that seemed like a real pain in the a55
lxe 6y ago
I've dabbled with WebRTC API over the years, and I think I understand and can explain fairly clearly (to myself) the user's end of it. Having said that, it's an absolute nightmare of an API that should probably be re-done from scratch.
- kaycebasques 6y ago
  Any specific problems you recall?
TrueGeek 6y ago
Can we now get support for it in Safari WebView on iOS?
- GZJOHN 6y ago
  Apple is the new Microsoft when it comes to foot dragging, don't hold your breath.
- saagarjha 6y ago
  Doesn't iOS Safari already support WebRTC?
  - TrueGeek 6y ago
    Safari does, and SFControllerView does. WKWebView does not. Which means apps can’t use WebRTC inside simple WebViews, and Chrome can’t support WebRTC on iOS.
    - saagarjha 6y ago
      Oh, hmm. That's quite unfortunate…
- pgo 6y ago
  Didn't we get support for it last month
thomzane 6y ago
Jitsi made it into the announcement!
ChrisArchitect 6y ago
how far this has come.....from a dream, over 10 years ago, to this. I know it still seems complicated in some regards etc but the possibility of video over web, p2p capabilities etc instead of having to use terrible apps, Apple stuff, quicktime, etc just to have some video conferencing....was a pipe dream
qwerty456127 6y ago
Does it still leak IP addresses?
- nostrebored 6y ago
  No, the negotiation phase doesn't leak ip addresses anymore
- miohtama 6y ago
  Here is the standard discussion how to limit IP exposure: https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candi... It is a trade off as this would also prevent applications like snapdrop.net working in the local network.
- deleted 6y ago
  [deleted]
ElijahLynn 6y ago
Here is the link to the WebRTC specification 1.0, published Jan 26, 2021: https://www.w3.org/TR/webrtc/ https://www.w3.org/TR/webrtc/
deleted 6y ago
[deleted]
est 6y ago
Still requires signal server. Is it possible to avoid the signal server in some way? So we can have true p2p network inside a browser directly.
- azernik 6y ago
  If you're willing to solve the discovery and NAT traversal problems yourself, but it's perfectly doable - AFAIU the WebRTC protocol doesn't care how you solve those problems, just that you do. See e.g. this little demo: https://github.com/lesmana/webrtc-without-signaling-server https://github.com/lesmana/webrtc-without-signaling-server
  - est 6y ago
    If two browsers are inside the same LAN, are they able to communicate with each other directly without any server?
    - nerdbaggy 6y ago
      Yup. And if one of the servers is on a public IP then no other servers generally needed
    - azernik 6y ago
      Or if both are on un-NATted IPv6, and can get open ports through their respective firewalls. Specifically, you need to construct an object[1] that kind of looks like an SDP[2] message and pass it into the API; the demo applications generally get this from a signalling server, but you can make it based on whatever input you want. [1] https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidateInit https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandi... [2] https://developer.mozilla.org/en-US/docs/Glossary/SDP https://developer.mozilla.org/en-US/docs/Glossary/SDP
      - est 6y ago
        looks like the only useful info in the SDP are the `a=fingerprint:sha-256 ` line, and the `a=candidate:` for the actual IP. Anything else can be hard-coded in both peers. Is there a way to further strip down the long-ass sha-256 fingerprint? A 6 digit pin should be sufficient for communications inside a LAN.
seeyacall 6y ago
hi, nice to contact you . Here is a HOT strangers random video call app :Seeya-online video chat.To find a girl friend, boy friend, foreign friends , nearby friends FACE TO FACE Click link and download: Click this link : http://www.seeya.video/ http://www.seeya.video/ Thanks babe.
dep_b 6y ago
I've done WebRTC cross-platform between iOS, Android and web browsers (in the end only Chrome...wasn't the web developer though, perhaps it was fixable) and I can tell you even while you're using Chrome, an OS built by the creator of Chrome and the WebRTC part of Chrome repackaged as an iOS library there were many, many caveats getting a solid connection. And the fun of iOS background modes while getting an incoming call. Of course the Google examples were all broken in their own little devious way. And there is really jack shit on WebRTC on the web, seems like everybody that figured it out just said "fuck it I'm not giving away this for free" after spending possibly months to get it working. Though some people here seem to complain about no audio or no video...I have to say once we got it working it kept working. Sometimes the websocket we used for signalling dropped it's connection but the video call kept on trucking on some really bad WiFi!
ximm 6y ago
AFAIU there need to be more than one independent implementation to reach recommendation status. Last time I checked chrome and firefox both used the google implementation[0]. Has this changed? Which other implementations do exist? [0]: https://webrtc.googlesource.com/src/ https://webrtc.googlesource.com/src/
- deleted 6y ago
  [deleted]
- detaro 6y ago
  The W3C process does not strictly require independent implementations. It's a good safeguard against issues, and not having it opens the spec up to questions, but this has been covered elsewhere in the case of WebRTC: Multiple independent protocol implementations exist (and the protocol part was handled at IETF, through their processes), so interoperability on protocol level has been shown even if browsers happened to pick the same one. The W3C spec describes the wrapping JS APIs, sufficiency of that spec has been shown by the browsers independently building those layers around a WebRTC library. Especially given the working real-world use WebRTC already has it those two layers combined are a good argument that the spec is suitable.
wejick 6y ago
AFAIK WebRTC is already widely adopted, so what does it mean actually for most of the people?
baxuz 6y ago
Oh nice! Can't wait for streaming services like Twitch, Mux, or even Azure Streaming Services to accept WebRTC!
dikaio 6y ago
Anyone have a good open-source webrtc project? I’d like to donate this domain to the cause https://webrtc.io https://webrtc.io

645 points by kaycebasques 6y ago

Aside: I've heard about web platform tests, but I never realized that it could be a viable alternative to MDN for representing browser compatibility information. In this case they have a pretty good collection of tests [1] that give you a picture of overall WebRTC compatibility. Of course MDN is still the gold standard and we on web.dev will always link there as our default choice when they do a good job representing browser compatibility data, but in this case they don't seem to have a good table representing the state of WebRTC at large [2] (happy to update the article if it's just an oversight on my part and they do have a good browser compat table somewhere that I missed). Specifically, it seems like the WebRTC API page [3] should have a list of the browser compatibility of each of the interfaces that are mentioned on the page. [1] https://wpt.fyi/results/webrtc?label=experimental&label=master&aligned https://wpt.fyi/results/webrtc?label=experimental&label=mast... [2] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API [3] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API Disclosure: I edited the web.dev announcement

Sean-Der 6y ago

This is so exciting. WebRTC is our best hope to have video interop between platforms. I love that it works outside web browsers, compeitors like WebTransport assume a 100% browser world. Or you have protocols like RTMP/SRT... that will never make it into the browser. WebRTC might be our best bet to establish P2P connectivity between all languages/platforms. Would love to get rid of the single point of falure in Pub/Sub systems. WebRTC also feels like a great path towards easy cloud-agnostic code. You can use lots of different languages, and not dependent on SDKs/Servers. * https://github.com/aiortc/aiortc https://github.com/aiortc/aiortc (Python) * GStreamer’s webrtcbin (C) * https://github.com/shinyoshiaki/werift-webrtc https://github.com/shinyoshiaki/werift-webrtc (Typescript) * https://github.com/pion/webrtc https://github.com/pion/webrtc (Golang) * https://github.com/webrtc-rs/webrtc https://github.com/webrtc-rs/webrtc (Rust) * https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c https://github.com/awslabs/amazon-kinesis-video-streams-webr... (C/Embedded) * https://webrtc.googlesource.com/src/ https://webrtc.googlesource.com/src/ (C++) * https://github.com/rawrtc/rawrtc https://github.com/rawrtc/rawrtc (C++) ---- Then you have a couple that aren't Open Source. But proves it is possible for these platforms also. * Shiguredo (Erlang) * |pipe| (Java) ---- If you are new to WebRTC I have been working on making it more accessible https://webrtcforthecurious.com https://webrtcforthecurious.com. I am currently pretty tied up with Pion so haven't been able to make much progress lately.

api 6y ago
WebRTC is also a decent P2P data protocol, and to have a P2P protocol like that enshrined in IETF standards means that P2P is now considered a "normal" thing on the Internet. This in turn means that symmetric NAT will be considered sort of broken, which it should be as it is horrible for anything P2P or any novel protocol for that matter. Of course IPv6 is the ultimate long term solution.
- taf2 6y ago
  "Of course IPv6 is the ultimate long term solution." I feel like this is similar to "We'll have nuclear fusion in the next 30 years." :) However if you look at the graph from google - https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html maybe it'll be here sooner than we think...
  - api 6y ago
    Nuclear fusion may be closer than you think too. We've been developing better and better superconductors that could yield more compact and more powerful electromagnets, which is a major bottleneck to making it practical. ITER is huge and fabulously expensive, but it's intended to be more of an experiment/testbed that happens to maybe generate some power. It's not intended to be a practical reactor.
  - LinuxBender 6y ago
    It would be nice if they broke that chart down by AS numbers, as I suspect much of that is the mobile carriers. Here is some data [1] looks like about 27k AS numbers comprise all of the ipv6 usage. I stand corrected, looks like mostly mobile and Amazon for the US and then the rest is several other countries that are primarily using ipv6. [1] - https://www.cidr-report.org/v6/as2.0/#Aggs https://www.cidr-report.org/v6/as2.0/#Aggs
  - solarkraft 6y ago
    Side note: Try browsing the internet v6-only. It's pretty eye opening.

viktorcode 6y ago

> WebRTC implementations are required to support both Google's free-to-use VP8 video codec and H.264 for processing video. I understand that backwards compatibility is very important, but this adds to technical debt.

Sean-Der 6y ago
It is pretty nice to have both! For beefier machines VP8 works great, and you don't need to worry about cost. For IoT/Embedded space you usually just get H264 (from a hardware encoder). If we didn't have both I think it would shut out a lot of interesting use cases.
dane-pgp 6y ago
I don't know if people remember the fraught Codec War of 2014, but the choice of VP8 and H.264 both being "Mandatory To Implement" was the compromise that the IETF reached, despite much opposition from both sides.[0] As often happens with wars, though, the outcome in 2014 wasn't enough to permanently settle the matter, and there was a further outbreak of fighting later between VP9 and HEVC. More recently, some are saying[1] that the Codec Wars are back, with the arrival of AV1 as a contender. [0] https://bloggeek.me/winners-losers-webrtc-video-mti/ https://bloggeek.me/winners-losers-webrtc-video-mti/ [1] https://bloggeek.me/av1-vs-hevc-webrtc-codec/ https://bloggeek.me/av1-vs-hevc-webrtc-codec/
userbinator 6y ago
IMHO it would've been better if they specified some clearly out-of-patent and also simple-to-implement codec like H.261 or MPEG-1 as a minimal requrement.

aerovistae 6y ago

I have tried using this API and found it incredibly technical and complex. Personally I find the PeerJS library an excellent wrapper rendering it useable. Hopefully over time it will become more accessible.

afavour 6y ago
I think that what it's doing is sufficiently complex that the API is always going to be difficult. As long as abstractions like PeerJS exist I'm OK with that.
kaycebasques 6y ago
Any specific problems you recall?
amelius 6y ago
The main achievement of the technology is to work around the shortcomings of other technologies. Complex might be the wrong word as it's not rocket science; convoluted sounds better.
throw_m239339 6y ago
> I have tried using this API and found it incredibly technical and complex. It is meant to be relatively low level. It's like WebGL, in order to draw a simple square on the canvas it takes likes 50 lines of code just to bind attributes to buffers and stuff, link, compile your shaders and execute the program on the GPU. It takes 3 lines with Three.js. You are probably not meant to use it directly if you don't know the domain, but use a library. So I'd argue that if every single WebAPI was like that, the web would have been a failure. At the same time, it's also a great playground if you INTEND to learn some things that can be useful OUTSIDE the browser. For instance, WebGL knowledge can be directly transferred to any OPENGL application, because the API is similar to C or C++ version of it.
- kwindla 6y ago
  I think the comparison to WebGL is apt. It's also worth adding that scaling WebRTC -- both to calls with more than a few participants, and to large numbers of users on a service -- is still a bit of a specialized undertaking. Partly because it's intended to be a really, really flexible API, the abstractions are pretty leaky. You end up learning a lot about video codecs, UDP and RTP networking, and browser implementation details as you build out WebRTC applications! (I'm the cofounder Daily.co of a YC company that tries to make WebRTC "just a few lines of code" for common use cases, and to be the best possible application-level APIs and global infrastructure for advanced developers.)

ocdtrekkie 6y ago

Probably an issue that should've gotten addressed ahead of standardization, IMHO: https://github.com/w3c/webappsec-csp/issues/92 https://github.com/w3c/webappsec-csp/issues/92

chovybizzass 6y ago

i always stayed away from WebRTC because of that tunnel thing that seemed like a real pain in the a55

lxe 6y ago

I've dabbled with WebRTC API over the years, and I think I understand and can explain fairly clearly (to myself) the user's end of it. Having said that, it's an absolute nightmare of an API that should probably be re-done from scratch.

kaycebasques 6y ago
Any specific problems you recall?

TrueGeek 6y ago

Can we now get support for it in Safari WebView on iOS?

GZJOHN 6y ago
Apple is the new Microsoft when it comes to foot dragging, don't hold your breath.
saagarjha 6y ago
Doesn't iOS Safari already support WebRTC?
- TrueGeek 6y ago
  Safari does, and SFControllerView does. WKWebView does not. Which means apps can’t use WebRTC inside simple WebViews, and Chrome can’t support WebRTC on iOS.
  - saagarjha 6y ago
    Oh, hmm. That's quite unfortunate…
pgo 6y ago
Didn't we get support for it last month

thomzane 6y ago

Jitsi made it into the announcement!

ChrisArchitect 6y ago

how far this has come.....from a dream, over 10 years ago, to this. I know it still seems complicated in some regards etc but the possibility of video over web, p2p capabilities etc instead of having to use terrible apps, Apple stuff, quicktime, etc just to have some video conferencing....was a pipe dream

qwerty456127 6y ago

Does it still leak IP addresses?

nostrebored 6y ago
No, the negotiation phase doesn't leak ip addresses anymore
miohtama 6y ago
Here is the standard discussion how to limit IP exposure: https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candi... It is a trade off as this would also prevent applications like snapdrop.net working in the local network.
deleted 6y ago
[deleted]

ElijahLynn 6y ago

Here is the link to the WebRTC specification 1.0, published Jan 26, 2021: https://www.w3.org/TR/webrtc/ https://www.w3.org/TR/webrtc/

deleted 6y ago

[deleted]

est 6y ago

Still requires signal server. Is it possible to avoid the signal server in some way? So we can have true p2p network inside a browser directly.

azernik 6y ago
If you're willing to solve the discovery and NAT traversal problems yourself, but it's perfectly doable - AFAIU the WebRTC protocol doesn't care how you solve those problems, just that you do. See e.g. this little demo: https://github.com/lesmana/webrtc-without-signaling-server https://github.com/lesmana/webrtc-without-signaling-server
- est 6y ago
  If two browsers are inside the same LAN, are they able to communicate with each other directly without any server?
  - nerdbaggy 6y ago
    Yup. And if one of the servers is on a public IP then no other servers generally needed
  - azernik 6y ago
    Or if both are on un-NATted IPv6, and can get open ports through their respective firewalls. Specifically, you need to construct an object[1] that kind of looks like an SDP[2] message and pass it into the API; the demo applications generally get this from a signalling server, but you can make it based on whatever input you want. [1] https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidateInit https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandi... [2] https://developer.mozilla.org/en-US/docs/Glossary/SDP https://developer.mozilla.org/en-US/docs/Glossary/SDP
    - est 6y ago
      looks like the only useful info in the SDP are the `a=fingerprint:sha-256 ` line, and the `a=candidate:` for the actual IP. Anything else can be hard-coded in both peers. Is there a way to further strip down the long-ass sha-256 fingerprint? A 6 digit pin should be sufficient for communications inside a LAN.

seeyacall 6y ago

hi, nice to contact you . Here is a HOT strangers random video call app :Seeya-online video chat.To find a girl friend, boy friend, foreign friends , nearby friends FACE TO FACE Click link and download: Click this link : http://www.seeya.video/ http://www.seeya.video/ Thanks babe.

dep_b 6y ago

I've done WebRTC cross-platform between iOS, Android and web browsers (in the end only Chrome...wasn't the web developer though, perhaps it was fixable) and I can tell you even while you're using Chrome, an OS built by the creator of Chrome and the WebRTC part of Chrome repackaged as an iOS library there were many, many caveats getting a solid connection. And the fun of iOS background modes while getting an incoming call. Of course the Google examples were all broken in their own little devious way. And there is really jack shit on WebRTC on the web, seems like everybody that figured it out just said "fuck it I'm not giving away this for free" after spending possibly months to get it working. Though some people here seem to complain about no audio or no video...I have to say once we got it working it kept working. Sometimes the websocket we used for signalling dropped it's connection but the video call kept on trucking on some really bad WiFi!

ximm 6y ago

AFAIU there need to be more than one independent implementation to reach recommendation status. Last time I checked chrome and firefox both used the google implementation[0]. Has this changed? Which other implementations do exist? [0]: https://webrtc.googlesource.com/src/ https://webrtc.googlesource.com/src/

deleted 6y ago
[deleted]
detaro 6y ago
The W3C process does not strictly require independent implementations. It's a good safeguard against issues, and not having it opens the spec up to questions, but this has been covered elsewhere in the case of WebRTC: Multiple independent protocol implementations exist (and the protocol part was handled at IETF, through their processes), so interoperability on protocol level has been shown even if browsers happened to pick the same one. The W3C spec describes the wrapping JS APIs, sufficiency of that spec has been shown by the browsers independently building those layers around a WebRTC library. Especially given the working real-world use WebRTC already has it those two layers combined are a good argument that the spec is suitable.

wejick 6y ago

AFAIK WebRTC is already widely adopted, so what does it mean actually for most of the people?

baxuz 6y ago

Oh nice! Can't wait for streaming services like Twitch, Mux, or even Azure Streaming Services to accept WebRTC!

dikaio 6y ago

Anyone have a good open-source webrtc project? I’d like to donate this domain to the cause https://webrtc.io https://webrtc.io