If there is anything in particular you would like to see, please let us know!

You can visit the channel at: http://www.youtube.com/user/GetAddLive/

And you can watch the AddLive video here: http://www.youtube.com/watch?v=I310xApnlfc

For those of you who do not know, Monday 18th March was the WebRTC Conference-within-a-conference at Enterprise Connect (EC13).

The day was hosted by Brent Kelly and Irwin Lazar. The morning started with a highly informed talk by Jan Linden of Google and Cullen Jennings of Cisco, both pivotal and highly respected engineers working on WebRTC. Despite it being a fairly technical overview, the room was completely full. And as the talk continued, more and more Enterprise Connect attendees piled in.

About 45 minutes into the session the conference organizer, Eric Krapf, asked Cullen and Jan to pause. We were told that there were too many people and that they were going to extend the room size. In a few minutes a wall was removed to reveal 100 more seats that were all quickly taken.

This buzz continued through out the day with the AddLive and other ‘WebRTC Innovators’ demo’s were delivered shortly after 1pm to a still packed room.

The interest that day was a surprise to all of us involved in WebRTC, but we had no idea what was going to happen over the following days.

For those of you who don’t know about Enterprise Connect, it is the single most important enterprise communications conference globally. It is attended by 5,000 enterprise professionals, including CIO’s of large enterprises, CEO’s of vendors and also smaller disruptive companies like us at AddLive and our friends at Plivo.

The likes of Microsoft, Cisco and Avaya presented the keynotes. They shared their next generation products and their vision of the future and the panels discussed topics like the Cloud, BYOD, business models and the communication requirements of the enterprise.

But what was remarkable was that every single keynote, panel, and lecture had either a dedicated WebRTC segment or the conversation drifted to WebRTC. It became the hot topic of EC13. WebRTC was being talked about in the corridors, during lunch and even over evening drinks.

When I introduce AddLive, I introduce WebRTC. Firstly I introduce the term, then the technology, then the implications. On Monday this was still the case, but by Wednesday things had changed. Although I still needed to explain the tech and what it means to businesses, when I mentioned WebRTC to others their face lit up and they began asking me questions.

So when we look back at the WebRTC journey, I believe that Monday 18th March was the day when the business world woke up to WebRTC. The day that WebRTC entered the imagination of the enterprise.

Now they are bringing it to WebRTC.

In a blog post by Julien Michot Ericsson has announced that they have their 3D implementations running in the browser. Although 3D video is not a requirement of WebRTC, and is not in the specifications, it is still very cool and with their depth sensor implementation 3D could potentially be rendered on a screen without the need for the user to wear glasses.

It is great to see teams like Ericsson labs pushing the boundries of where the technology could go so early in the process.

For more information, view the Ericsson blog post here: https://labs.ericsson.com/blog/3d-webrtc-3d-video-communication-in-a-browser

The session is ‘Innovation within WebRTC’ and runs from 1pm to 2pm EST in the Osceola 5 room.

More details can be found here: http://www.enterpriseconnect.com/orlando/conference/webrtc-and-the-voice-enabled-web.php

Look forward to seeing you there!

Wow! I’ve had a huge break from blogging for a while now especially about WebRTC. I’m sure you all have been tracking how much WebRTC has been evolving over the past few months. The most recent and exciting news which you have got to know is the interop between Chrome and Mozilla has landed and it is undeniably super cool. You could check out the demo by following up this link. So, without any further delay let me start with the peer connection tutorial which I am sure is a component everyone is dying to try.

I have realized that a peer connection tutorial has got to have a minimum of two parts so that I do at least some justice to it. So here in part1, lets start with the basics of what you have got to know to get started with establishing your own peer connection i.e learn how a basic call is established.
Assumptions : I assume that you can understand the basics of HTML and JavaScript so that you can understand the other parts of what is happening and that you have already ready my tutorial on gUM or you know the basic usage of gUM. A little bit of going through the WebRTC blogs (I’ve listed a few in the last) would be really helpful as well.

I will be using the code from Anant’s demo to walk you through the steps of setting up a call. It provides an easy way of testing the peer connection component (especially when you are not hosting your app). This page basically has two video elements, one called Remote and the other called Local. The video captured by your local machine (using gUM) is displayed by your Local video component. The basic idea is to establish a call using WebRTC’s peer connection component between the Remote and Local video components on the page. Thus finally when the call is established the video captured by your local machine is streamed to the Remote Video element on that page through its connection with the Local Video element. I highly recommend you try out this demo yourself on Peer Connection Test Page before getting started with this tutorial so that you have a clear idea of what you are trying to build. (I’m not sure if it works on windows yet )

Note: For the demo to work you have to have the latest version of Mozilla Nightly. Now that the peer connection preferences are turned on by default I don’t think you need to tinker with your browser preferences.

Lets start of from the very beginning. When I want to initiate a call what should I do? ( what to do in the code when I click on the start button in the pc test page ) – The first and foremost step is to create the peer connection objects based on the number of connections that are required. For our example, we require only two, so we create pc1 and pc2 as follows:

pc1 = new mozRTCPeerConnection();
pc2 = new mozRTCPeerConnection();

The peer connection objects has several in built methods which can be used quite effectively as you will notice in this tutorial. The next important step is to capture the local video by making use of gUM as follows:

navigator.mozGetUserMedia({video:true}, function(video1) {

In the above function we have set the captured media by the gUM function to video1 i.e. currently video1 is the local machine’s captured video. The next part deals with setting the local video source as video1. Once the video begins to play (thanks to invoking play()) we add this video to the Stream attribute of the peer connection object by making use of the method addStream(video)

// Add stream obtained from gUM to <video> to start media flow.
localvideo.mozSrcObject = video1;
localvideo.play();
pc1.addStream(video1);

So now, we have the local video running. We will also create fake audio streams for both pc1 and pc2 (The reason we have pc1′s audio as a fake stream is due to the echo problem) . These can be used later on in case some captured audio has to be added to the stream.

navigator.mozGetUserMedia({audio:true, fake:true}, function(audio1) {
pc1.addStream(audio1);
pc2.addStream(audio1);

Similarly we also add a fake video stream to the pc2 object, so that once the call is established the video from pc1 can be added to this stream.

navigator.mozGetUserMedia({video:true, fake:true}, function(video2) {
pc2.addStream(video2);

You might be wondering if I’ve forgotten the method onaddstream. Don’t worry I don’t forget that easily So, this function is invoked everytime the addStream function is called. Let me explain this with respect to pc1.onaddstream. In this method we set the source stream for the pc2 video and we play it using the play method. Since, intially there is only a fake video stream nothing will play, but later on once the call is established – voila! pc2 will be playing the local video from pc1 i.e it plays the remote stream when a video call is established.

pc1.onaddstream = function(obj) {
log("pc1 got remote stream from pc2 " + obj.type);
pc2video.mozSrcObject = obj.stream;
pc2video.play();
}

The pc2.onaddstream does something similar, but this is for the case where pc2 is the local stream and pc1 is the remote stream.

pc2.onaddstream = function(obj) {
log("pc2 got remote stream from pc1 " + obj.type);
pc1video.mozSrcObject = obj.stream;
pc1video.play();
}

Now that we have everything ready, the only thing left is to establish a call. In WebRTC, calls are established through a process called Signalling which can roughly be defined as – “For a caller to be able to make a call he first has to make an offer to the callee (general procedure) and for the call to be established it is required that the callee accepts the offer and return an answer which is in turn accepted by the callee (yeah, yeah its the preliminary handshake). “ Signalling in itself is a huge topic to cover and is achieved through a protocol called Interactive Connectivity Establishment (ICE) and I plan to explain it in the next blogpost. For now, all you need to know about signalling is a higher level abstraction of it which is pretty much clearly stated in the definition. So the first step to signalling takes place here (creating an offer):

pc1.createOffer(step1, failed);

Here, tha basic idea is to make pc1 create an offer to pc2 as mentioned before. The offer will contain the Local Description of pc1 object and this Description is generated in the method setLocalDescription(..) in the function step1 as follows:

// pc1.createOffer finished, call pc1.setLocal
function step1(offer) {
pc1_offer = offer;
pc1.setLocalDescription(offer, step2, failed);
}

Now that pc1 has set its description, we have to set the Remote Description of pc2. This is done through the method setRemoteDescription(..) using the previously generated offer in the function step2 which is invoked while setting the Local Description of pc1 above. The function step2 looks like this:

// pc1.setLocal finished, call pc2.setRemote
function step2() {
pc2.setRemoteDescription(pc1_offer, step3, failed);
};

Now that the Local and Remote Descriptions are set for pc1 and pc2 respectively, it is required for pc2 to create an Answer which it will then send to pc1. This answer is created using the method pc2.createAnswer(..) in the function step3 invoked while creating the remote Description of pc2.

// pc2.setRemote finished, call pc2.createAnswer
function step3() {
pc2.createAnswer(step4, failed);
}

After creating the answer now pc2 also creates a Local Description using this answer. This is done through the method pc2.setLocalDescription(answer, step5, failed) as shown in the function step4 which is invoked previously while creating the answer:

function step4(answer) {
pc2_answer = answer;
pc2.setLocalDescription(answer, step5, failed);
}

Finally, the last step that remains is to set the Remote Description of pc1 using the answer generated previously by pc2. This is done in the method pc1.setRemoteDescription(pc2_answer, step6, failed) in the function step5 invoked while setting the Local Description of pc2:

// pc2.setLocal finished, call pc1.setRemote
function step5() {
pc1.setRemoteDescription(pc2_answer, step6, failed);
}

At long last our call is established – and your eyes will be filled with tears of joy

// pc1.setRemote finished, media should be running!
function step6() {
log("HIP HIP HOORAY");
}

Now look back at all the steps – not so bad eh? – Doable? – Of course. This is the power of WebRTC – peerConnection established in a few simple steps. Though it does get a little tricky when it comes to real world apps (which I realized very recently), its still manageable right?! For those of you who think its not, there are a few great APIs (one of which is AddLive’s API) available and more coming

I almost forgot – still a few final steps left.
In case of an error you can add the required error handlers and handle the errors differently/better depending upon your application/usage.But this is not a part that we shall cover here.

function failed(code) {
log("Failure callback: " + code);
}

Finally when you want to end the call you just close the peer connection using the syntax pc.close()

function stop() {
pc1.close();
pc2.close();

button.innerHTML = "Start!";
button.onclick = start;
}

That’s about it for this PeerConnection Overview.

In the next tutorial, I will try to explain what is going on underneath this neat JavaScript code. So it is enough if you have an abstract idea of how this works for now If possible I will also try to give you guys a brief idea of the underlying ICE protocol in the next blogpost. Hope you find this helpful. If you have any queries, feel free to comment here or ask on Twitter

“You could describe AddLive as a supplement to WebRTC; it takes the technology a step further. WebRTC only supports web browsers, but AddLive expands on this and also allows for the development of native iOS, Android, Windows and Mac OS X applications. Where WebRTC is solely a peer-to-peer technology, AddLive extends this to enable multiparty conferencing. It also supports screen sharing, firewall traversal, usage and quality analytics, and enterprise level support.

The rest is here: http://blog.programmableweb.com/2013/01/31/real-time-communications-made-easy-addlive-api/

1. It is still early days for WebRTC, “The various browser implementations of the current WebRTC specifications are the first go around with some of the implementations not even complete”
2. The codec issue, is it going to be H264 or VP8?
3. What are MS going to do with CU-RTC-Web?

I believe that the first issue will only last for 2013. By this time next year we’ll have robust implementations in Chrome, Firefox and Opera. The second issue will be solved by companies like us if the browser vendors can’t agree. The codec debate will continue though, but perhaps Google have an ace up their sleeve with VP9. If they can show that it is roughly as good as H.265, then perhaps its royalty free status will get the nay sayers on their side.

Full article here: http://blog.tmcnet.com/blog/tom-keating/webrtc/webrtc-challenges.asp

Fast forward two years and we are now offering our clients easy access to this technology not only in browsers but also in native WebRTC iOS and Android SDKs. We save them time and  money, allowing them to focus on their products and their business.

Steve Anderson, a contributing writer for TMCNet, just wrote a post summarizing how we are helping the WebRTC community.

I have added the first paragraph below, the rest you can find at: http://www.webrtcworld.com/topics/webrtc-world/articles/324429-addlive-looks-offer-peace-a-crazy-world-webrtc.htm

With constant movement going on in the Web-based real-time communications (WebRTC) market, it leaves a lot of room open for potential competitors to enter the field and show off just what they can do. The folks at AddLive are looking to not only provide a powerful new solution, but also throw in a little extra information about the idea of WebRTC as a whole, and what forces are impacting this constantly changing market.

It is part of a two article tutorial that teaches you how to create a 1-1 video room. You can have a look at a working prototype on JSFiddle here.

A big thanks to the guys at Gun.io. If you are looking for an engineering job, or looking to employ an engineer, make sure you give them a shout!

About Gun.io: gun.io is where hackers find jobs. Every month, tens of thousands of the best independent software developers from the open source community use gun.io to find high-quality freelance and full-time jobs.