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 my@email.com --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!