4 ms·

Some signaling strategies for WebRTC: - WebSockets - XHR and other Comet options - SIP over WebSockets - XMPP/Jingle - WebRTC's Data Channel Obviously, on

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.

valera_rozuvan 6y ago
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/infrastructure https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...
- sktrdie 6y ago
  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.
  - SahAssar 6y ago
    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.
    - sktrdie 6y ago
      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 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.
      - SahAssar 6y ago
        As you see if you run that it is a request-response like flow. So sure you can send the initial offer in the URL, but then you somehow need to get the answer back to the initiator. So while you can have a initatior URL sent to the responder and then the responder send back a URL to the initiator that is still not "click link and you are connected". Handling signaling is pretty much the easiest bit of webrtc as it is basically just a HTTP/websocket echo server with some ID or similar for the meeting. If you have a websocket server (or REST & SSE as I i usually do) you can just have meet.example/{meetingId} and echo everything on meetingId to all others on the same meetingId. That is as simple as the web chat examples that thousands of beginner programmers create their first year. You should also consider that the signaling info (called the SDP) does not have a set lifetime and can in some cases be valid indefinitely and in some cases just valid for less that a minute, so if you encode the SDP in the URL you: 1. Can't setup a meeting URL beforehand which is how most people want them to work. 2. Need a back-and-forth over some other medium like email/chat/pigeon.
        sktrdie 6y ago
        But it's a very similar flow as you'd normally do with a URL no? - You'd send someone a link such as http://chat.com/#id http://chat.com/#id - Other person opens http://chat.com/#id http://chat.com/#id redirects to another url, and this other url (http://chat.com/#someOtherId http://chat.com/#someOtherId) is sent back to creator - Creator clicks on link again So it's just adding an extra step where the owner needs to also click on a new URL. But I agree since signalling server is rather dumb this can probably also be outsourced by a "public signalling server"?
        SahAssar 6y ago
        Yeah, that is possible but my point is that it sorta breaks how people are used to join these kinds of meetings. The back and forth required is not the expectation most people have. If you have more people then you'd need to do this once per person, (after that they can gossip the SDP over data channels to find the other participants). Usual flow: 1. I and other people go to meet.example/DiscussImportantStuff Your proposed flow: 1. I go to meet.example/DiscussImportantStuff (and it generates my sdp in the background and appends it to URL) 2. I send meet.example/DiscussImportantStuff#MySDPHere to my friend 3. He goes to meet.example/DiscussImportantStuff#MySDPHere (and it generates an answer SDP and replaces it to URL) 4. He sends me back meet.example/DiscussImportantStuff#FriendsSDPHere 5. I go to that link and we are connected. Repeat steps 2-5 for each participant. Considering how little technical complexity is saved and that you still need to have some sort of communication channel set up I don't think the proposed flow is worth it.
- k__ 6y ago
  You need a signaling channel to your peer. This doesn't have to be a server, but it makes things simpler.
  - ChristianBundy 6y ago
    My preference is IPoAC.
    - RcrdBrt 6y ago
      I think that adds up some latency
SahAssar 6y ago
> 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?
- littlestymaar 6y ago
  In a 1 to 1 setting, it obviously doesn't work. But in a mesh setting with n connected peers, when you want to add a new peer, you can perform the first signaling step via a server to connect with one member of the mesh, and then do all the subsequent signaling through this peer. This way, to set-up a mesh with n users you only need n-1 signaling messages processes by your server (down from n(n-1)/2 if you perform everything through a centralized signaling server). In practice, I know nobody who does that though. I don't think the extra complexity is worth it if your mesh are never really big, and with WebRTC, you rarely encounter situations where you have more than a few peers in the same mesh (Google Chrome even used to struggle a lot if you had more than a few dataChannel opened on the same page, while Firefox handled hundreds of connexions without issue).
  - SahAssar 6y ago
    Ah, yeah, I was thinking of the initial connection. I guess the mesh needs to be pretty small so that you can have a fully connected mesh or you'd need some way to deal with netsplits and a gossip-style protocol for discovery of new nodes, right?
barbegal 6y ago
You can signal in more ways than this: email, QR code or any method that can transfer a small amount of data [1]. You do need to think of the security of this channel though as it forms the basis of authenticating the other party through the fingerprint attribute in the signaled SDP payload [2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Session_lifetime#Signaling https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://rtcweb-wg.github.io/security-arch/ https://rtcweb-wg.github.io/security-arch/
- k__ 6y ago
  I did it via WhatsApp and copying data from TextAreas the first time I played around with it.
kodablah 6y ago
For my project that has a server side peer connection, I use a simple HTTP POST from the browser via fetch with the offer that responds with the answer. Then as I need renegotiation, I send the offer from the server side over the data channel and wait for the client side answer back over the data channel. Works fine.
dboreham 6y ago
> WebRTC's Data Channel Whoops turtles..

valera_rozuvan 6y ago

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/infrastructure https://www.html5rocks.com/en/tutorials/webrtc/infrastructur...

sktrdie 6y ago
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.
- SahAssar 6y ago
  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.
  - sktrdie 6y ago
    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 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.
    - SahAssar 6y ago
      As you see if you run that it is a request-response like flow. So sure you can send the initial offer in the URL, but then you somehow need to get the answer back to the initiator. So while you can have a initatior URL sent to the responder and then the responder send back a URL to the initiator that is still not "click link and you are connected". Handling signaling is pretty much the easiest bit of webrtc as it is basically just a HTTP/websocket echo server with some ID or similar for the meeting. If you have a websocket server (or REST & SSE as I i usually do) you can just have meet.example/{meetingId} and echo everything on meetingId to all others on the same meetingId. That is as simple as the web chat examples that thousands of beginner programmers create their first year. You should also consider that the signaling info (called the SDP) does not have a set lifetime and can in some cases be valid indefinitely and in some cases just valid for less that a minute, so if you encode the SDP in the URL you: 1. Can't setup a meeting URL beforehand which is how most people want them to work. 2. Need a back-and-forth over some other medium like email/chat/pigeon.
      - sktrdie 6y ago
        But it's a very similar flow as you'd normally do with a URL no? - You'd send someone a link such as http://chat.com/#id http://chat.com/#id - Other person opens http://chat.com/#id http://chat.com/#id redirects to another url, and this other url (http://chat.com/#someOtherId http://chat.com/#someOtherId) is sent back to creator - Creator clicks on link again So it's just adding an extra step where the owner needs to also click on a new URL. But I agree since signalling server is rather dumb this can probably also be outsourced by a "public signalling server"?
        SahAssar 6y ago
        Yeah, that is possible but my point is that it sorta breaks how people are used to join these kinds of meetings. The back and forth required is not the expectation most people have. If you have more people then you'd need to do this once per person, (after that they can gossip the SDP over data channels to find the other participants). Usual flow: 1. I and other people go to meet.example/DiscussImportantStuff Your proposed flow: 1. I go to meet.example/DiscussImportantStuff (and it generates my sdp in the background and appends it to URL) 2. I send meet.example/DiscussImportantStuff#MySDPHere to my friend 3. He goes to meet.example/DiscussImportantStuff#MySDPHere (and it generates an answer SDP and replaces it to URL) 4. He sends me back meet.example/DiscussImportantStuff#FriendsSDPHere 5. I go to that link and we are connected. Repeat steps 2-5 for each participant. Considering how little technical complexity is saved and that you still need to have some sort of communication channel set up I don't think the proposed flow is worth it.
k__ 6y ago
You need a signaling channel to your peer. This doesn't have to be a server, but it makes things simpler.
- ChristianBundy 6y ago
  My preference is IPoAC.
  - RcrdBrt 6y ago
    I think that adds up some latency

SahAssar 6y ago

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

littlestymaar 6y ago
In a 1 to 1 setting, it obviously doesn't work. But in a mesh setting with n connected peers, when you want to add a new peer, you can perform the first signaling step via a server to connect with one member of the mesh, and then do all the subsequent signaling through this peer. This way, to set-up a mesh with n users you only need n-1 signaling messages processes by your server (down from n(n-1)/2 if you perform everything through a centralized signaling server). In practice, I know nobody who does that though. I don't think the extra complexity is worth it if your mesh are never really big, and with WebRTC, you rarely encounter situations where you have more than a few peers in the same mesh (Google Chrome even used to struggle a lot if you had more than a few dataChannel opened on the same page, while Firefox handled hundreds of connexions without issue).
- SahAssar 6y ago
  Ah, yeah, I was thinking of the initial connection. I guess the mesh needs to be pretty small so that you can have a fully connected mesh or you'd need some way to deal with netsplits and a gossip-style protocol for discovery of new nodes, right?

barbegal 6y ago

You can signal in more ways than this: email, QR code or any method that can transfer a small amount of data [1]. You do need to think of the security of this channel though as it forms the basis of authenticating the other party through the fingerprint attribute in the signaled SDP payload [2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Session_lifetime#Signaling https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://rtcweb-wg.github.io/security-arch/ https://rtcweb-wg.github.io/security-arch/

k__ 6y ago
I did it via WhatsApp and copying data from TextAreas the first time I played around with it.

kodablah 6y ago

For my project that has a server side peer connection, I use a simple HTTP POST from the browser via fetch with the offer that responds with the answer. Then as I need renegotiation, I send the offer from the server side over the data channel and wait for the client side answer back over the data channel. Works fine.

dboreham 6y ago

> WebRTC's Data Channel Whoops turtles..