News from Industry

The FreeSWITCH 1.4.21 release is here!

FreeSWITCH - Fri, 08/28/2015 - 20:30

The FreeSWITCH 1.4.21 release is here! This is a routine maintenance release and the resources are located here:

New features that were added:

  • FS-7760 [mod_sofia] Added xml fetch for channels to externally support nightmare transfer depends on channel-xml-fetch-on-nightmare-transfer profile param (default is disabled)

Improvements in build system, cross platform support, and packaging:

  • OPENZAP-238 [freetdm] Fix some GSM compilation errors and do a bit of code cleanup
  • OPENZAP-237 [freetdm] Use __func__ instead of __FUNCTION__ to comply with c99 in gcc 5.1
  • FS-7043 Fixed apr1 unresolved symbols in libfreeswitch.so.1.0.0
  • FS-7985 [mod_voicemail] Fixed a compilation error on 32-bit PCC platform
  • FS-8047 [mod_basic] Fixed a build error on newer compiler

The following bugs were squashed:

  • FS-8028 [mod_shout] fix random sockets
    being closed regression from FS-7621
  • FS-8037 [core] zrtp-passthru shouldn’t activate unless the zrtp-hash is in the SDP.
  • FS-7732 [mod_commands] Continue recording with uuid_transfer
  • FS-7721 [core] Fixed a segfault caused when using session:recordFile() and session:unsetInputCallback in a lua script
  • FS-7429 [mod_curl] Fixed to output valid json. NOTE: this may cause issues if you have worked around this invalid json already
  • FS-7761 [core] Fix shutdown races running api commands during shutdown
  • FS-7767 [mod_sofia] Fixed a segfault caused by invalid arguments to sip_dig
  • FS-7778 [mod_sofia] Fixed a bug causing a SQL statement to fail because of a double quote instead of a single quote
  • FS-7754 [freetdm] Fixed a bug relating to single digit dial-regex with analog devices
  • FS-7731 [mod_xml_cdr] Fixed a curl default connection timeout
  • FS-7685 [mod_say_nl] Fix Dutch numbers pronunciation
  • FS-7654 [core] Fixed regressions on eavesdropping on channels playing a file and on channels with unlike rates
  • FS-7866 [core] Fixed a crash when running incorrect var api expansion syntax “eval ${${external_sip_ip}:4}”
  • FS-7872 [mod_verto] Gracefully fail attempting to transfer 1 legged call
  • FS-7891 [mod_spandsp] Allow spandsp dtmf detector to work on rates other than 8k
  • FS-7839 [webrtc] Correct firefox > 38 DTLS behavior to match new EC requirements
  • FS-7917 [mod_sofia] Fixed default config, we really shouldn’t be setting ext-*-ip settings for ipv6 profiles
  • FS-7951 [mod_rayo] Completely clean up mod_rayo if it fails to load
  • FS-7955 [mod_sofia] Fixed a crash caused by invalid contact when using event to send a notify message
  • FS-7975 [mod_voicemail] Fix record-greeting event missing VM-Greeting-Path
  • FS-7969 Fixed a segfault due to pthread_setschedparam() on a thread that has exited
  • FS-7962 [mod_sofia] Fixed sporadic invite/replaces failure
  • FS-7486 [mod_sofia] Fixed the handling of queued requests
  • FS-7750 [mod_commands] Set uuid_setvar to handle arrays

Gaming with the WebRTC DataChannel – A Walkthrough with Arin Sime

webrtchacks - Thu, 08/27/2015 - 14:51

The fact that you can use WebRTC to implement a secure, reliable, and standards based peer-to-peer network is a huge deal that is often overlooked.  We have been notably light on the DataChannel here at webrtcHacks, so I asked Arin Sime if would be interested in providing one of his great walkthrough’s on this topic.  He put together a very practical example of a multi-player game.  You make recognize Arin from RealTime Weekly or from his company Agility Feat or his new webRTC.ventures brand. Check out this excellent step-by-step guide below and start lightening the load on your servers and reducing message latency with the DataChannel.

{“editor”: “chad hart“}

WebRTC is “all about video chat”, right? I’ve been guilty of saying things like that myself when explaining WebRTC to colleagues and clients, but it’s a drastic oversimplification that should never go beyond your first explanation of WebRTC to someone.

Of course, there’s more to WebRTC than just video chat. WebRTC allows for peer-to-peer video, audio, and data channels.  The Data channels are a distinct part of that architecture and often forgotten in the excitement of seeing your video pop up in the browser.

Don’t forget about the Data Channel!

Being able to exchange data directly between two browsers, without any sort of intermediary web socket server, is very useful. The Data Channel carries the same advantages of WebRTC video and audio:  it’s fully peer-to-peer and encrypted.  This means Data Channels are useful for things like text chat applications, file transfers, P2P file exchanges, gaming, and more.a

In this post, I’m going to show you the basics of how to setup and use a WebRTC Data Channel.

First, let’s review the architecture of a WebRTC application.

You have to setup signaling code in order to establish the peer to peer connection between two peers.  Once the signaling is complete (which takes place over a 3rd party server), then you have a Peer to Peer (P2P) connection between two users which can contain video and audio streams, and a data channel.

The signaling for both processes is very similar, except that if you are building a Data Channel only application then you don’t need to call GetUserMedia or exchange streams with the other peer.

Data Channel Security

There are a couple of other differences about using the DataChannel.  The most obvious one is that users don’t need to give you their permission in order to establish a Data Channel over an RTCPeerConnection object.  That’s different than video and audio, which will prompt the browser to ask the user for permissions to turn on their camera and microphone.

Although it’s generating some debate right now, data channels don’t require explicit permission from users.  That makes it similar to a web socket connection, which can be used in a website without the knowledge of users.

The Data Channel can be used for many different things.  The most common examples are for implementing text chat to go with your video chat.  If you’re already setting up an RTCPeerConnection for video chat, then you might as well use the same connection to supply a Data Channel for text chat instead of setting up a different socket connection for text chat.

Likewise, you can use the Data Channel for transferring files directly between your peers in the RTCPeerConnection.  This is nicer than a normal socket style connection because just like WebRTC video, the Data Channel is completely peer-to-peer and encrypted in transit.  So your file transfer is more secure than in other architectures.

The game of “Memory”

Don’t limit your Data Channel imagination by these common examples though.  In this post, I’m going to show you how to use the Data Channel to build a very simple two-player game.  You can use the Data Channel to transfer any type of data you like between two browsers, so in this case we’ll use it to send commands and data between two players of a game you might remember called “Memory”.

In the game of memory, you can flip over a card, and then flip a second card, and if they match, you win that round and the cards stay face up.  If they didn’t match, you put both face down again, and it’s the next person’s turn.  By trying to remember what you and your opponents have been flipping, and where those cards were, you can win the game by correctly flipping the most pairs.

Photo Credit: http://www.vwmin.org/memory-game.html

Adam Khoury already built a javascript implementation of this game for a single player, and you can read his tutorial on how to build the game Memory for a single player.  I won’t explain the logic of his code for building the game, what I’m going to do instead is build on top of his code with a very simple WebRTC Data Channel implementation to keep the card flipping in synch across two browsers.

You can see my complete code on GitHub, and below I’m going to show you the relevant segments.

In this example view of my modified Memory game, the user has correctly flipped pairs of F, D, and B, so those cards will stay face up.  The cards K and L were just flipped and did not match, so they will go back face down.

Setting up the Data Channel configuration

I started with a simple NodeJS application to serve up my code, and I added in Express to create a simple visual layer.  My project structure looks like this:

The important files for you to look at are datachannel.js (where the majority of the WebRTC logic is), memorygame.js (where Adam’s game javascript is, and which I have modified slightly to accommodate the Data Channel communications), and index.ejs, which contains a very lightweight presentation layer.

In datachannel.js, I have included some logic to setup the Data Channel.  Let’s take a look at that:

//Signaling Code Setup var configuration = {         'iceServers': [{                 'url': 'stun:stun.l.google.com:19302'         }] }; var rtcPeerConn; var dataChannelOptions = {         ordered: false, //no guaranteed delivery, unreliable but faster         maxRetransmitTime: 1000, //milliseconds }; var dataChannel;

The configuration variable is what we pass into the RTCPeerConnection object, and we’re using a public STUN server from Google, which you often see used in WebRTC demos online.  Google is kind enough to let people use this for demos, but remember that it is not suitable for public use and if you are building a real app for production use, you should look into setting up your own servers or using a commercial service like Xirsys to provide production ready STUN and TURN signaling for you.

The next set of options we define are the data channel options.  You can choose for “ordered” to be either true or false.

When you specify “ordered: true”, then you are specifying that you want a Reliable Data Channel.  That means that the packets are guaranteed to all arrive in the correct order, without any loss, otherwise the whole transaction will fail.  This is a good idea for applications where there is significant burden if packets are occasionally lost due to a poor connection.  However, it can slow down your application a little bit.

We’ve set ordered to false, which means we are okay with an Unreliable Data Channel.  Our commands are not guaranteed to all arrive, but they probably will unless we are experiencing poor connectivity.  Unless you take the Memory game very seriously and have money on the line, it’s probably not a big deal if you have to click twice.  Unreliable data channels are a little faster.

Finally, we set a maxRetransmitTime before the Data Channel will fail and give up on that packet.   Alternatively, we could have specified a number for maxRetransmits, but we can’t specify both constraints together.

Those are the most common options for a data channel, but you can also specify the protocol if you want something other than the default SCTP, and you can set negotiated to true if you want to keep WebRTC from setting up a data channel on the other side.  If you choose to do that, then you might also want to supply your own id for the data channel.  Typically you won’t need to set any of these options, leave them at their defaults by not including them in the configuration variable.

Set up your own Signaling layer

The next section of code may be different based on your favorite options, but I have chosen to use express.io in my project, which is a socket.io package for node that integrates nicely with the express templating engine.

So the next bit of code is how I’m using socket.io to signal to any others on the web page that I am here and ready to play a game.  Again, none of this is specified by WebRTC.  You can choose to kick off the WebRTC signaling process in a different way.

io = io.connect(); io.emit('ready', {"signal_room": SIGNAL_ROOM}); //Send a first signaling message to anyone listening //In other apps this would be on a button click, we are just doing it on page load io.emit('signal',{"type":"user_here", "message":"Would you like to play a game?", "room":SIGNAL_ROOM});

In the next segment of datachannel.js, I’ve setup the event handler for when a different visitor to the site sends out a socket.io message that they are ready to play.

io.on('signaling_message', function(data) {         //Setup the RTC Peer Connection object         if (!rtcPeerConn)                 startSignaling();         if (data.type != "user_here") {                 var message = JSON.parse(data.message);                 if (message.sdp) {                         rtcPeerConn.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {                                 // if we received an offer, we need to answer                                 if (rtcPeerConn.remoteDescription.type == 'offer') {                                         rtcPeerConn.createAnswer(sendLocalDesc, logError);                                 }                         }, logError);                 }                 else {                         rtcPeerConn.addIceCandidate(new RTCIceCandidate(message.candidate));                 }         }         });

There are several things going on here.  The first one to be executed is that if the rtcPeerConn object has not been initialized yet, then we call a local function to start the signaling process.  So when Visitor 2 announces themselves as here, they will cause Visitor 1 to receive that message and start the signaling process.

If the type of socket.io message is not “user_here”, which is something I arbitrarily defined in my socket.io layer and not part of WebRTC signaling, then the code goes into a couple of WebRTC specific signaling scenarios – handling an SDP “offer” that was sent and crafting the “answer” to send back, as well as handling ICE candidates that were sent.

The WebRTC part of Signaling

For a more detailed discussion of WebRTC signaling, I refer you to http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/”>Sam Dutton’s HTML5 Rocks tutorial, which is what my signaling code here is based on.

For completeness’ sake, I’m including below the remainder of the signaling code, including the startSignaling method referred to previously.

function startSignaling() {         rtcPeerConn = new webkitRTCPeerConnection(configuration, null);         dataChannel = rtcPeerConn.createDataChannel('textMessages', dataChannelOptions);         dataChannel.onopen = dataChannelStateChanged;         rtcPeerConn.ondatachannel = receiveDataChannel;         // send any ice candidates to the other peer         rtcPeerConn.onicecandidate = function (evt) {                 if (evt.candidate)                         io.emit('signal',{"type":"ice candidate", "message": JSON.stringify({ 'candidate': evt.candidate }), "room":SIGNAL_ROOM});         };         // let the 'negotiationneeded' event trigger offer generation         rtcPeerConn.onnegotiationneeded = function () {                 rtcPeerConn.createOffer(sendLocalDesc, logError);         }   }   function sendLocalDesc(desc) {         rtcPeerConn.setLocalDescription(desc, function () {                 io.emit('signal',{"type":"SDP", "message": JSON.stringify({ 'sdp': rtcPeerConn.localDescription }), "room":SIGNAL_ROOM});         }, logError); }

This code handles setting up the event handlers on the RTCPeerConnection object for dealing with ICE candidates to establish the Peer to Peer connection.

Adding DataChannel options to RTCPeerConnection

This blog post is focused on the DataChannel more than the signaling process, so the following lines in the above code are the most important thing for us to discuss here:

rtcPeerConn = new webkitRTCPeerConnection(configuration, null); dataChannel = rtcPeerConn.createDataChannel('textMessages', dataChannelOptions); dataChannel.onopen = dataChannelStateChanged; rtcPeerConn.ondatachannel = receiveDataChannel;

In this code what you are seeing is that after an RTCPeerConnection object is created, we take a couple extra steps that are not needed in the more common WebRTC video chat use case.

First we ask the rtcPeerConn to also create a DataChannel, which I arbitrarily named ‘textMessages’, and I passed in those dataChannelOptions we defined previously.

Setting up Message Event Handlers

Then we just define where to send two important Data Channel events:  onopen and ondatachannel.  These do basically what the names imply, so let’s look at those two events.

function dataChannelStateChanged() {         if (dataChannel.readyState === 'open') {                 dataChannel.onmessage = receiveDataChannelMessage;         } } function receiveDataChannel(event) {         dataChannel = event.channel;         dataChannel.onmessage = receiveDataChannelMessage; }

 

When the data channel is opened, we’ve told the RTCPeerConnection to call dataChannelStateChanged, which in turn tells the dataChannel to call another method we’ve defined, receiveDataChannelMessage, whenever a data channel message is received.

The receiveDataChannel method gets called when we receive a data channel from our peer, so that both parties have a reference to the same data channel.  Here again, we are also setting the onmessage event of the data channel to call our method receiveDataChannelMessage method.

Receiving a Data Channel Message

So let’s look at that method for receiving a Data Channel message:

function receiveDataChannelMessage(event) {                 if (event.data.split(" ")[0] == "memoryFlipTile") {                 var tileToFlip = event.data.split(" ")[1];                 displayMessage("Flipping tile " + tileToFlip);                 var tile = document.querySelector("#" + tileToFlip);                 var index = tileToFlip.split("_")[1];                 var tile_value = memory_array[index];                 flipTheTile(tile,tile_value);         } else if (event.data.split(" ")[0] == "newBoard") {                 displayMessage("Setting up new board");                 memory_array = event.data.split(" ")[1].split(",");                 newBoard();         } }

Depending on your application, this method might just print out a chat message to the screen.  You can send any characters you want over the data channel, so how you parse and process them on the receiving end is up to you.

In our case, we’re sending a couple of specific commands about flipping tiles over the data channel.  So my implementation is parsing out the string on spaces, and assuming the first item in the string is the command itself.

If the command is “memoryFlipTile”, then this is the command to flip the same tile on our screen that our peer just flipped on their screen.

If the command is “newBoard”, then that is the command from our peer to setup a new board on our screen with all the cards face down.  The peer is also sending us a stringified array of values to go on each card so that our boards match.  We split that back into an array and save it to a local variable.

Controlling the Memory game to flip tiles

The actual flipTheTile and newBoard methods that are called reside in the memorygame.js file, which is essentially the same code that we’ve modified from Adam.

I’m not going to step through all of Adam’s code to explain how he built the single player Memory game in javascript, but I do want to highlight two places where I refactored it to accommodate two players.

In memorygame.js, the following function tells the DataChannel to let our peer know which card to flip, as well as flips the card on our own screen:

function memoryFlipTile(tile,val){         dataChannel.send("memoryFlipTile " + tile.id);         flipTheTile(tile,val); }

Notice how simple it is to send a message to our peers using the data channel – just call the send method and pass any string you want.  A more sophisticated example might send well formatted XML or JSON in a message, in any format you specify.  In my case, I just send a command followed by the id of the tile to flip, with a space between.

Setting up a new game board

In Adam’s single player memory game, a new board is setup whenever you load the page.  In my two player adaptation, I decided to have a new board triggered by a button click instead:

var setupBoard = document.querySelector("#setupBoard"); setupBoard.addEventListener('click', function(ev){         memory_array.memory_tile_shuffle();         newBoard();         dataChannel.send("newBoard " + memory_array.toString());         ev.preventDefault(); }, false);

 

In this case, the only important thing to notice is that I’ve defined a “newBoard” string to send over the data channel, and in this case I want to send a stringified version of the array containing the values to put behind each card.

Next steps to make the game better

That’s really all there is to it!  There’s a lot more we could do to make this a better game.  I haven’t built in any logic to limit the game to two players, keep score by players, or enforce the turns between the players.  But it’s enough to show you the basic idea behind using the WebRTC data channel to send commands in a multiplayer game.

The nice thing about building a game like this that uses the WebRTC data channel is it’s very scalable.  All my website had to do is help the two players get a connection setup, and after that, all the data they need to exchange with each other is done over an encrypted peer-to-peer channel and it won’t burden my web server at all.

A completed multiplayer game using the Data Channel

Here’s a video showing the game in action:

Demo of a simple two player game using the WebRTC Data Channel video

As I hope this example shows you, the hard part of WebRTC data channels is really just in the signaling and configuration, and that’s not too hard.  Once you have the data channel setup, sending messages back and forth is very simple.  You can send messages that are as simple or complex as you like.

How are you using the Data Channel?  What challenges have you run into?  Feel free to contact me on Twitter or through my site to share your experiences too!

{“author”: “arin sime“}

Sources:

http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

http://www.w3.org/TR/webrtc/#simple-peer-to-peer-example

https://www.developphp.com/video/JavaScript/Memory-Game-Programming-Tutorial

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.

The post Gaming with the WebRTC DataChannel – A Walkthrough with Arin Sime appeared first on webrtcHacks.

40 days until the Communications Revolution! Time to book your...

2600hz - Tue, 08/25/2015 - 23:29


40 days until the Communications Revolution! Time to book your hotel. Join us at KazooCon for talks from FreeSWITCH, Kamailio, Mast Mobile, Virtual PBX, IBM Cloudant, Telnexus and many more! Register now and save: www.KazooCon.com

Making WebRTC source building not suck (Alex Gouaillard)

webrtchacks - Tue, 08/25/2015 - 15:17

One of WebRTC’s benefits is that the source to it is all open source. Building WebRTC from source provides you the ultimate flexibility to do what you want with the code, but it is also crazy difficult for all but the small few VoIP stack developers who have been dedicated to doing this for years. What benefit does the open source code provide if you can’t figure out how to build from it?

As WebRTC matures into mobile, native desktop apps, and now into embedded devices as part of the Internet of Things, working with the lower-level source code is becoming increasingly common.

Frequent webrtcHacks guest poster Dr. Alex Gouaillard has been trying to make this easier. Below he provides a review of the building WebRTC from source, exposing many of the gears WebRTC developers take for granted when they leverage a browser or someone else’s SDK. Alex also reviews the issues complexities associated with this process and introduces the open source make process he developed to help ease the process.

{“editor”: “chad hart“}

Building WebRTC from source sometimes feels like engineering the impossible. Photo courtesy of Andrew Lipson.

Building WebRTC from source

Most of the audience for WebRTC (and webrtcHacks)  is made of web developers, JavaScript and cloud ninjas that might not be less familiar with handling external libraries from source. That process is painful. Let’s make it clear, it’s painful for everybody – not only web devs.

 What are the cases where you need to build from source?

  1. Writing a native app – mobile, desktop, IoT,..)
  2. Some kind of server (gateway, media, ….)
  3. Plugin (either for IE, Safari, Cordova, …)

 You basically need to build from source anytime you can’t leverage a browser, WebRTC enabled node.js (for the sake of discussion), SDK’s someone how put together for you,  or anything else.

 These main cases are illustrated below in the context of a comprehensive offering.

Figure 1: map of a WebRTC solution

Usually, the project owners provide precompiled and tested libraries that you can use yourself (stable) and the most recent version that is compiled but not tested for those who are brave.

Pre-compiled libraries are usable out of the box, but do not allow you to modify anything. Sometimes there are build scripts that help you recompile the libs yourselves. This provides more flexibility in terms of what gets in the lib, and what optimizations/options you set, at the cost of now having to maintain a development environment.

Comparing industry  approaches

For example, Cisco with its openH264 library provides both precompiled libraries and build scripts. In their case, using the precompiled library defers H264 royalty issues to them, but that’s another subject. While the libwebrtc project includes build scripts, they are complex use, do not provide a lot of flexibility for modifying the source, and make it difficult to test any modifications.

The great cordova plugin from eFace2Face is using a precompiled libWebRTC (here) (see our post on this too). Pristine.io were among the first one to propose build script to make it easier (see here; more about that later).

Sarandogou/doubango’s webrtc-everywhere plugin for IE and Safari does NOT use automated build scripts, versioning or a standard headers layout, which causes them a lot of problems and slows their progress.

The pristine.io guys put a drawing of what the process is, and noted that, conceptually, there is not a big difference between android and iOS build as to the steps you need to follow. Practically, there is a difference in the tools you used though.

My build process

Here is my build process:

 

Please also note that I mention testing explicitly and there is a good reason for that, learned the hard way. I will come to it in the next section.

You will see I have a “send to dashboard” step. I mean something slightly different than what people usually refer to as a dashboard. Usually, people want to report the results of the tests to a dashboard to show that a given revision is bug free (as much as possible) and that the corresponding binary can be used in production.

If you have performance tests, a dashboard can also help you spot performance regressions.  In my case here, I also want to use a common public dashboard as a way to publish failing builds on different systems or with different configurations, and still provide full log access to anyone. It makes solving those problem easier. The one asking the question can point to the dashboard, and interesting parties have an easier time looking at the issue or reproducing it. More problems reported, more problems solved, everyone is happy.

Now that we have reviewed the build from source process a bit, let’s talk about what’s wrong with it.

Building from Source Sucks

Writing an entire WebRTC stack is insanely hard. That’s why Google went out and bought GIPS, even though they have a lot of very very good engineers at disposal. Most devs and vendors use an existing stack.

For historical reasons most people use google’s contributed WebRTC stack based on the GIPS media engine, and Google’s libjingle for the network part.

Even Mozilla is using the same media engine, even though they originally went for a Cisco SIP soft phone code as the base (see here, under “list of components”, “SIPCC”) to implement the network part of WebRTC. Since then, Mozilla went on and rewrote almost all that part to support more advanced functionality such as multi-party. However, the point is, their network and signaling is different from Google’s while their media engine is almost identical. Furthermore, Mozilla does not attempt to provide a standalone version of their WebRTC implementation, which makes it hard for developers to make use of it right away.

Before Ericson’s OpenWebRTC announcement in October 2014, the Google standalone version was the only viable option out there for most. OpenWebRTC has advantages on some parts, like hardware support for H.264 on iOS for example, but lacks some features and Windows support that can be a showstopper for some. It is admittedly less mature. It also uses GStreamer, which has its own conventions and own build system (cerbero), which is also tough to learn.

The webrtc.org stack is not available in a precompiled library with an installer. This forces developers to compile WebRTC themselves, which is “not a picnic”.

One needs first to become accustomed to Chrome dev tools which are quite unique, adding a learning step to the process. The code changes quite often (4 commits a day), and the designs are poorly documented at best.

Even if you manage to compile the libs, either by yourself or using resources on the web, it is almost certain that you cannot test it before using it in your app, as most of the bug report, review, build, test and dashboard  infrastructure is under the control of Google by default.

Don’t get me wrong, the bug report and review servers allow anybody to set up an account. What is done with your tickets or suggestions however is up to Google. You can end up with quite frustrating answers. If you dig deep enough in the Chrome infrastructure for developers, you will also find how to replicate their entire infrastructure, but the level you need to have to go through this path, and the amount of effort to get it right is prohibitive for most teams. You want to develop your product, not become a Chrome expert.

Finally, the contributing process at Google allows for bugs to get in. You can actually looks at the logs and see a few “Revert” commits there.

Figure 2: Example of a Revert commit message.

From the reverted commits (see footnote[1]: 107 since January 2015), one can tell that revisions of WebRTC on the HEAD are arbitrarily broken. Here again, this comment might be perceived as discriminatory against Google. It is not. There is nothing wrong there; it always happen for any project, and having only 107 reverts in 6 months while maintaining 4 commits a day is quite an achievement. However, it means that you, as a developer, cannot work with any given commit and expect the library to be stable. You have at least to test it yourself.

My small side project to help

My goals are:

  1. Provide information to the community that is not documented elsewhere, or not consolidated. The blog posts on www.webrtcbydralex.com fulfill this goal.
  2. Learn more about WebRTC
  3. Prepare a course for the local university.
  4. Do something useful of my current “long vacations”

    Yes, vacations in Boracay, Philippines, once voted #2 most beautiful beach in the world by tripadvisor are nice. But I very quickly get that I-need-to-code urge, and they have Wi-Fi on the beach ….

  5. Have fun!

More importantly I would like to lower the barrier of adoption / collaboration / contribution by providing:

  • WebRTC installers that sync with chrome revisions that developers could use blindly out of the box (knowing they’ve been tested)
  • Code for anyone to set up their own build/try/package pipeline, either locally or in the cloud
  • Easy patching and testing framework to enhance Webrtc. As an example, provide an h264 compliant WebRTC lib based on work from Kaiduan Xue, Jesup Randell, and others.
  • More examples and applications for Devs to start from. A first example will be a stand-alone, h264 compliant, appRTCDemo desktop app.
  • Public dashboard for a community to come together, contribute build bots and de duplicate the tests efforts going on at almost every vendor for the base stack.
  • Public dashboard for people to submit their fail builds as a way to ask question on the mailing list and get faster answers.

Example of my dashboard

What we did exactly

We leveraged the CMake / CTest / CDash / CPack suite of tools instead of the usual shell scripts, to automate most of the fetch, configure, build, test, report and package processes.

CMake is cross platform from the ground up, and makes it very easy to deploy such processes. No need to maintain separate or different build scripts for each platform, or build-toolchain.

CTest help you manage your test suites, and is also a client for CDash which handle the dashboard part of the process.

Finally CPack handle packaging your libs with headers and anything else you might want, and support a lot of different packagers with a unified syntax.

This entire suite of tools have also designed in such a way that “a gifted master student could use it and contribute back in a matter of days”, while being so flexible and powerful that big companies like Netflix or Canonical (Ubuntu), use it as the core of their engineering process.

Most of the posts at webrtcbydralex.com will take you through the process, step by step of setting up this solution., in conjunction with a github repository holding all the corresponding source code.

The tool page provides installers for WebRTC for those in a hurry.

{“author”: “Alex Gouaillard“}

[1] git log –since=1.week –pretty=oneline | grep Revert | wc -l

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.

The post Making WebRTC source building not suck (Alex Gouaillard) appeared first on webrtcHacks.

Kamailio Advanced Training, Sep 28-30, 2015, in Berlin

miconda - Tue, 08/25/2015 - 10:32
Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during September 28-30, 2015.The content will be based on latest stable series of Kamailio 4.3.x, released in June 2015, the major version that brought a large set of new features.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:Looking forward to coordinating the training session in Berlin!

FreeSWITCH Week in Review (Master Branch) August 15th-August 21st

FreeSWITCH - Tue, 08/25/2015 - 06:03

Hello, again. This past week in the FreeSWITCH master branch we had 56 commits. This week the features are: a wonderful perl script, filebug.pl, to help file bugs from the command line, and more work on improving verto communicator including integration of Gravatars, some filter options, and grunt.

Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

  • FS-7988 Add a perl script to help file bugs from the command line and add fixbug.pl to tree
  • FS-8009 [verto communicator] Create a grunt project with livereload support. Documentation can be found here.
  • FS-8010 [verto communicator] Add options for googAutoGainControl, googNoiseSuppression, and googHighpassFilter
  • FS-7855 [verto communicator] Pass userVariables back to the live array to allow for displaying the Gravatar associated with a member’s email address

Improvements in build system, cross platform support, and packaging:

  • FS-7965 [mod_conference] Fixed an error thrown when compiling with GCC
  • FS-7985 [mod_voicemail] Fixed a compilation error on 32-bit PCC platform
  • FS-8015 [mod_conference] Add project dir to include for mod_conference so it picks up mod_conference.h for Windows

The following bugs were squashed:

  • FS-7970 Fixed crash in video_bug_thread caused by double free
  • FS-7971 [mod_opus] Fixed a rate mismatch and correctly advertise telephone-event and CN rates based on the advertised rates of offered codecs
  • FS-7960 Fixed check_ice routine in switch_core_media.c to not use dropped candidates
  • FS-7975 [mod_voicemail] Fix record-greeting event missing VM-Greeting-Path
  • FS-7969 Fixed a segfault due to pthread_setschedparam() on a thread that has exited
  • FS-7962 Fixed sporadic invite/replaces failure
  • FS-8004 Send keyframe on receiving nack with multiple consecutive packets
  • FS-8005 [mod_opus] Fix for rare decoder error when doing PLC, OPUS_GET_LAST_PACKET_DURATION might return 0
  • FS-8006 Changed the typedef of switch_core_video_thread_callback_func_t for consistency
  • FS-7932 [mod_verto] Removed the param from the getMute function in verto class, not needed on underlying method
  • FS-8008 [mod_verto] Separate verto default config to have sep v4 and v6 listeners
  • FS-8016 [mod_conference] Reduce buffering of video in conference mux
  • FS-7977 [verto communicator] Fixing default resolution and cleaning code
  • FS-7992 [verto communicator] Fixed device list at settings
  • FS-8017 [verto communicator] Fixed uses of serialized verto in local storage
  • FS-7986 [verto communicator] Fix for devices not refreshing if system config changes
  • FS-7998 [verto communicator] Don’t prompt when recovering call, just do it.
  • FS-8003 [verto communicator] Use audioInDevices instead of audioDevices to match verto plugin

Kamailio and Docker

miconda - Mon, 08/24/2015 - 17:59
Containers have become rather popular lately and Docker is the technology leader. Containers make it easy to prototype and test, but many see them as a way to scale on demand, therefore pushing towards production deployments.Searching the web about Kamailio and Docker reveals plenty of resources, from bare dockerfiles to detailed blog articles to combine Docker, Kamailio and other VoIP applications such as Asterisk.Here are links to such resources:Some Docker resources exist for Siremis, the web management interface for Kamailio:Note that we haven’t explicitly tested those resources, it is up to you to select one, adjust and test as you need. This post has the role to provide a starting point for using Kamailio with Docker.If you are aware of other resources relevant for Kamailio and Docker, write to mailing list  to get them listed here.Enjoy!

Quick vacation

bloggeek - Fri, 08/21/2015 - 13:00

It is time for a quick vacation.

In the past, I tried publishing here while on vacation, I’ll refrain from it this time.

Please do your best not to acquire anyone until end of August.

See you all next month!

The post Quick vacation appeared first on BlogGeek.me.

What WebRTC Tool are you using for your Service?

bloggeek - Thu, 08/20/2015 - 12:00

I need your help to gain better visibility.

If you are developing something with WebRTC, there’s a good chance you are using existing tools and frameworks already. Be it signaling or messaging frameworks, a media engine in the backend, a third party mobile library.

As I work on my research around the tools enabling the vibrant ecosystem that is WebRTC, I find myself more than once wondering about a specific tool – how much is it used? What do people think about? Are they happy with it? What are its limitations? While I know the answers in some cases, in others not so much. This is where you come in.

If you are willing to share your story with a third party tool – one you purchased or an open source one – I’d like to hear about it. Even if it is only the name of the tool or a one liner.

Feel free to comment below or just use my contact form if you wish this to stay private between us.

I really appreciate your help in this.

The post What WebRTC Tool are you using for your Service? appeared first on BlogGeek.me.

We’re officially less than 50 days until KazooCon! Buy...

2600hz - Wed, 08/19/2015 - 03:07


We’re officially less than 50 days until KazooCon! Buy your tickets, get a flight, and get out to San Francisco! http://goo.gl/SQqpO4

ClueCon Follow Up

miconda - Tue, 08/18/2015 - 17:57
Another edition of Cluecon conference ended recently in Chicago, a good crowd of VoIP developers spent time together to share what is new around the world for real time communications.I had a presentation about Kamailio and API driven SIP routing (slideshare– pdf).Erik Davidson and Gary Kramlich from Corvisa presented a scalable VoIP platform architecture (pdf) relying on Kamailio and FreeSwitch, announcing also the intent of publishing two new modules for Kamailio.Guys at Kazoo (contributors of kazoo module in Kamailio) gave an update about their open source cloud PBX system.Hopefully, the video recording of the sessions will be available soon, there were plenty of other sessions referring to Kamailio, which shared interesting concepts for use with real time communication services.

FreeSWITCH Week in Review (Master Branch) August 8th-August 14th

FreeSWITCH - Tue, 08/18/2015 - 00:22

Hello, again. This past week in the FreeSWITCH master branch we had 7 commits. There were no new features this week, but you should go check out the Verto Communicator that was added last week!

Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.

The following bugs were squashed:

  • FS-7930 [mod_conference] Correct termination of conference when the last member with endconf left.
  • FS-7953 [verto communicator] Fixed dialing when typing extension using the keyboard.
  • FS-7958 [mod_conference] Fixed a race condition causing crash in conference video MCU
  • FS-7951 [mod_rayo] Completely clean up mod_rayo if it fails to load
  • FS-7955 [mod_sofia] Fixed a crash caused by invalid contact when using event to send a notify message

FreeSWITCH Week in Review (Master Branch) August 1st-August 7th

FreeSWITCH - Tue, 08/18/2015 - 00:22

Hello, again. This past week in the FreeSWITCH master branch we had 17 commits. The new features this week are: new properties added to the amqp configuration, fixed the usage for enable_fallback_format_fields, a fix for a routing key issue in amqp, and the awesome new Verto Communicator!

Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

  • FS-7806 FS-7803 [mod_amqp] Added new properties to amqp configuration, fixed the usage for enable_fallback_format_fields, and added amqp_util_encode to fix a routing key issue
  • FS-7972 [verto communicator] Creating Verto Communicator

Improvements in build system, cross platform support, and packaging:

  • FS-7728 Fixed Windows build issues minus video features

The following bugs were squashed:

  • FS-7940 [mod_conference] Fixed an issue where the video image does not appear on the new canvas when switching

FreeSWITCH Week in Review (Master Branch) July 25th-July 31st

FreeSWITCH - Tue, 08/18/2015 - 00:18

Hello, again. This past week in the FreeSWITCH master branch we had 41 commits. The new features this week are: improved mod_png to allow snapshot of single legged calls, added session UUID to lua error logs and added session UUID to embedded language (lua, javascript, etc) logs when session sanity check fails, improved the xml fetch lookup for channels on nightmare transfer, and added uuid_redirect API command to mod_commands.

Join us on Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

  • FS-7900 [mod_png] Allow snapshot of single legged calls
  • FS-7912 [mod_lua] Added session UUID to lua error logs, if known and added session UUID to embedded language (lua, javascript, etc) logs when session sanity check fails
  • FS-7760 [mod_sofia] Improved the xml fetch lookup for channels on nightmare transfer
  • FS-7922 [mod_commands] Added uuid_redirect API command. This provides the equivalent functionality of the dptools “redirect” application as an api command.

The following bugs were squashed:

  • FS-7769 [mod_conference] Fixed vmute on personal canvas and fixed changing layouts on personal canvas
  • FS-7893 [mod_conference] Fixed a bug causing muxing write thread to occasionally not close on shutdown
  • FS-7904 Fixed alpha image patching
  • FS-7906 [mod_av] Correct crash from multi-threaded opening or closing of multiple files at the same time
  • FS-7913 [mod_conference] Fixed miscast variable
  • FS-7918 [mod_kazoo] Small fixes in mod_kazoo
  • FS-7917 [mod_sofia] Fixed default config, we really shouldn’t be setting ext-*-ip settings for ipv6 profiles
  • FS-7908 FS-7092 Fixed the generated sdp including telephone-event for the rates of video codecs (90000) when it should only be audio codec rates
  • FS-7927 Fixed a typo in variable name: eavesdrop_annnounce_macro

If Microsoft can Deliver Windows 10 P2P, Why Can’t we with WebRTC?

bloggeek - Mon, 08/17/2015 - 12:00

What do you know? Peer assisted delivery a-la WebRTC data channel is acceptable.

Whenever write something about the potential of using WebRTC’s data channel for augmenting CDN delivery and getting peers who want to access content to assist each other, there are those who immediately push back. The main reasons? This eats up into data caps and takes up battery.

It was hard to give any real user story besides something like BitTorrent for consumers or how Twitter uses BitTorrent internally to upgrade its servers. Not enough to convince many of my readers here that P2P is huge and WebRTC will be a part of it.

The WebRTC will be a part of it has been covered on this blog many times. P2P is huge is a different story. At least until last month.

Windows 10 was officially released end of July. And with it, millions of PCs around the world got updated. I ran into this article on TheNextWeb by Owen Willions:

by default, Windows 10 uses your internet connection to share updates with others across the internet.

The feature, called Windows Update Delivery Optimization is designed to help users get updates faster and is enabled by default in Windows 10 Home and Pro editions. Windows 10 Enterprise and Education have the feature enabled, but only for the local network.

It’s basically how torrents work: your computer is used as part of a peer to peer network to deliver updates faster to others. It’s a great idea, unless your connection is restricted.

So. Microsoft decided to go for peer assisted delivery and not only a CDN setup to get Windows 10 installation across the wires to its millions of users. That’s 2-3 Gb of a download.

Probably the first large scale commercial use of P2P out there – and great validation for the technique.

I know – they received backlashes and complaints for doing so, but what I haven’t seen is Microsoft stopping this practices. This is another step in the Internet decentralization trend that is happening.

I wonder who will be next.

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post If Microsoft can Deliver Windows 10 P2P, Why Can’t we with WebRTC? appeared first on BlogGeek.me.

48 Hours left for the WebRTC PaaS Summer Sale

bloggeek - Sat, 08/15/2015 - 12:00

Grab your copy of my WebRTC PaaS report at a $450 discount.

If you are subscribed to my monthly newsletter, then you already know about this summer sale for two weeks:

  • My Choosing a WebRTC API Platform is available at a discount
  • $1,500 instead of $1,950
  • Time limited until the 17th of August
  • Which leaves you 48 hours to purchase it

The reasons?

  1. I am heading towards vacation, making August a short month for me
  2. In September, the an update to this report will be released
  3. This update will include a real membership/subscription service with a few interesting additions:
    1. Online vendor comparison matrix that will be updated periodically
    2. Monthly web meetings to discuss recent changes and any questions you may have on the subject

If you hurry and purchase it in the next two days, you’ll enjoy the lower price point as well as the membership perks – so why wait? Get your copy of the report now.

The post 48 Hours left for the WebRTC PaaS Summer Sale appeared first on BlogGeek.me.

WIT Software and WebRTC: An Interview With André Silva

bloggeek - Thu, 08/13/2015 - 12:00
isVisible=false; function show_hide_searchbox(w){ if(isVisible){ document.getElementById('filterBoxSelection').style.display = 'none'; w.innerText='Filter ▼'; }else{ document.getElementById('filterBoxSelection').style.display = 'block'; w.innerText='Filter ▲'; } isVisible=!isVisible; } function checkIfSelected(chk){ if(chk.checked==1) chk.parentNode.className = "selected"; else chk.parentNode.className = "notselected"; getSelectedValues(); } function getSelectedValues(){ var a=document.getElementsByClassName('selected'); var vtVal=[] , ctVal=[] , ftVal=[]; var ct=0,vt=0,ft=0; for (x = 0; x < a.length; ++x) { try{ if(a[x].getElementsByTagName('input')[0].className=='companyType'){ ctVal[ct]= a[x].getElementsByTagName('input')[0].value; ct++; } if(a[x].getElementsByTagName('input')[0].className=='vendorType'){ vtVal[vt]= a[x].getElementsByTagName('input')[0].value; vt++; } if(a[x].getElementsByTagName('input')[0].className=='focusType'){ ftVal[ft]= a[x].getElementsByTagName('input')[0].value; ft++; } }catch(err){ } } search_VType(vtVal); search_CType(ctVal); search_FType(ftVal); } function search_VType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null){ a[x].style.display='block'; } } if(val.length==0){ a[x].style.display='block'; } } } function search_CType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } function search_FType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } Check out all webRTC interviews >>

WIT Software: André Silva

August 2015

Telco vendor's offering

WebRTC at the hands of a telecom vendor.

The Telecom world has its own set of standards and needs. At times, they seem far remote from the way the Internet and WebRTC operates.

How do you bridge between the two? André Silva, Team Leader & WebRTC Product Manager at WIT Software tries to explain in this interview.

 

What is WIT Software all about?

WIT is a software development company specialized in advanced solutions for mobile telecommunications companies. The company has over 14 years of experience and a deep expertise in mobile communications and network technologies including IP Multimedia Subsystem (IMS), mobile voice (Mobile VoIP and Voice over LTE), messaging (SMS, MMS and IM), Rich Communication Suite (RCS) and Multimedia Telephony Services (MMTel). Located in Portugal, UK, Germany and California, the company has over 230 fulltime employees and a blue chip industry client base.

 

You’ve been working in the Telco space offering IMS and RCS products. What brought you towards WebRTC?

Back to 2008, WIT started the development of a Flash-to-SIP Gateway to support voice calls from web browsers to mobile phones. The first commercial deployment was done in 2011, enabling calls from a Facebook App to mobile subscribers connected to the Vodafone Portugal network. This first version included features like enhanced address-book, presence, IP messaging, IP voice calls and video calls.

When Google released the WebRTC project back in 2011, WIT started following the technology and as soon as it got stable we have implemented a new release of our Web Gateway with support for all the browsers in the market, including Chrome, Firefox and Opera that are WebRTC-compliant, but also Safari and IExplorer where we use the Flash-to-SIP capabilities.

 

How are your customers responding to the WebRTC capabilities you have?

Our customers are searching for ways to extend their mobile/fixed networks to web browsers and IP devices, either to extend voice calling with supplementary services and SMS, or to make more services available to off-net users. We are providing our WebRTC Gateway and our RCS capabilities to provide richer messaging and voice calling use-cases for the consumer and the enterprise market.

One of the facts that is much appreciated is the support for non-WebRTC browsers. The conversion of protocols (DTLS-SRTP and RTMP) to RTP is done by our Gateway and it is transparent for the network.

For codec transcoding, we support the standard JSR-309 to integrate with MRF’s in order to support extra codecs that are not natively available in WebRTC.

Recently we just announced a partnership with Radisys that is a leading provider of products and solutions, to address emerging media processing challenges for network operators and solution vendors.

 

What signaling have you decided to integrate on top of WebRTC?

We are using a proprietary JSON protocol over WebSockets. This is a lightweight protocol that exploits the best of asynchrony of WebSockets and provides the best security for Web Apps.

We have built a Javascript SDK that abstracts all the heterogeneity of the different browsers, and the technology that is used to establish calls. The Javascript SDK loads a Flash plugin when WebRTC is not available in the browser.

 

Backend. What technologies and architecture are you using there?

WIT WebRTC Gateway is a Java-based Application Server that can run in several containers. It can be scaled horizontally over several instances. The Gateway integrates with SIP Servlet Containers, for the integration with standard Media Servers, and with streaming servers, to make the media available over RTMP. Our Media engine copes with the WebRTC media and contains a STUN/TURN server to solve the NAT traversal issues.

 

Where do you see WebRTC going in 2-5 years?

I think WebRTC will become the standard for IP Communications that every VoIP application and server will support, either because they use the WebRTC native APIs, or because they will be improved to also support the extras brought by WebRTC specification.

In 2-5 years I expect to see web developers using the WebRTC JavaScript API to create new applications and just assume that WebRTC is there accessible in every browser, since Microsoft is moving forward to add WebRTC in the new browser.

On the negative side, I also expect browsers to continue having distinct implementations which will force developers to have specific code for each browser. Unfortunately, web development has always been like this.

 

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

WebRTC aims to enable VoIP without plugins. So you need to think about WebRTC alternatives for the cases where it is not available, because from our experience, the end user doesn’t really care what’s underneath the application, they just want it to work.

So, you should not filter the browsers or systems where your application will run and force the user to download a new browser.

 

Given the opportunity, what would you change in WebRTC?

Since H.264 is now one of the video codecs in the specification, a great step would be to add some audio codecs like AMR-WB and G.729 to avoid transcoding with some of the common codecs in existing services.

Also, I would give more focus to the advanced cases that depend on the renegotiation of the WebRTC sessions. We provide supplementary services like call hold, upgrade and downgrade and there are still some limitations in the APIs to allow us to have full control across browsers.

 

What’s next for WIT-Software?

We are creating WebRTC applications that will be launched later this year for the consumer market, and we are preparing a solution for the enterprise market that will leverage the best of WebRTC technology.

Our latest implementation adds support to voice calls between web browsers and VoLTE devices, and this is a major breakthrough for the convergence of Web Apps and new generation mobile networks.

For more information, please visit our product page at http://webrtc.gw

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

The post WIT Software and WebRTC: An Interview With André Silva appeared first on BlogGeek.me.

It’s Time to Remove GSM Call Prioritization from Smartphones

bloggeek - Tue, 08/11/2015 - 12:00

Smarphones are more laptops than phones.

What’s more important to you? That your smartphone is with you so people call call your phone number to reach you and you can call their phone numbers to reach them. Or the fact that you can have your apps and the internet available at your fingers due to that data package you have or the WiFi you are connected to?

For me the answer is simple. I don’t really care much about my phone number anymore. It is there. It is used. There are hours a month that I am “on the phone”, but it isn’t as important as it used to be. Oftentimes, the most important conversations I conduct are done elsewhere.

This special treatment smartphones give GSM calls is getting a bit tired. The notion of call waiting, hold and switching between calls – who cares anymore?

I had a meeting the other day. As usual, it took place on my desktop machine, with a video camera attached. In the middle, the person I talked to had to answer his phone. Say he is busy. On another call he received he decided not to answer. Apparently, that meeting with me was less important than his daughter and more important than the other person.

The other day, I had a meeting. Again, on my desktop. The house phone rang (a novelty here). When it stopped ringing, my smartphone rang. Call was from an international number. I didn’t answer. The current meeting I was already having was important enough. Whoever searched for me pinged me by email as well.

Interactions happen today not only no multiple apps and services. They also happen to us on multiple devices. The concept that we have one number or service, aggregating all of our communication, and needs to handle a calling queue and be prioritized over everything else is no longer valid. It doesn’t fit our world anymore.

Time to let go of that quaint idea of GSM call prioritization. Treat its notifications and app as just another smartphone app and be done with it.

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post It’s Time to Remove GSM Call Prioritization from Smartphones appeared first on BlogGeek.me.

WebRTC’s Extremes. Aggregation or Embedability? Federated or Siloed?

bloggeek - Mon, 08/10/2015 - 12:00

WebRTC is but a technology. Its adoption happens at the edges.

It is interesting to see what people do with WebRTC – what use cases do they tackle and what kind of solutions do they come up with.

Here are a few opposite trends that are shaping up to be mainstream approaches to wielding WebRTC.

1. Aggregation

In many cases, WebRTC is used to aggregate. The most common example is expert marketplaces.

Popexpert and 24sessions are good examples of such aggregators. You open up your own page on these services, state what services you offer and your asking price. People can search for you and schedule a video session with you. Interesting to see in this space LiveNinja who recently shutdown their aggregation service, shifting towards and embedability alternative.

2. Embedablity

The opposite of aggregating everyone into a single domain is to enable embedding the service onto the expert’s own website.

The company will offer a piece of JavaScript code or a widget that can be placed on any website, providing the necessary functionality.

Aggregation of Embedability?

Which one would be preferred, and to whom?

The Vendor in our case, has more power as an aggregator. He is in charge of all the interaction, offering the gateway into his domain. Succeeding here, places him in a position of power, usually way above the people and companies he serves.

The Expert may enjoy an aggregator when he is unknown. Having an easy way to manage his online presentation and being reachable is an advantage. For someone who is already known, or that have spent the time to make a brand of himself online, being aggregated on someone else’s site may dilute his value or position him too close to his competitors – not something you’d want doing.

The Customer on one hand, can easily find his way through an aggregator. But on the other hand, it places the expert or service he is reaching out to at a distance. One which may or may not be desired, depending on the specific industry and level of trust in it.

Ben Thompson has a good read about aggregation theory which I warmly suggest reading.

 

3. Silo

Most WebRTC services live in their own silo world. You envision a service, you build the use case with WebRTC, and that’s it. If someone needs to connect through your service – he must use your service – he can’t get connected from anywhere elsewhere. Unless you add gateways into the system, but that is done for specific needs and monetization.

I’ve talked about WebRTC islands two years ago. Here’s a presentation about it:

WebRTC Islands from Tsahi Levent-levi

WebRTC makes it too easy to build your own island, so many end up doing so. Others are hung up to the idea of federations:

4. Federation

Why not allow me to use whatever service I want to call to you, and you use whatever service you prefer to receive that call?

Think calling from Skype to WeChat. Or ooVoo to Hangouts. What a wonderful world that would be.

Apparently, it doesn’t happen because the business need of these vendors isn’t there – they rather be their own silos.

Who is federating then?

  • Some connect to the PSTN in order to “federate” – or to enjoy the network effect of the legacy phone system
  • Those who have a network already (federated or not), end up using WebRTC as an access point. That’s what Polycom did recently with their RealPresence Web Suite.
  • Solutions such as Matrix, looking to offer a framework that enables federated signaling that is suitable for WebRTC as well
Why is this important?

At the end of the day, WebRTC is a building block. A piece of technology. Different people and companies end up doing different things with it.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post WebRTC’s Extremes. Aggregation or Embedability? Federated or Siloed? appeared first on BlogGeek.me.

Upcoming Webinar: Five Advantages WebRTC Brings to Your Video Conferencing Solution

bloggeek - Fri, 08/07/2015 - 14:00

WebRTC has more to offer in video conferencing than just an access point.

My roots are in video conferencing. I’ve been working in that industry for 13 years of my adult life, most of it spent dealing with signaling protocols and enabling others to build their VoIP solutions. You can say I have a special place in my heart for this industry.

This is why I immediately said yes when LifeSize wanted me to join them for a webinar. We’ve got a mouthful as a title:

Five Advantages WebRTC Brings to Your Video Conferencing Solution

Truth be told – there’s a lot that WebRTC has to offer in the video conferencing space than the mere “additional access point as a browser to our great video conferencing products”. It starts by taking cloud and video seriously, and continues with unlocking the value that a technology like WebRTC can bring to video conferencing solutions.

If you want to learn more, then be sure to join LifeSize and me in this webinar.

When? Aug 18 2015 11:00 am EDT

Register now and join us

The post Upcoming Webinar: Five Advantages WebRTC Brings to Your Video Conferencing Solution appeared first on BlogGeek.me.

Pages

Subscribe to OpenTelecom.IT aggregator

Using the greatness of Parallax

Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.

Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Yet more available pages

Responsive grid

Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.

More »

Typography

Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.

More »

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.