Live data from Hacker News

Modern and Cross Platform Stack for WebRTC

github.com

1–10 of 49 posts

Re: Modern and Cross Platform Stack for WebRTC

#2
Some 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.

Re: Modern and Cross Platform Stack for WebRTC

#3

Some 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

#7

Some 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...

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.

Re: Modern and Cross Platform Stack for WebRTC

#8
post #7

Earlier 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.

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, 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

#9

Some 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.

> 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

#10
post #8
post #7

Earlier 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…

Ah indeed. But can't the handshaking be done without rolling our your own signaling server?

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.

Post reply on HN