0

At the moment, my RWS (RPi-WebRTC-Streamer) application works on my local network. I am now trying to connect it to my hosted coTURN server.

My main_rws_orig.js is pointing at my coTurn server:

var localTestingUrl = "ws://10.0.0.11:8889/rws/ws";

//var pcConfig = {"iceServers": [{"urls": "stun:stun.l.google.com:19302"}]};

var pcConfig = {"iceServers": [{"urls": "stun:172.104.xxx.xxx:3478"}]};

In using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ I get the following when testing TURN and STUN:

0.009 rtp host 3376904655 udp c7f50fee-cbd0-4332-ae51-a013c4d35c5e.local 41771 126 | 30 | 255

0.091 rtp srflx 842163049 udp 42.116.95.19 41771 100 | 30 | 255

0.158 rtp relay 3617893847 udp 172.104.xxx.xxx 17857 2 | 30 | 255 39.809 Done 39.811

My coTurn web configuration tool is working also.

I have read about a signalling server, but have not found much documentation regarding it. I am just trying to figure out how to finish. How do connect my RWS application to the outside world using coturn.

Any tips or information will be greatly appreciated.

Harry Hobson
  • 37
  • 6

1 Answers1

0

A signalling server is basically a service that sends the ICE candidates betweens the peers of your conversation. Usually it uses Websockets for this communication. The ICE candidates may include the CoTurn server credentials you provide to the WebRTC Object in JavaScript. But you need to share all candidates between the participants and for THIS you need the signalling server. You can use any language that supports full websockets communication like NodeJS or Java (not PHP!).

Take a look at this article, it describes this very well: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#how-can-i-build-a-signaling-service

Except you explicitly want to use Peer-To-Peer WebRTC, I recommend you also to take a look at the tutorials of Kurento Media Server to get a better understanding of this principle, the NodeJS/Java is signalling between Kurento and your browser. Please note by using a media server it will be always in the middle between the participants, what has advantages like reducing the network usage of each participant + recording the whole conversation on the media server, but also disadvantages like no end-to-end encryption.

NodeJS example: https://doc-kurento.readthedocs.io/en/6.14.0/tutorials/node/tutorial-one2one.html

Java example: https://doc-kurento.readthedocs.io/en/6.14.0/tutorials/java/tutorial-one2one.html

Maxi
  • 415
  • 4
  • 24
  • Thank you for responding. My project is just a few Pi based cameras that can be controlled remotely. The video will be only one way. Two way audio maybe interesting. I will look at what sent to see if I can get something working. Thanks again! – Harry Hobson Jun 30 '20 at 09:27
  • To make things far easier for my application, I will NOT be using a NAT of any kind and the IP's will be externally visible. Do I still need a signalling server ? – Harry Hobson Jul 07 '20 at 04:02
  • Yes, NAT (=TURN Server) has nothing to do with signalling. A TURN server allows you to communicate with another peer even if he is behind a proxy/firewall, it is simply said a Socket-Relay. A signalling server you need to handshake with the other participant and share your ICE-candidates. Within the ICE candidates there may be included the TURN server and when the clients decides to use it, it will be used. But still you need to exchange the ICE candidates between the peers. Thats what the signalling server basically do. You can develop this with a simple Websocket Server + client impl. – Maxi Jul 07 '20 at 15:04