force use of TURN server

[bryand...@gmail.com]

Is it possible to tell a PeerConnection to always connect through the TURN server and to not attempt direct connection to a candidate contained in an offer?

One reason this could be desirable is to force a TCP connection on Firefox, which does not support ICE-TCP but does support TURN in Fx28.

[Kaiduan Xie]

You can force to use TURN server by dropping all other ICE candidates except relay candidate allocated by TURN server before sending out to other peer.

For example,

function onIceCandidate(event) {

    if (event.candidate) {

        console.log(\"onIceCandidate, \" + event.candidate.candidate);

        var components = event.candidate.candidate.split(\" \");

        if (components[7] == \"relay\") {

            var candidateMsg = {type: 'candidate',

                            label: event.candidate.sdpMLineIndex,

                            id: event.candidate.sdpMid,

                            candidate: event.candidate.candidate};

            send(candidateMsg);

        } else {

            console.log(\"Ignore local host.\");

        }

    } else {

        console.log(\"End of candidates.\");

    }

}

/Kaiduan

On Thu, Dec 12, 2013 at 1:48 PM, <bryand...@gmail.com> wrote:

Is it possible to tell a PeerConnection to always connect through the TURN server and to not attempt direct connection to a candidate contained in an offer?

One reason this could be desirable is to force a TCP connection on Firefox, which does not support ICE-TCP but does support TURN in Fx28.

--
 
---
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.

[bryand...@gmail.com]

Thanks for the reply, but I think that does not address my issue.  

In your example, client A gathers a relay candidate, puts it in an offer as the sole candidate, and sends that offer to client B.

Client B will then attempt to connect directly to the relay candidate, rather than going through a turn server, and will only use its TURN server if it fails to directly connect to A's relay candidate.

Please correct me if I am wrong, but I think that client A providing  only a relay candidate in no way requires client B to use a relay server to connect with that candidate.  In some cases, I want client B to always use TURN.

[Kaiduan Xie]

If you also drop all other candidates except relay candidate on B side, B should always use relay candidate.

/Kaiduan

[bryand...@gmail.com]

I'm not so sure about that.  While you can control the candidates sent to the remote peer, you don't directly control the generation of local candidates and which of them will be tried.  addIceCandidate adds remote candidates, not local. 

[Kaiduan Xie]

Of course, you can't directly control the generation of candidates locally (the candidate may be host, reflexive or relay). But during ICE check stage, if side A receives a STUN connectivity check request noted as STUNb from B, but if the source address of STUNb is not advertised by B, A will reject the connectivity check. In this case, only relay candidate is sent by B to A, so A will reject all other STUN connectivity check request from other candidates of B.

/Kaiduan

[bryand...@gmail.com]

Yes, obviously.  But my question was about whether it is possible to preclude all checks except TURN.  (As in subject: force use of TURN).  

If other candidate checks were to succeed, then they would be preferred over TURN.

Thanks anyway.