Force using TRUN server in ICE candidate

[DotanS]

Hi,

I set up STUN/TURN server, and would like that both peers relay the media through it.

I changed the ICE candidates before passing them from one peer to another by replacing the ICE transport from 'host' to 'relay' and replacing host IP/PORT with TURN server IP/PORT.

I can see that traffic is hitting TURN server, but no video/audio on both sides.

Attached TURN server console log.

Please advise

[Oleg Moskalenko]

In your log, I see several problems with your setup:

1) There is no authentication going on. You run the TURN server in anonymous mode. WebRTC requires authentication.
2) I do not see CREATE_PERMISSION and/or BIND_CHANNEL commands in the log. It means that your client is not finishing the session setup. I guess because the server is not requiring authentication.

Read the wiki page on the project site, the turnserver wiki page section "WebRTC", it describes how you have to set the TURN server for WebRTC. ALso, there are links on the front page of the project with information about WebRTC usage.

http://code.google.com/p/rfc5766-turn-server/

[Anders Both]

Offcause your turn server needs to work first. (as Oleg mention)

Besides this, to force that relay/turn is always used, just ignore all candiates received from the other peer that does not contain the word "relay".

[Iwan Budi Kusnanto]

I have done something like this with jssip & rfc5766-turn-server. What
i have done:
- leave stun servers config empty
- set turn server config to your rfc5766-turn-server with username and
credential
- set rfc5766-turn-server to 'no stun' mode, it will ignore all STUN request.

>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss-webrt...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Iwan Budi Kusnanto

[DotanS]

I did the following changes:

1. turnserver: modify config file turnserver.conf

- uncomment option:  lt-cred-mech

- set option: realm=mycompany

2. turnadmin: add user

$ turnadmin -a -u myuser -r mycompany -p mypassword

turnuserdb.conf:

myuser:0xf41ae10e00697bfee0c899c1888543db

3. WebRTC: Peer Connection configuration

var stun =

{

     'url': 'stun:10.56.39.203:3478'

};

var turn = 

{

     'url': 'turn:myu...@10.56.39.203:3478',

     'credential': 'mypassword'

};

var config = 

{

  'iceServers': [ stun , turn ]

};

4. I am getting the following output from turnserver console:

552: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.149.174.60:54401

552: user <>: incoming packet BINDING processed, success

552: user <>: incoming packet BINDING processed, success

552: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.149.174.60:54402

552: user <>: incoming packet message processed, error 401

552: user <>: incoming packet BINDING processed, success

552: user <>: incoming packet message processed, error 401

553: user <>: incoming packet BINDING processed, success

553: user <>: incoming packet message processed, error 401

554: user <>: incoming packet BINDING processed, success

554: user <>: incoming packet message processed, error 401

555: user <>: incoming packet BINDING processed, success

555: user <>: incoming packet message processed, error 401

557: user <>: incoming packet BINDING processed, success

557: user <>: incoming packet message processed, error 401

558: user <>: incoming packet BINDING processed, success

558: user <>: incoming packet message processed, error 401

560: user <>: incoming packet BINDING processed, success

560: user <>: incoming packet message processed, error 401

562: user <>: incoming packet BINDING processed, success

562: user <>: incoming packet BINDING processed, success

562: user <>: incoming packet BINDING processed, success

563: user <>: incoming packet BINDING processed, success

563: user <>: incoming packet BINDING processed, success

565: user <>: incoming packet BINDING processed, success

567: user <>: incoming packet BINDING processed, success

568: user <>: incoming packet BINDING processed, success

570: user <>: incoming packet BINDING processed, success

571: user <>: incoming packet BINDING processed, success

572: user <>: incoming packet BINDING processed, success

572: user <>: incoming packet BINDING processed, success

572: user <>: incoming packet BINDING processed, success

573: user <>: incoming packet BINDING processed, success

575: user <>: incoming packet BINDING processed, success

576: user <>: incoming packet BINDING processed, success

578: user <>: incoming packet BINDING processed, success

579: user <>: incoming packet BINDING processed, success

581: user <>: incoming packet BINDING processed, success

581: user <>: incoming packet BINDING processed, success

581: user <>: incoming packet BINDING processed, success

582: user <>: incoming packet BINDING processed, success

612: TURN connection closed (non-mobile pattern), user <>

612: TURN connection closed (non-mobile pattern), user <>

[Oleg Moskalenko]

try to add option "-b turnuserdb.conf" to the turnserver command line, and also add -f.

Oleg

[DotanS]

Hi Oleg,

I did what you suggested, but still no video/audio. Also, seems the TURN connection is closed. TURN server logs attached.

Just to clarify, in order to force using TURN server, I change the ICE candidates of both sides as the following example:

Origin ICE candidate:

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:812970409 1 udp 2113937151 10.149.174.60 49766 typ host generation 0\r\n"}

Changed ICE candidate:

{"sdpMLineIndex":0,"sdpMid":"audio","candidate":"a=candidate:812970409 1 udp 2113937151 10.56.39.203 3478 typ relay generation 0\r\n"}

As you can see, I replaced the 'typ' from host to relay, and the IP/port of the local peer to the IP/port of the TURN server.

Is it the correct way to force prres using TURN server as media relay?

[Anders Both]

Hi Dotans.

I dont think you can change the candidate like that. Just ignore the stun candidate. If the turn server is working, relay candidates will show up.

Best regards.

Anders Both

www.basechat.com

[DotanS]

Hi Anders,

Although I added the turn server to the peer connection configuration, the ice candidates I got are all of type=host. No relay candidates are received.
It is related that both peers are running on the same host? Does ice candidates of type relay are generated only in case when direct route is no available between the peers?

[SProgrammer]

@DotanS: FYI - this is a Chrome or WebRTC BUG and its not being resolved yet since 2012.

According to Alex suggestion you have to change the ENUM value to "relay" in his point 1, and in his point 2 he mentioned to do some tricks which is nonsense cause then the BUG is not resolved. But all those thing "how you do that yourself?" is nowhere/ never / ever explained nor documented regarding TURN relay. 

NOTE: As a result we are blaming either the TURN-SERVER is buggy!! or something else!!. 

the bottom line is that Chrome 33 (tested) did not fixed the TURN relay problem yet, which is causing it.

Question: Anyone has the update for this BUG issue or when it will be resolved please? even i force to use turn it says: type=host  instead of type=relay

[Oleg Moskalenko]

I see lots of BINDING requests with 420 error (unknown attribute). There may be only one case when the "unknown attribute" can appear in this case - if the ICE STUN requests are sent directly to the TURN server. In a correct situation, those STUN requests must be encapsulated in the TURN protocol ans sent to the peer (through TURN server). The ICE STUN requests indeed contain attributes which are never used for TURN server communications and are not known to the TURN server. If the TURN server sees them - then something is very wrong.

So, something very weird is happening in the ICE discovery procedure. I cannot say what. But that's not a TURN server problem. Somebody help him to set up his WebRTC client.

Oleg

[SProgrammer]

See here how to setup the TURN CLIENT for TURN SERVER: https://groups.google.com/forum/#!topic/discuss-webrtc/LKChBGTmA3c

Please note that i have been testing 2 weeks. Chrome 33 has problems with relay and turn.

Somebody should check and fix it in Chrome browser this relay issue. in my post you can see how to do it 

[SProgrammer]

Is this a BUG? Follow up: https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/EGcbuYhlIMQ

- Chrome 33 or Canary do not refresh the connection of TURN relay

- As a result after 5 or 10 or 15 minutes later the call automatically getting dropped

Its a BUG or there is keep-alive for turn relay? (tested with PjSIP, Bria and it works with there client)

[Mallinath Bareddy]

Chrome looks for LIFETIME attribute in allocate response before scheduling the refresh request. Otherwise it will not send refresh request.

[Oleg Moskalenko]

The TURN server rfc5766-turn-server always, unconditionally, includes the LIFETIME attribute in ALLOCATE response.

Oleg

[DotanS]

some updates:

1. manipulating ICE candidates in order to use TURN is not working

2. Chrome (version 33) is not supporting iceTransports=relay constraint

3. I succeeded generating relay ICE candidates when connecting to the TURN server via VPN tunnel. When connecting directly to the TURN server only host ICE candidates are generated.

[SProgrammer]

Please do the follow up here: https://groups.google.com/forum/#!topic/turn-server-project-rfc5766-turn-server/EGcbuYhlIMQ

(still the auto disconnect is happening on every attempts with random duration)

[DotanS]

My issue is that I do not get relay ICE candidate when connecting without VPN tunneling to the TURN server. Only host ICE candidate are being generated.

[Anders Both]

Dotan - I think its because you turnserver instalation is not right, or because something is wrong with your WebRTC client.

[Tarik Cicic]

Hi, is anybody directly involved in Chrome development reading this thread?  Using RTCIceTransports Enum as described in Section 4.2.3 http://dev.w3.org/2011/webrtc/editor/webrtc.html seems to be the right solution to this problem.  Any update on when this is going to be fixed / supported?  Thank you.

[DotanS]

Hi Anders,

TURN server installation is quite straight forward. The did change the following properties in turnserver.conf:

- enable verbose

- enable fingerprint

- enable lt-cred-mech

- enable realm

- enable log-file

On client side, I use the following configuration for the RTCPeerConnection:

var stun =

{

     'url': 'stun:10.56.39.203:3478'

};

var turn = 

{

     'url': 'turn:10.56.39.203:3478',

     'credential': 'mypassword',

     'username': 'myuser'

};

var pc_config = 

{

  'iceServers': [ stun , turn ]

};

var pc_constraints = 

{

'mandatory' :

{

'OfferToReceiveAudio' : true,

'OfferToReceiveVideo' : true,

'iceTransports': 'relay' 

},

};

[SProgrammer]

@DotanS: is your iceTransports relay value really doing relay, i do not think so? 

That is a Chrome BUG which seems not fixed. Did you re-open the BUG for that ?

please share that bug reference link here so that we can do the follow up.

};

[DotanS]

Hi SProgrammer,

There is an open bug related to ICE Transport.

See: https://code.google.com/p/webrtc/issues/detail?id=1179

However, my issue is that I am not receiving relay ICE candidates.

I would like to know if one succeeded getting relay ICE candidates when using TURN server on the same LAN.

[Alexandre GOUAILLARD]

hi dotans, 

Your issue is that you are not **creating** ICE candidates. You have a problem with ICE Gathering, not ICE Connection.

You can already rule out being on the same LAN as a potential problem.

In most of the case this is due to either:

- Wrong ice servers string

- Connection problem between your client and the TURN server (either transport protocol, or port)

- Identification problem between your client and the TURN server.

- problem on the TURN side

Lots of those steps, when failing, fail silently, or at the very least are invisible to the JS layer. You might want to run chrome from the command line with extra tracing arguments and check the generated logs, and/or run a debug version of chrome and/or fire wireshark to see what is happening on your client side. Since you have the VPN version generating candidate, you have a base for comparison, and it should due easy to see what is different in the failing case.

HTH.

alex.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[Alexandre GOUAILLARD]

Guys,

chances are high that it would not help you. Instead of trying to generate all possible candidate, it would try to generate only relay candidate.

it will not automagically start generating relay candidates if it was not generating them in the default case.

I would suggest that you look on the gathering side and investigate why you are not generating those candidates in the first place. Deja Vu?

[Anders Both]

Hi Dtoan. If you email me hostname, portnumber and some credentials
for your turnsserver. I can test if it is working.

Best regards

Anders Both
www.basechat.com

and...@basechat.com

[Justin Uberti]

I don't understand what you are trying to accomplish in your application, and why RTCIceTransports is needed.

If you think Chrome is malfunctioning, please file a new bug with details.

[DotanS]

Hi Alex,

My setup is that my client browser is on different subnet than the TURN server, but have route to it.

However, when I tested the same code on a different host which is on the same subnet as the TURN server, I succeeded get relay candidates.

So I guess its related to TURN configuration or credentials issue.

I had the TURN logs for both cases and they are different:

Client(10.56.39.24) on the same LAN as TURN server(10.56.39.203):

78919: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.56.39.24:63885

78919: user <>: incoming packet BINDING processed, success

78919: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.56.39.24:63886

78919: user <>: incoming packet message processed, error 401

78919: IPv4. Server relay addr: 10.56.39.203:3478

78919: IPv4. Local relay addr: 10.56.39.203:59187

78919: new: session id=003000000000000030, username=<myuser>, lifetime=600

78919: user <myuser>: incoming packet ALLOCATE processed, success

78929: user <>: incoming packet BINDING processed, success

78931: TURN connection closed (non-mobile pattern), user <>

78938: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.56.39.24:63896

78938: user <>: incoming packet BINDING processed, success

78938: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.56.39.24:63897

78938: user <>: incoming packet message processed, error 401

78938: IPv4. Server relay addr: 10.56.39.203:3478

78938: IPv4. Local relay addr: 10.56.39.203:52641

78938: new: session id=003000000000000032, username=<myuser>, lifetime=600

78938: user <myuser>: incoming packet ALLOCATE processed, success

Compare to:

Client(10.149.174.60) on different LAN of TURN server(10.56.39.203):

78962: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.149.174.60:50623

78962: user <>: incoming packet BINDING processed, success

78962: user <>: incoming packet BINDING processed, success

78962: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.149.174.60:50624

78962: user <>: incoming packet message processed, error 401

78963: user <>: incoming packet BINDING processed, success

78963: user <>: incoming packet message processed, error 401

78963: user <>: incoming packet BINDING processed, success

78963: user <>: incoming packet message processed, error 401

78964: user <>: incoming packet BINDING processed, success

78964: user <>: incoming packet message processed, error 401

78965: user <>: incoming packet BINDING processed, success

78965: user <>: incoming packet message processed, error 401

78967: user <>: incoming packet BINDING processed, success

78967: user <>: incoming packet message processed, error 401

78968: user <>: incoming packet BINDING processed, success

78969: user <>: incoming packet message processed, error 401

78970: user <>: incoming packet BINDING processed, success

78970: user <>: incoming packet message processed, error 401

78972: user <>: incoming packet BINDING processed, success

78972: user <>: incoming packet BINDING processed, success

78972: user <>: incoming packet BINDING processed, success

78972: user <>: incoming packet BINDING processed, success

78973: user <>: incoming packet BINDING processed, success

78975: user <>: incoming packet BINDING processed, success

78976: user <>: incoming packet BINDING processed, success

78978: user <>: incoming packet BINDING processed, success

78979: TURN connection closed (non-mobile pattern), user <>

78980: user <>: incoming packet BINDING processed, success

78981: user <>: incoming packet BINDING processed, success

78981: user <>: incoming packet BINDING processed, success

78982: user <>: incoming packet BINDING processed, success

78982: user <>: incoming packet BINDING processed, success

78983: user <>: incoming packet BINDING processed, success

78984: user <>: incoming packet BINDING processed, success

78986: user <>: incoming packet BINDING processed, success

78988: user <>: incoming packet BINDING processed, success

78989: user <>: incoming packet BINDING processed, success

78991: user <>: incoming packet BINDING processed, success

78991: user <>: incoming packet BINDING processed, success

78991: user <>: incoming packet BINDING processed, success

78992: user <>: incoming packet BINDING processed, success

78998: TURN connection closed (non-mobile pattern), user <>

79022: TURN connection closed (non-mobile pattern), user <>

79022: TURN connection closed (non-mobile pattern), user <>

79094: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.14.174.60:64700

79094: user <>: incoming packet BINDING processed, success

79094: user <>: incoming packet BINDING processed, success

79094: handle_udp_packet: New UDP endpoint: local addr 10.56.39.203:3478, remote addr 10.14.174.60:64701

79094: user <>: incoming packet message processed, error 401

79094: user <>: incoming packet BINDING processed, success

79094: user <>: incoming packet message processed, error 401

79094: user <>: incoming packet BINDING processed, success

79095: user <>: incoming packet message processed, error 401

79095: user <>: incoming packet BINDING processed, success

79095: user <>: incoming packet message processed, error 401

79097: user <>: incoming packet BINDING processed, success

79097: user <>: incoming packet message processed, error 401

79098: user <>: incoming packet BINDING processed, success

79099: user <>: incoming packet message processed, error 401

79100: user <>: incoming packet BINDING processed, success

79100: user <>: incoming packet message processed, error 401

79154: TURN connection closed (non-mobile pattern), user <>

79154: TURN connection closed (non-mobile pattern), user <>

79471: TURN connection closed (non-mobile pattern), user <myuser>

79471: delete: session id=003000000000000028, username=<myuser>

79519: TURN connection closed (non-mobile pattern), user <myuser>

79519: delete: session id=003000000000000030, username=<myuser>

79538: TURN connection closed (non-mobile pattern), user <myuser>

79538: delete: session id=003000000000000032, username=<myuser>

[Oleg Moskalenko]

In the second case, TURN relay is not involved - I see only STUN messages in the log.

Oleg

[DotanS]

Hi Oleg,

What make the difference, since the client code and TURN server configuration are the same in both cases?

[Oleg Moskalenko]

Network topology makes the difference. The decision how to proceed with the ICE process is made by the client, not by the server.

[DotanS]

Hi Oleg,

Some good news. I did STUN check from the subnet which had the issues(10.149.X.X) to the TURN server on 10.56.39.203, and the STUN binding failed.

Switching to TCP and retest STUN binding succeeded.

Next step - I configured TURN URL on client side using TCP and finally I got the relay candidates from TURN server.

Seems that UDP protocol is blocked between the two subnets, which cause to both STUN/TURN to fail. When I use VPN tunneling to the TURN server subnet thats override the UDP blocking issue.

[Oleg Moskalenko]

Cool

[Alexandre GOUAILLARD]

Happy we could help.

I forgot to mention two things that could have helped you, and maybe will in the future to test this specific problem:

- check-connectivity.com

- the ICE candidate test, which shows you for a given ICE server config what candidates chore would generate:

https://webrtc.googlecode.com/svn/trunk/samples/js/demos/html/ice-servers.html

[DotanS]

Thank you Alex, Oleg and the team!

[Jed]

This is what I'm seeing in the logs for my turn server. I'm seeing unauthorised with empty user then success with my user. It doesn't seem though the traffic is going through my server, after the success I don't see anymore log output. 

96: session 130000000000000001: user <>: incoming packet message processed, error 401: Unauthorised

96: IPv4. Server relay addr: 10.40.10.106:3478

96: IPv4. Local relay addr: 10.40.10.106:53887

96: session 130000000000000001: new, username=<turnrtc>, lifetime=600

96: session 130000000000000001: user <turnrtc>: incoming packet ALLOCATE processed, success

462: handle_udp_packet: New UDP endpoint: local addr 10.40.10.106:3478, remote addr 172.16.41.55:58392

462: session 130000000000000002: user <>: incoming packet message processed, error 401: Unauthorised

462: IPv4. Server relay addr: 10.40.10.106:3478

462: IPv4. Local relay addr: 10.40.10.106:53374

462: session 130000000000000002: new, username=<turnrtc>, lifetime=600

462: session 130000000000000002: user <turnrtc>: incoming packet ALLOCATE processed, success

496: handle_udp_packet: New UDP endpoint: local addr 10.40.10.106:3478, remote addr 172.16.41.212:35822

496: session 130000000000000003: user <>: incoming packet message processed, error 401: Unauthorised

496: IPv4. Server relay addr: 10.40.10.106:3478

496: IPv4. Local relay addr: 10.40.10.106:62130

496: session 130000000000000003: new, username=<turnrtc>, lifetime=600

496: session 130000000000000003: user <turnrtc>: incoming packet ALLOCATE processed, success

496: session 130000000000000003: user <turnrtc>: incoming packet CREATE_PERMISSION processed, success

496: session 130000000000000003: user <turnrtc>: incoming packet CREATE_PERMISSION processed, success

496: session 130000000000000003: user <turnrtc>: incoming packet CREATE_PERMISSION processed, success

610: handle_udp_packet: New UDP endpoint: local addr 10.40.10.106:3478, remote addr 172.16.41.55:55227

610: session 130000000000000004: user <>: incoming packet message processed, error 401: Unauthorised

610: IPv4. Server relay addr: 10.40.10.106:3478

610: IPv4. Local relay addr: 10.40.10.106:58072

610: session 130000000000000004: new, username=<turnrtc>, lifetime=600

610: session 130000000000000004: user <turnrtc>: incoming packet ALLOCATE processed, success

I've made the following changes to the AppRTCDemoActivity for android to try to force the app to use my local turn server. I already have "no-stun" uncomment in the turnserver.conf file :

 Changes I've made :

    private PeerConnection.IceServer requestTurnServer(String url) {

      try {

        URLConnection connection = (new URL(url)).openConnection();

        connection.addRequestProperty("user-agent", "Mozilla/5.0");

        connection.addRequestProperty("origin", "https://apprtc.appspot.com");

        String response = drainStream(connection.getInputStream());

        JSONObject responseJSON = new JSONObject(response);

        //change from 

        //String uri = responseJSON.getJSONArray("uris").getString(0);

        //String username = responseJSON.getString("username");

        //String password = responseJSON.getString("password");

      

         //to

        String username = "turnrtc";

        String password = "mypassword";

        String uri = "turn:10.40.10.106:3478?transport=udp";

        //

        return new PeerConnection.IceServer(uri, username, password);

      } catch (JSONException e) {

        throw new RuntimeException(e);

      } catch (IOException e) {

        throw new RuntimeException(e);

      }

    }

  }

I've also tried  sending candidate with "relay" type :

private class PCObserver implements PeerConnection.Observer {

    @Override public void onIceCandidate(final IceCandidate candidate){

     //jenco

runOnUiThread(new Runnable() {

          public void run() {

            JSONObject json = new JSONObject();

            jsonPut(json, "type", "candidate");

            jsonPut(json, "label", candidate.sdpMLineIndex);

            jsonPut(json, "id", candidate.sdpMid);

            jsonPut(json, "candidate", candidate.sdp);

            if(!candidate.sdp.contains("relay"))

            {

             return;

            }

            sendMessage(json);

          }

        });

    }