Works on same network but not on diffferent networks

[M0LTE]

Hi there

When spinning up webrtc-cli on one machine and your HTML sample in a browser on another machine on the same network, audio flows fine.

When one machine is moved to a different network, the audio never connects.

Both networks are behind NAT, one is my home internet connection, the other is my laptop tethered to my phone using its 4G.

I notice you can specify a STUN server in webrtc-cli, but the internet suggests this may not be enough, and TURN might be needed.

Any ideas? I can grab wireshark traces if helpful.

Cheers.

[gavv]

Sorry for late reply.

Hm, both STUN and TURN are implemented by pion framework. Although our parameter is called STUN, it seems that actually can be both STUN or TURN url.

(I guess we should rename --stun to --ice).

So you can just try to provide an url of a TURN server (starting with turn: or turns:). AFAIK, google doesn't provide a free TURN server. So you'll have to find another one or run your own.

Unfortunately I didn't work with TURN before, so can't provide more details. Let me know if I can help somehow.

[M0LTE]

Good pointer, thanks. Great software too, by the way.

Can I just clarify, would you have expected webrtc-cli to have worked in the scenario I described, or is this expected?

[gavv]

So far I used webrtc-cli only when one of the hosts was behind NAT, and on the other host a range of ports was open. However, WebRTC is supposed to work with both hosts behind the NAT too, so if Pion implements everything needed, it should work. However probably there are some difficulties with finding or running a TURN server, I don't know.

[gavv]

I guess we should rename --stun to --ice

Done. (--stun is still present for compatibility, but is now deprecated).

[M0LTE]

So far I used webrtc-cli only when one of the hosts was behind NAT, and on the other host a range of ports was open. However, WebRTC is supposed to work with both hosts behind the NAT too, so if Pion implements everything needed, it should work. However probably there are some difficulties with finding or running a TURN server, I don't know.

Okay, I’ll give TURN a go and report back.

[M0LTE]

Hi @gavv
I've spun up a TURN server.
While STUN servers don't seem to require authentication, since TURN servers cost real money to host and run they generally do seem to require authentication.
My Go isn't very good, but here, it looks like just a URL is being passed, with no obvious way to pass any credentials.
This spec looks to suggest that parameters other than "urls" are available - username and credential.
Is there any chance of you adding this support please?
I can provide a URL, username and password if you wish for testing.
Thank you!

[gavv]

I've added --ice-username and --ice-password options and pushed them to ice branch. Could you check it please?

If it wont work, yes you could send me credentials so I can debug it..

BTW, what TURN server are you using?

BTW2, have you looked at http://numb.viagenie.ca/ ?

[M0LTE]

Hey, I'm seeing:

a=end-of-candidates
-------------------------->8--------------------------
Starting recording...
ICE connection state changed to checking
Starting playback...
ICE connection state changed to failed

I appear to get the same thing with a numb.viagenie.ca account.

I'll try and find a way to send you creds to my (unverified) TURN server securely.

[M0LTE]

Yeah I can confirm I see the same using --ice turn:numb.viagenie.ca:3478 --ice-username [email protected] --ice-password xxxxxxx whereas the browser reaches "connected"

[M0LTE]

Hey @gavv sorry to pester but anything I can do to help with the above?

[elmeyer]

Hi! First of all thanks @gavv for this great piece of software, it's been very useful for us already.

Now, to the issue: Relay via TURN servers will not work with webrtc-cli in its current state, because the final choice of relay candidates for the communication has to happen over the signaling channel. One of the involved parties (called the controlling agent) has to nominate candidates and inform the other party/parties (the controlled agent(s)) of their choice of best candidate that should be used, which happens after the initial SDP exchange. So the current solution of copying SDP around is not enough for this, also because the signaling channel is technically meant to be permanently open, so that new candidates can be picked in case of network changes.

We've been working on adding simple signaling via WebSockets to webrtc-cli, but it needs some more time before it's ready. Planning to make a PR once it's working.

[M0LTE]

This is fantastic @elmeyer thank you so much!

[gavv]

Sorry for late reply again, being busy and tired these days.

@M0LTE Thanks for checking it out.

@elmeyer Thanks for the detailed explanation. Looking forward for a PR!

[trojek]

Hi.

Are there any plans to implement turn server support?

[M0LTE]

@elmeyer any progress on your work? Would dearly love to see this.

[elmeyer]

Sorry, cannot give an ETA yet. I'm changing jobs at the moment which will delay things for a while, but I have not forgotten about this.

[M0LTE]

Hey @elmeyer how's the job move? :-)

[M0LTE]

@gavv In lieu of the solution from @elmeyer I had the maybe daft idea of putting two copies of webrtc-cli back-to-back on a box with a public IP, then have each of the clients behind NATs connect to one of the two instances of webrtc-cli. Besides some fiddly orchestration, can you see that working?

[soundex-dele]

If you want to connect two webrtc-cli on the public network, you need to set up a turn server and a signaling server (I use websocket). After the answer and offer are exchanged for sdp, you also need to exchange the candidates. Use AddICECandidate on both client to add candidates.

[elmeyer]

Hi all. @M0LTE, thanks for asking - job move going well so far and I'm enjoying the new work. However life has managed to throw yet more stuff in the way, so still no ETA... sorry. @X-Dele's comment describes almost exactly what is needed, though (you don't strictly need a TURN server depending on your network setup; STUN may suffice). The solution we have is, as I mentioned, also based on a simple WebSocket listener. It just has to be part of webrtc-cli since the post-initial-offer/answer candidate exchange (as of yet not present in webrtc-cli) needs (multiple) AddICECandidate calls and therefore a more persistent signaling connection.

[gavv]

@gavv In lieu of the solution from @elmeyer I had the maybe daft idea of putting two copies of webrtc-cli back-to-back on a box with a public IP, then have each of the clients behind NATs connect to one of the two instances of webrtc-cli. Besides some fiddly orchestration, can you see that working?

Yes, I guess this would work, with a cost of higher latency.