Modern and Cross Platform Stack for WebRTC
1–10 of 49 posts
Re: Modern and Cross Platform Stack for WebRTC
#2- WebSockets
- XHR and other Comet options
- SIP over WebSockets
- XMPP/Jingle
- WebRTC's Data Channel
Obviously, one would want the data channel (last option). There's some work done in this area. However, it's still not full featured.
Re: Modern and Cross Platform Stack for WebRTC
#3Some signaling strategies for WebRTC: - WebSockets - XHR and other Comet options - SIP over WebSockets - XMPP/Jingle - WebRTC's Data Channel Obviously, one would want the data channel (last option). There's some work done in this area. However, it's still not full featured.
WebRTC enables peer to peer communication.
BUT...
WebRTC still needs servers:
For clients to exchange metadata to coordinate communication: this is called signaling. To cope with network address translators (NATs) and firewalls.
-------------
[1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
Re: Modern and Cross Platform Stack for WebRTC
#4Re: Modern and Cross Platform Stack for WebRTC
#5Has anyone noticed "Modern and Cross Platform" usually means Golang?
Re: Modern and Cross Platform Stack for WebRTC
#6Re: Modern and Cross Platform Stack for WebRTC
#7Some signaling strategies for WebRTC: - WebSockets - XHR and other Comet options - SIP over WebSockets - XMPP/Jingle - WebRTC's Data Channel Obviously, one would want the data channel (last option). There's some work done in this area. However, it's still not full featured.
For anyone curious, there is a great article [1]. WebRTC enables peer to peer communication. BUT... WebRTC still needs servers: For clients to exchange metadata to coordinate communication: this is called signaling. To cope with network address translators (NATs) and firewalls. ------------- [1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
Re: Modern and Cross Platform Stack for WebRTC
#8Earlier quoted context omitted.
For anyone curious, there is a great article [1]. WebRTC enables peer to peer communication. BUT... WebRTC still needs servers: For clients to exchange metadata to coordinate communication: this is called signaling. To cope with network address translators (NATs) and firewalls. ------------- [1] https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
But you can use publicly available servers to do that no? STUN servers and such. So you don't need to roll our your own.
So you always need some form of signaling but that can be over email or even a handwritten note if you prefer, although it is usually done over HTTP/websockets.
STUN is required if you are behind some sort of NAT.
TURN is required if your NAT does not play well with hole-punching.
Re: Modern and Cross Platform Stack for WebRTC
#9Some signaling strategies for WebRTC: - WebSockets - XHR and other Comet options - SIP over WebSockets - XMPP/Jingle - WebRTC's Data Channel Obviously, one would want the data channel (last option). There's some work done in this area. However, it's still not full featured.
How would that even work? You need signaling to set up the data channel, so how could you handle signaling over a channel that isn't set up?
Re: Modern and Cross Platform Stack for WebRTC
#10Earlier quoted context omitted.
But you can use publicly available servers to do that no? STUN servers and such. So you don't need to roll our your own.
No, signaling is different from STUN. Signaling is basically pairing together the people who want to communicate so that they can get the info required to connect to each other, STUN is how they find out their public IP:port pairs and TURN is how they can talk over a proxy if direct communication fails. So you always need some form of signaling but that can be over email or even a handwritten note if you prefer, alth…
Here's a great example: https://jameshfisher.github.io/serverless-webrtc/index.html
Checkout the process in the console! For instance you can do the handshake the same way you'd send someone the URL of the actual thing.