Search code examples
webrtckurentoturn

Kurento : Client side TURN configuration


As per my understanding from my previous question : Kurento: STUN/TURN

The TURN server configured from webrtcendpoint.conf.ini is used only for exchanging ice candidates. Also we can specify only one TURN server in webrtcendpoint.conf.ini because What I have observed is that if i provide 2 or more TRUN server in webrtcendpoint.conf.ini Kurento media server service fails to start, is this correct ?

Also is there any way to verify which STUN/TURN server is being used at Kurento media server and between two peers?

The STUN/TURN which we provide in conferenceroom.js will be used for the actual media flow/mediapipeline between peers. Is this correct ?

If we provide multiple TURN servers in conferenceroom.js then the TURN server neatest/fastest response time will be selected for media flow between the two peers? Same as we get response time form this Link.

Also what I have observed is that if the TURN server provided in webrtcendpoint.conf.ini and conferenceroom.js are different then we are not able to see remote participants video but if both the TURN server are the same then I am able to see remote participants video. Is this correct ?

Edit 1:

In groupcall sample example we have onExistingParticipants() and onNewParticipants() where we can define iceServers in receiveVideo() and onExistingParticipants() so what will happen if we specify TURN server t1 in kurentoUtils.WebRtcPeer.WebRtcPeerSendOnly() and TURN server t2 in kurentoUtils.WebRtcPeer.WebRtcPeerRecvOnly() then will these two TURN server communicate between each other as relay chain ?


Solution

  • The TURN server configured from webrtcendpoint.conf.ini is used only for exchanging ice candidates. Also we can specify only one TURN server in webrtcendpoint.conf.ini because What I have observed is that if i provide 2 or more TRUN server in webrtcendpoint.conf.ini Kurento media server service fails to start, is this correct ?

    It is used for gathering candidates, and if needed as video relay. You KMS won't probably need this, as the location where it's deployed is managed by you. If you can do with STUN only which is the desired way, then the relay server won't be used.

    Only one server can be configured,

    Also is there any way to verify which STUN/TURN server is being used at Kurento media server and between two peers?

    Yes, the WebRtcEndpoint has methods for this

    • getStunServerPort()
    • getStunServerAddress()
    • getTurnUrl()

    The STUN/TURN which we provide in conferenceroom.js will be used for the actual media flow/mediapipeline between peers. Is this correct ?

    It will be used to gather candidates in your client. Also, if your client is behind a NAT that needs to use a relay server, it will use the one configured in conferenceroom.js. Keep in mind that the media path might not be symmetric: while media going from client->kms might be not using a relay server, media going from KMS-> client might due to the network conditions at your client's location.

    If we provide multiple TURN servers in conferenceroom.js then the TURN server neatest/fastest response time will be selected for media flow between the two peers? Same as we get response time form this Link.

    Yes, candidates are probed and the best one is chosen.

    Also what I have observed is that if the TURN server provided in webrtcendpoint.conf.ini and conferenceroom.js are different then we are not able to see remote participants video but if both the TURN server are the same then I am able to see remote participants video. Is this correct ?

    This shouldn't be the case, unless one TURN is working and the other not.


    EDIT

    TURN servers will not exchange media between them. They will be used, if needed, to act as a relay with the other peer. The process is

    • Each peer gathers candidates: host, srflx (STUN) and relay (TURN). Nothe that if the TURN server is different, the relay candidates will also be different.
    • Candidates get sent to the other peer.
    • Each candidate is probed individually, and the best one is chosen.

    Since all media is going through KMS, it will be the KMS the one sending media to the relay server. Keep in mind that KMS is always in between peers. It would be

    kms->t2->client client->t1->kms

    Even if the connection was browser to browser, the TURN servers would not communicate directly, as they would act as relay for the media sent from one peer to the other. Here it would be

    client1->t2->client2 client2->t1->client1