News from Industry

Dean Elwood CEO of Voxygen joins the ClueCon talk about how his company, Voxygen, provide value added services and products for Tier 1 mobile carriers and how FreeSWITCH has acted as an enabler for that.

[Luis Lopez is the face in front of Kurento, one of the popular open source media servers that can handle WebRTC. He wanted to share here the story of the new open source WebRTC PaaS – NUBOMEDIA]

When I first heard about WebRTC by 2011, I was fascinated by the idea of standardized APIs and protocols enabling the creation of interoperable RTC applications for the Web. However, I noticed very soon that my peer-to-peer services were too limited and that, as a developer, I was hungry for further features that could only be provided by a WebRTC infrastructure. This is why I got involved in the Kurento project for creating a media server. Kurento got nice traction but, as it was maturing, we found an increasing number of feature requests related to its scalability. The message was quite clear: a cloudification of Kurento was necessary.

With this in mind, by 2014 we got down to work and, with the financial support of the European Commission, we worked hard during a couple of years in cooperation with some of the most remarkable cloud experts around Europe. These efforts were worthy: NUBOMEDIA, the first open source WebRTC PaaS, is now a reality.

NUBOMEDIA: the first WebRTC PaaS

In the WebRTC ecosystem, scalable clouds for developers are not new. Providers such as Tokbox, Kandy, Twilio and many others offer them. These solutions are commonly called “WebRTC API PaaS”, “WebRTC Cloud APIs”, or just “Cloud APIs” as they expose a number of WebRTC capabilities through custom APIs that exhibit all the nice “-ilities” of cloud services (i.e. scalability, security, reliability, etc.)

For NUBOMEDIA we also considered this “Cloud API” concept as a solution. However, although APIs are the main building block developers use for creating applications, applications are more than just a set of API calls. After analyzing WebRTC developers’ needs, we felt more appealing the concept of platform than the concept of API. A platform is more than an API in the sense that it provides all the required facilities for executing applications. These typically include an operating system, some programming-language-specific runtime environments and some service APIs. The cloud version of a platform is commonly called a PaaS, which is (literally) a platform that is offered “as a Service”.

There are many such PaaSes in the market including Heroku, the Google App Engine or AWS Elastic Beanstalk. All of them expose to developers the ability of uploading, deploying, executing and managing applications written in different programming languages. These PaaS services are quite convenient as they let developers to concentrate on creating their applications’ logic while all the complex aspects of provisioning, scaling and securing them are assumed by the PaaS. In spite of the wide offer of PaaS services, we noticed that most common PaaS providers did not expose WebRTC capabilities as part of their APIs. Hence, WebRTC developers were not able to enjoy all the advantages of full PaaSes.

The main difference between a WebRTC cloud API and a full WebRTC PaaS is illustrated in the following figure. As it can be observed, WebRTC Cloud API providers (left) do not host developers’ applications, but just expose some WebRTC capabilities through a network API that applications consume. On the other hand, full WebRTC PaaSes host application and take the responsibility of executing, scaling and managing them.

Based on these ideas, the NUBOMEDIA idea emerged clearly: instead of evolving Kurento into a cloud API we should rather create a full PaaS out of it, so that developers could enjoy the nice features of PaaSes (i.e. application deployment, execution, scaling, etc.) while consuming the Kurento APIs in a scalable and secure way.

Why NUBOMEDIA may be interesting for you

NUBOMEDIA is now a reality and it can be enjoyed openly by developers worldwide. Like solutions such as OpenShift, Cloud Foundry or Apprenda, NUBOMEDIA is a private PaaS in the sense that it consists of an open source software stack that can be downloaded, installed and executed on top of any OpenStack IaaS cloud.

If you are a developer, you may be interested in trying NUBOMEDIA for your next application as it combines the simplicity and ease of development of WebRTC Cloud APIs with the flexibility of full PaaSes. When doing so, consider that NUBOMEDIA is a Java PaaS. Hence, you will be able to leverage all the capabilities of the Java platform for creating your WebRTC application. The only difference with other Java PaaS services it that NUBOMEDIA will provide you a specific SDK through which you will be able to access the complete feature set of Kurento in a scalable way.

From a practical perspective, the main differences between NUBOMEDIA and other WebRTC cloud solutions are illustrated in the next figure. As it can be seen, there is a trade-off between flexibility and simplicity: the simplest the development, the less flexible the application is and the more difficult it is to adapt it to custom needs and requirements.

For example, most flexible solutions (IaaS on the bottom left corner of the image) require complex developments for creating fully operational WebRTC applications. On the other hand, SaaS solutions (top right corner) do not require much development efforts, but developers’ ability for customizing and adapting it to special requirements is typically very limited. For this reason, WebRTC developers tend to prefer WebRTC Cloud APIs that provide some flexibility but, at the same time, enable simple developments.

NUBOMEDIA also positions within this balance but giving more prevalence to flexibility. This makes NUBOMEDIA more suitable for developments requiring to comply with special or rare requirements. Just for illustration, these are some of the things you can make with NUBOMEDIA that are complex to achieve using the common WebRTC Cloud APIs:

• To use the signaling protocols you prefer (e.g. SIP, XMPP, custom, etc.)
• To have special communication topologies. For example, imagine that you need a videoconferencing room with “spy participants” that can view others but should not be noticed by the rest; or imagine that you need simultaneous translators that are not viewed but need to listen to some participants while being listened by others.
• To have custom AAA (Authentication, Authorization and Accounting). For example, imagine that you wish to implement rules customizing who can access the media capabilities (e.g. recording, viewing a specific stream, etc.) so that they depend on some non-trivial logic (e.g. context information, time-of-day, time-in-call, etc.).
• To go beyond calls. We may imagine lots of use-cases where WebRTC might be used beyond plain calls. For example, person-to-machine or machine-to-machine scenarios where you need cameras to connect to users or to other systems in a flexible way without restricting to the typical room videoconferencing models commonly exposed by WebRTC Cloud APIs.

As another interesting property, as NUBOMEDIA is a private PaaS, it can execute onto any OpenStack infrastructure. This means that the operational costs of an application running in NUBOMEDIA are fully under your control as you can decide in which IaaS to deploy the PaaS. This significantly reduces the operational costs with respect to an equivalent application consuming a Cloud API, as the Cloud API provider margins disappear.

The NUBOMEDIA Open Source Community

We have created NUBOMEDIA following the same open philosophy we used with Kurento. Currently, it is supported by an active and vibrant open source software community that is structured as an association of several projects providing different technological enablers including: the cloud orchestration mechanisms, the PaaS management technologies, the media server, many media processing modules and client SDKs for Android, iOS and Web.

If you are interested in knowing more about NUBOMEDIA you can check the community documentation where you will be able to find detailed information showing how to install and manage the platform and how to develop and deploy applications into the PaaS. You can also check the community YouTube channel and see one of the many videos with demos and tutorials illustrating how to develop and deploy NUBOMEDIA applications. If you want to know about the latest news of the NUBOMEDIA Community, you may follow it on Twitter.

 

Want to make the best decision on the right WebRTC platform for your company? Now you can! Check out my WebRTC PaaS report, written specifically to assist you with this task.

Get your Choosing a WebRTC Platform report at a $700 discount. Valid until the beginning of May.

The post NUBOMEDIA: the first open source WebRTC PaaS appeared first on BlogGeek.me.

The video recordings for all the session at Kamailio World Conference 2016 are available on Kamailio World Youtube Channel:

• https://www.youtube.com/channel/UCElq4JNTPd7bs2vbfAAYVJA

Enjoy!

And not only the development.

For too many years now we’ve been enamored with Agile. Supposedly the successor of the fountain development model, agile is all about short iterations and faster feedback.

In larger places, agile is usually just the next undertaking of the program manager – or whatever equivalent you have in the company that deals with processes. I remember hearing the term “we must be agile”. With the end result being… 18 to 24 months product release cycles.

That’s nice, but it isn’t really agile – at least not more than the Geek & Poke caricature above.

I had an interesting discussion with a consultant during the London WebRTC conference two months ago. He complained that browsers are moving too fast, making it hard for enterprises to follow suit and adopt WebRTC.

Here’s a quick reminder – WebRTC doesn’t care about enterprises. It cares about innovation and forward moving. If something breaks, then you’re just out of luck.

WebRTC today forces enterprises to think and act Agile

Why is this the case?

• Browsers are updating at the speed of light – every 6 to 8 weeks
  • Each time they do, something gets deprecated
  • And other things can get broken
  • This is doubly so with WebRTC, which is essentially a perpetual work in progress
  • And will stay that way well into 2017
  • Enterprises need to be prepared for it and willing to update their own deployments to keep pace
• WebRTC’s codecs are changing – and upgrading
  • VP9 is upon us
  • H.264 is here to stay
  • R&D teams need to adopt new codecs to keep their service pristine
  • Otherwise, competitors will do it and win the market simply by offering better user experience and media quality
• New capabilities
  • Browser side recording?
  • Playing video from a canvas?
  • Pipelining media?
  • WebRTC has it all, and things are only improving
  • Do these affect your product? Do you need someone to define how this changes things for you?

What Needs to Change

Enterprises need to change their stance. They aren’t in control anymore. They should act accordingly.

This means having product managers, developers, testers, support and IT all working in concert in an agile way – thinking about launched products as living and breathing entities that must be updated continuously.

Thinking of launchng a WebRTC based product? Especially if it is an on premise one – you must make sure you understand the implications AND that your customers understand the implications as wlel.

 

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

The post With WebRTC, Vendors Must Embrace True Aglie appeared first on BlogGeek.me.

This week we had a feature in mod_sofia with the addition of a channel variable to suppress auto-answer notify and another feature in mod_commands to allow show calls to be filtered by accountcode.

Join us 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-9188 [mod_sofia] Added a channel variable to suppress auto-answer notify
• FS-9184 [mod_commands] Allow show calls to be filtered by accountcode

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

• FS-9158 [build] Add include for Solaris to changes to build
• FS-9185 [build] Fixed the format of ifdefs for Solaris SPARC

The following bugs were squashed:

• FS-9153 [mod_commands][mod_event_socket] Fixed a uuid_bridge issue on ESL
• FS-9164 [core] Add Session-Per-Sec-Last to heartbeat event
• FS-9034 [mod_sofia] Fixed an issue in sofia.c that prevents register in new thread
• FS-9167 [mod_conference] Fixed an issue where playing a file when all video feeds are vmuted does not show file
• FS-9160 [mod_sofia] Tweak sip_invite_failure_* chan vars for properly reporting last outbound call failure when there are multiple bridge attempts on a single call

Conference calling is a multi-billion dollar industry that is mostly powered by expensive, high-powered conferencing servers. Now you can replicate much of this functionality for free with a modern browser using the combination of WebRTC and WebAudio. Like with video, multi-party audio can utilize a few architectures: Full mesh – each client sends their audio […]

The post Your Browser as a Audio Conference Server with WebRTC & Web Audio (Alexey Aylarov) appeared first on webrtcHacks.

Wasn’t there enough complications already?

I use Hangouts all the time. At testRTC, we use it for most of our demos and customer meetings. As good and complete as Hangouts is in terms of the feature set that I need, it can be quite confusing at times. Something that probably stems from its dual use nature: Google Hangouts is both a consumer messaging app and an enterprise unified communications app. And while the two rely on the same technology – they are not the same.

If there is one other similar service that does that it is Skype, and even with it, it is mostly by branding and not by the service itself (I am not sure how uniform the Skype and Skype for Business apps and infrastructure are, but they sure are getting worse in the last year or two).

Can a single app rule them all? By the way things look today – no.

And yet this latest move by Google leaves me somewhat baffled.

At Google I/O’s keynote yesterday, Google came out with a slew of announcements. The ones interesting for me here are those related to messaging or to WebRTC:

• Allo – a new messaging app to fend off Facebook Messenger
• Duo – a new video chat app to fend off Apple FaceTime
• Firebase – a new version which I won’t be covering here

Allo

Allo is Google’s “Smart Messaging App”.

It is yet-another-messaging-app – until you see the suggestions it gives you.

I use Switfkey as my Android keyboard, and it “learns” what you click so future clicking is shorter. The smart messaging replies in Allo are the next step for me – instead of doing it on the word level it does it on the conversation level.

The smarts in Allo seems to be split into two parts – what Allo does on his own, which is suggestions inside the conversation. On top of it, Google added something they call Google Assistant, which goes “out” of the conversation to offer suggestions for external actions. The example in the I/O keynote was restaurant reservation.

This competes directly with messaging and bots. Specifically Facebook. Maybe others.

Where can this lead us?

• If I were Google, I’d make this into a bot or a layer that can be stitched into everything
• Messaging services could use it directly, which will allow Google to sift every interaction and offer their suggestions and automation – no matter the app
• Would messaging apps adopt it? I don’t know, but why shouldn’t they try it out?

Duo

Duo IS WebRTC. Or at least what you can do with it.

A not about Duo, WebRTC and purism – Duo is mobile only (for now), closed app, running on Android and iOS.

I’ll repeat that.

Duo is mobile only (for now), closed app, running on Android and iOS.

No web browser. No complaints about unsupportive Safari or IE browsers. And from Google.

To those who decide to skip WebRTC just because it doesn’t run on IE or not supported by Safari (without really understanding what WebRTC means) – this should be the best wake up call. Coming directly from Google, the company who wants everything running in the browser.

Recognize anyone in the Duo app?

If tech media outlets taught me anything this time, is that you should be suspicious at what they write.

Ingrid Lunden on TechCrunch did a nice write up on Duo, offering the gist of it:

• 1:1 video chat app, like FaceTime
• Focus is on super fast (responsiveness) and media quality
• You see the caller’s video before you answer a call. A nice gimmick I guess
• Based on WebRTC

This is where things flal apart a bit in her coverage:

The other thing that Duo is touting is the engineering that has gone into making the video in the app work. Google says it will work the same whether your network is superfast or patchy. This in itself, if it really bears out, would be amazing for anyone who has cursed his or her way through a bad Hangout or Skype call.

Duo was built by the same team that created WebRTC and it uses WebRTC, engineering director Erik Kay said today on stage at I/O. It was built using a new programming protocol, Quic, which Google unveiled last year as a route to speeding up data-heavy applications that travel over the web.

So Duo has this magic of working better than Hangouts and Skype. Great. So why didn’t Google just build it into Hangouts? Especially considering both use WebRTC…

That reference to the QUIC protocol – to be sure – this does NOTHING to the actual media – only to the time you wait until the smartphone “dials”. You shave a few hundreds of milliseconds there, but that won’t move the needle in the industry either way.

Mashable’s Raymond Wong explains QUIC and how it is a serious advantage:

Google says people don’t place as many video calls with their friends and family because connections can sometimes be spotty and drop. Duo uses a new protocol called QUIC that’s supposed to be more robust than any other video calling infrastructure out there.

QUIC won’t make the call more robust or get calls work better. It will just make them make the initial connection faster or having the mute button appear QUICker on the other end’s device. QUIC is a nice touch of how Google can go to extremes sometimes with optimizing the technology. Sometimes it makes a lot of sense, but other times less so. QUIC is definitely a step forward from TCP, but its effect on video calling isn’t huge.

What do we have here? Apple FaceTime, done by Google, working on both Android and iOS. Nothing more and nothing less.

 

There’s also Jibe

An acquisition from last year, placing Google as a serious RCS player.

No mention of it in I/O. Probably because its focus is on “fixing”/”improving”/”popularizing” the basic Google Messenger app, which does SMS.

This being something that needs to be synchronized with carriers – it will take time to materialize.

The future of Hangouts

Is the enterprise.

With Allo and Duo, why should consumers even care about Hangouts from now on?

Can this succeed?

Can such an approach succeed for Google? Having multiple communication apps, two of them announced in the same day.

Can they reach mass adoption?

Google is taking the path of unbundling here, but doing it to what was until now the same service – communications. They split it into multiple smaller apps, tearing real time voice and video calling from current messaging apps. It feels somewhat like iMessage and FaceTime, but Allo is more capable than iMessage (sans SMS) and Duo is a bit more capable than FaceTime (the knock knock feature).

I can’t really decide if taking this unbundling approach is better or worse. Will it increase engagement of users with these services or hurt them. And where does Google Hangouts fit in here, if at all?

The post Allo, Duo, Hangouts or Jibe? Help… appeared first on BlogGeek.me.

A refresher on what I’ve written in 2014 (here and here).

Can you guess the signaling and transport here?

WebRTC as a protocol comes without signaling. This means that you as a developer will need to take care of it.

The first step will be selecting the protocol for it. Or more accurately – two protocols: transport and signaling. In many cases, we don’t see the distinction (or just don’t care), but sometimes, they are important. A recent question in the comments section of one of the two posts mentioned here in the beginning, got me to write this explanation. Probably yet again.

WebRTC Transport Protocols and Browsers

This actually fits any browser transport protocol.

A transport protocol is necessary for us to sent a message from one device to another. I don’t care what is in that message or how the message is structured at this point – just that it can be sent – and then received.

HTTP/1.1

5 years ago browsers were simple when it came to transport protocols. We essentially had HTTP/1.1 and all the hacks on top of it, known as XHR, SSE, BOSH, Comet, etc. If you are interested in the exact mechanics of it, then leave a comment and I’ll do my best to explain in a future post (though there’s a lot of existing explanation around the internet already).

I call the group of solutions on top of HTTP/1.1 workarounds. They make use of HTTP/1.1 because there was no alternative at the time, but they do it in a way that makes no technical sense.

Oh – and you can even use REST to some extent, which is again a minor “detail” above HTTP/1.1.

Since then, three more technique materialized: WebSocket, WebRTC and recently HTTP/2.

WebSocket

The WebSocket was added to do what HTTP/1.1 can’t. Provide a bidirectional mechanism where both the client and the web server can send each other messages. What these messages are, what they mean and what type of format they follow was left to the implementer of the web page to decide.

There’s also socket.io or the less popular SockJS. Both offer client side implementations that simulate WebSocket in cases it cannot be used (browser or proxy doesn’t support it). If you hear that the transport is socket.io – for the most part you can just think about it as WebSocket.

When your WebSocket work great, they are great. But sometimes it doesn’t (more on that below, under the HTTP/2 part).

WebRTC’s Data Channel

To some extent, the Data Channel in WebRTC can be used for signaling.

Yes. You’ll need to negotiate IP addresses and use ICE first – and for that you’ll need an additional layer of signaling and transport (from the list in this post here), but once connected, you can use the data channel for it.

This can be done either directly between the two peers, or through intermediaries (for multiple reasons).

Where would you want to do that?

1. To reduce latency in your signaling – this is theoretically the fastest you can go
2. To reduce load on the server – now it won’t receive all messages just to route them around – you’ll be sending it things it really needs
3. To increase privacy – not sending messages through the server means the server can’t be privy to their content – or even the fact there was communication

For the most part, this is quite rare as transport for signaling in WebRTC.

HTTP/2

I’ve written about HTTP/2 before. Since then, HTTP/2 has grown in its popularity and spread.

HTTP/2 fixes a lot of the limitations in HTTP/1.1, which can make it a good long term candidate for transport of signaling protocols.

A good read here would be Allan Denis’ writeup on how HTTP/2 may affect the need for WebSocket.

 

WebRTC Signaling Protocols

Signaling is where you express yourself. Or rather your service does. You want one user to be able to reach out to another one. Or a group of people to join a virtual room of sorts. To that end, you decide on what types of messages you need, what they mean, how they look like, etc.

That’s your signaling protocol.

As opposed to the transport protocol, you aren’t really limited by what the browser allows, but rather by what you are trying to achieve.

Here are the 3 main signaling protocols out there in common use with WebRTC:

SIP

I hate SIP.

Never really cared for it.

It has its uses, especially when it comes to telephony and connecting to legacy voice and video services.

Other than that, I find it too bloated, complex and unnecessary. At least for most of the use cases people approach me with.

SIP comes from the telephony world. Its main transport was UDP. Then TCP and TLS were added as transport protocols for it. Later on SCTP. You don’t care about any of these, as you can’t really access them directly with a browser. So what was done was to add WebSocket as a SIP transport and just call it “SIP over WebSocket”. Before WebRTC got standardized (it hasn’t yet), SIP over WebSocket got standardized and already has an RFC of its own. Why is it important? Because the only use of SIP over WebSocket is to enable it to use WebRTC.

So there’s SIP. And if you know it, like it or need it. You can use it for your WebRTC signaling protocol.

XMPP

I hate XMPP.

Not really sure why. Probably because any time I say something bad about it, a few hard core fans/followers/fanatics of XMPP come rushing in to its rescue in the comments section. It makes things fun.

XMPP has a worldview revolving around presence and instant messaging, and use cases that need it can really benefit from it – especially if the developer already knows XMPP and what he is doing.

If you like it enough – make sure to slam me in the comments – you’ll find their section at the end of this post…

Proprietary

I hate NIH. And yet a proprietary signaling protocol has a lot of benefits in my view.

In many cases, you just want to get the two darn users into the “same page”. Not much more. I know I am dumbing it down, but the alternative is to carry around you extra protocol messages you don’t need or intend using.

In many other cases, you don’t really want to add another web server to handle signaling. You want your web server to host the whole site. So you resolve into a proprietary signaling protocol. You might not even call it that, or think of it as a signaling protocol at all.

How to Choose?

Always start from the signaling protocol.

If there’s reason to use SIP due to existing infrastructure or external systems you need to connect to – then use it. If there’s no such need, then my suggestion would be to skip it.

If you like XMPP, or need its presence and instant messaging capabilities – then go use it.

If the service you are adding WebRTC to already has some logic of its own, it probably has signaling in there. So you just add the relevant messages you need to that proprietary signaling.

In any other case, my advice would be to use a proprietary signaling solution that fits your exact need. If you’re fine with it, I’d even go as far as picking a SaaS vendor for signaling.

 

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

The post WebRTC Signaling Protocols and WebRTC Transport Protocols Demystified appeared first on BlogGeek.me.

This week the possibility to create dedicated audio/video tags for each dialog was added to verto! Also, ClueCon 2016 is just around the corner, register today to seal your spot! And if you would like to attend the training day on August the 12th you will need to sign-up this week! The spaces for that are very limited and we are quickly running out. Visit https://cluecon.com/ for all the information.

Join us 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-9157 [verto] Added the possibility to create dedicated audio/video tags for each dialog in verto

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

• FS-8623 [build] Fix libvpx Solaris Studio build
• FS-9152 [mod_avmd] Fixed warnings on FreeBSD
• FS-9155 [Centos] Fixed lang_es and lang_pt package to have the right language module

The following bugs were squashed:

• FS-9151 [mod_av] Fixed playback a mp4 file on a session without video not ending
• FS-9010 [mod_avmd] Dynamic passing of parameters
• FS-8584 [mod_callcenter] Request agents and tiers when reloading queue

If you install FreeSWITCH 1.6 on Debian 8 from official .deb packages, and then add FusionPBX on top, the server boot sequence needs a modification: now FreeSWITCH configuration depends on the presence of Postgresql server, and it would load an empty configuration if the database service is not available at the moment of start.

This fixup adds a dependency on FreeSWITCH systemd service, so that it launches only after Postgresql has started:

mkdir /etc/systemd/system/freeswitch.service.d/ cat  >/etc/systemd/system/freeswitch.service.d/fusionpbx.conf <<'EOT' [Unit] After=syslog.target network.target local-fs.target postgresql.service EOT
Filed under: Networking Tagged: freeswitch, linux, pbx, voip

Grab your copy now.

I am in the last stretch of updates for my Choosing a WebRTC API Platform report. In the past month, the report has been available at a discounted price – from $1950 down to $1250. Purchasing the report includes 1 year of updates, which means that if you get your copy now – you’ll be receiving the new update next week.

What’s new in the report?

Things are at constant change with the WebRTC ecosystem, and the best place to see it is in the API space. Since the last update, we’ve experienced the rebranding of Comverse as XURA, which affected their Forge platform as well.

Here’s what you will find in the updated report, due next week:

• Updated all vendor profiles and feature sets, so they now reflect the existing
• Added a new vendor – QuickBlox. This brings us to 24 covered platforms in the report
• I added a new KPI to the report – investment level – where I indicate for periods between updates how much investment was made in new features and capabilities in the platform. This can be an indicator to the level of commitment the vendor has to his platform and what to expect moving forward when it comes to new features being introduced
• I’ve written a new Vendor Selection Blueprint. This document can assist you in the vendor selection process by guiding you through it. It includes an Excel sheet as well as a mockup example of such a process for an imaginary use case
• Presentation deck of the visuals has been redesigned and improved, so now if you need visuals – they will be even more professional looking

What do you get when you purchase the report?

The report itself isn’t only a PDF file you print and put on your manager’s table. It includes a lot more than that:

• The report, in PDF format (obviously)
• 1 year of free updates, these will cover 1-2 more updates (I tend to publish them every 6-8 months or so)
• Site membership access to additional materials
• Online comparison matrix, to make quick comparisons easy to handle
• Presentation visuals, which you can use in your own presentations
• Vendor Selection Blueprint, to guide you through the vendor selection process
• Access to the monthly Virtual Coffee sessions as well as the archived sessions

How to purchase?

Online.

1. Go to the WebRTC PaaS report page
2. Scroll down to the end of the page
3. Select the Premium option and press the BUY NOW button
4. Use your PayPal account or a credit card to make the purchase

If you do this in the next couple of days – you are guaranteed to enjoy the discounted price.

The post Last Chance to Enjoy a $700 Discount on my WebRTC PaaS Report appeared first on BlogGeek.me.

Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.

Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.

Hope to see you there!

Erik

The Keys to the Communications Universe

Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.

Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.

There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.

Thank you!

Warm hugs, Jeff

The real benefits of Apple and WebRTC has been left out of the conversations.

Can you help Apple find WebRTC?

There’s been too much chatter recently about Apple adding WebRTC. I am definitely in the opinion of Fippo here:

Things are going wild on the twitter #webrtc tag. Not a day without someone writing about Apple and WebRTC. Usually with little actual information.

I am not one to say I have inside information – I don’t. I don’t even know personally any Apple employee.

What I can say for sure, is that the real discussion on why Apple is important in the ecosystem of WebRTC has been ignored – as does the only place that is important.

Apple can add WebRTC in 3 places:

1. Safari on Mac OS X
2. Safari on iOS
3. Webview on iOS

Just as a point of reference, when Google adopted WebRTC, it added it to Chrome on the desktop, then to Chrome on Android and somewhat later to Android webview. Not surprisingly, the priorities were decided based on the complexity and risk of the tasks (from the “easiest” to the most complex).

WebRTC in Mac OS X Safari

Safari on Mac OS X is nice, but at this point it won’t matter much. For the most part, Chrome is the leading browser these days – surpassing even IE; and from asking around, it seems that Mac users are used to switching from Safari to Chrome when needed – it isn’t unheard of.

Adding support for WebRTC to Safari on Mac OS X is nice, but for the most part, it won’t change things in any meaningful way.

WebRTC in iOS Safari

Safari on iOS is interesting. For iOS, there’s only a single alternative today, and that’s to port WebRTC on your own and integrate it into your app.

While this works well for most use cases, there are a few edge cases where this isn’t desirable.

Here are 4 such areas:

#1 – Porn

I had an interesting discussion two years ago with a porn vendor who wanted to start exploring WebRTC as a long term solution and a migration path from Flash.

Their main concern was that porn viewers were migrating from the desktop to their smartphones. I guess it has something to do with phone use in restrooms.

Surprisingly (or not), the main reason for him to want WebRTC was iOS. Applications on iOS require to be puritan apps to a large degree. If an app’s content doesn’t abide to the app store submission rules (and porn doesn’t), then the app won’t get approved. This becomes a kind of a headache if what you do is serve porn.

There are two ways to “fix” that today, both run in the browser (Safari on iOS that is):

1. Use HLS to stream the video, but the latency wasn’t good for this vendor. He needed low latency. In his words, “the viewer needs to be able to interact with the performer and tell her what to do”. Apparently, waiting 20 or 30 seconds until the performer responds to the viewer’s whims isn’t fast enough
2. Capture JPEG images and send them over HTML as if they are video. It means 3 frames per second or something just as stupid, but it seems porn viewers are happy with it. At least to some extent

Having WebRTC in Safari for iOS means no need to go through the approval process of Apple’s App Store, something impossible for such companies.

As you might have guessed, I learned a lot in the meeting with that company.

#2 – Click to dial

There are times when WebRTC is used for customers and potential customers to reach out to the vendor. They happen to search the internet, bump into your travel agency, and want to make a call to book a flight. Or they might have bumped into an issue with the toaster they purchased and want to ask for assistance. Whatever the case is, that person has no inclination to install an app on his phone just to make that one time interaction.

WebRTC on Safari’s iOS means that this is possible now to achieve for iOS users – and not only the Android ones.

#3 – Guest Access

In many cases, there’s a UC (Unified Communication) system already in use. While its focus is in employees communicating with each other, these systems also allow for guest access. Think of joining one of them GoToMeeting or WebEx sessions. First thing you do in them is install a client to be able to do them – or fumble around with a phone number and a PIN code. Both ugly practices.

WebRTC enables to leave that behind by sending the guest a URL in his email – not a URL with instructions in it, or an installation link – but a URL to the actual session. Along the way, you can also make that URL unique per participant if you wish. This is already available today – unless you use an iOS device.

#4 – Gaming (the gambling kind)

Apple takes 30% of all purchases made through apps. 30%

Gambling and booking usually work on profit margins that are usually lower than 10%.

That being the case, how, if at all, can they make money out of gamblers using apps without letting them pay through the app? The whole idea of gambling is the reduction of friction.

Now, getting gamblers to open a URL and play from there, with whatever interactivity they wish to add through the use of WebRTC – that’s a useful capability.

WebRTC in iOS Webview

This is where things get really interesting.

As stated earlier, most consumption on mobile today is done via apps. For WebRTC, most of these apps are developed as native apps. This happens for a couple of reasons:

1. Force of habit. That’s just life as we know it today
2. Native tends to work slightly better than HTML5 apps
3. WebRTC dictates porting it and wrapping it as an SDK on iOS today

While native is great, HTML5 is even better. It offers cross platform development capabilities across desktop, browser and mobile – and in them, across ALL operating systems. WebRTC isn’t there yet because Apple isn’t there yet.

Add to that the new technique behind PWA (Progressive Web Applications), and you may well find HTML5 enticing for your service. To support such a thing, WebRTC on iOS isn’t enough, but it is still needed. What got this piece of technology into my radar was this write up by Henrik Joreteg – Why I switched to Android after 7 years of iOS. It goes into detail on the user experience of PWAs.

Even if you decide to stick to native development, having WebRTC implemented, optimized and fine tuned by Google and Apple for their respective mobile operating systems and then just slapping a Webview in place to use them in your app is a worthwhile investment.

–

Will Apple add WebRTC to its products? Probably yes

Do we know when will it happen? No

Should we prepare for it? Maybe. You tell me

 

The post What will Happen when iOS Webviews Adopt WebRTC? appeared first on BlogGeek.me.

Time is passing fast, no doubt, feels like yesterday when we were toying with the idea of organizing a Kamailio related conference and now we are one week before its 4th edition.Every year there was an increase in the number of the attendees and we are going to run full house this edition. Of course, we take this chance to celebrate 15 years of development for Kamailio, a long journey, not always smooth, but everything ended up strengthening the project. Being the oldest very active developer, I (Daniel-Constantin Mierla) can say that Kamailio has one of the most active, challenging and pleasant to work with community, including here all the developers and users, this being the main reason of getting to where we are now with the project. Many thanks to all of you for that!Back to the next week, some last minutes updates.
The trip to Fraunhofer Fokus Institute is confirmed and if nothing unexpected happens, those that registered for workshops can choose to visit the NGNI laboratories. It will worth it, few very interesting demos will be shown on site and you can interact with some of the bleeding technologies that may shape the future of how we communicate and interact in real time with all things around us. A shuttle bus will be available to transport between Kamailio World location and Fokus institute. More details are available at:

• https://www.kamailioworld.com/k04/fokus-ngni-laboratories/

If you haven’t participated at the past editions, take a bit of time to get familiar with the address of the event:

• https://www.kamailioworld.com/k04/venue/

Like in the past, it is a single track conference, the schedule is available at:

• https://www.kamailioworld.com/k04/schedule/

The exhibitors are preparing again very interesting product or services show cases and demos for the entire duration of the conference days. Expect some local 4G/VoLTEinfrastructure from NG Voice and Core Network Dynamics. Matrix.org returns this year with an integration between SIP and the matrix federating protocol and platform.Digium will give you the chance to play with their latest SIP phones as well as see demos about the new cool Asterisk features. A consistent team from Sipwise will be around to reveal all the bits of SIP:Provider platform.Special thanks to all sponsors that allowed us to bring again an amazing group of speakers: FhG Fokus, Asipto, Sipwise, Sipgate, Simwood, Evariste Systems, Matrix.org, Digium, Core Network Dynamics, Voicetel, DIDx and Pascom.See you next with in Berlin!

This week we have a new feature in mod_callcenter adding a ring-progressively strategy, extended the XML configuration for avmd, and changes to the pastebin API for the website! Also, ClueCon 2016 is just around the corner, register today to ensure your spot! And if you would like to attend the training day on August the 12th you will need to sign-up this week! The spaces for that are very limited and we are quickly running out. Visit https://cluecon.com/ for all the information.

Join us 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-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.
• FS-9124 [avmd] Extend XML config
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9132 [mod_kazoo] Add more variables to default filter

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

• FS-9070 [configuration] Update config.sub and config.guess
• FS-5936 [Debian] ESL.pm packaged for Debian
• FS-9075 [Debian] Additional tweaks to help ease upgrading freeswitch-all

The following bugs were squashed:

• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-8795 [mod_png] Fixed an issue with audio only call
• FS-9131 [core] Improve validation of ice candidates to handle malformed as well
• FS-9135 [core] Handle incorrect uses of switch_core_media_set_sdp_codec_string function passing null sdp gracefully
• FS-7783 [core] Properly handle NULL var_name for switch_play_and_get_digits

Kamailio SIP Server v4.4.1 stable is out – a minor release including fixes in code and documentation since v4.4.0. The configuration file and database schema compatibility is preserved.Kamailio v4.4.1 is based on the latest version of GIT branch 4.4, therefore those running previous 4.4.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.4.x.Resources for Kamailio version 4.4.1Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/4.4.1/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.4.1/ChangeLog

Download via GIT: # git clone git://git.kamailio.org/kamailio kamailio
# cd kamailio
# git checkout -b 4.4 origin/4.4Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/4.4.1/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/4.4.x/

What is new in 4.4.x release series is summarized in the announcement of v4.4.0:

• http://www.kamailio.org/w/kamailio-v4-4-0-release-notes/

Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference 2016 next week in Berlin!

Both.

VP8 and VP9 are video codecs developed and pushed by Google. Up until recently, we had only VP8 in Chrome’s WebRTC implementation and now, we have both VP8 and VP9. This lead me to several interesting conversations with customers around if and when to adopt VP9 – or should they use H.264 instead (but that’s a story for another post).

This whole VP8 vs VP9 topic is usually misunderstood, so let me try to put some order in things.

First things first:

1. VP8 is currently the default video codec in WebRTC. Without checking, it is probably safe to say that 90% or more of all WebRTC video sessions use VP8
2. VP9 is officially and publicly available from Chrome 49 or so (give or take a version). But it isn’t the default codec in WebRTC. Yet
3. VP8 is on par with H.264
4. VP9 is better than VP8 when it comes to resultant quality of the compressed video
5. VP8 takes up less resources (=CPU) to compress video

With that in mind, the following can be deduced:

You can use the migration to VP9 for one of two things (or both):

1. Improve the quality of your video experience
2. Reduce the bitrate required

Let’s check these two alternatives then.

1. Improve the quality of your video experience

If you are happy with the amount of bandwidth required by your service, then you can use the same amount of bandwidth but now that you are using VP9 and not VP8 – the quality of the video will be better.

When is this useful?

• When the bandwidth available to your users is limited. Think 500 kbps or less – cellular and congested networks comes to mind here
• When you plan on supporting higher resolutions/better cameras etc.

2. Reduce the bitrate required

The other option is to switch to VP9 and strive to stay with the same quality you had with VP8. Since VP9 is more efficient, it will be able to maintain the same quality using less bitrate.

When is this useful?

• When you want to go “down market” to areas where bandwidth is limited. Think a developed countries service going to developing countries
• When you want to serve enterprises, who need to conduct multiple parallel video conferences from the same facility (bandwidth towards the internet becomes rather scarce in such a use case)

How is bitrate/quality handled in WebRTC by default?

There is some thing that is often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the network.

The standard practice in enterprise video conferencing is to never use more than you need. If you are trying to send a VGA resolution video, any reputable video conferencing system will not take more than 1 Mbps of bitrate – and I am being rather generous. The reason for that stems from the target market and timing.

Enterprise video conferencing has been with us for around two decades. When it started, a 1 mbps connection was but a dream for most. Companies who purchased video conferencing equipment needed (as they do today) to support multiple video conferencing sessions happening in parallel between their facilities AND maintain reasonable internet connection service for everyone in the office at the same time. It was common practice to reduce the internet connection for everyone in the company every quarter at the quarterly analyst call for example – to make sure bandwidth is properly allocated for that one video call.

Even today, most enterprise video conferencing services with legacy in their veins will limit the bitrate that WebRTC takes up in the browser – just because.

WebRTC was developed with internet thinking. And there, you take what you are given. This is why WebRTC deals less with maximum bandwidth and more with available bandwidth. You’ll see it using VP8 with Chrome – it will take up 1.77 Mbps (!) when the camera source is VGA.

This difference means that without any interference on your part, WebRTC will lean towards improving the quality of your video experience when you switch to VP9.

One thing to note here – this all changes with backend media processing, where more often than not, you’ll be more sensitive to bandwidth and might work towards limiting its amount on a per session basis anyway.

All Magic Comes with a Price

We haven’t even discussed SVC here and it all looks like pure magic. You switch from VP8 and VP9 and life is beautiful.

Well… like all magic, VP9 also comes with a price. For start, VP9 isn’t as stable as VP8 is yet. And while this is definitely about to improve in the coming months, you should also consider the following challenges:

• If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements
• It isn’t yet available in hardware coding, so this is going to be challenging (VP8 usually isn’t either, but we’re coping with it)
• Mobile won’t be so welcoming to VP9 now I assume, but I might be mistaken
• Microsoft Edge won’t support it any time soon (assuming you care about this Edge case)

This is a price I am willing to pay at times – it all depends on the use case in question.

 

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

 

 

The post VP8 vs VP9 – Is this about Quality or Bitrate? appeared first on BlogGeek.me.

http://ortc.org/wp-content/uploads/2016/05/ortc.html#change-log*

B.1 Changes since 01 March 2016

1. Added the gather() method, as noted in: Issue 165
2. Removed “public” from RTCIceGatherPolicy, as noted in: Issue 224
3. Removed the minQuality attribute, as noted in: Issue 351
4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
5. Provided additional information on ICE candidate errors, as noted in: Issue 402
6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
8. Clarified payloadType uniqueness, as noted in: Issue 405
9. Updated the list of header extensions, as noted in: Issue 409
10. Added “goog-remb” to the list of feedback mechanisms, as noted in: Issue 410
11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
12. Clarified send() restrictions on kind, as noted in: Issue 414
13. Added getAlgorithm() method, as noted in: Issue 427
14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
16. Clarified support for the “direction” parameter, as noted in: Issue 442
17. Clarified the apt capability of the “red” codec, as noted in: Issue 444
18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
19. Clarified firing of onssrcconflict event, as noted in: Issue 448
20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
21. Updated references, as noted in: Issue 457
22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
24. Corrected use of enums in the examples, noted in: Issue 466
25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
27. Changed hostCandidate type, as noted in: Issue 474
28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
30. Updated description of RTCIceTransport object, as noted in: Issue 477
31. Updated description of relatedPort, as noted in: Issue 484
32. Updated description of RTCIceParameters, as noted in: Issue 485
33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
34. Provided a reference to error.message, as noted in: Issue 495
35. Clarified RTCRtpReceiver description, as noted in: Issue 496
36. Clarified default for clockRate attribute, as noted in: Issue 500
37. Removed use of “null if unset”, as noted in: Issue 503
38. Updated RTCSctpTransport constructor, as noted in: Issue 504
39. Clarified behavior of getCapabilities(), as noted in: Issue 509
40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

Part of development for next major release Kamailio 5.0, we would like to announce that the framework (code-named kemi) which allows writing the routing blocks in embedded languages is already in place. At this moment, Lua or Python can be use as alternative to the native scripting language to write the routing blocks. More details can be found at:

• https://www.kamailio.org/wiki/devel/config-engines

Examples of SIP routing scripts that offer more or less same features as etc/kamailio-basic.cfg are available in source tree at examples/kemi. For convenience of reading, here are the links to git repository:

• the common file setting global and modules parameters as well as specifying the config engine:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi.cfg
• the part of config with routing blocks in native language:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-native.cfg
• the part of config with routing blocks in Lua:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-lua.lua
• the part of config with routing blocks in Python:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-python.py

You can compare the last three above and see how different or similar they look for providing same SIP routing features using different languages.The work is not finished, lot of modules need to export now functions to embedded config interface, which is quite straightforward:

• https://www.kamailio.org/wiki/devel/config-engines#exporting_functions_to_kemi

Also, a missing part is handling the equivalents of event_route blocks in embedded languages, an ongoing discussion being open on mailing lists..Interesting that some incipient performance tests to compare the interpreters show good results for using especially Lua but also Python:

• https://www.kamailio.org/wiki/devel/config-engines#interpreters_performances

Anyone willing to help can start exporting functions from modules to embedded interface or test some more complex configs in Lua or Python.Thank you for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference in less than two weeks!

tcpkali is a lightweight and  easy-to-use tool that allows you to generate a traffic load with multiple TCP sessions. You push the load in one or both directions at the same time. Also the tool works easily over a NAT’ed connection. This tool is great if you need to test QoS for VoIP applications.

Here’s an example of a bidirectional load test:

# listening machine: listen on tcp port 8000, send traffic, and use 4 threads. # the program will exit in 1 hour. tcpkali -l 8000  --listen-mode=active -m X -T 1h -w 4 # connecting machine: send traffic using 4 threads and 10 simultaneous sessions # for 1 minute tcpkali 192.168.1.109:8000 -m Y -c 10 -T1m -w 4

The above test between directly connected PC Engines APU2 boards has shown 1Gbps of traffic, and the average CPU load was about 50%.

Filed under: Networking Tagged: linux, networking, pcengines, testing, voip