News from Industry

WebRTC is Ready. Now What? (a look at the state of WebRTC in 2019)

bloggeek - 1 hour 32 min ago

There should be no doubt about WebRTC anymore. It is here and it is ready for everyone. The question is: “now what?” Where are we headed with WebRTC in 2019

Is WebRTC Ready Yet?

That was the name of a website that tracked how well is WebRTC adopted by the various browser vendors.

Apparently, it is also the most common question on Google about WebRTC:

It is time we say it outloud (I don’t believe anyone has done that up until now):

WebRTC is READY

I was asked to speak at Apidays Amsterdam last week, which was a true joy. The topic I was tasked was around WebRTC being a standard, and well… where are we headed next. So I decided to rephrase it a bit and ignore that tiny bit of a fact that WebRTC 1.0 still isn’t an official standard (nobody but those in standardization organizations and those opposing to adopting WebRTC seem to care either).

So I sat down to think what does it mean that WebRTC is ready. Which led to this question:

Why I think that WebRTC is ready?

The best way for me to answer that question was to give 3 recent examples on things happening with WebRTC (and I don’t mean Uber doing VoIP using WebRTC):

#1 – VP8 Supported by Safari

I’ve been a critic about Apple’s non-support of WebRTC and then Apple’s non-support of VP8.

The fact that Apple decided at the time to support only the H.264, a royalty bearing video codec, and ignore VP8, the royalty free alternative, wasn’t a good sign.

In the past two weeks, tweets and webkit bug links have been flying around, indicating that if the mountain won’t come to Muhammad, then Muhammad must go to the mountain. Or more accurately, that Apple decided to do a Microsoft and support VP8.

Do a Microsoft because this is the same steps Microsoft took when going WebRTC. Starting with H.264 and only later adding VP8.

So Apple has started with H.264 and only now adding VP8.

When will this be available for all? Ask Apple.

What’s important is that ALL modern browsers now support both VP8 and H.264. More on that in a sec.

It doesn’t stop there either. Apple joined the Alliance of Open Media as a founding member. This alliance is behind the future video codec AV1, and now has 40 members in it.

#2 – H.264 Simulcast Support

The second example is H.264. It is now becoming a first class citizen.

H.264 on Chrome didn’t have simulcast support. The “fix” for that was available for quite some time, but was never incorporated into Chrome. Simulcast increases the quality of group video calls, so not supporting it in H.264 made H.264 useless for group video calls.

There can be two reasons for this feet dragging by Google:

  1. Timing and priorities. Google didn’t really care enough to add that in and deal with the headaches of pushing code from a third party with the fix and validating it
  2. The push towards VP8. Increasing the quality of H.264 would get more developers to adopt it, especially when Apple supports only H.264 on Safari

Since VP8 is coming to Safari, the reason to give it an edge over H.264 isn’t there anymore. Especially considering the healthy growth of the Alliance of Open Media.

The end result?

  • All modern browsers support VP8 (Safari support is imminent)
  • All modern browsers support H.264; and simulcast will soon be possible for it
  • VP9 is available only in Chrome and Firefox for WebRTC – but who cares? The future will be AV1. And ALL browser vendors are part of the Alliance of Open Media where AV1 is getting specified (YouTube is already testing AV1 decoding in Chrome and Firefox)

This media codecs disparity between browsers was the main challenge for the WebRTC community. It is now behind us.

#3 – Google Shifts Focus

That third reason why I believe WebRTC is ready?

Google is shifting focus. It is doing what is needed to support WebRTC and the migration to the 1.0 specification (unified plan for example), but its heart and mind is already elsewhere:

At the beginning of this month, Google announced Project Stream – a cloud based service that streams high end games from resource intensive cloud based machines to low end devices in real time.

There’s not a lot to go on about the technology, but it seems to be based on WebRTC.

Project Stream official gameplay capture: 1080p@60fpshttps://t.co/SjznbRCBAP

— Justin Uberti (@juberti) October 2, 2018

Why else would Justin Uberti from Google’s WebRTC team publish this? 1080p resolution at 60 frames per second with low latency for gaming. This type of a use case is different from real time communications. It requires a different focus and optimizations. And yet… the WebRTC team at Google have probably spent some cycles on supporting it.

Why is that a good thing?

Because for Google, WebRTC is ready when it comes to real time communications, and beyond optimizations and house keeping, it is time to move on and look at other use cases where WebRTC can be beneficial.

What’s Next?

So. WebRTC is here:

  1. Apple supports it now; and there’s codec parity across browsers
  2. H.264 is a first class citizen in WebRTC
  3. And Google has moved on to other use cases for WebRTC

What’s next for WebRTC?

The answer I gave in that presentation at Apidays was Machine Learning.

I like that slide above. I like it because you can take RTC out of it, replace it with whatever word/term/industry you want and it will STILL be true.

In the rest of that presentation, I went over the research report that Chad Hart and I have written, sharing some of our findings.

I went into the 4 domains we’ve mapped in our research, in each giving an example of the impact and use cases that are now possible:

  1. Speech analytics, and how we’re shifting from offline processing to real time
  2. Voicebots, and how work in that area is accelerating
  3. Computer vision, where use cases are vastly different between consumer and enterprise settings
  4. Media optimization, and the shift from heuristics to machine learning
That Deck from Amsterdam

That slide deck from Amsterdam is now available online as well. You can view it here:

WebRTC is READY. What's Next? from Tsahi Levent-levi Machine Learning and Real Time Comms

If you are interested to learn more about machine learning, to be able to make smart decisions in your own company about the use and introduction of machine learning and artificial intelligence in a communications application, then definitely check out our report: AI in RTC

The post WebRTC is Ready. Now What? (a look at the state of WebRTC in 2019) appeared first on BlogGeek.me.

Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard)

webrtchacks - Fri, 10/19/2018 - 05:47

If you plan to have multiple participants in your WebRTC calls then you will probably end up using a Selective Forwarding Unit (SFU).  Capacity planning for SFU’s can be difficult – there are estimates to be made for where they should be placed, how much bandwidth they will consume, and what kind of servers you need.

To help network architects and WebRTC engineers make some of these decisions, webrtcHacks contributor Dr. Alex Gouaillard and his team at CoSMo Software put together a load test suite to measure load vs.

Continue reading Breaking Point: WebRTC SFU Load Testing (Alex Gouaillard) at webrtcHacks.

Can Google RCS Win the Messaging Game Through AI?

bloggeek - Mon, 10/15/2018 - 12:00

RCS is being brought from the dead by Google, and its next play will probably be with AI.

Carriers have a problem

SMS won’t stay here forever. In fact, most of the messaging traffic is happening on social networks now.

Voice is shifting as well. Migrating to these same social networks. With the ability to upgrade these calls to video calls. With stickers. And silly hats, cat lenses and whatnots.

Want to learn more about the use if silly hats and other AI features in communications? Check out our AI in RTC report preview

Download the preview

Their circuit switched network technology is decaying, left in its 80’s or probably 50’s. Most of what goes on there is spam or OTP passwords anyways. Nobody cares.

So much so that Google is planning on diverting incoming calls to its assistant (but more about it later).

The solution, in the form of IMS and later RCS (or call it Joyn or whatever other branding it was given throughout the years) are some 20 years in the making. And they don’t seem to be coming any time soon. At least not if left to the arduous processes of carriers and their suppliers.

Google has a problem

 

A VERY different problem.

Google has no messaging clout.

For consumers?

Apple iMessage wins on iOS. It acts as a Chameleon, catching up your messages and deciding if they should be demoted to SMS or use modern messaging via iMessage instead.

Facebook with Messenger and Whatsapp is ruling supreme in Android, and in many cases on iPhones as well. Where they aren’t as strong, you’ve got a slew of other social players with 100+ million monthly active users. None of them looks like a carrier. And none of them is Google.

Google has Allo, Duo, Chat, Meet, Hangouts, Messages and probably a few more apps that I’ve forgotten to mention. All in different states and capabilities; but none which is dominant compared to its competitors. Actual monthly active users and amount of real messages going between users? Not shared. Probably not stellar.

And Google has RCS..

For businesses?

Apple, Facebook and others are adding APIs. Introducing bot platforms. Building marketplaces. And they are doing it slowly, fearful of becoming the spam cesspit that is the good ol’ carrier communications tech today.

Slack is killing it. And the rest of the cadre of UCaaS and enterprise communications players are trying to move into their space.

Google has Meet and Hangouts Chat. Part of G Suite. Meet gets used. Hangouts Chat I don’t really know. But it seems that most just skip it and move on to Slack or some other tool.

Google also has nothing similar to a business angle to its consumer facing communications applications yet, or at least nothing popular enough.

What’s new in RCS land?

Nothing really.

I’ve written in April about RCS being still dead. For some reason, Google is still hammering away at it. Similar to Google+ if I need something to compare it to.

A press release last month by Samsung and Google brings Samsung to the RCS graveyard. New Samsung devices, and maybe layer older ones will come -gasp- with a Samsung Messages app that will work seamlessly with the Android Messages app using each other’s RCS technology!

This interoperability nightmare of the carriers will continue on, leaving RCS dead.

Adding new carriers or smartphones or chipset makes into the fold won’t help either.

And it isn’t as if Apple is making any noises of being interested in RCS, and why should they be?

That said, there are those who will be adopting RCS.

We are shifting towards an omnichannel world. No single protocol to rule them all. No single vendor to rule them all. You want to send your message as a business to a consumer?

You can use SMS. Or better do it over Messenger or Whatsapp or Apple Business Chat – there’s more context and richness in those, and consumers actually care about these channels. Which brings us to a place where businesses just need to support wherever their customers are with no decent common denominator.

And wouldn’t it be great if we could throw SMS and use RCS instead? At least where we can?

So CPaaS vendors are adding support for RCS and announcing it in their arms race to world domination by collecting as many social messaging icons as they can.

That’s great, but not enough to save RCS.

Can Google change RCS predicament?

Not really.

There are just too many players and this is a domain where Google has been struggling to go it alone as it is.

Here’s what it takes to bring RCS properly to the masses:

Chipset vendors

Chipset vendors are at the bottom of the food chain, but they need to offer their support to make RCS happen.

Unlike other messaging services, RCS is “bolted” on to the identity of the user and his device. The SIM card. The ability to connect the end user, through an application, to the SIM card, and from there to the carrier network is what presumably makes RCS different. But for that to happen, chipset vendors need to pave the way, even if just a little bit.

Handset manufacturers

Handset manufacturers need to make sure that the RCS application is there implemented, supported and pre-installed in the device.

Without being pre-installed, users will need to pick and choose between an RCS app from a handset manufacturer or a carrier (the word bloatware comes to mind) OR pick Whatsapp instead. The choice is a simple one for most.

They need to make the application attractive and sleek. Things they can’t really do. Competing with current successful social messaging apps requires a lot of investment. Nailing the user experience is a lot harder than it looks.

Carriers

Carriers need to actually support RCS. As a service. In their network. And have these things called mobile phones that support RCS. and enough people that have these devices so they can actually talk to each other.

Preferably, all carriers within a country should light on the switch on RCS simultaneously.

How likely is that to happen?

Single, very complex specification

And all of these players need to do so for a very complex IMS/RCS specification.

Testing the combinations of devices and networks is going to be hellish, especially for those who aren’t going to just select the default Google implementation of RCS client/server.

Which is exactly what Samsung decided to do. Have its own service and then interoperate it with Google’s. I can easily see other big players – chipset vendors, handset vendors and carriers who would be either scared shitless of ceding control to Google or not magnanimous enough in letting Google take control over that piece.

This headache also suggests something really important:

If RCS succeeds, it won’t move as fast as any of the other social networks in introducing new features, services and capabilities

There are too many moving parts, controlled by different players, some of which doing the same things.

Network effects

Then there’s the network effects.

When can I use RCS on my phone?

It needs to be installed there. Probably pre-installed.

The people I communicate should have it as well.

Our networks should support it.

Oh – and there’s this minor detail of me actually going into that app to send a message.

How many times this week have you clicked on this icon on your Android phone?

What about these icons?

Enter Artificial Intelligence

I’ve been thinking about it for quite some time.

How can Google become relevant in messaging?

It is unlikely to come from features and capabilities at the core of social messaging. None of its services stick:

  • Google+ was “shutdown” publicly this month. Google found a great excuse – a potential security flaw
  • Duo was supposed to compete head-on with Apple FaceTime, offering things like faster connections and knock knock feature. But what have we seen from Duo since its launch? And are you using it at all?
  • Allo was interesting, but got no adoption. It got halted on April if you believe the news
  • Hangouts is being replaced by Meet, at least for the enterprise. Will it be shut down for consumers? Time will tell
  • Hangouts Chat is only starting its way, though I haven’t heard anything at all since its public launch
  • Meet works just fine. For the enterprise. If you have a Google account
  • The Google Messages app is purely for SMS. And it is crappy to say the least. It doesn’t respond as fast or as fluid as other social messaging apps, and frankly, I don’t really care about the technical reasons for it

The one thing Google has going for it is AI. in droves.

Which is probably why Google Duplex is reportedly rolling out next month, helping phone users book tables at restaurants – on their behalf.

It is also why Google is now adding to its Assistant the ability to screen spam calls:

These AI features have a potential to actually succeed. They don’t really relate to RCS or even messaging, but they are about telephony.

Allo was about messaging. As reported on The Verge in the April Allo pause:

As part of that effort, Google says it’s “pausing” work on its most recent entry into the messaging space, Allo. It’s the sort of “pause” that involves transferring almost the entire team off the project and putting all its resources into another app, Android Messages.

Google won’t build the iMessage clone that Android fans have clamored for, but it seems to have cajoled the carriers into doing it for them. In order to have some kind of victory in messaging, Google first had to admit defeat.

That’s the Google RCS effort right there.

If you take the AI related features in Allo, and think of them as getting Google Assistant into Messages, the Google RCS app, then it makes sense in a way. But not enough sense.

The Google Assistant doesn’t feel like a product by now. It is a large set of features and capabilities that can be used to add smarts into phones. It is a window to the phone’s (and Google’s) AI for the consumer.

Limiting it to run for RCS only doesn’t seem like the right thing to do. Would it be enough to save RCS? Would it be enough for Google to gain back users from other messaging apps?

It is too early to say, as none of it as come to fruition in an app customers can use.

Google could have tried to do with Allo the same things it is doing with its Contact Center AI:

Provide the whole AI for communication part as an API, a set of building blocks for others to use and embed. It worked so well for them that it got many in the industry lining up to partner with it in contact centers. Launch partners for the Contact Center AI include Mitel, Genesys, Vonage, Cisco, RingCentral, Five9 and Twilio to name a few.

Would such a thing work with social messaging apps?

Apple wouldn’t touch it with a long stick for its iMessage.

Facebook wouldn’t either. So no Messenger or Whatsapp.

Telegram? I don’t see that happening.

WeChat? Chinese.

Who would they be left with? The smaller players, who might grow, but none seem to be rising above white noise level.

Which gets us back to Google itself. With Messenger/RCS/Chat.

What Google needs to do is find the sticky features that will get users to use its app. Those that can get value out of it even when the other participant isn’t using the same app. Add smarts into SMS itself, while providing a rich experience to the user when interacting with others who have that app.

The real question is why limit this to RCS and carriers? why not just offer it as the out of the box Android experience to everyone? Have it there by default. Let people download and install it on older devices and on iPhones.

Probably because Google still believes it relies on carriers for its Android success. Which is what’s keeping it back in mobile social messaging since Android came to our lives.

Want to learn more about the use if silly hats and other AI features in communications? Check out our AI in RTC report preview

Download the preview

The post Can Google RCS Win the Messaging Game Through AI? appeared first on BlogGeek.me.

WebRTC vs Zoom. Who has Better Video Quality?

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

WebRTC vs Zoom? WebRTC is actually quite good. But you knew that already – didn’t you?

They say quality is in the eye of the beholder. So behold.

We’ve all been told once and again that this video conferencing vendor or that video conferencing vendor work great. They offer the best quality. The best experience. They work in conditions that others don’t.

I even had a call once with an entrepreneur that explained to me how he is going to offer a service that is better in its 1:1 video quality than Skype and Google Hangouts. And he is going to do it with WebRTC. I spent the better part of that call to get him off that idea (something about his logic was off there).

But I am digressing.

As many others, I’ve been told time and again how Zoom is great. How in spite of the fact that it doesn’t work in the browser and forces you to download its client (some even refer to it as a virus), it gets traction and adoption. It feels like it is the best game in town. And then they mention the reasons:

  1. It’s free (until it isn’t, which is a great business model if you can make it work, and Zoom is making it work)
  2. It has better video quality than the competition. Especially WebRTC

I am not the only one who needs to listen to it, and even believe it to some extent. The guys at Jitsi got curious – why not put it to the test?

So they took a Mac device, placed it on a WiFi network, added a network limiter so they can fiddle with the network configuration, and did a 1:1 call. Once with Zoom. And once with WebRTC.

Idea is this – start with as much bandwidth as the video call wants. Then limit it to 500kbps. Check how much time it takes to adapt. Remove the limit and change how much time it takes it to adapt back. More about it in Jitsi’s blog.

Essentially – testing for this network conditions:

The longer that marked areas, the worse the experience is going to be for the users.

And guess what? Zoom faired worse than WebRTC. Not a little, but a lot worse.

Full adaptation to limiting the bandwidth took WebRTC 20 seconds. It took Zoom 156 seconds (!).

Ramp up back to 2mbps took WebRTC 32 seconds. It took Zoom 62 seconds.

Now here’s my analysis of this.

WebRTC Rocks

Yap. it really does.

The screen capture from that Zoom blog post that was pasted by Jitsi?

Stating that “web-RTC is a very limited solution that would not allow us to provide all the excellent features that our users have come to expect from us”?

That’s from 2015.

A lot have been improved in WebRTC since then, if that explanation was even correct in 2015 to begin with.

Without the need for most of us to do anything, we’re getting updates to a top notch media engine in the form of WebRTC inside the browsers we use. The code used in Chrome are open sourced, so they are accessible to all to embed it in their own applications as well.

Security fixes? New codecs? Improved media algorithms? They just “happen”. Out of thin air. For most of us.

Defending Zoom

If I look at it from Zoom’s point of view, besides the fact of being a dominant player in the market with or without WebRTC, here’s the challenges with such a test scenario:

  • It was done once, or a few times. But it is still only one scenario
  • It wasn’t a real life scenario. Just something concocted for this. Jitsi could have rigged it and tweaked it so that WebRTC would shine, but in real life, that doesn’t happen, and at Zoom we’re optimizing for real life scenarios
    • (that isn’t really so. From my experience and knowledge of the Jitsi team, I’d estimate they tried to be VERY careful here to not fall into that trap)
    • (and what’s real life scenarios anyway?)
  • The network limiter used changes behavior in ways that aren’t close enough to reality
    • (that I can understand and live with. We see faster uptake of the same type of scenarios for WebRTC at testRTC – more on that later)
  • Zoom might be working through external remote servers for that same session while WebRTC is going peer to peer on the local network. Servers behave differently than clients, so the results seem somewhat “off”
  • In other scenarios, Zoom might actually be better than WebRTC

Which leads us to the fact that more tests are needed to know which one is best and in which scenarios.

This starts to sound like the VP8 vs H.264 quality comparisons of the past (I never could tell the difference).

It’s the Infrastructure Stupid

With WebRTC, it all boils down to the infrastructure. The one with the better deployment wins the quality game.

  1. Do you peer to peer for 1:1 sessions and seamlessly switch to SFU architecture when more participants join?
  2. Where are your media servers located?
  3. Do you cascade the session across media servers to improve quality?
  4. Do you provide feedback to the user about the network conditions?
  5. Do you switch video off when there’s not enough bandwidth?
  6. How are you managing things like FEC, simulcast, SVC, … ?
  7. What about mobile and native app support?

And the list goes on.

With vendors who use proprietary codecs and transport protocols, this is doubly so, as they need to cater for the browser once they reach WebRTC. So while their native apps might be optimized, it might all go down the drain once they transcode or just “translate” to reach the browser using WebRTC.

Need to understand WebRTC and how to design and architect real world solutions with it? A first step is to understand the servers used to connect WebRTC.

Join a free video course on WebRTC servers

Which brings us to why someone like Zoom should use WebRTC and thing about the quality issues once connecting to it:

You Need WebRTC

Zoom already supports WebRTC. I just found out when I searched for stuff to write this article: there’s a Zoom Web Client

It runs on Chrome and enables using audio in Chrome when joining meetings. No video, probably because transcoding the proprietary video codec Zoom uses to the ones in WebRTC is too complicated, but using G.711 or Opus in the browser and transcoding or using the same in Zoom is way simpler.

Zoom is going through the same phases that Amazon did with Chime:

  • Amazon Chime started with a downloadable client
  • They then added limited browser support that enabled users to view the screen shared in the browser and connect via the phone without the need to download the client
  • Later on, audio support was added to the web client
  • And recently, video got supported
  • Screen sharing and remote desktop control still doesn’t work. I’d say it is a matter of time

This exact same path has been happening to other vendors in one way or another.

Why not Check Your Own Service?

While writing this article, it dawned on me, that this is one of these scenarios that is ridiculously easy to simulate using testRTC, so I went ahead and created a script that does just that:

  • Loads up Jitsi with 2 participants. That should cause them to work peer-to-peer
  • Run the call for 1 minute unhindered
  • Limit bitrate to 500kbps and run for 2 more minutes
  • Remove bitrate limit and run for 2 more minutes

Here’s how the main part of the script looks like:

   // Wait for 1 minute client    .pause(60*sec)    .rtcScreenshot('ALL GOOD');    if (probeType === 1) {    client        .rtcEvent('Start limit', 'global')        .rtcSetNetworkProfile('custom', 'bandwidth', 500000, 'both', 'both')    }    // 2 minutes with bandwidth limits client    .pause(60*sec)    .rtcScreenshot('LIMITED')    .pause(60*sec);    if (probeType === 1) {     client        .rtcSetNetworkProfile('') // back to pristine network conditions        .rtcEvent('Stop limit', 'global');    } client    // 2 more minutes unlimited    .pause(60*sec)    .rtcScreenshot('BACK TO NORMAL')    .pause(60*sec);

 

The .rtcEvent() calls are there to place a vertical lines on the graphs while the .rtcSetNetworkProfile() is there to fiddle around with the network conditions.

There were two probes here, each one a participant in the call. The first one is the one I limited while the second one was left “untouched”.

Here’s what the graphs look like on the second probe:

The above graph shows the outgoing birate. Within a span of 5 seconds, WebRTC finds out the new effective bitrate and adapts to it. Ramping back up takes some 20 seconds.

The above graph shows the incoming frame rate. You can see how frame rate reporting in WebRTC takes a bit of time to get back to its usual self – also some 20 seconds or so.

I wanted to check how the Jitsi SFU would behave, so I tweaked the test URL for that. The results? Still better than the Zoom one. 20 seconds to hit 30 frames per second and around 50 seconds to get back to full bitrate.

If you want to try it yourself, just import the JSON file in this Google Drive folder to your testRTC account and modify it to fit your needs.

Where to now?

WebRTC is more than good enough.

Making it better is usually about thinking your way through the best possible architecture, along with media servers that take care of network conditions properly.

As for Zoom… please make sure your next call with me is on something that has WebRTC. The machine I regularly use for call is Linux. Zoom doesn’t work there… it doesn’t really support Chrome or Linux. Yet.

The post WebRTC vs Zoom. Who has Better Video Quality? appeared first on BlogGeek.me.

Development Of Kamailio v5.2.x Series Is Frozen

miconda - Fri, 10/05/2018 - 10:12
Here we mark the freezing of development for Kamailio v5.2 series.From now on, for few weeks, no new new features will be pushed in the master branch. Development can still be done, but should be hold in developers’ GIT personal branches.Once the branch 5.2 is created (expected to happen in 3-4 weeks), the master branch becomes again open for new feature. Meanwhile the focus has to be on testing current code.Work on related tools (e.g., kamctl) or documentation can still be done as well as getting the new modules in 5.2 in good shape, plus adding exports to KEMI interface (which should not interfere with old code).The entire testing phase is expected to be 4 to 6 weeks, then the release of v5.2.0 will be out.Thanks for flying Kamailio!

Kamailio v5.1.6 Released

miconda - Thu, 10/04/2018 - 19:00
Kamailio SIP Server v5.1.6 stable is out – a minor release including fixes in code and documentation since v5.1.5. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.Kamailio® v5.1.6 is based on the latest source code of GIT branch 5.1 and it represents the latest stable version. We recommend those running previous 5.1.x or older versions to upgrade. There is no change that has to be done to configuration file or database structure comparing with the previous releases of the v5.1 branch.Resources for Kamailio version 5.1.6Source tarballs are available at:Detailed changelog:Download via GIT: # git clone https://github.com/kamailio/kamailio kamailio
# cd kamailio
# git checkout -b 5.1 origin/5.1Relevant notes, binaries and packages will be uploaded at:Modules’ documentation:What is new in 5.1.x release series is summarized in the announcement of v5.1.0:Thanks for flying Kamailio!

Messenger was not forced to wiretap but…

webrtchacks - Mon, 10/01/2018 - 22:26

By david drexler – Flickr, CC BY 2.0, Link

 

Back in August, Reuters reported on a “secret legal fight” between the FBI and Facebook about wiretapping Messenger calls. The Verge as they found our old post about reverse-engineering Messenger from 2015 and had a number of follow-up questions on it for a Messenger wiretapping article they ran. Technical details on the case are quite hard to find so I was not able to dig deeper into the specifics around wiretapping.

Continue reading Messenger was not forced to wiretap but… at webrtcHacks.

Astricon 2018

miconda - Mon, 10/01/2018 - 10:09
Astricon 2018, the Asterisk users’ conference, is just several days away. It takes place again in Orlando, FL, USA, during October 9-11, 2018.Kamailio is very well represented at this edition, besides having a stand in the expo floor, there will be presentations by Alex Balashov, Daniel-Constantin Mierla and Fred Posner.You can find the schedule and more details about the event at:We hope to see many of you in Orlando!Thanks for flying Kamailio!

Kamailio Developers Meeting, Sep 27-28, 2018, in Dusseldorf

miconda - Sat, 09/29/2018 - 10:02
Kamailio SIP Server project is organizing a meeting of its developers during September 27-28, 2018, hosted by sipgate.de in Dusseldorf, Germany.The event is intended to facilitate the interaction between Kamailio developers and to offer a convenient environment for working together on several topics of high interest for the project, including writing code for Kamailio and its tools, improving documentation, or discuss about future development.Everyone from the community is welcome to join. Please note we have a limited capacity of 20 seats in the meeting room. Also, very important to be aware that this is not an event to learn how to use Kamailio.More details about the event, the venue, how to register, are available at:Looking forward to those two intensive hacking Kamailio days in Dusseldorf!Thanks for flying Kamailio!

New Kamailio Module Exports Interface

miconda - Fri, 09/28/2018 - 10:08
As a result of collaborative work at Kamailio Developers Meeting, we succeeded to merge the two existing module exports interface (one for Kamailio modules and the other one from SER modules) in a single one.All public modules were updated, but if you have any private module then you have to update as well in order to get it compiled with the latest master. Just look at one of the modules (e.g., sl module is a good option) and all the fields in mod exports structure have comments with their meaning.In short: we removed unused fields for statistics, mi commands and extra-processes (from Kamailio old interface) and oncancel (from SER old interface), kept the RPC exports from SER interface and PV exports and dlopen flags from kamailio interface. The other fields were common in both interfaces, but be aware that order was also changed.If you have a module implementing the SER old interface, you also need to add the free fixup field in functions exports structure — you can just set it to 0.With this we have now a single mod exports interface in all modules, the core is also cleaner as we got rid of the various compatibility layers.Thanks for flying Kamailio!

Maintenance Work On deb.kamailio.org

miconda - Thu, 09/27/2018 - 10:07
There will be some maintenance work done to deb.kamailio.org server these days in order to move to a better infrastructure, so it may not be available for a while. The DNS needs to be updated as well, this also can affect you if your router/provider does caching.This is affecting the APT repository for Debian and Ubuntu packages.Update Sep 28: migration has been completed, if you encounter any issue with the apt repositories, contact us.Thanks for flying Kamailio!

Upcoming Events – Autumn 2018

miconda - Mon, 09/24/2018 - 10:06
The autumn of 2018 has plenty of events where Kamailio developers and community members will participate. Among them:If you attend any of these events or are around their location at their dates, get in contact with Kamailio’s community via sr-users mailing list and let’s meet, greet and discuss latest news about the project and RTC market.Enjoy the autumn!Thanks for flying Kamailio!

Kamailio On Tap – Social Event In Dusseldorf, Sep 27, 2018

miconda - Thu, 09/20/2018 - 10:04
About 15 Kamailio developers are traveling to Dusseldorf for the Kamailio Developers Meeting during September 27-28, 2018, giving the opportunity to organize an open social networking event in the evening of September 27, 2018, at 19:00!That’s “Kamailio On Tap“, an informal meeting of Kamailio developers and VoIP community/RTC industry, to be hosted at:Pub: Hafenquelle (front of the street)
Gladbacherstrasse 74
40219 DusseldorfIt is not an event only for Kamailio developers, anyone from the VoIP community/RTC industry that wants to join us is welcome! It is a free to attend event, you just need to register in order to be sure we do not exceed available seats and dimension properly what is offered during the event.To register, send an email to  with the subject: “Kamailio On Tap” until September 26, 2018. Feel free to pass these details to friends, colleagues or business connections that you have in the area of Dusseldorf and you think they may be interested to attend.Beer and pizza are sponsored for everybody!Looking forward to meeting many of you in Dusseldorf!Thanks for flying Kamailio!

WebRTC FAQ: The 2018 Version

bloggeek - Mon, 09/17/2018 - 12:00

An updated WebRTC FAQ for those who wish to understand this tech somewhat better.

It is 2018, and it seems like there’s no good FAQ for WebRTC. Nowhere. They’re just not up to date. That, coupled with my own need to be the best source of information on the web about WebRTC (and the fact that my last few articles were more about CPaaS and messaging than WebRTC), got me to write this one.

What is WebRTC?

WebRTC is both a standard specification and an open source project.

WebRTC allows sending and receiving of real time voice, video and arbitrary data across browsers and other devices. This means we now have an easy way as users to conduct voice and video conferences from a browser or from our mobile devices. WebRTC can do a lot more than that, but voice and video in real time is the basis of what you get out of it.

There’s a short video explaining What is WebRTC on my site.

Who is behind WebRTC?

WebRTC originated from Google. It started by an acquisition of a few companies, whose technology was then repackaged and released as open source under the name of WebRTC.

Google is still the main vendor behind WebRTC. That’s because its own WebRTC engine is the main WebRTC open source project out there and it is also the one that gets integrated into the Chrome browser.

Mozilla, Microsoft and Apple all contribute to WebRTC and have their own implementations of WebRTC in their browsers (some of these implementations are derived from the Google code).

Other vendors and individuals contribute to the specification through the IETF and W3C, where the standardization process of WebRTC takes place.

My own contribution to WebRTC is this site, which publishes a lot of free information around WebRTC as well as the Kranky Geek event, WebRTC Index and WebRTC Glossary.

Is WebRTC ready for commercial use?

Yes.

WebRTC is used today by commercial services (here are 10 such examples).

Some complain and gripe that WebRTC isn’t ready for commercial use. This stems due to the many changes that the codebase and specification is undergoing. It also means that if you plan on using WebRTC, either do that through a third party managed service (a CPaaS vendor – list here) or make sure to have a team of savvy developers that can keep up with the pace.

The changes introduced to the WebRTC codebase itself oftentimes breaks backward compatibility and features, probably by sticking to a “move fast and break things” motto to some extent.

Why should I use WebRTC?

If you don’t need real time voice and video then you might not need to use WebRTC at all.

If you do, then it is a matter of capability, resources and time to market:

  • If you want your service to work inside a web browser, then WebRTC is your only way of getting real time voice and video into a browser
  • If you want it elsewhere, then in almost all cases, using WebRTC will cost you less and get you there faster than the alternatives
What codecs are used in WebRTC?

For voice, the mandatory codecs are G.711 and Opus. Out of these two, be sure to use Opus (G.711 is old and crappy).

For video, the mandatory codecs are VP8 and H.264. Apple’s Safari browser doesn’t support VP8. And on Android, Chrome won’t support H.264 on *some* devices (I’ll let you go figure out on which ones). More about that in this video mini-series.

VP9 is supported by Chrome and Firefox. AV1 seems to be the future.

What browsers support WebRTC?

All of them. Almost. But not exactly. And there are differences.

  • Chrome is where most developers focus. It isn’t 100% aligned with the specification yet (none of the browsers are)
  • Firefox is the next that gets focus from developers. Close enough to Chrome in its implementation
  • Edge doesn’t support data channels. And many skip it when it comes to testing due to is low market adoption
  • Safari is what everyone wants (Apple you know), but it is still buggy and doesn’t have support for VP8. Most need Safari support for iOS but are fine with not supporting Safari on Mac. Read this webrtcHacks post for more

There’s a devices cheat sheet on my website.

And then there’s adapter.js which you should definitely use.

Can I use WebRTC on mobile devices?

Yes.

On Android, on official Chrome and Firefox browsers, WebRTC is available.

On iOS, Safari offers something usable if you are willing to invest the energy to get it working well.

On both Android and iOS you can take the WebRTC source code and integrate it inside your native application. Google even releases prebuilt packages for both Android and iOS.

If you want to use a Webview inside your app, then this is easy with Android, restrictive with iOS for now (you won’t be able to access the camera or the microphone there).

Do I need special servers to run WebRTC?

Yes.

You definitely need a signaling server. And STUN/TURN server. You might need a media server.

WebRTC is said to be peer-to-peer. It is when it comes to the media as much as possible. But developers can make use of it in server centric environments. And there are some scenarios where it makes no technical sense to use peer-to-peer (for example if you want to broadcast something to a million people or conduct a video conference with 20 participants).

There’s a free video mini series explaining WebRTC servers on this site.

Can WebRTC be used to create large conferences?

Yap.

Think of WebRTC as a basic building block that gives you superpowers. With it you have the ability to send and receive voice and video in real time virtually on every device and browser.

Now what you do with this superpower, how you interact with it, architect your solution around it – that’s up to you.

There are vendors offering video conferencing that uses WebRTC and gets to 10’s of participants. Webinars with 100’s of live viewers in the audience.

You can read more about scale and size of WebRTC.

Is WebRTC posing a security threat for me?

No.

And yes.

Depending who you are and what are your needs.

I wrote a lot about WebRTC security in the past. It gets tiring.

WebRTC comes with security in mind. It encrypts everything. Can’t remove that encryption. And browsers get security updates faster than any other software you have.

The one sticking issue is probably the fact that it exposes the local IP address of your machine when it is used. VPNs that are implemented properly solve that as well. More about that over at webrtcHacks and VPN leaks.

What does WebRTC 1.0 mean?

WebRTC 1.0 is the first time that WebRTC will have an official specification.

Up until now, we had drafts and browser implementations that were an approximation of the drafts. Now we have an approximation of the WebRTC 1.0 specification and approximations of implementations to it in browsers.

Confused?

Don’t be. Assume WebRTC is good to go commercially (check that part of my FAQ) and just go read Jan-Ivar’s explanation @ Mozilla’s Advancing WebRTC blog.

Oh – and be sure to use adapter.js.

How much does WebRTC cost?

It doesn’t. And it does.

WebRTC is freely available in browsers.

The source code is also freely available.

The servers you will need to use it – someone will need to pay for them. That payment can be to a managed service, or to a cloud vendors and developers who will develop, install and maintain them. Up to you to decide.

Oftentimes, developers assume everything should be free with WebRTC, whereas reality is different. And for some reason, most perceive development  costs as free or sunk costs (they will call it investment) as opposed to paying a third party for doing the hard stuff for you.

A bit more on this here.

How can I learn more about WebRTC?

If you are into free, then try reading the specs, playing with the official samples, reading this blog and webrtcHacks.

There are a few courses on coursera, pluralsight and elsewhere. Never tried them, but read their agendas. Take a look for yourself and decide what’s for you.

There are books, but none of them is up to date with the specification.

Best place? Hands down? My paid course. Advanced WebRTC Architecture Course

Can I help you?

Maybe.

There’s my course. There’s testRTC where I am a co-founder (we do testing and monitoring of WebRTC apps).

I also consult. Around architecture, vendor selection, defining requirements, setting roadmaps, working on differentiation and doing pure marketing related work. What can I say?

I like the variety.

You can reach out to me here.

Got a question about WebRTC that needs to go into this FAQ? Add it below in the comments.

The post WebRTC FAQ: The 2018 Version appeared first on BlogGeek.me.

Social Messaging != Carrier Messaging (the stories of Whatsapp Business API & Apple Business Chat)

bloggeek - Thu, 09/13/2018 - 12:00

Social messaging is killing RCS in all the places that matter.

When looking at messaging in the context of communications and people, we can probably split the story into 3 distinct models:

  1. Consumer centric
  2. Business centric
  3. Businesses to consumers (and vice versa)

I’ll quickly sift through the first two and focus on the third.

Consumer Centric

Consumer centric is easy. That’s where Apple iMessage, WhatsApp, Facebook Messenger, Telegram, WeChat and a bunch of others are competing. The approach there today is to deliver a rich messaging experience that includes text, images, video, voice and video calling, location, groups, … – the list goes on. And on. And on.

They have won the war against SMS. We still have SMS. Some mistakenly call it ubiquitous (on my phone it is used for spam and 2FA messages only). They won the war against RCS that never really started.

To give you a clue – Israel is a WhatsApp country. If you don’t have WhatsApp you don’t exist. It is true from the age of 8. I just purchased the first smartphone for my 8 year old boy. Not so he can play or call with the phone – just so he can send messages to his classmates and stay part of the social fabric of his class. It happened to my daughter when she reached that age. I am now a part of multiple WhatsApp groups: family, close friends, parents of my kids’ classes and after classes, work related, etc.

How easy would it be to move people in Israel from entrenched groups that hold history, images and videos? And to what end? How would RCS be any better in its experience?

Business Centric

Business centric is Slack. It used to be all about calling and the PBX. Slack changed the game. Everyone is talking about “team messaging” today. I used the term enterprise messaging years ago.

What Slack did was find a good balance between functionality and user experience that no other player has been able to copy properly so far, but everyone is after.

WhatsApp is unlikely to penetrate businesses in a meaningful way. Facebook built Workplace instead of trying to introduce Facebook or Messenger directly.

Where’s SMS in this orgy of messaging? Meaningful conversations happen in IP messaging services and not over SMS anymore. Some solutions, like VonageFlow offer a seamless experience that encompasses both messaging as we know it today and SMS, though I’d argue that capability is a business to consumer one.

For all intent and purpose, SMS is non-existent when it comes to business centric messaging.

Business to Consumer

Back to RCS. RCS was supposed to be the future of SMS when we all move to IP based packet networks. Guess what? We’re all on IP based packet networks, and RCS isn’t really here yet in any meaningful way.

In the past couple of years, RCS got a new tune by its proponents. The strategy changed from getting consumers back from social networks towards being the one ubiquitous network – the ring to rule them all. Here’s the idea: you get RCS on all smartphones worldwide. Now carriers have the ubiquity they had with SMS. And businesses would pay for such access to customer’s phones.

Not going to happen.

Why? Because Apple and Facebook have other plans for us.

Apple now has Apple Business Chat. It is built into the iPhone, making businesses discoverable and reachable over iMessage from the Safari browser, Spotlight search, Siri assistant and Apple Maps. I’ve written extensively about it when it was introduced on SearchUC: Apple Business Chat looks to polish customer messaging

WhatsApp came out with their own offering called WhatsApp Business API. Similarly to Apple Business Chat, it offers the ability for businesses to communicate with consumers. Apple does that by focusing on contact center vendors while Whatsapp partners with CPaaS vendors. The goal? Get higher exposure and not working directly with longtail developers in the initial release.

What drove me to even start writing this article? This title of a TechCrunch post: Wish, Netflix, Uber and ~100 others testing WhatsApp’s new Business API

Businesses aren’t waiting for RCS. They are trying to figure out how to communicate with their customers via WhatsApp.

They had Line, WeChat, Facebook Messenger. And they’re still aiming for WhatsApp – a messaging service that isn’t even a US-thing.

Which brings me to the main thing – business to consumer is now a social messaging realm. Carriers have lost that domain as well.

1 Billion Defines the Moat

Remember ubiquity? Here’s what it takes to be interesting:

1 Billion Monthly Active Users

Who has that number today?

Facebook (WhatsApp + Messenger), Apple Business Chat and WeChat. WhatsApp being the biggest one are redefining this market. You hear a lot about how customers still phone businesses and chat isn’t catching up with contact centers. That might be true, but only partially.

Today’s chat solutions usually require being on the company’s website. SMS hasn’t proven itself in a large scale for anything other than notifications to customers on orders and transactions. Whatsapp can change that – and to that extent, any of the other 1B+ MAU social messaging apps.

RCS? With what billion users exactly?

With the large social networks, a 100 million monthly active users seem like a rounding error.

Focus is on Customer Care – Not Marketing

Another interesting aspect (and difference) is that social networks are keeping user identity and access close to their chest. While WhatsApp is using phone numbers for identity, piggybacking on carriers in a way, they are not allowing anyone access to a user without the user’s permission. This means:

  1. Businesses can’t “spam” users by sending them unsolicited messages just because they know their phone number or user name
  2. A user must first approach the business. Inbound use cases are the focus here, which lends itself nicely to support and purchasing activities
  3. Outbound marketing campaigns, ads, promotions – these aren’t something that are encouraged at the moment

What these networks are trying to do is to get businesses and consumers off their SMS communications and shift it to their network. To do so, they plan on offering a superior experience. They are doing that not only by adding richness over the limited 160 character experience of SMS, but they are also making sure this will be a useful service to their user base and won’t be considered spammy.

Will there be other avenues opened to businesses on social networks to interact with users through marketing campaigns and outbound messaging? Sure. But it isn’t the first priority. The market needs to be created first.

Where Can We Go Next?

We are headed towards an omnichannel interaction model.

To me that means that a business will meet a customer wherever it is comfortable for the customer in the context of that specific interaction.

A customer may prefer a phone call at one interaction, but a chat over WhatsApp on another.

The challenge here is that different customers may prefer different social networks. Or aren’t even approachable on some of the social networks. This isn’t going to change any time soon either. The number of social networks is still growing, and while we have a few huge players, others are important to specific populations.

Businesses will need to rely on multiple such channels if they want to reach out to a larger target audience of potential customers.

Back to RCS

It is coming. In some carriers. On some devices. In some form.

Is it going to take back ownership of the interactions from social networks? No.

What it can be, is just another channel. Right next to the rest. It will only become important if it can make that 1 billion monthly active users mark.

Oh, and it will need to succumb to the rules of engagement laid out by social networks today, around business-to-user permissions.

The post Social Messaging != Carrier Messaging (the stories of Whatsapp Business API & Apple Business Chat) appeared first on BlogGeek.me.

Guide to WebRTC with Safari in the Wild (Chad Phillips)

webrtchacks - Fri, 09/07/2018 - 13:55

I has been more than a year since Apple first added WebRTC support to Safari. My original post reviewing the implementation continues to be popular here, but it does not reflect some of the updates since the first limited release. More importantly, given its differences and limitations, many questions still remained on how to best develop WebRTC applications for Safari.

I ran into Chad Phillips at Cluecon (again) this year and we ended up talking about his arduous experience making WebRTC work on Safari.

Continue reading Guide to WebRTC with Safari in the Wild (Chad Phillips) at webrtcHacks.

New Developer: Tsvetomir Dimitrov

miconda - Thu, 09/06/2018 - 10:03
The warm welcome note for Tsvetomir Dimitrov joining the Kamailio Developers Team, who recently contributed the ims_ipsec_pcscf module. In the past, he submitted fixes and improvements to the code for other existing modules related to IMS/VoLTE and SMS operations.We are glad to have the team expanded and we are looking forward to more contributions from Tsvetomir!Thanks for flying Kamailio!

The CPaaS Version of iPaaS: MessageBird & Plivo Join the Twilio Studio Bandwagon

bloggeek - Tue, 09/04/2018 - 12:00

Visual design tools in CPaaS are now a part of the offering.

In October 2017, almost a year ago, Twilio announced Studio. I wrote at the time a lengthy article about my thoughts on Twilio Studio and CPaaS. My closing paragraph then was this one:

It will be interesting to see how competitors would react to this in the long run, and even more interesting to see what will Twilio Studio grow into.

Then in January 2018, I wrote about the 7 CPaaS Trends to Follow in 2018. The ones I zeroed in on:

  1. Serverless – a few more CPaaS vendors now offer serverless
  2. Omnichannel – more about that in one of my next articles
  3. Visual/IDE – guess why I wrote this article?
  4. Machine learning and Artificial Intelligence – Got a whole new report covering AI in RTC if you are interested
  5. AR/VR – planning to write about this one a bit later
  6. Bots – they’re already everywhere, directly linked to both omnichannel and AI
  7. GDPR – everyone covers that now in CPaaS

Not sure which CPaaS vendor to use? Check out my free CPaaS Vendor Selection Matrix. It will give you the KPIs to look for.

Download the CPaaS Vendor Selection Matrix

Guess what happened since with Visual/IDE?

Messagebird introduced Flow Builder: “The power of our Voice and SMS solutions at your fingertips, without writing a single line of code.”

Plivo announced PHLO on August: “A whole new visual way of integrating communications that would empower developers to design collaboratively, build visually and deploy instantly.”

 

Voximplant came out with Smartcalls: “a smart and flexible tool that helps you create outbound call campaigns in no time”

All of these CPaaS players invested into a Twilio Studio-like tool.

Let’s check out what each player did and why.

Twilio Studio

Where it all started (even if there were tools before or in parallel to it).

Studio’s entry point is either an incoming message, an incoming call or a REST API call. From there, the actions include things you do with messages and phone calls, along with the ability to execute generic functions.

A nice touch to Studio is its revision control system – it saves past changes made to the flows you built, allowing switching back and forth between revisions. It would be nice to have named revisions, some automated verbose explanation of changes made, etc.

Messagebird Flow Builder

Messagebird Flow Builder is focused around SMS. The inputs you can use for it are either an incoming SMS or an incoming webhook API call. Once in the “flow”, you can branch the flow based on the time and date or other conditions related to the contents of the message. The end result? An outgoing SMS, email or webhook. There’s a bit more to it than that, like the ability to manage subscriptions in Messagebird or wait for certain replies inside the flow.

What I like about the Messagebird Flow Builder is that it is rigid in how it outlines the boxes and their connections – it doesn’t let you move boxes around (a cool feature that got tiresome rather quickly on me in other tools here – Studio and PHLO).

Plivo PHLO

Plivo PHLO is a me-too Twilio Studio tool.

It has the same entry points, node types and capabilities, assuming you’re interested in SMS and voice calls that is. Where Twilio Studio offers more generic “Messages”, Plivo has only SMS. This is probably fine for most users.

The only thing I couldn’t find in PHLO is the ability to execute an arbitrary JS function. There’s also no revision control as of yet. Other than that, PHLO is a rather straightforward too to use.

Voximplant Smartcalls

The Voximplant Smartcalls service is different in nature. Where the rest of the pack here is focused on incoming events that trigger action, Smatcalls is all about campaigns. And all about voice.

You can create a scenario. Scenarios in Smartcalls is a visual decision tree of what to do with an outgoing call. You dial, someone answers, you play a specific recording, maybe ask them to click on digits, etc.

You can do things like send email or call a REST webhook, but the purpose of it all is to drive an automated outbound voice campaign: once you have a scenario, you create a campaign. A campaign is a time window, a scenario and a list of phone numbers to dial out to. Smartcalls does the rest to automate the scenario created across all phone numbers at the specified time window.

On Pricing

Here things get somewhat murkier.

Do you pay for using the designer tool itself when it gets invoked? (you do with Twilio Studio)

Do you need to pay for the communications used within the flows created? (you don’t with Voximplant Smartcals).

Plivo, being the shadow of Twilio for voice and SMS, decided not to price the use of PHLO at all, and make that an important part of their announcement as well:

“That’s why, in addition to bringing in 100% Plivo-API support out-of-the-box, we are also making it FREE to build using PHLO. This is not just a commercial decision. This is our stake in the ground — as we truly believe this is how the communication capabilities of the future will be built.”

Here’s the visual from the product page:

Will this create pressure on Twilio? I doubt it, but who am I to say?

A Comparison Table

I put these tools in a table, to see where each one is focused:

 

Twilio Studio Messagebird Flow Builder Plivo PHLO Voximplant Smartcalls Focus Inbound Inbound Inbound Outbound Medium Voice, SMS, Omnichannel messages SMS Voice, SMS Voice Cool factor Revision control Really easy to use Campaign management Flow pricing Per flow invoked Free Free Per minute charges Communications pricing Not included Not included Not included Included A Word about iPaaS

Maybe a few paragraphs…

iPaaS stands for Integration Platform as a Service. The poster child service here is probably Zapier, allowing the connectivity of one service to another. I use it daily in my own business to power many of the integrations on this website.

Many of the CPaaS players have been working on enabling their use via Zapier, so a user doesn’t need to be a developer to send a message for example. Being able to build more complex communication flows using a visual builder sits well with this approach.

What will be interesting to see is how the two play out with each other, if at all. Will these visual builders get integrated into Zapier? Will these visual builders include easier integration points to other services besides what they themselves offer and a rudimentary capability of invoking a REST call?

Welcome to Visual CPaaS

CPaaS is more than making communication API calls or offering github repositories. In the past two years we’ve seen some interesting movements in this space and innovations coming out.

I can’t wait to see what will come next.

Not sure which CPaaS vendor to use? Check out my free CPaaS Vendor Selection Matrix. It will give you the KPIs to look for.

Download the CPaaS Vendor Selection Matrix

The post The CPaaS Version of iPaaS: MessageBird & Plivo Join the Twilio Studio Bandwagon appeared first on BlogGeek.me.

VR Video Calling with WebRTC and WebVR (Dan Jenkins)

webrtchacks - Tue, 08/28/2018 - 03:31

WebRTC isn’t the only cool media API on the Web Platform. The Web Virtual Reality (WebVR) spec was introduced a few years ago to bring support for virtual reality devices in a web browser. It has since been migrated to the newer WebXR Device API Specification.

I was at ClueCon earlier this summer where Dan Jenkins gave a talk showing that it is relatively easy to add a WebRTC video conference streams into a virtual reality environment using WebVR using FreeSWITCH.

Continue reading VR Video Calling with WebRTC and WebVR (Dan Jenkins) at webrtcHacks.

New Module: IMS IPSEC PCSCF

miconda - Fri, 08/24/2018 - 10:01
A new module has been contributed recently by Tsvetomir Dimitrov extending Kamailio capabilities on IMS and VoLTE.The module is named ims_ipsec_pcscf and contains the methods for IPSec initialisation and deinitialisation needed for using Kamailio as a Proxy-CSCF. The documentation of the module is available at:Enjoy!Thanks for flying Kamailio!

Pages

Subscribe to OpenTelecom.IT aggregator

Using the greatness of Parallax

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

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

Get free trial

Wow, this most certainly is a great a theme.

John Smith
Company name

Yet more available pages

Responsive grid

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

More »

Typography

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

More »

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