TURN Credentials Not Returned with Token in 2.17

Issues with deployment
1

Hello all. I’m not sure whether this is a deployment error, code change etc.

In 2.16 when we created sessions in OpenVidu we would something like the following back from the API:
openvidu-server_1 | [INFO] 2021-04-14 12:52:43,331 [SessionHandler-2h86jbsip2pun58l3l1424lnig-e2940-t0] io.openvidu.server.core.Session - Token consumed { Session: ses_XFBNZ07Yrn | Tokens: [wss://x.y.co.uk:988x?sessionId=ses_XFBNZ07Yrn&token=tok_Wj42ivcrtiVtwtBA&role=PUBLISHER&version=2.16.0&coturnIp=xxx.xxx.xxx.xxx&turnUsername=S6B1US&turnCredential=iopbxf] }

Note that the turn credentials are appended to the end.

In 2.17 the turn credentials are not appended to the end. This is how our devs currently extract the TURN credentials. So 2.17 breaks our application. The logs do say that TURN credentials are being generated, they just aren’t being returned in the reply to the start session API call.

Please can someone advise on this? Should we be using a different mechanism to retrieve the TURN credentials?

Thanks for reading.

2

Hi,

Since 2.17.0, turn credentials are not available inside the token. They are now stored in OpenVidu object of openvidu-browser, only available after successfully calling Session.connect(TOKEN).

To get them:

var turnAlreadyConfigured = false;
var openvidu = new OpenVidu();
var session = openvidu.initSession();
session.connect(token).then(() => {
    var iceServer = openvidu.iceServers[0];
    var turnUsername = iceServer.username;
    var turnCredential = iceServer.credential;
    openvidu.setAdvancedConfiguration({ iceServers: [{
      urls: "turn:YOUR_OPENVIDU_TURN_IP:YOUR_OPENVIDU_TURN_PORT" ,
      username: turnUsername,
      credential: turnCredential
    }]});

    turnAlreadyConfigured = true;

    // Now you can safely call Session.subscribe and Session.publish, but NOT before!
    // SUBSCRIBERS
    myStoredRemoteStreams.forEach(stream => session.subscribe(stream, "subscriber");
    // PUBLISHER
    session.publish(mypublisher);

});

The last comment is just a reminder that as event streamCreated can be triggered by the Session object asynchronously, if you are not careful and directly subscribe to the already existing remote streams, they could be started before you configure your custom TURN in the OpenVidu object.

So that’s the goal of the variable turnAlreadyConfigured, and your streamCreated event should be something like this:

var myStoredRemoteStreams = [];
session.on("streamCreated", function (event) {
    if (turnAlreadyConfigured) {
       session.subscribe(event.stream, "subscriber");
    } else {
       myStoredRemoteStreams.push(event.stream);
    }
});
1 Like
3

We will probably rethink this scenario in the near future and try to design a more suitable API to handle this situations where the TURN IP needs to be customizable for the client side, but still using the automatic OpenVidu turn credentials system.

1 Like
4

Thanks very much for the quick and detailed response.

Is there somewhere where we can find this sort of information for ourselves in future so that we’re not using your time? I didn’t see it in the release notes, perhaps there is a changelog?

5

Because you are basically using a hack. This is not documented because this is not part of the official API. To sum it up: you are doing something that technically shouldn’t be done.
That’s ok, as long as you take into account that this can happen, and your hack could stop working between releases.
My last message was addressed in that direction: we will possibly include this “Use your own TURN IP but still using OpenVidu TURN credentials” feature in the official API.

Cheers.

6

Makes sense, many thanks.