Licode Blog

Deploying Licode with Nginx

2017-07-31T00:00:00+00:00

Hi all!

Today we are going to briefly show you how to configure your Licode deployment to use Nginx and secure HTTP connections for both the application and the socket.io server. In the following figure you can see the configuration we want to deploy:

As you can see, clients connect to the application and to the socket.io server using the HTTPS port (443). Then, Nginx redirects the requests to the HTTP ports (3001 and 8080 respectively).

Configuring the scenario is very simple. You have just to install and configure an instance of Nginx and to introduce a small change in Licode’s default configuration. The following steps explain how to proceed with this configuration in Ubuntu 14.04):

Install nginx
```
sudo apt-get install nginx
```
Configure nginx by editing the default configuration file (in /etc/nginx/sites-enabled/) or by creating and enabling your own one:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name {your_server_name};
    return 301 https://$server_name$request_uri;
}

server {
   listen 443;
   server_name {your_server_name};

   ssl on;
   ssl_certificate {path/to/your/ssl_cert/file};
   ssl_certificate_key {path/to/your/ssl_key/file};
   ssl_session_cache shared:SSL:10m;

   ssl_ciphers !RC4:HIGH:!aNULL:!MD5;
   ssl_prefer_server_ciphers on;
   ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

	location /socket.io/ {
		proxy_pass http://localhost:8080/socket.io/;

		proxy_http_version 1.1;
		proxy_redirect off;

		proxy_set_header 'Access-Control-Allow-Origin' '*';
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_set_header X-NginX-Proxy true;
		proxy_read_timeout 86400;
	}

	location / {
		proxy_pass http://localhost:3001/;
		proxy_set_header Host $host;
		proxy_http_version 1.1;
	}

}

Note that you have to modify the text in {your_server_name}, {path/to/your/ssl_cert/file} and {path/to/your/ssl_key/file}.

Configure socket.io connection in licode_config.js file. You have just to change the following parameters:

[...]

// This configuration is used by the clients to reach erizoController
// Use '' to use the public IP address instead of a hostname
config.erizoController.hostname = ''; //default value: ''
config.erizoController.port = 443; //default value: 8080
// Use true if clients communicate with erizoController over SSL
config.erizoController.ssl = true; //default value: false

// This configuration is used by erizoController server to listen for connections
// Use true if erizoController listens in HTTPS.
config.erizoController.listen_ssl = false; //default value: false
config.erizoController.listen_port = 8080; //default value: 8080

[...]

As you can see, erizoController is still listening on 8080 port but clients will try to reach it on 443 port using SSL. Then, Nginx will redirect them to the correct port based on the /socket.io/ path.

Configure your application to listen on port HTTP 3001. If you are using the Basic Example this is already done!

And… that’s all. Enjoy Licode!

Licode now uses Discourse!

2016-12-01T00:00:00+00:00

We’re happy to announce we’re moving our forum to http://discourse.lynckia.com Using Google Groups as a mailing list is no longer working for us. While it has served us well in the years we’ve been here, we feel we have outlived it’s utility for us and we’re ready to move the discussion to greener (and newer) pastures.

Discourse provides a better way to engage in discussions and also its is ready to serve as a knowledge repository for Licode, something we’re lacking and want to correct. On top of all that, it’s an open source project and we love open source projects :). Bare with us as we figure out how to better use it, and feel free to posts your suggestions/feedback on the switch.

We’ve already moved all the content over there (discourse.lynckia.com) and all of the accounts.

To recover your account over at discourse.lynckia.com if you made one here:

Go to discourse.lynckia.com
Click login
Introduce the email you used to register in Google Groups
Click “I forgot my password”
You should receive an activation link -> follow it and you should have your new account set up :)

See you in discourse!

Multiple Ice Servers Configuration

2016-02-19T00:00:00+00:00

Till now, Licode configuration file allows only to configure a single Stun server and a single Turn server. We have just published an update that allows you to introduce multiple Ice servers. The new configuration parameter iceServers is an array in wich you can set several servers independently of the type:

Use undefined to run clients without Ice Servers

Stun servers format
{
    "url": url
}

Turn servers format
{
    "username": username,
    "credential": password,

    "url": url
}

For instance:

config.erizoController.iceServers = [
	{
		'url': 'stun:stun.l.google.com:19302'
	},
	{
		'url': 'stun:stun.mystunserver.com:19302'
	},
	{
		'username': 'turn_username',
		'credential': 'turn_password',
		'url: 'turn:myturnserver.com:80?transport=tcp'
	}
];

Introducing custom Cloud Handler policies

2015-06-08T00:00:00+00:00

As you know Licode is designed to be deployed in private or public clouds taking advantage of the scalability capabilities of this type of environments. One of the scalability levels that Licode offers is the possibility of having more than one Erizo Controller conected to the same Nuve. Thus, in the same service you can have different Erizo Controllers managing different rooms. When a user connects to a new Room, Nuve decides to which Erizo Controller assign the room depending on different conditions.

The component that takes that decision is called Cloud Handler and until know it took the decision basing on the number of rooms each Erizo Controller was managing. Today we introduce a machanism to customize that decision thus enabling a more advanced resource handling.

And it is so easy, you can start from the template we have created as the default policy script and modify it introducing your own algorithm. The algorithm has to be encapsulated in a method with the following format:

Params:
---
room: room to which we need to assing a erizoController.
	{
	name: String, 
	[p2p: bool], 
	[data: Object], 
	_id: ObjectId
	}
ec_list: array with erizo controller objects
	
	{
    ip: String,
    rpcID: String,
    state: Int,
    keepAlive: Int,
    hostname: String,
    port: Int,
    ssl: bool
	}
ec_queue: array with erizo controllers priority according rooms load

Returns:
---
erizoControlerId: the key of the erizo controller selected from ec_list

Once implemented, you have only to set it in your licode_config.js file:

// Cloud Handler policies are in nuve/nuveAPI/ch_policies/ folder
config.nuve.cloudHandlerPolicy = 'my_own_policy.js'; // default value: 'default_policy.js'

New master branch, now with 100% more trickle

2015-02-04T00:00:00+00:00

We have just updated the master branch with the changes in trickle_ice. The most obvious new feature is the support of Trickle Ice. It will make the delay until you start receiving or sending media via Licode a lot smaller.

However, this has a drawback, this new implementation modifies the protocol used to communicate erizoController with erizoClients.

Basically, if you modified erizoClient, erizoJSController or erizoController you will find you have to work a little to merge the new changes, we promise it is worth it :)

As always, we created a new [release/tag] (https://github.com/ging/licode/releases/tag/v1.1.0) to the previous version so you guys can find easily the exact commit we made the change. Furthermore, the legacy branch also points to the previous state of master.

But enough about the past, let’s summarize the new additions:

Main new features:

Trickle ICE support
Initial Openwebrtc/Bowser support: There are still some things to improve but we’ll get there soon
Support for Ubuntu 14.04: Licode should now work with the latest LTS release out of the box! I’d advise to start moving to 14.04 ;)

Fixes:

Fixes to Video/only audio/only streams in Firefox
Fixes to erizoJS management
Fixed the infamous ‘Cannot call method ‘hasAudio’ of undefined
A lot of smaller fixes

We hope all of you switch to this branch as soon as possible and, as always, report your problems so we can keep fixing them. Thanks to everyone that contributed with code or reports!

Configuration of roles in Licode (update)

2014-11-14T00:00:00+00:00

This is an update of the previous post about roles management in Licode.

We have changed the format in which roles are defined in Licode’s installation. The new format is:

config.roles = {
  "teacher": {"publish": true, "subscribe": true, "record": true},
  "student": {"subscribe": true}
};

We can edit the roles in the configuration file that we can find at licode/licode_config.js once installed.

The new Licode master branch

2014-08-12T00:00:00+00:00

We have finally made the switch from the async_events branch to master. This branch includes a host of new features that make Licode more potent, configurable, scalable and stable than ever!

Here we will discuss the new distributed MCU architecture. As you know, erizo was a single process started with erizoController, the whole MCU is a single process. From now on, each publisher in Licode will have its own process in the Licode server.

What once was the erizoController process has been divided into three components. These new modules follow the same design philosophy we use in all Licode, they can be deployed separately in different machines or together. This components are:

ErizoController: The good old erizoController, it still has the same function in terms of control and signalling.
ErizoAgent: This new component is in charge of starting new processes. Any machine running erizoAgent will be able to host resources for the distributed MCU by starting and stopping ErizoJSs. These ErizoJSs can be started on demand and/or have a pool of pre-started ones.
ErizoJS: A single broadcaster of the distributed MCU.

This iteration in the architecture brings many new features. Let’s go over some of them:

Improved Scalability: A single Licode Room can be now easily distributed among an array of servers. By starting erizoAgent in different machines and configuring them properly, the workload of a room will be intelligently distributed.
Improved Stability: Before, an irrecoverable error caused by a single stream could potentially bring down erizoController, shutting down all the rooms managed by it. In the new distributed architecture, a fatal error in a stream will only shutdown that stream, while the rest of the room(s) keep working.
Configurable: You can manage this behavior in the revamped Licode configuration file (licode_config.js):
- config.erizoAgent.maxProcesses: The maximum amount of ErizoJSs this particular ErizoAgent is allowed to start.
- config.erizoAgent.prerunProcesses: The amount of prestarted processes ErizoAgent will have at all times.

Some of the other new features have already been documented in our Server and Client API Doc pages, or even in this blog:

Client Roles.
Enhancements to recording and playback
Better STUN and TURN configuration
Tons of fixes and improvements.

To ease the transition, we will move the current master branch to legacy in our github repository. As always, feel free to write in the list with any problems, suggestions or ideas you have!

Configuration of roles in Licode

2014-08-07T00:00:00+00:00

In this post we will explain in detail how to configure our custom roles in our Licode’s service.

Erizo Controller now supports the definition of role as a set of permissions, and these permissions are already predefined in this component. A permission allows a user to perform an action on a resource. Below you can find a list of the current permissions:

Publish: it allows a user to make a local stream public into the room. This stream can be used to send video, audio or data, and once published other users should be able to subscribe to it.
Subscribe: it allows a user to receive a stream that has been previously published into the room. The stream can be also stored or can be received from external sources.
Record: it allows a user to store publishing streams in a room, even if it only contains audio or video.

These permissions are fixed in the source code, we can not create new ones without changing the code. But we can create roles from them. For example, if we aim to create e-learning applications we could create a role for the teacher, who should be able to publish, subscribe and even record the stream. On the other hand, the student could only subscribe to other streams. In this case our application would have both roles. In this case we should configure our Licode’s installation with the next line:

config.roles = {
  "teacher":["publish", "subscribe", "record"],
  "student":["subscribe"]
};

Important update: the new format to specify roles is:

config.roles = {
  "teacher": {"publish": true, "subscribe": true, "record": true},
  "student": {"subscribe": true}
};

As said above we can edit the roles in the configuration file that we can find at licode/licode_config.js once installed.

Lynckia Screensharing extension

2014-05-28T00:00:00+00:00

As you know, some days ago Chrome has updated the screensharing feature in WebRTC. Now you need to add a Chrome extension in order to share your desktop. Of course, Licode is totally compatible with the new feature and from Lynckia team we have uploaded our own extension to Google Web Store in order to support it.

Thanks to the extension now you can select the screen or the window that you are going to share.

You can download the extension here and test it in our screen sharing rooms at Licode’s demo portal.

Enjoy it!

Licode + Vagrant

2014-02-21T00:00:00+00:00

We are always looking for ways to improve the productivity when it comes to developing, deploying and testing Licode. As a project with several library dependencies, 2-3 programming languages, etc. setting up a new machine for development can be daunting at times, even with our super-easy installation scripts.

Furthermore, testing in different network configurations (behind NAT, firewall, with remote erizos…) can be quite time consuming. We have found the solution to these problems with Vagrant

Vagrant is a very powerful tool to easily create, configure and port work environments. It uses virtualization and advanced provisioning tools such as Chef to automatically set up and provision virtual machines.

Not only that, but Vagrant also makes it easy for us to deploy several machines at the same time with only one configuration file. Furthermore, it supports several VM provides such as VMWare, VirtualBox and even cloud providers (AWS, Openstack) via plug-ins.

We have included our own Vagrantfile configuration and provision shell script in the repository. The provision script will download the repository inside the new virtual machine, install the dependencies and compile everything.

The prerequisites are: Vagrant (of course :)) and VirtualBox.

So what you have at the end is :

Ubuntu 12.04 64 bits
All Licode dependencies installed
Licode installed in /vagrant/licode in the guest VM
Host IP automatically configured in the guest VM
Ports forwarded:
- 3001 for BasicExample
- 3000 for Nuve
- 30000-31000 udp for WebRTC also configured for Licode

Using vagrant ssh you can start and stop Licode as usual. So there you have your full Licode development environment.

Besides, by changing things in the Vagrantfile you can set up several machines, network configurations, etc. to help you with your testing. Take a look at the tutorials in http://www.vagrantup.com for more information.

We will be playing with this the next weeks, trying AWS, OpenStack, etc. Any experiences, comments suggestions are welcome :)

See you all developers in the list!

New demos portal

2013-11-21T00:00:00+00:00

This week we have uploaded our demos portal with new types of applications of Licode. We have videoconference, audioconference and screen sharing demos. Furthermore, some of them are in peer-to-peer configuration.

You can try them as always at Licode’s demos portal

And, of course, we are going to add new demos very soon!

Best regards and enjoy Licode.

Branch merging and reorganization post

2013-10-29T00:00:00+00:00

Last week we took Licode a step further by incorporating in the main branch many of the repository several features that have been in the works in the last few months.

Here are some highlights:

TURN server support
Stream recording
DTLS/Firefox support
Cleaner logging system

As well as a bunch of bugfixes!

We encourage all of you to switch to this branch and keep helping Licode with your feedback and opinions. We have already posted here regarding the TURN server support feature and we will keep posting more information about the others in the next few weeks as well as the documentation part of this site.

We will keep the other branches for a while but will soon be replaced or removed as we move on into new territories :)

You can start testing it, and again, feedback is very welcome! Thank you!

Turn Support

2013-10-28T00:00:00+00:00

In the latest version of Chrome Turn support in PeerConnection objects is enabled. So from today we have included this feature in Licode.

You can use it including the Turn Server configuration in licode-config file:

config.erizoController.turnServer = {};
config.erizoController.turnServer.url = "turn:myTurnServerHost:443?transport=tcp";
config.erizoController.turnServer.username = "username";
config.erizoController.turnServer.password =  "pass";

This way all clients connected to Licode will include that Turn server in their PeerConnection configuration. We have made some test with rfc5766-turn-server and the results are really cool. You can start testing and tell us your impressions.

Thanks to Turn servers relay, Firefox compatibility and Chrome mobile for Android support, every day more types of web clients and in very different conditions of connectivity can connect to Licode services. And a very important part of this work is due to our community’s tests and feedback.

Thank you again.

Peer – to – peer functionality

2013-09-04T00:00:00+00:00

We have developed a very cool feature in Licode. Now you can use peer – to – peer rooms in your services. That means that you can communicate your users directly between their browsers without passing through the MCU server (only for signalling). And this is very useful in applications with a low number of users in which you want to save server side resources.

An initial version is implemented in Licode’s “cleanup” branch (by the moment it only works between peers using the same browser, we are developing the interoperability Chrome - Firefox). And use it is very easy! You only need to create a p2p room using Nuve API like this:

var roomName = 'myP2PRoom';

N.API.createRoom(roomName, function(room) {
	console.log('P2P room created with id: ', room._id);
}, errorCallback, {p2p: true});

And from here use the room with the client API as always!

You can start testing it, and again, every feedback is very welcome!

Thank you very much and enjoy Licode!

Licode now supports Firefox

2013-07-17T00:00:00+00:00

Today we’ve finished the main tasks of making Licode compatible with Firefox.

Now users can access Licode rooms from stable versions of Chrome and Firefox. If you’re developing a solution with Licode and can’t wait to try this new functionality you have to pull the code from the “cleanup” branch.

There is still work to be done. For example, feedback compatibility and overall stabilization. So, please, don’t install it if you’re already providing a service using Licode.

As part of this work we’ve also switched the security mechanism from SDES to DTLS, and we’re making a partial refactorization of the transport and connection files in Erizo.

During the next weeks we’ll continue testing this new feature in several scenarios and we’ll let yu know when it is ready to use. And we’ll probably finish the very first version of the recording API very soon.

Stay tuned!

We are 100 Licode developers!

2013-06-13T00:00:00+00:00

We are very happy to announce that today we have processed the membership request of the 100th developer in Licode community.

Since November 2012, when we started with the community, we have more than 55 discussions with about 4 messages per day. Moreover, Licode GitHub repository has 94 stars, 27 forks, 503 commits, 8 branches and every day developers are more interested in contribute to our code.

All these numbers are the evidence of Licode is becoming a bigger and richer project every day. Thanks to all of you, your interest, testing and hard work Licode is a reference in the Open Source WebRTC communications providers.

Thank you very much.

Screen sharing with Licode

2013-06-07T00:00:00+00:00

We have just implemented a new very interesting functionality in Licode. From today you can include in your Licode applications the feature of share any client screen using the GetUserMedia API of WebRTC.

This is very easy. To allow it in a Stream you only need to create it this way:

var stream = Erizo.Stream({screen: true, data: true, attributes: {name:’myStream’}});

And then publish it in a room in the traditional way. Instructions in Client API.

We think this is a very useful feature and, in the tests that we have made, its performance its very amazing. We are also developing a demo service in order to you can try the new functionality and use to share your screen in any scenario.

Note that the clients that will share their screen have to access your web application using a secure connection (https protocol). Furthermore, by the moment, he or she has to allow the access activating a flag in Chrome browser (Enable screen capture support in getUserMedia()).

New GitHub repository name

2013-06-07T00:00:00+00:00

Regarding the new name of our project Licode today we have made the last change. It consists of update the name of our github repository. The new path is Licode GitHub.

GitHub redirects automatically your project to the new one. So if you have already cloned it you only need to make a pull in order to update the changes (we have made some changes in scripts names and so on).

In advance you should clone the repository from the new path. We have updated the instructions in installing Licode.

Thank you very much and enjoy Licode. Best regards

Licode wins the Open Source University Challenge

2013-05-28T00:00:00+00:00

Last Friday Lynckia team have won with Licode the seventh Open Source University Challenge CUSL.

In this edition have been participated more than 80 Open Source projects developed by the Spain University community. Licode has been specially valued because its increasing community and its ambitious development.

We want to thank the whole community because the effort, the testing and the contributions. This prize is also yours.

Lynckia project now is Licode

2013-05-10T00:00:00+00:00

Today we announce that our Open Source project Lynckia now is called Licode. But don’t worry! Nothing is different in Licode. We are working hard on new features and with your help, and all the community Licode is becoming more and more amazing every day.

You can find some information about our development group at Lynckia and all the resources and documentation of Licode at Licode.

Thank you very much. And enjoy Licode.

Licode working with Chrome beta on Android!!

2013-03-06T00:00:00+00:00

Great news everyone!

Licode is now officially working with the last version of Chrome Beta on Android. That means all your applications using Licode are now going mobile.

To enable WebRTC on Chrome Dev for Android:

Type in “chrome://flags” in the omnibox to access the flags
Scroll about a third down and enable the “Enable WebRTC” flag
You will be asked to relaunch the browser at the bottom of the page in order for the flag to take effect.

Now you can open your Licode application url (or our [test page] (http://chotis2.dit.upm.es) ) and that’s it :)

Keep in mind this is still a beta version and there is still a lot of work to be done for it to work perfectly.

You can see it in action in this video:

We want to thank Google WebRTC group for their great work implementing the standard in Chrome in every platform.

Nuve Client now available in ruby

2013-03-01T00:00:00+00:00

Today we announce that now you can access to nuve API from your ruby server applications. Thanks to the nuve library developed in ruby now Licode is able to run with the three most popular server side languages: node.js, python and ruby.

You can find the library in our github repository (https://github.com/ging/licode/tree/master/nuve/nuveClient_ruby) and use it following the same API that in the rest of languages (http://lynckia.com/licode/server-api.html). You can feedback your impressions or problems in our mail list. Enjoy it!

Introducing RTCP feedback forwarding in Licode.

2013-01-17T00:00:00+00:00

One of the most important problems to be faced when working with real time communications is how to react to varying network conditions. Even if a bandwidth and general quality is agreed during the signalling or negotiation phase, any change in one of the participants’ connection will degrade the communication. There are many studies and implemented mechanisms to help solve this problem. These solutions are heavily dependant on the protocols and technologies used in each application

Licode lives in the WebRTC world and has to communicate with the current implementations, being Google Chrome the most important today. Chrome has been advancing in the implementation of the SAVPF RTP Profile for some months that, among other things, defines feedback RTCP packets to adapt the communication between the peers.

Today we announce we have implemented the forwarding of RTCP packets via Licode in the master branch. In our tests it has greatly improved the communication in environments with high packet losses and latency. While this is only the first step, it is very important for providing a high quality service.

We encourage all of you to test it and tell us what you think of it. Please remember to uninstall libsrtp and use the one included in the repository now. All the scripts have been fixed so installing everything again should work just fine.

We also have updated our demo page and we also encourage you to try it :)

Connecting erizo clients to Licode in your node.js applications.

2012-12-19T00:00:00+00:00

Some weeks ago we had a very cool idea. We were talking about the posibility of running an erizo client in a node.js application and connect it to a Licode session. With this feature you can include in your Licode rooms streams from a client that not necessarily runs in a browser. It may be of interest, for example, for doing some operations with the streams like processing or synchronization.

Today it is posible with erizofc, a node module that you can include in your node application to run erizo clients with the same API used in browsers. You can check the API here. erizofc is simply a new compilation of the erizoClient source code changing the socket.io library and considering some particular characteristics that differentiates browser and node applications. To connect with socket.io a node.js application working like a client to another working like a server we use the node module socket.io-client.

At the moment it is only possible to publish and subscribe data streams from the node.js clients. However we are working in the feature of manage different ways of obtain media streams using streams from URLs rtp, rtsp, rtmp …

Automated testing in Travis CI for WebRTC

2012-12-17T00:00:00+00:00

Intro

We’ve been working on developing tests for checking WebRTC connections in Licode and Google Chrome (stable and unstable versions). We started using Travis for the server tests some weeks ago, but at this time, we wanted to go beyond simple tests of Nuve and basic room’s functionality.

Our idea is to test publishng, subscribing and further features of our client library in Chrome and in future versions of Firefox. During these tests we need to automatically start Chrome, accept the browser’s GetUserMedia request, and to send a fake video stream to check whether streams are sent or not.

Testing environment

For this puporse we used three different and compatible frameworks:

Travis CI: We continued using it for running tests in a standalone machine. It allows to setup experimental environments based on a Linux machine that is almost fully configurable.

Testacular: This is a Test Runner for JavaScript that allows to test JS applications directly on the browser. It supports different providers, such as Google Chrome, Firefox, and so on. And it also supports custom browser launchers.

Testacular also allows you to use several testing frameworks, but it comes with built-in Jasmine and Mocha integration.

Jasmine: It is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.

We’ve also tested it against Mocha in our experiments, so you can choose your own framework.

Setting up Travis and Testacular

We first need to install Chrome in the Travis machine for every test. Travis helps us to do it by the before_install command:

language: node_js
node_js:
  - 0.8
before_install:
  - ./.travis/scripts/install_chrome.sh
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start

In this case you have to create the install_chrome.sh script to start chrome before the tests. You can access this script [here] (https://github.com/ging/licode/blob/master/.travis/scripts/install_chrome.sh).

Since Travis runs npm test for running tests we also need to create a package.json with info about the tests. Here we should add the next lines to our code:

"scripts": {
    "test": "./node_modules/coffee-script/bin/cake test"
} 

And we’ll also add the corresponding Cakefile:

exec = require('child_process').exec
task 'test', 'run all tests suites', ->
    console.log 'Running front-end tests'
    chrome_bin = "DISPLAY=:99"
    testacular = "#{__dirname}/node_modules/testacular/bin/testacular"
    browsers = '.travis/chrome-start.sh'
    options = "--single-run --browsers=#{browsers}"
    exec "#{chrome_bin} #{testacular} start #{__dirname}/.travis/testacular.conf.js", (err, stdout, stderr) ->
        console.error err if err
        console.log stdout

In the chrome-start.sh file we have the corresponding starting scripts. With this script we setup Chrome with some default Chrome Preferences:

It allows the user to start Chrome and use Webrtc from a local URL (http://localhost:9876/) without asking permissions. This is configured in the Preferences file.
It also starts Chrome by using a fake video device, that is used to send synthetic video packets between clients. This is achieved in the starting script, with the option: --use-fake-device-for-media-stream. Below you can see the resulting video.

Testing

For testing we used Jasmine and its asynchronous functionalities. We use it to test Licode but it can also be used to test WebRTC applications. Below we show one of our examples in the test cases:

it('should get access to user media', function () {
    var callback = jasmine.createSpy("getusermedia");

    localStream = Erizo.Stream({audio: true, video: true, data: true});

    localStream.addEventListener("access-accepted", callback);

    localStream.init();

    waitsFor(function () {
        return callback.callCount > 0;
    });

    runs(function () {

        expect(callback).toHaveBeenCalled();
    });
});

In this example we call the GetUserMedia command, and it automatically accepts on behalf of the user given the previous configuration. Once it is accept we check whether the Jasmine’s Spy has been called.

New LookAndFeel in Licode

2012-12-04T00:00:00+00:00

Lately, we’ve been changing the LookAndFeel of Licode’s Web Site. Now we can introduce the brand new Blog!!

Here we’ll talk about news related to Licode and other WebRTC stuff, like demos, examples, screencasts, and so on.