Twilio & Kurento

[vi...@opentest.co]

So I've been using our production setup with Kurento and Numb (numb.viagenie.ca) TURN servers for a little while now. About 10% of our recordings end up empty, and this got me thinking that I really need to make our production environment more solid. Firstly by swapping out our free Numb TURN server with a production-ready one from Twilio. We really need to hit a margin where almost every recording goes through properly (although, to be fair, I'm not sure this is an issue with the TURN server - that is simply my guess).

So in order to integrate with Twilio's TURN/STUN servers, you have to generate TURN credentials that expire within a TTL like so:

var accountSid = 'ACXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';
var authToken = "{{ auth_token }}";
var client = require('twilio')(accountSid, authToken);

client.tokens.create({}, function(err, token) {
    process.stdout.write(token);
});

After you send the token to your client, they use the iceServers set on that object to establish the RTCPeerconnection object. I can easily do this on our Node app server to the web client, but the trouble arises when supplying Kurento with these credentials on an ongoing basis (since they expire and must be regenerated). Right now I think I'll probably settle for generating new credentials before each deploy that expire in a week and hope that we don't go more than a week without a deploy.

This is obviously brittle, so I was wondering if there was planned support on being able to supply dynamic TURN credentials to the KMS on an ongoing basis during its life cycle.

[vi...@opentest.co]

A couple other questions that are relevant to being able to integrate with something like Twilio:

1. How might we allow for multiple TURN servers in the Kurento config?
   
2. When can we expect proper domain names to be valid for the Kurento config?
   

[vi...@opentest.co]

As an update for people looking to integrate with Twilio's TURN/STUN servers, these are IP ranges for their different regions:

https://www.twilio.com/docs/api/stun-turn/regions

Again, it would be awesome if I could just use the CNAME (global.turn.twilio.com) and provide multiple TURN sources. Is there active work being done on this? I don't even mind contributing to Kurento and getting this functionality into the media server.

[Ivan Gracia]

Yeah, CNAMEs would be great. The problem is that libnice does not support them, and we are stuck with what they support. 

You can change the TURN server configuration for each WebRtcEndpoint via the setTurnUrl(String turnUrl) method.

​

Ivan Gracia

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

[vi...@opentest.co]

Seems like the phabricator ticket for the libnice project for domain resolution is here:

https://phabricator.freedesktop.org/T108

Would there be big opposition to either of the following solutions?

1. Provide domain resolution within Kurento itself. This seems possible with many C/C++ libs:

http://www.chiark.greenend.org.uk/~ian/adns/

http://www.corpit.ru/mjt/udns.html

http://www.25thandclement.com/~william/projects/dns.c.html

http://directory.fsf.org/wiki/FireDNS

2. Provide a hook to dynamically provide Kurento a TURN IP when it needs one.

The second option seems messy from an API perspective and not congruent with the way Kurento is setup as of now.

The first option seems to be the simplest and cleanest to implement. I'm looking through the kurento-media-server and kurento-core repos at a bit of a loss for finding where the turn/stun server IPs are ingested. Can anyone provide a gentle nudge?

[Ivan Gracia]

The problem with #1 is that the IP could change after you have resolved the CNAME. Then you would need to throw away whatever libnice elements you had created.

Ivan Gracia

[vi...@opentest.co]

In actuality, how expensive do you think it would be to tie libnice elements to the lifecycle of a group of peers? I would think this is fairly inexpensive and follows the lifecycle of actual peer connections made in the browser more closely than caching the libnice elements (if that's what is currently happening). This way the domain is resolved for each new logical group of peers.

[Ivan Gracia]

Not sure, really. Perhaps Jose can give you a better answer, as he's the one managing that part.

Ivan Gracia

[jusaf]

Hi guys, 

this is an interesting topic as i have switched to Twilio for the TURN/STUN services (i was also using numb,viagenie.ca).

But i'm not sure i understand what the problem is since at the moment we were instructed by the Kurento team to remove TURN configurations from the KMS v6.4 because of some bug in a library (libnice if i am not mistaken) and for the client side we can easily provide users with dynamic credentials from whatever app they are running on... what am i missing?

[vhire...@gmail.com]

@jusaf 100%. This is still a giant problem for us since we're running Kurento on our backend and now *have* to deploy once a day at least since Twilio API keys are only valid for 24 hours.

[Ivan Gracia]

You can also setTurnServer in the WebRTC endpoints. That way you wouldn't need to restart.

Ivan Gracia

[vhire...@gmail.com]

Awesome this is what I was looking for. Is there any way to do this with the Node.js lib as of now? If not, how difficult would it be to build this API into the Node.js library? I can create a Pull Request on GitHub (or whatever your code submission process is).

If that's something that will take a while, would me creating a small Java app that refreshes the token once an hour and then updates the WebRTC endpoint via the method you described also update the endpoint for other clients with already-established connections? Or does that method only apply for the current connection between the Java app and the server?

[Ivan Gracia]

No need to. Both APIs are the same, so you have it also there. It's just that I happened to have the javadoc page open.

Ivan Gracia

[vhire...@gmail.com]

Awesome! This is exactly what I was looking for a few comments back in this thread. Thank you man - you might have just saved me (doubly so because I did not realize there was a JSDoc for the node API).

[Ivan Gracia]

No worries! ;-)

Ivan Gracia

[vhire...@gmail.com]

Seems to work! Will be testing within different coffee shops and networks tomorrow. I'll post back here.

[Ivan Gracia]

Cool! Please do.

[vhire...@gmail.com]

Tried across a few different conference rooms and coffee shops. All seems well. I have the Twilio credentials refreshing once an hour, each with a TTL of 1 day.

[jul...@ctrlventure.com]

Hi guys,

i am also trying to use Twilio and specifying the TURN URL using the setTurnServer but looking at the docs it asks specifically for an IP, but Twilio only provides domains, i inquired with them and they replied that we must use the domains since its a service in the cloud with lots of different IPs that change without notice. How did you solve that?

Is there any specific reason why domains are not supported?

And now that i think about it, when specifying ice servers in the client side JS in the options for creating the WebRTCPeer, does it has to be an IP there as well or can we use domains there?

[Ivan Gracia]

Yes, that's because libnice, which is the library we are using for ICE, does not support it.

In the client side, that constrain does not exist.

Ivan Gracia

[vi...@opentest.co]

Julien,

Check this previous thread and read the whole thing. Twilio actually provides a range of IPs that will work, so you can choose one and ensure it's good by putting it in your browser URL bar and ensuring it returns "TURN Server" (here's an example IP in Oregon: http://54.244.51.10).

Here is a list of the IP ranges for their TURN/STUN servers.

https://www.twilio.com/docs/api/stun-turn/regions

I'm not sure who you talked to, but the customer rep I talked to said that I should totally be fine using a static IP from these ranges. Of course it's not ideal since some people may be hitting a server much further away, but it's a good half-way solution until libnice supports CNAMEs. Hope that helps.

Vinay

[jul...@ctrlventure.com]

Thanks guys this is good info. Regarding what Twilio had answered me, here it is:

"Our service is cloud-based, so we have many IP addresses and they change periodically without warning. You'll need to use the STUN/TURN domain names in your application to avoid sudden loss of service."

I'm gonna follow your method anyway.

Where is a good place to call setTurnUrl? 

I'm guessing right after the endpoint is created, before calling processOffer and setting the onIceCandidate callback right? or should i execute all that in the callback of the setTurnUrl?

If you have some example code that would be definitely helpful.

Thanks

Julien

[vi...@opentest.co]

I'm currently calling setTurnUrl right after I create the webRtcEndpoint media element from the pipeline object. This is the general code pipeline for me (note: if you're writing node.js definitely use promises or prepare to be submerged in callback hell):

1. get kurento client

2. create media pipeline

3. create webrtc endpoint

4. set turn credentials on webrtc endpoint

[jusaf]

thats exactly what i am doing, sadly this didn't help with my problem of video not loading occasionally in chrome/rarely loading in FF.

thanks anyway!

[vi...@opentest.co]

Ah ok bummer. :-\ It may very well be a different issue in that case. I would post a separate topic with as much diagnostic information and then cc me in the post and I can help you dig deeper.

[jusaf]

yeah i'm guessing its something else, although everything points out to ICE negotiations issue.

Already made a post about it: https://groups.google.com/forum/#!topic/kurento/0wBNXedjDxs

when you have time have a look, you might be able to spot something that i may have missed.

Thanks a lot!