News from Industry

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.

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:

• http://www.asipto.com/sw/kamailio-advanced-training/

Looking forward to coordinating the training session in Berlin!

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

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:

• http://blog.alezzandro.com/post/112533470033/fast-kamailio-deployment-using-docker
• http://dougbtv.com/2015/05/21/high-availability-asterisk-coreos/
• https://blog.irontec.com/voip-y-la-guerra-por-el-crecimiento-horizontal-con-el-trio-docker-kamailio-y-asterisk/ (spanish)
• https://github.com/linuxmaniac/pkg-kamailio-docker
• https://github.com/Ntipa/docker-kamailio
• https://hub.docker.com/r/guardianproject/kamailio-base/

Some Docker resources exist for Siremis, the web management interface for Kamailio:

• https://github.com/sboily/dockerfile/tree/master/siremis
• https://hub.docker.com/r/quintana/siremis/

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!

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.

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 your tickets, get a flight, and get out to San Francisco! http://goo.gl/SQqpO4

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.

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

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

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

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.

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.

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

Telephony

Medium

Voice, Video

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.

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 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.

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.

Ebbene sì, ne abbiamo combinata un’altra! A seguito delle sempre più numerose richieste dei nostri partner e clienti, abbiamo sviluppato il client 3CXPhone per gli smartphone Windows. Il 3CXPhone per Windows Phone può essere usato unicamente sui dispositivi dotati di Windows 10. Così come gli altri client 3CXPhone per iOS e Android, il nuovo client per Windows Phone vi consentirà di portare con voi il vostro interno aziendale ovunque voi siate! L’aumentata mobilità e produttività, così come i risparmi sulla bolletta sono solo alcuni fra i maggiori vantaggi che gli utenti di Windows Phone potranno toccare con mano.

3CXPhone per Windows 10 è l’unico SIP Phone per Windows Phone e può anche essere usato con altri centralini.

Segui questa semplice procedura per provare il client 3CXPhone per Windows Phone:

• Aggiorna il tuo Windows Phone a Windows Phone 10
• Apri l’icona “Store”
• Digita “3CXPhone” nel campo di ricerca
• Tocca l’app per installarla
• L’URL dello store è: https://www.microsoft.com/en-us/store/apps/3cx-phone/9nblggh1nj7b 

 

Approfondimenti

• Mai più chiamate perse con il nuovo 3CXPhone per Mac
  

  Fedele alla sua reputazione di azienda innovatrice, 3CX è uno dei primi produttori di centralini telefonici ad offrire un client per Mac completo di funzionalità professionali. Con il nuovo aggiornamento del popolare [...]

• 3CX Phone System v14: Preview tecnica
  

  La nuova major release di 3CX Phone System è pronta! Il nostro team Ricerca&Sviluppo c’è riuscito un’altra volta e ci ha fornito una versione straordinaria: pronta per il Cloud e corredata di [...]

• Fring pronto a sbarcare su Windows Mobile
  

  Dopo il recente rilascio della versione 3.20 per i dispositivi basati su OS Symbian, a giorni dovrebbe essere rilasciata la versione per Windows Mobile 5 e 6 del noto client voip e [...]

Adobe Migrating to WebRTC?

The company behind the abomination called Flash? Adobe.

The logic then, is that when Adobe moves to WebRTC, there’s no reason anymore to try and run real time communications related use cases with Flash. Correct?

Well… it is already happening.

Guillaume Privat, Director and General Manager of the Adobe Connect business unit, spilled the beans: Adobe Connect “plans to be ready to support HTML5″ “when WebRTC matures”.

AT&T. Cisco. Microsoft. Comcast. Facebook. And now Adobe. An interesting 2015.

Some thoughts about this partial announcement by Adobe (read it all – it is short and rather interesting):

• Why did Adobe go with WebRTC?
  • The promise of HTML5 content working across desktops and mobile devices
  • Portability – cross platform development and deployment
  • The same thing I always say – if you plan on developing any communication service these days, WebRTC needs to be your first choice and the question should by why you haven’t picked it
• Their future plans are broad, and rather simplistic – use HTML5/WebRTC wherever to bring feature compatibility to what Adobe Connect is capable of today
• Somehow, Adobe places WebRTC as an immature technology. While I see this type of thinking in many places, I believe it is short sighted at best. Those who deem it immature probably aren’t wielding it correctly
• Worse – maturity in WebRTC means “once HTML5 can support large scale collaboration across browsers”
  • Will Microsoft Edge imminent support of it enough?
  • Will Adobe wait until benevolent Apple introduces WebRTC in Safari?
  • Will Adobe be adamant that WebRTC must run on the older Internet Explorer browsers before it is mature enough for Adobe?
  • Or is there some other arbitrary rule at play? Maybe the development time inside Adobe Connect’s team?
• The context of the announcement is odd
  • It resides on a blog that talks about use cases deployed by Adobe Connect and features introduced
  • This announcement is neither
  • It says “we know there’s WebRTC and we plan on using it. One day. When we think it is time. Maybe. If we get there. And browsers support it”
  • Not sure how should I respond to it. Should I use Adobe Connect now that I know they plan on using WebRTC in some far flung future? Should I sit and wait until they do? Should I rejoice? Should I be worried about my existing Adobe Connect integration?

At least we have another incumbent openly validate WebRTC as a technology. I wonder when the rest of the ostriches burying their head in the sand out there will also come to their senses.

Adobe is abandoning Flash. Shouldn’t you be doing the same?

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

The post The Day Adobe Adds WebRTC is the Day we Kill Flash appeared first on BlogGeek.me.

About Slable

Slable provides affordable enterprise I.T. and communication solutions for small-to-medium businesses (SMB) in the Washington, D.C. metropolitan area. Their goal is to eliminate all I.T.-related hassle from work environments of various types ranging from veterinarians to marketing/PR firms. Their network infrastructure enables companies to host their applications on a reliable and secure network so that their customers can focus on what they do best. Slable’s team of 14 employees is able to provide stellar support around the clock for all customers.

Challenges

Slable needed a reliable VoIP platform that could be easily by their customers. Slable’s previous VoIP solution was not powerful enough to handle complex features and began to experience weekly outages, resulting in a loss of faith in their services. Facing the prospect of losing customers, Slable decided to find a reliable VoIP platform that would scale with their growing customer base and provide feature rich applications for advanced users. Slable needed a reliable VoIP platform that could be easily by their customers. Slable’s previous VoIP solution was not powerful enough to handle complex features and began to experience weekly outages, resulting in a loss of faith in their services. Facing the prospect of losing customers, Slable decided to find a reliable VoIP platform that would scale with their growing customer base and provide feature rich applications for advanced users.

2600Hz’s Solution

Implementation

When Slable started researching VoIP platforms, they realized that there
was little focus on SMB customers. Most providers lacked the training and documentation for Slable to implement their solution and had minimums that were too high. 2600Hz was able to provide a reliable platform, partner support, quick onboarding/training and customized solutions for advanced users.

Business Outcome

2600Hz’s customizable platform enhanced Slable’s VoIP capabilities and freed time for customer outreach, service, and support. Slable achieved a better ROI due to prompt support responses, reduced downtime, easy migration, and better tracking of customers.

2600Hz is continuously adding unique and bleeding edge features, creating a one-of-a-kind telecom experience for Slable’s clients. As a result, Slable has been able to grow their VoIP business and are aggressively pushing VoIP in the local Washington, D.C. market with cost-savings and increased features.

Key Improvements

• Comprehensive 
  
• Training 
  
• Competitive Pricing 
  
• True Support 
  
• Customizable Solutions 
  
• Scalability
  
• Mobility