4

So I am trying to develop a web application that has the capability to make video calls between users of the web application. Theoretically, Caller A can look in a directory in the web application, see that Caller B is online and make a video call. My question is how do you get the IP and port number of Caller B? I realize that this information needs to be exchanged via signaling but how does Caller A ever get their information to Caller B if they don't know what Caller B's IP or port number are?

user3704351
  • 67
  • 2
  • 6
  • in webrtc, they discover each other through ICE candidates, which is why you would need a signalling server in the beginning – mido Feb 18 '16 at 01:40

2 Answers2

4

The peers discover each other through the ICE protocol. This is part of the normal WebRTC connection establishment. ICE has methods to discover the necessary information like IPs and ports.

What you need to worry about is getting the ICE candidates from one peer to the other. You do this via your signalling server. Peer A is discovering ICE candidates and will surface them to you on the RTCPeerConnection object; you take those candidates, send them to your server, the server sends them to peer B, where they must be incorporated into peer B's RTCPeerConnection; and the whole thing in reverse as well. Once enough ICE candidates have been exchanged and a matching possibility has been discovered, the two peers will establish a direct connection.

The implementation of the signalling server is left up to you and your particular needs.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • Thanks for clearing that up for me, getting the candidates to the other peer was the part that didn't make sense to me conceptually. – user3704351 Feb 20 '16 at 00:38
  • 1
    @Deceze , in your answer you needed an server , is their a way peers discover other peers without running server? "you take those candidates, send them to your server, the server sends them to peer B" this thing turns them into Client Server Model for making peers to connect – Akhil Surapuram May 10 '20 at 14:16
  • @Akhil You can of course exchange that information server-less, if you have some other P2P peer discovery mechanism. WebRTC leaves that part of the implementation entirely up to you. Realistically speaking in most web based scenarios you’ll likely need a server, but that’s no fixed requirement by WebRTC in any way. – deceze May 10 '20 at 18:47
  • @deceze , even to ask a peer about other peer's you need at that peer id or information to connect to that peer via ICE. – Akhil Surapuram May 10 '20 at 19:26
  • @deceze , is there possibility in this current tech having a pure p2p and Not like master and peer. Its okay if peers can't discover master than one of the peer can turn to master – Akhil Surapuram May 10 '20 at 19:32
  • 1
    @Akhil There sure are other protocols out there, but they are outside the scope of WebRTC and they probably don't work in a browser. Yes, there's a bit of a chicken and egg problem: if you already have some other P2P protocol that can do the negotiation, then why are you using a P2P protocol to bootstrap a P2P protocol? That's only sensible if your existing protocol doesn't do audio/video as well as WebRTC does; e.g. some local UDP broadcast protocol purely for peer discovery. – deceze May 10 '20 at 20:42
1

I agree with the comment above that ICE is critical here to exchange the media streams but I'm assuming you are asking this question from a signaling point of view.

One solution for this is a simple presence capability built on MQTT and a feature called retained messages. Basically, every client publishes a document to an MQTT topic in the form of a retained message that subscribers get. Retained messages stay on the broker until they are cleared by the client or when the client disconnects from the broker (using an MQTT Last Will and Testament message). The retained message contains information that can be used to connect to other peers (e.g. peer topic names). You can see a demo of it here: https://angular-rtcomm.wasdev.developer.ibm.com.

This is all implemented in open source. If you want to get a quick demo off the ground you can do it using Node.js with the Mosca MQTT broker and the Rtcomm open source. Takes about 20 mins to set up if you're familiar with Node. Instructions can be found at the link above.

bpulito
  • 646
  • 4
  • 7