webrtc-echoes VS stun

I am really excited about https://github.com/sepfy/libpeer. It has examples ready for ESP32 etc....

When working on KVS I wasn't familiar with the embedded space at all. I saw 'heavyweight' embedded where you were running on Linux. Then you had RTOS/No OS at all. I wasn't prepared for these devices at all. If we can make WebRTC work in the embedded space I think it will really accelerate what developers are able to build!

Remotely driven cars, security cameras, robots in hospitals that bring iPads to infectious patients etc... Creative people are building amazing things. The WebRTC/video space needs to work harder and support them :)

-----

I love how diverse the WebRTC space is now. Outside of this implementation you have plenty of other options!

* https://github.com/shinyoshiaki/werift-webrtc (Typescript)

* https://github.com/pion/webrtc (Golang)

* https://github.com/webrtc-rs/webrtc (Rust)

* https://github.com/algesten/str0m (Rust)

* hhttps://github.com/sepfy/libpeer (C/Embedded)

* https://webrtc.googlesource.com/src/ (C++)

* https://github.com/sipsorcery-org/sipsorcery (C#)

* https://github.com/paullouisageneau/libdatachannel (C++)

* https://github.com/elixir-webrtc (Elixir)

* https://github.com/aiortc/aiortc (Python)

* GStreamer’s webrtcbin (C)

See https://github.com/sipsorcery/webrtc-echoes for examples of some running against each other.

Lots of other WebRTC implementation exist (in many languages). Happy to help if you have any questions

See https://github.com/sipsorcery/webrtc-echoes for examples of all of them running against each other.

Lots of great WebRTC implementations exist. Do you want to stick with node.js?

I am a big fan of https://github.com/shinyoshiaki/werift-webrtc it is pure Typescript.

Check out https://github.com/sipsorcery/webrtc-echoes for all the other implementations.

WebRTC has so many great implementations now! The author of the C# implementation started a really great project webrtc-echoes[0] that shows them all working together.

The next big challenge in the space seems to be getting widely available congestion control. The hard part is making sure it is understandable and customizable for everyones use cases.

[0] https://github.com/sipsorcery/webrtc-echoes

This isn't true.

In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-...

Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch.

Also if possible I would avoid the terms `Full-cone NAT` and `Symmetric NAT` they don't do a good job of describing what is actually happening. NAT Mapping/NAT Filtering is the best way to describe it. I wrote a little bit about it here [0]. To see what type of NAT you have try stun-nat-behaviour[1]

[0] https://webrtcforthecurious.com/docs/03-connecting/#nat-mapp...

[1] https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...

If you test your NAT on the destination via a tool like https://github.com/pion/stun/tree/master/cmd/stun-nat-behaviour, what does it report for mapping and filtering?