News from Industry

A new module has been imported in Kamailio’s git repository, respectively app_ruby. It allows embedded execution of Ruby scripts, either inline inside a native kamailio.cfg or as a KEMI routing logic.The readme of the module is available at:

• https://www.kamailio.org/docs/modules/devel/modules/app_ruby.html

The idea of the module was suggested during Kamailio World Conference 2018, couple of attendees mentioning that they are mainly Ruby developers and KEMI framework didn’t support it. With some hints given by some of them, it proved that developing such module was not that complex. It is still in early stage, but testing can be done and feedback is very appreciated.The KEMI exported functions by the core and all the other modules are already available, some work needs to be done for KSR.x submodule, which is going to be exported by app_ruby itself.Now the list of scripting languages supported by the KEMI framework are: Lua, JavaScript, Python (v2 and v3), Ruby and Squirrel.Enjoy! Thanks for flying Kamailio!

Shortly after the end of the 6th edition of Kamailio World Conference (May 14-16, 2018, in Berlin, Germany), the video recordings of the sessions were published on KamailioWorld Channel on Youtube:

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

The channel is a valuable knowledge base, only from Kamailio World 2018 there are over 35 recorded sessions, approaching topics such as IMS/VoLTE, emergency services, use of Kamailio with Redis, SIP routing scripting with KEMI (Lua, Python, JavaScript, …), least cost routing engine, deployments and continuous integration with Docker, integration with other systems such as Asterisk, FreeSwitch, CGRateS or SipCapture. All these add to the videos from the past Kamailio World editions.If you haven’t followed the channel, you should do it and watch the videos on topics of interest for you, there are many tips and hints shared by developers and experienced users of Kamailio.Enjoy!Thanks for flying Kamailio!

Building an interactive application? There’s more than one WebRTC programming language that can fit your needs.

Last time I’ve written about WebRTC programming languages it was some two years ago. My focus then was how programming languages fit to different WebRTC components. That article is still relevant, so I suggest you read it as well.

This time, I want to focus on something slightly different. In recent months I’ve had the pleasure of watching as well as consulting teams of developers who are using programming languages that don’t always make sense to me when it comes to WebRTC. And yet, once they explained their reasoning, the decision and path they took would be one I couldn’t just dismiss if I were in their shoes.

Instead of doing this one by component, lets do it by language:

JavaScript

When it comes to languages, JavaScript is probably the most popular one these days. Don’t just take my word for it – look at Stack Overflow’s annual survey:

JavaScript is a winner with a huge margin on any other technology. It is also what you need if you are planning to make use of WebRTC in the browser.

There are two main places where you see JaveScript in WebRTC apps today: client side as well as signaling server.

Clients

Client side is simple enough. It is due to the fact that this is how you use WebRTC in browsers, but it can also be seen in cross platform mobile development (though not that much) or when using Electron for WebRTC.

Signaling

Signaling servers is about Node.js. And yes, the guest article from 2013 (!) is as relevant now as it was then. Twelephone (mentioned in that article) is long dead, and Chris has moved on to IOT and later decentralized networks. But the use of Node.js as a signaling server for WebRTC is going strong. If you take that route, just make sure to pick a popular framework.

Media Servers

I’ve seen Node.js being used in media servers as well:

• mediasoup for example, is an open source SFU that was built as a Node.js module to fit into a larger application
• SwitchRTC, a commercial SFU that got acquired by YouNow, was a combination of C/C++ and Node.js
• appear.in’s SFU (available for their PRO accounts) was built using Node.js

C/C++

I’ll be using C and C++ together here, as I don’t see a huge distinction between the two (and in most cases, those that develop code in C create C++ abstractions, and those developing in C++ end up writing C code anyways).

C/C++ is a kind of a lowest common denominator. My guess is that a lot of the languages here have their compilers/interpreters written in C/C++ anyways. It is also a language that is available everywhere, though not always accessible directly.

Clients

Go to webrtc.org and you’ll find out that the code WebRTC that Google open sourced is written in C++. The easiest thing to do if you want to support WebRTC on an embedded device is probably to start by taking that code and hammering it until it fits your device.

It isn’t the only way to get WebRTC into a device but it sure is a popular one.

Signaling

Signaling with C++ isn’t common. Where you will find it is when SIP meets WebRTC.

Interestingly, all main open source SIP servers are written in C/C++: Asterisk, OpenSIPS and FreeSWITCH.

I am assuming this is because they are older than other WebRTC signaling implementations that tend to use higher languages.

STUN/TURN

NAT traversal servers are written today in C/C++.

Not all of them. But the most popular one is (coturn).

Media Servers

Media servers need to be highly performant, which is why most of them also end up being written in C/C++ – at least the parts that matter for performance.

• Janus, a popular media server is written in C
• SwitchRTC mentioned in relation to Node.js has a C++ component to it handling all media networking
• Kurento’s core is written in C/C++
• CPaaS vendors are using C/C++ in their media servers – at least those that I know the programming languages that they use

Java

Java is the most popular language based on the TIOBE index.

I don’t like Java that much, probably due to its verbosity and all the pain that its garbage collection causes to real time apps. But I don’t get to decide what others use

Java is probably one of the most popular programming languages also in WebRTC backend development, but not only there.

Clients

Android requires Java, which means Android native development with WebRTC also requires Java coding.

Besides this obvious option, there’s also the part of writing WebRTC clients in Java from scratch.

While you won’t find any open source Java client for WebRTC, I know of two separate WebRTC client implementations that use Java.

Signaling

There are many signaling servers out there that end up using Java when it comes to WebRTC. You’ll find it in enterprise software but not only.

A few of them are also open sourced, though there isn’t a specific one that is widely popular or highly recommended as far as I can tell.

Media Servers

Several of the media servers out there use Java. Either for everything or for the higher level abstractions.

Here are two of them:

• Jitsi is written in Java
• OpenVidu, an SFU implemented on top of Kurento by the Kurento maintainers is written in Java

Swift

If Java is needed for development of WebRTC in Android, then Swift is what you need for iOS.

Unless you’re fine with using Objective-C and not adopt Swift.

Other than iOS, I haven’t seen Swift used anywhere else when it comes to WebRTC implementations (or otherwise for that matter).

Python

As a higher level language, Python gets high marks. I’ve been introduced to it about a decade ago and loved it since, though I can’t say I used it too much myself.

When it comes to WebRTC, Python has its role in signaling servers, as many other higher level languages.

The most notable Python project related to WebRTC is [matrix]. Its open source Synapse server implementation is written in Python.

There are others using Python for their signaling. My guess is that this is just because of familiarity with the language.

Ruby

You can’t mention Python without mentioning Ruby.

I am guessing that Ruby can fit in signaling servers just as well as Python. Only difference is that I know of no one that is doing that.

C#

If someone is making use of a Windows based development stack, he is more likely to use C# than anything else.

In such cases, you will see the use of C# for all aspects of WebRTC – from native WebRTC client implementations, through signaling, to NAT traversal and media servers.

I am not a big fan of backend development on Windows, but if you are one of those who need it, then know you are not alone.

PHP

Yes. PHP.

PHP has gotten a bad rep when it comes to programming languages. It sits well with the fact that over 80% of all the websites use PHP:

Having such huge market share means more haters, especially when the language itself isn’t the most modern one out there.

What surprised me (it shouldn’t, but it did), was that there are companies who use PHP for their signaling server when it comes to WebRTC. I would never have thought that would be the case, but it is.

If you want to use PHP for your signaling server, then go for it. Just make sure you understand the limitations and implications of it.

Erlang

We’re getting into the more exotic alternatives.

Erlang is such a programming language to me. Created by Ericsson and open sourced ages ago, Erlang offers some interesting capabilities (go read Wikipedia).

There are a few projects out there that make use of Erlang for signaling and one for NAT traversal. I am not aware of anyone using Erlang in a production service, though I am sure there is.

Elixir

Elixir is built on top of Erlang (or at least on its virtual machine).

Only one I know who makes use of it for WebRTC is Slack.

In last year’s Kranky Geek event, Slack shared their plans of migrating from their Janus implementation to an in-house developed Elixir media server. You can watch that here:

Go

Go is a programming language created by Google. It is somewhere between C and C++ as much as I can tell (never been an expert in Go).

This one came to my attention with the recent implementation of STUN/TURN in Go – Pion TURN.

Not sure how popular is Go with WebRTC developers.

Where do these languages fit?

I tried taking the information above and placing it in an easy to use table, to give a quick summary of the state of WebRTC programming languages.

• Green indicates a popular choice
• Orange indicates an alternative that I’ve seen being used in the wild (or in production)
• Gray is something I haven’t seen used at all

Which language should you use?

I am sure I missed a language or two. And I am also sure some people are using WebRTC programing languages differently than I’ve described here. Feel free to share in the comments for this article or by emailing me about it – I’d love to learn more.

What programming language should you use?

That’s a different question. I’d say it depends on several factors:

• What is it you are implementing and for which devices?
• What do your current developers know and are comfortable with?
• What is your operational envelope for the service?
• Are there any popular open source or commercial products for WebRTC in that language?
• How easy will it be to find experienced developers for that language? How about developers who know both this language and WebRTC?

The post WebRTC Programming Languages and Where they fit appeared first on BlogGeek.me.

There will be a short maintenance timeframe for kamailio.org server schedule for later today, May 25, 2018, at 18:00 CEST (16:00 GMT). The website, including the wiki, as well as the mailing lists are going to be affected.The maintenance is expected to take no longer than 5 minutes.

Google in 2018 is all about AI. But not only…

In November 2015, Google released TensorFlow, an open source machine learning framework. While we’ve had machine learning before that – at Google and elsewhere, this probably marks the date when machine learning and as an extension AI got its current spurt of growth.

Some time, between that day and the recent Google I/O event, Sundar Pichai, CEO of Google, probably brought his management team, knocked on the table and told them: “We are now an AI company. I don’t care what it is that you are doing, come back next week and make sure you show me a roadmap of your product that has AI in it.”

I don’t know if that meeting happened in such a form or another, but I’d bet that’s what have been going at Google for over a year now, culminating at Google I/O 2018.

After the obligatory icebreaker about the burger emoji crisis, Pichai immediately went to the heart of the keynote – AI.

Google announced AI at last year’s Google I/O event, and it was time to show what came out of it a year later. Throughout the 106 minutes keynote, AI was mentioned time and time again.

That said, there was more to that Google I/O 2018 keynote than just AI.

Google touched at its keynote 3 main themes:

1. AI
2. Wellbeing
3. Fake news

I’d like to expand on each of these, as well as discuss parts of Smart Displays, Android P and Google Maps pieces of the keynote.

I’ll try in each section to highlight my own understanding and insights.

Before we begin

Many of the features announced are not released yet. Most of them will be available only closer to the end of the year.

Google’s goal was to show its AI power versus its competition more than anything else they wanted to share in this I/O event.

This is telling in a few ways:

1. Google weren’t ready with real product announcements for I/O that were interesting enough to fill 100 minutes of content. Or more accurately, they were more interested in showing off the upcoming AI stuff NOW and not wait for next year or release it later
2. Google either knows its competitors are aware of all the progress it is making, or doesn’t care if they know in advance. They are comfortable enough in their dominance in AI to announce work-in-progress as they feel the technology gap is wide enough

AI

When it comes to AI, Google is most probably the undisputed king today. Runners up include Amazon, Microsoft, IBM, Apple and Facebook (probably at that order, though I am not sure about that part).

If I try to put into a diagram the shift that is happening in the industry, it is probably this one:

Not many companies can claim AI. I’ll be using ML (Machine Learning) and AI (Artificial Intelligence) interchangeably throughout the rest of this article. I leave it to you to decide which of the two I mean

AI was featured in 5 different ways during the keynote:

1. Feature enhancer
2. Google Assistant (=voice/speech)
3. Google Lens (=vision)
4. HWaaS

Feature Enhancer

In each and every single thing that Google does today, there’s an attention to how AI can improve that thing that needs doing. During the keynote, AI related features in GMail, Google Photos and Android were announced.

It started off with four warm-up feel-good type use cases that weren’t exactly product announcements, but were setting the stage on how positive this AI theme is:

• Diagnosing diseases by analyzing human retina images in healthcare
• Predicting probability of rehospitalization of a patient in the next 24 hours
• Producing speaker based transcription by “watching” a video’s content
• Predictive morse typing for accessibility

From here on, most sections of the keynote had an AI theme to them.

Moving forward, product managers should think hard and long about what AI related capabilities and requirements do they need to add to the features of their products.What are you adding to your product that is making it SMARTER?

Google Assistant (=voice and speech)

Google Assistant took center stage at I/O 2018. This is how Google shines and differentiates itself from its main 3 competitors: Apple, Amazon and Facebook.

In March, Forbes broke some interesting news: at the time, Amazon was hiring more developers for Alexa than Google was hiring altogether. Alexa is Amazon’s successful voice assistant. And while Google hasn’t talked about Google Home, its main competitor at all, it did emphasize its technology differentiation. This emphasis at I/O was important not only for Google’s customers but also for its potential future workforce. AI developers are super hard to come by these days. Expertise is scarce and competition between companies on talent is fierce. Google needs to make itself attractive for such developers, and showing it is ahead of competition helps greatly here.

Google Assistant got some major upgrades this time around:

1. WaveNet. Google now offers an improved text to speech engine that makes its speech generator feel more natural. This means:
   1. To get new “voices” now requires Google to have less samples of a person speaking
   2. Which allowed it to introduce 6 new voices to its Assistant (at a lower effort and cost)
   3. To make a point of it, they started working with John Legend to get his voice to Assistant – his time is more expensive, and his voice “brand” is important to him, so letting Google use it shows his endorsement to Google’s text-to-speech technology
   4. This is the first step towards the ability to mimic the user’s own voice. More on that later, when I get to Google Duplex
2. Additional languages and countries. Google promised support for 30 languages and 80 countries for Assistant by year end
3. Naturally Conversational. Google’s speech to text engine now understand subtleties in conversations based not only on what is said but also how it is said, taking into account pitch, pace and pauses when people speak to it
4. Continued conversation. “Hey Google”. I don’t need to say these action words anymore when engaging in a back and forth conversation with you. And you maintain context between the questions I ask
5. Multiple actions. You can now ask the assistant to do multiple things at once. The assistant will now parse them properly

Besides these additions, where each can be seen as a huge step forward on its own right, Google came out with a demo of Google Duplex, something that is best explained with an audio recording straight from the keynote:

If you haven’t watched anything from the keynote, be sure to watch this short 4 minutes video clip.

There are a few things here that are interesting:

• This isn’t a general purpose “chatbot”/AI. It won’t pass a turing test. It won’t do anything but handling appointments
• And yet. It is better than anything we’ve seen before in doing this specific task
• It does that so naturally, that people can’t distinguish it from a real person, at least not easily
• It is also only a demo. There’s no release date to it. It stays in the domain of “we’ve got the best AI and we’re so sure of it that we don’t care of telling our competitors about it”
• People were interested in the ethical parts of it, which caused Google to backtrack somewhat later and indicate Duplex will announce itself as such at the beginning of an interaction
  • Since we’re still in concept stage, I don’t see the problem
  • I wouldn’t say google were unethical – their main plan on this one was to: 1. Show supremacy; 2. Get feedback
  • Now they got feedback and are acting based on it
• Duplex takes WaveNet to the next level, adding vocal queues to make the chatbot sound more natural when in a conversation. The result is uncanny, and you can see by the laughs of the crowds at I/O
• Duplex is a reversal of the contact center paradigm
  • Contact center software, chatbots, ML and AI are all designed to get a business better talk with its customers. Usually through context and automation
  • Duplex is all about getting a person to better talk to businesses. First use case is scheduling, but if it succeeds, it won’t be limited to that
  • What’s there to stop Google from reversing it back and putting this at the hands of the small businesses, allowing them to field calls of customers more efficiently?
  • And what happens once you put Duplex in both ends of the call? An AI assistant for a user trying to schedule an appointment with an AI assistant of a business
• When this thing goes to market, Google will have access to many more calls, which will end up improving their own services:
  • An improvement to the accuracy and scenarios Duplex will be relevant for
  • Ability to dynamically modify information based on the content of these calls (it showed an example of how it does that for opening hours on Google Maps during the keynote)
  • Can Google sell back a service to businesses for insights about their contact centers based on people’s requests and the answers they get? Maybe even offer a unique workforce optimization tool that no one else can
• I’d LOVE to see cases where Duplex boches these calls in Google’s field trials. Should be hilarious

You’d like to read what Chad Hart has to write about Duplex as well.

For me, Duplex and Assistant are paving the way to where we are headed with voice assistants, chatbots and AI. Siri, Cortana and Lex seem like laggards here. It will interesting to see how they respond to these advancements.

Current advancements in speech recognition and understanding make it easier than ever to adopt these capabilities into your own products.If you plan on doing anything conversational in nature, look first at the cloud vendors and what they offer. As this topic is wide, no single vendor covers all use cases and capabilities.

While at it, make sure you have access to a data set to be able to train your models when the time comes.

Google Lens (=vision)

Where Google Assistant is all (or mostly) about voice, Google Lens is all about vision.

Google Lens is progressing in its classification capabilities. Google announced the following:

• Lens now recognizes and understands words it “sees”, allowing use cases where you can copy+paste text from a photo – definitely a cool trick
• Lens now handles style matching for clothing, able of bringing suggestions of similar styles
• Lens offers points of interest and real time results by offering on-device ML, coupled with cloud ML

That last one is interesting, and it is where Google has taken the same approach as Amazon did with DeepLens, one that should be rather obvious based on the requirements here:

1. You collect and train datasets in the cloud
2. You run the classification itself on the edge device – or in the cloud

It took it a step further, offering it also programmatically through ML Kit – Google’s answer to Apple’s Core ML and Amazon’s SageMaker.

Here’s a table summarizing the differences between these three offerings:

Google Apple Amazon ML Framework TensorFlow Core ML + converters MXNet & TensorFlow Cloud component Google Firebase none AWS SageMaker Edge component ML Kit Core ML AWS DeepLens Edge device types Android & iOS iOS DeepLens Base use cases

• Image labeling

• Text recognition
• Face detection
• Barcode scanning
• Landmark detection
• Smart reply

Handpicked samples from open source repositories Samples:

• Object detection
• Hot dog not hot dog
• Cat and dog
• Artistic style transfer
• Activity recognition
• Face detection

Proprietary parts Cloud TPUs and productized use cases iOS only AWS ecosystem only Open parts Devices supported Machine learning frameworks Machine learning frameworks

 

Apple Core ML is a machine learning SDK available and optimized for iOS devices by Apple. You feed it with your trained model to it, and it runs on the device.

• It is optimized for iOS and exists nowhere else
• It has converters to all popular machine learning frameworks out there
• It comes with samples from across the internet, pre-converted to Core ML for developers to play with
• It requires the developers to figure out the whole cloud backend on their own

 

AWS DeepLens is the first ML enabled Amazon device. It is built on top of Amazon’s Rekognition and SageMaker cloud offerings.

• It is a specific device that has ML capabilities in it
• It connects to the AWS cloud backend along with its ML capabilities
• It is open to whatever AWS has to offer, but focused on the AWS ecosystem
• It comes with several baked samples for developers to use

 

Google ML Kit is Google’s machine learning solution for mobile devices, and has now launched in beta.

• It runs on both iOS and Android
• It makes use of TensorFlow Lite for the device side and on TensorFlow on the backend
• It is tied into Google Firebase to rely on Google’s cloud for all backend ML requirements
• It comes with real productized use cases and not only samples
• It runs its models both on the device and in the cloud

This started as Google Lens and escalated to an ML Kit explanation.

Need to run ML? You need to think where training the model occurs and where classification takes place. These seem to be split these days between cloud and devices. In many cases, developers are pushing the classification algorithms towards the devices at the edge to gain speed and reduce costs and load on the backend. HWaaS

With everything moving towards the cloud, so does hardware in some sense. While the cloud started from hardware hosting of virtualized Linux machines, we’ve been seeing a migration towards different types of hardware recently:

We’re shifting from general purpose computing done by CPUs towards specialized hardware that fits specific workloads in the form of FPAG.

The FPGA in the illustration above is Google’s TPU. TPU stands for TensorFlow Processing Unit. These are FPGAs that have been designed and optimized to handle the TensorFlow mathematical functions.

TensorFlow is said to be slow on CPUs and GPUs compared to other alternatives, and somehow Google is using it to its advantage:

• It open sourced TensorFlow, making it the most popular machine learning framework out there in a span of less than 3 years
• It is now in its third generation of TPUs on Google Cloud for those who need to train large datasets quickly
• TPUs are out of the reach of Amazon and other cloud providers. It is proprietary hardware designed, hosted and managed by Google, so any performance gains coming from it are left at the hands of Google for its customers to enjoy

Google’s TPUs got their fair share of time at the keynote in the beginning and were stitched throughout the keynote at strategic points:

• Google Lens uses TPUs to offer the real time capabilities that it does
• Waymo makes use of these TPUs to get to autonomous cars

Pichai even spent time boasting large terms like liquid cooling…

It is a miracle that these TPUs aren’t plastered all over the ML Kit landing page.

Going with TensorFlow? You’ll need to decide on the cloud platform you are going to use, especially when it comes to dataset processing and training. Google is working hard to differentiate itself there. Wellbeing

I am assuming you are just as addicted to your smartphone as I am. There are so many jokes, memes, articles and complaints about it that we can no longer ignore it. There are talks about responsibility and its place in large corporations.

Apple and Google are being placed on the spotlight on this one in 2018, and Google took the first step towards a solution. They are doing it in a long term project/theme named “Wellbeing”.

Wellbeing is similar to the AI initiative at Google in my mind. Someone came to the managers and told them one day something like this: “Our products are highly addictive. Apple are getting skewered in the news due to it and we’re next in line. Let’s do something about it to show some leadership and a differentiation versus Apple. Bring me ideas of how we can help our Android users with their addiction. We will take the good ideas and start implementing them”.

Here are a few things that came under Wellbeing, and one that didn’t but should have been:

• Dashboard – Google is adding to Android P an activity dashboard to surface insights to the users on what they do on their smartphones
• YouTube includes a new feature to remind you to take a break when a configured amount of time passes. You can apply the same to other third party apps as well
• Smarter do not disturb feature, coupled with Shush – all in an effort to reduce notifications load and anxiety from the user
• Wind down – switching to grayscale mode when a predetermined time of day arrives

• Pretty Please – Google Assistant can be configured to respond “better” and offer positive reinforcements when asked nicely. This one should help parents make their kids more polite (I know I need it with my kids at home)

In a way, this is the beginning of a long road that I am sure will improve over time. It shows the maturity of mobile platforms.

Not sure how responsibility, accountability and wellbeing like aspects lend themselves to other products. If you are aiming at machine learning, think of the biases in your models – these are getting attention recently as well. Fake News

Under responsibility there’s the whole Fake News of recent years.

While Wellbeing targets mainly Apple, The Google News treatment in the keynote was all about addressing Facebook’s weakness. I am not talking about the recent debacle with Cambridge Analitica – this one and anything else related to user’s data privacy was carefully kept away from the keynote. What was addressed is Fake News, where Google gets way more favorable attention than Facebook (just search Google for “google fake news” and “facebook fake news” and look at the titles of the articles that bubble up – check it also on Bing out of curiosity).

What Google did here is create a new Google New experience. And what is interesting is that it tried to bring something to market that skims nicely between objectivity and personalization – things that don’t often correlate when it comes to opinion and politics. It comes with a new layer of visualization that is more inviting, but most of what it does is rooted in AI (as anything else in this I/O keynote).

Here’s what I took out of it:

• AI is used to decide what are quality sources for certain news topics. They are designed to build trust in the news and to remove the “fake” part out of it
• Personalized news is offered in the “category” level. Google will surface topics that interest you
• Next to personalized news, there’s local news as well as trending news, which gets surfaced, probably without personalization though the choice of topics is most probably machine learning driven
• Introduced Newscast – a presentation layer of a topic, enabling readers to get the gist of a topic and later drill down if they wish in what Google calls Full Coverage – an unfiltered view of an event – in an unpersonalized way

One more thing Google did? Emphasized that they are working with publishers on subscriptions, being publisher-friendly, where Facebook is… er… not. Will this hold water and help publishers enough? Time will tell.

AI and Machine Learning lends themselves well to this approach. It ends up being a mixture of personalization, trending and other capabilities that are surfaced when it comes to news. Can you see similar approaches suitable for your product offering? Smart Displays

Smart displays are a rather new category. Besides Android as an operating system for smartphones and the Waymo AI piece, there was no other device featured in the keynote.

Google Home wasn’t mentioned, but Smart Displays actually got their fair share of minutes in the keynote. The only reason I see for it is that it is coupled nicely with the Google Assistant.

The two features mentioned that are relevant?

• It can now show visuals that relate to what goes on in the voice channel
  • This is similar in a way to what MindMeld tried doing years back, before its Cisco acquisition
  • The main difference is that this involves a person and a chatbot. Adding a visual element makes a lot of sense and can be used to enhance the experience
• It offers rich and interactive responses, which goes hand in hand with the visuals part of it

I am unsure why Google gave smart displays the prominence it did at Google I/O. I really have no good explanation for it, besides being a new device category where Apple isn’t operating at all yet – and where Amazon Alexa poses a threat to Google Home.

Android P

10 years in, and Android P was introduced.

There were two types of changes mentioned here: smarts and polish.

Smarts was all about AI (but you knew that already). It included:

• • Adaptive Battery
  • Adaptive Brightness
  • ML Kit (see the Lens section above)

Polish included:

• App Actions and Slices, bot offering faster and better opportunities for apps to interact with users outside of the app itself
• UI/UX changes all around that are just part of the gradual evolution of Android

There was really not much to say about Android P. At least not after counting all the AI work that Google has been doing everywhere anyway.

App Actions and Slices are important if you develop Android Apps. ML Kit is where the true value is and it works on both Android and iOS – explore it first. Google Maps

Google Maps was given the stage at the keynote. It is an important application and getting more so as time goes by.

Google Maps is probably our 4th search destination:

1. Google Search
2. Google Assistant
3. YouTube
4. Google Maps

This is where people look for information these days.

In Search Google has been second to none for years. It wasn’t even part of the keynote.

Google Assistant was front and center in this keynote, most probably superior to its competitors (Siri, Cortana and Lex).

YouTube is THE destination for videos, with Facebook there, but with other worries at this point in time. It is also safe to say that younger generations and more visual audiences search YouTube more often than they do anything else.

Maps is where people search to get from one place to another, and probably searching even more these days – more abstract searches.

In a recent trip to the US, I made quite a few searches that were open ended on Google Maps and was quite impressed with the results. Google is taking this a step further, adding four important pillars to it:

1. Smarts
2. Personalization
3. Collaboration
4. Augmented Reality

Smarts comes from its ML work. Things like estimating arrival times, more commune alternatives (they’ve added motorcycle routes and estimates for example), etc.

Personalization was added by the introduction of a recommendation engine to Maps. Mostly around restaurants and points of interest. Google Maps can now actively recommend places you are more likely to like based on your past preferences.

On the collaboration front, Google is taking its first steps by adding the ability to share locations with friends so you can reach out a decision on a place to go to together.

AR was about improving walking directions and “fixing” the small gripes with maps around orienting yourself with that blue arrow shown on the map when you start navigating.

Where are we headed?

That’s the big question I guess.

More machine learning and AI. Expect Google I/O 2019 to be on the same theme.

If you don’t have it in your roadmap, time to see how to fit it in.

The post Google I/O 2018 and the Future of Computing appeared first on BlogGeek.me.

If you are contemplating build versus buy for your live video platform, or just undecided on which one to pick, check out this 10-part video series.

My consulting projects these days tend to be in one of 3 domains:

1. “We need more marketing exposure, and would like you to help us” (=marketing)
2. “We want to talk about our strategy, differentiation and roadmap” (=product)
3. “We want to make sure we’re building the product properly” (=architecture/development)

I like doing all of these types of projects simply because it keeps me interested. Especially since there’s no specific one that I like more than the others here. It does sometimes confuse potential customers, and probably doesn’t help me with “niching” or “focusing”, but it does give me a very wide view of the communications market.

I want to focus on the 3rd project type, the one where developers want assistance in making sure they pick the right technology, architecture the solution and get it to market with as little risk as possible, this is where things get interesting.

The first thing I do in such projects? Check for NIH.

NIH stands for Not Invented Here, and it is a syndrome of all developers. I know, because I suffer from it as well. Developers are builders and tinkerers. They like to make things work – not get them readymade, which is why when they have the opportunity of building something – they’ll go ahead and do it. The problem though, is that economies of scale as well as time to market aren’t in their favor. In many of the cases, it would be easier to just pick a CPaaS vendor and build your live video product on top of his platform instead of building it all from scratch.

There are many reasons why people go build their own video platform:

1. They think it will cost them less in the long run (usually coupled with a feeling that the price points of the CPaaS vendors are too high and a dislike of paying per usage/minute and not a fixed fee)
2. They have a unique scenario that isn’t quite covered by CPaaS vendors they tried out
3. They want to own the video technology that they are using
4. They need to run on premise due to their customers, regulation or any other reason/excuse

I spend some time uncovering and better understanding the reasons for the decision. Sometimes I feel they make sense, while other times less so.

Which is why when I sat down with Vidyo to think about an interesting project to do together some months back, the decision was made to put out a series of short videos explaining different aspects of live video platforms. I tried to cover as much ground as possible. From network impairments, through video coding technologies, through scale, devices and lots of other topics as well.

The purpose was to get developers and entrepreneurs acquainted with what is necessary when you go build your own infrastructure, and if you decide on buying a platform, to know what to look for.

The series is packed full with content. And I’d love to get your candid opinion of it. Check it out here:

What to Look for in a Live Video Platform

 

The post Choosing a Live Video Platform – a new video series appeared first on BlogGeek.me.

One of the great things about WebRTC is that it is built right into the web platform. The web platform is generally great for WebRTC, but occasionally it can cause huge headaches when specific WebRTC needs do not exactly align with more general browser usage requirements. The latest example of this is has to do […]

The post Autoplay restrictions and WebRTC (Dag-Inge Aas) appeared first on webrtcHacks.

There are opposite forces at play when it comes to the next wave of communication technologies.

There are a lot of changes going on at the moment, being introduced into the world of communications. If I had to make a shopping list of these technologies, I’d probably end up with something like this:

1. Cloud, as a Service
2. APIs and programmability
3. Business messaging, social messaging
4. “Teams”, enterprise messaging
5. Contextual everything
6. Artificial Intelligence, NLP, NLU, ML
7. X Reality – virtual, augmented, mixed, …

Each item is worthy of technobabble marketing in its own rite, but the thing is, they do affect communications. The only question is in what ways.

I have been looking at it lately a lot, trying to figure out where things are headed, building different models to explain things. And looking at a few suggested models by other industry experts.

Communication domains – simplified

Ignoring outliers, there are 3 main distinct communication domains within enterprises:

1. UC – Unified Communications
2. CC – Contact Center
3. CP – Communications Platform

Usually, we will be using the obligatory “aaS” to them: UCaaS, CCaaS and CPaaS

I’ll give my own simplified view on each of these acronyms before we proceed.

UCaaS

Unified Communications looks inwardly inside the company.

A company has employees. They need ways and means to communicate with each other. They also need to communicate with external entities such as suppliers, partners and customers. But predominantly, this is about internal communications. The external communications usually takes a second-class citizen position, with limited capabilities and accessibility; oftentimes, external communications will be limited to email, phone calls and SMS.

What will interest us here will be collaboration and communication.

CCaaS

Contact Centers are about customers. Or leads, which are potential customers.

We’ve got agents in the contact center, be it sales or customer care (=support), and they need to talk to customers.

Things we care about in contact centers? Handling time, customer satisfaction, …

CPaaS

Communication Platform as a Service is different.

It is a recent entry to the communications space, even if some would argue it has always been there.

CPaaS is a set of building blocks that enable us to use communications wherever we may need them. Both CCaaS and UCaaS can be built on top of CPaaS. But CPaaS is much more flexible than that. It can fit itself to almost any use case and scenario where communications is needed.

Communications in Consolidation

There’s a consolidation occuring in communications. One where vendors in different part of communications are growing their offering into the adjacent domains.

We are in a migration from analog to digital when it comes to communications. And from pure telecom/telephony towards browser based, internet communications. Part of it is the introduction of WebRTC technology (couldn’t hold myself back from mentioning WebRTC).

This migration opens up a lot of opportunities and even contemplation on how should we define these communication domains and are they even separate at all.

There have been some interesting moves lately in this space. Here are a few examples of where these lines get blurred and redefined:

• Dialpad just introduced a contact center, tightly integrated and made a seamless part of its unified communications platform
• Vonage acquires Nexmo, which is one of the leading CPaaS vendors. Other UC vendors have added APIs and developer portals to their UC offerings
• Twilio just announced Flex, its first foray out of CPaaS and into the contact center realm

These are just examples. There are other vendors in the communication space who are going after adjacent domains.

The idea here is communication vendors looking into the communications venn diagram and reaching out to an adjacency, with the end result being a consolidation throughout the whole communications space.

External disruption to communications

This is where things get really interesting. The forces at play are pushing communications outwards:

UCaaS, CCaaS, CPaaS. It was almost always about real time. Communications happening between people in real time. When the moment is over, the content of that communications is lost – or more accurately – it becomes another person’s problem. Like a contact center recording calls for governance or quality reasons only, or having the calls transcribed to be pushed towards a CRM database.

Anything that isn’t real time and transient isn’t important with communications. Up until now.

We are now connecting the real time with the asynchronous communications. Adding messaging and textual conversations. We are thinking about context, which isn’t just the here and now, but also the history of it all.

Here’s what’s changing though:

UC and Teams

Unified Communications is ever changing. We’ve added collaboration to it, calling it UC&C. Then we’ve pushed it to the cloud and got UCaaS. Now we’re adding messaging to it. Well… we’re mostly adding UC to messaging (it goes the other way around). So we’re calling it Teams. Or Team Collaboration. Or Workstream Collaboration (WSC). Or Workstream Communication and Collaboration (WCC). I usually call it Enterprise Messaging.

The end result is simple. We focus on collaboration between teams in an organization, and we do that via group chat (=messaging) as our prime modal for communications.

Let’s give it a generic name that everyone understands: Slack

The question now is this: will UC gobble up Team communication vendors such as Slack (and now Workplace by Facebook; as well as many other “project management” and messaging type tools) OR will Slack and the likes of it gobble up UC?

I don’t really know the answer.

CC and CRMs

What about contact centers? These live in the world of CRM. The most important customer data resides in CRMs. And now, with the introduction of WebRTC, and to an extent CPaaS vendors, a CRM vendor can decide to add contact center capabilities as part of his offering. Not through partnerships, but through direct implementation.

Can contact centers do the same? Can they expand towards the CRM domain, starting to handle the customer data itself?

If salesforce starts offering a solid contact center solution in the cloud as part of its offering, that is highly integrated with the Salesforce experience, adding to it a layer of sophistication that contact center vendors will find hard to implement – what will customers do? NOT use it in favor of another contact center vendor or source it all from Salesforce? Just a thought.

–

There’s an additional trend taking place. That’s one of context and analytics. We’re adding context and analytics into “customer journeys”, sales funnels and marketing campaigns. These buzzwords happen to be part of what contact centers are, what modern CRMs can offer, and what dedicated tools do.

For example, most chat widget applications for websites today offer a backend CRM-like dashboard that also acts like a messaging contact center, and at the same time, these same tools act similarly to Google Analytics by following users as they visit your website trying to derive insights from their journey so the contact center agent can use it throughout the conversation. Altocloud did something similar and got acquired recently by Genesys, a large contact center vendor.

CP and PaaS

CPaaS is different a bit. We’re dealing with communication APIs here.

CPaaS market is evolving and changing. There are many reasons for it:

1. SMS and voice is commoditized, with a lot of vendors offering these services
2. IP based services are considered “easier” to implement, eroding their price point and popularity
3. UCaaS vendors adding APIs, at times wanting to capture some of the market due to Twilio’s success
4. As the market grows, there’s a looming sense of what would tech giants do – would Amazon add more CPaaS capabilities into AWS?

That last one is key. We’ve seen the large cloud vendors enhancing their platforms. Moving from pure CPU and storage services up the food chain. Amazon AWS has so many services today that it is hard to keep up. The question here is when will we reach an inflection point where AWS, GCE and Azure start adding serious CPaaS capabilities to their cloud platforms and compete directly with the CPaaS vendors?

Where is CPaaS headed anyway?

• Does the future of CPaaS lies in attacking adjacent communication markets like Twilio is doing with Flex?
• Will CPaaS end up being wrapped and baked into UC and “be done with it”?
• Is CPaaS bound to be gobbled up by cloud providers as just another set of features?
• Will CPaaS stay a distinct market on its own?

The Future of Communications

The future can unfold in three different ways when it comes to communications:

1. Specialization in different communication domains continues and deepens
   • UC ,CC and CP remain distinct domains
   • May be a 4th domain comes in (highly unlikely to happen)
2. Communication domains merge and we refer to it all as communications
   • UC does CC
   • CP used to build UC and CC
   • Customers going for best of suite (=single vendor) who can offer UC, CC and CP in a single platform
3. Communication domains get gobbled up by their adjacencies
   • CC gets wrapped into CRM tools
   • UC being eaten by messaging and teams experiences (probably to be called UC again at the end of the process)
   • CP becoming part of larger, more generic cloud platforms

How do you think the future will unfold?

The post What Comes Next in Communications? appeared first on BlogGeek.me.

A Linux device, such as PC Engines APU, can be equipped with an LTE modem, but sometimes it’s desirable to use the mobile connection only if the wired connection is unavailable.

The following scenario is for Debian 9 on an APU box, but it’s also applicable to any other Linux device.

The DHCP client is tweaked to ignore the DNS server addresses that are coming with  DCHP offer. Otherwise, the LTE provider may provide DNS addresses that are not usable via the ethernet WAN link.

The “ifmetric” package allows setting metrics in interface definitions in Debian. This way we can have two default routes with a preferred metric over LAN interface. The default route with lower metric is chosen for outbound traffic.

The watchdog process checks availability of a well-known public IP address over each of the uplinks, and shuts down and brings up again the corresponding interface. It only protects from next-hop failures. If you want to protect from failures in the whole WAN service, you need to increase the Ethernet port metric if it fails, and then start checking the connectivity, and lower the metric when it’s stable again.

Also the second NIC on the box is configured to provide DHCP address and to NAT all outbound traffic.

Detailed installation instructions are presented here: https://gist.github.com/ssinyagin/1afad07f8c2f58d9d5cc58b2ddbba0a7

 

Ubiquiti EdgeRouter X is a tiny and cheap (around $50) router with a decent amount of memory: 256MB RAM and 256MB flash. The router offers 5 GigE copper ports, and there’s also a model with an additional SFP port. The device is produced since 2014, and it’s still up to date and a good value for money.

On hardware level, the device consists of a Gigabit Ethernet switch, with one GigE port attached to the MIPS CPU and used as a 802.1q trunk. Also inside the enclosure, serial console port is available for easy debugging or manipulating the boot loader.

The router comes with stock Ubuquiti software which is based on Debian Wheezy, so many files are from 2013-2014. OpenVPN package is pre-installed, but only version 2.3 is available. The software offers a nice GUI and SSH access.

OpenWRT provides excellent support for this hardware. The router is able to perform IP routing at more than 400Mbps (I haven’t tested it with back-to-back connection, so I don’t know the limit).

Also with OpenVPN 2.4 that is available in up-to-date OpenWRT packages, the box performs at up to 20Mbps with 256-bit AES encryption, and at about 55Mbps with encryption and authentication disabled.

In default OpenWRT configuration, the switch port 0 is dedicated to WAN link, and ports 1-4 are used as a LAN bridge. The WAN link acts as a DHCP client, and LAN is configured with DHCP service in 192.168.1.0/24 range. The command-line configuration utilities are quite straightforward, and there’s a Web UI as well.

Here’s a new repository for OpenVPN deployment scenarios and example configurations:

https://github.com/txlab/ovpn-scripts

At the moment it lists two scenarios with configuration generation scripts:

1. routed VPN for remote management
2. bridged VPN for anti-censorship isolation of a home LAN

 

WebRTC developers are really hard to come by. I want to improve my ability to help companies in search of such skill.

If there’s something that occurs time and again, it is entrepreneurs and vendors who ask me if I know of anyone who can build their application. Some are looking to outsource the project as a whole or part of it, and then they are looking for agencies to work with. Others are looking for a single expert to work with on a specific task, or someone they could hire for long stretches of time who has WebRTC skills.

You a WebRTC Developer?

Great!

I’d like to know more about you IF you are looking for projects or for a new employer.

Here are a few things first:

1. Even if you think I know you, please fill out the form
2. No agencies. If you are an agency, contact me and we can have a chat. I know a few that I am comfortable working with
3. Only starting out with WebRTC? Don’t fill out the form. Mark this page, get some experience and then fill it out
4. The form is short, so shouldn’t take more than 5 of your minutes to fill
5. Don’t beautify things more than they are – that will just get you thrown out of my radar. Tell things as they are

Fill out this form for me please (or via this link):

Loading…

I won’t be reaching out to you immediately (or at all). I’ll be using this list when others ask for talent that fits your profile.

You looking for WebRTC Developers?

Got a need for developers that have WebRTC skills?

I am not sure exactly how to find them and where, but I am trying to get there.

Two ways to get there:

1. I am thinking of opening up a job listing on WebRTC Weekly
   1. Payment will be needed to place a listing on the WebRTC Weekly, which reaches over 2,500 subscribers at the moment
   2. Cost will be kept low, especially considering the cost of talent acquisition elsewhere and the lack of available WebRTC developers out there
   3. I had a job listing sub-site in the past, didn’t work – this is another attempt I am trying out. If you want to try this one with me, I’ll be happy to take the leap
   4. Interested? Contact me
2. Need a bit more than just finding a developer? I offer consulting services
   1. There are hourly rates available, as well as one-off consulting sessions
   2. I’ll be using the list I’ll be collecting of the WebRTC developers above to match you up with a candidate if you need – or just connect you with the agencies I am comfortable working with

 

The post In Search of WebRTC Developers appeared first on BlogGeek.me.

Two weeks and few more days till the start of Kamailio World Conference 2018, to take place again in Berlin, during May 14-16. It will be the 6th edition of the event, hosted like all previous ones by Fraunhofer Forum, courtesy of Fraunhofer Fokus Research Institute, in the beautiful city center of Berlin, just across the river from Berlin Cathedral, few minutes walking from Alexanderplatz.For this edition we had an increased number of speaking proposals, we tried to accommodate as many as possible from the very interesting ones, therefore we are introducing a group of Lightning Talks, most of them being on Monday, May 14, in the afternoon.The range of topics is also richer, covering from the common use cases for IP telephony, VoLTE/5G or WebRTC, to scalability on demand with Docker, Blockchains in telecom, use of Redis backend for data sharing among many Kamailio instances, leveraging Lua for call routing and testing or VoIP security.Related projects in the RTC world are again very well represented: Asterisk, FreeSwitch, Kazoo, SIP:Provider, Homer SIP Capture, Janus Gateway, CGRateS, FusionPBX and reSIProcate.We continue to have the two interactive sessions that never missed a Kamailio World edition so far:

• VUC Visions coordinated by Randy Resnick – expect again an engaging debate about the future of RTC, the impact of sharing personal data and privacy matters with the Internet giants services or surprise topics brought on table by panelists and audience
• Dangerous Demos coordinated by James Body – prepare your demo and be part of a very entertaining contest that can make you famous as well as reward your work with a prize

A novelty for this edition is an open discussion with Kamailio developers – Ask Me Anything – aiming to get the participants face to face with several main Kamailio developers to chat and clarify any doubts about using or developing the project.To see the full schedule of the event, visit:

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

As usual, there will be couple expo spots where the sponsors are going to make demos of their products and services.We are very grateful to all our sponsors and partners that made possible this edition of Kamailio World Conference: FhG Fokus, FhG Forum, Asipto, Evosip, Netaxis Solutions, 2600hz and KazooCon, Sipwise, Sipgate, Simwood, LOD, Digium, Pascom, Evariste Systems, NG Voice, Core Network Dynamics and VUC.Should you plan to participate at Kamailio World 2018, do not delay your registration, we expect to be again fully booked – secure your registration now:

• https://www.kamailioworld.com/k06/registration/

Looking forward to meeting many of you in Berlin at Kamailio World 2018!Thanks for flying Kamailio!

Kamailio SIP Server v5.1.3 stable is out – a minor release including fixes in code and documentation since v5.1.2. The configuration file and database schema compatibility is preserved, which means you don’t have to change anything to update.Kamailio® v5.1.3 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.3Source tarballs are available at:

• https://www.kamailio.org/pub/kamailio/5.1.3/src/

Detailed changelog:

• https://www.kamailio.org/pub/kamailio/5.1.3/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:

• https://www.kamailio.org/pub/kamailio/5.1.3/

Modules’ documentation:

• https://www.kamailio.org/docs/modules/5.1.x/

What is new in 5.1.x release series is summarized in the announcement of v5.1.0:

• https://www.kamailio.org/w/kamailio-v5-1-0-release-notes/

Do not forget about the next Kamailio World Conference, taking place in Berlin, Germany, during May 14-16, 2018. The schedule has been published, registration is open!Thanks for flying Kamailio!

Chat won’t bring carriers to their SMS-glory days.

The Verge came out with an exclusive last week that everyone out there is regurgitating. This is my attempt at doing the same

We’re talking about Google unveiling its plans for the consumer chat experience. To put things in quick bulleted points:

• There’s a new service called “Chat”, which is supposed to be Google’s and the carrier’s answer to Apple iMessage, Facebook Messenger and the rest
• Google’s default messages app on Android for SMS is getting an upgrade to support RCS, turning it into a modern messaging application
• The moment this happens will vary between the different carriers, who are, by the way, those who make the decision and control and own the service
• Samsung and other Android handset manufacturers will probably come out with their own messaging app instead of the one provided by Google
• This is a risky plan with a lot of challenges ahead of it

I’d like to share my viewpoints and where things are going to get interesting.

SMS is dead

I liked Mashable’s title for their take on this:

Google’s plan to fix texting on Android is really about the death of SMS

While an apt title, my guess is that beyond carriers and reports written to them, we all know that already.

SMS has long been dead. The A2P (Application 2 Person) SMS messages are all that’s left out of it. Businesses texting us either their PIN codes and passwords for 2FA (2 Factor Authentication) and OTP (One Time Passwords) or just sending us marketing junk for us to ignore.

I asked a few friends of mine on a group chat yesterday (over Whatsapp, of course) when and how do they use SMS and why. Here are the replies I got (I translated them to English):

• I prefer Whatsapp. It is the most lightweight and friendly alternative. I only use SMS when they are automatically sent to me on missed calls
• Whatsapp is accessible. It has quick indicators and it is lightweight. It remembers everything in an orderly fashion
• I noticed that people take too long to respond on SMS while they respond a lot faster over Whatsapp. Since SMS is more formal to me, I use it when sending messages for the first time to people I don’t know
• I send SMS only to people I don’t know. I feel that Whatsapp is more personal
• I use iMessage only with my boss. She’s ultra religious so she doesn’t have Whatsapp installed. For everything else I use Whatsapp
• I mostly use Whatsapp for messages. I text via SMS only with my wife when I am flooded with Whatsapp messages and just want her notifications to be more prominent
• SMS is dead for me. I don’t even have it on my home screen, and that says anything. I use SMS only to receive PIN codes from businesses
• SMS is the new fax

These are 40 year olds in Israel. Most working out of the IT domain. The answers will probably vary elsewhere, but here in Israel, most will give you similar answers. Whatsapp has become the go-to app for communications. So much so, that we were forced to give our daughter her first smartphone at the age of 8 only so she can communicate with her friends via Whatsapp and won’t stay behind. Everyone uses it here in Israel.

You should also know that plans upwards of 2Gb of monthly data including unlimited voice and SMS in Israel cost less than $15 a month in Israel, so this has nothing to do with price pressure anymore. It has to do with network effects and simple user experience.

SMS is no longer ubiquitous across the globe. I can’t attest to other countries, but I guess Israel isn’t alone in this. SMS is just the last alternative to use when all else has failed.

Why is SMS interesting in this context?

Because a lot of what’s at stake here for Google relates to the benefits and characteristics of SMS.

RCS is (still) dead

RCS is the successor of SMS for getting carriers into the 21st century. It has been discussed for many years now, and it will most definitely, utterly, completely, unquestionably get people back from their Messenger, WhatsApp and WeChat back to the clutches of the carriers. NOT.

RCS is a design-by-committee solution, envisioned by people my age and older, targeting a younger audience across the globe in an attempt to kill fast moving social network with a standardized, ubiquitous, agreed upon specification that then needs to be implemented by multiple vendors, handset manufacturers and carriers globally to make any sense.

Not going to happen.

Google’s take on this was to acquire an RCS vendor – Jibe – two years ago for this purpose. The idea was probably to provide a combination of an infrastructure and a mobile client to speed up RCS deployments around the globe and make them interoperable faster than the carriers will ever achieve on their own.

Two years passed, and we’ve got nothing but a slide (and the article on The Verge) to show for this effort:

An impressive list of operators, OEMs and OS providers that are behind this RCS initiative. Is that due to Google? To some part, probably so.

In a way, this reminds me also of Google’s other industry initiative – the Alliance of Open Media, where it is one of 7 original founding members that just recently came out with AV1, a royalty free video codec. It is a different undertaking:

• RCS will be controlled by carriers, who were never kind or benevolent to their users
• For carriers, the incentive can be found in the GSMA’s announcement: “GSMAi estimate that this will open up an A2P RCS business worth an estimated $74bn by 2021”
  • This is about securing A2P SMS revenues by migrating to RCS
  • The sentences before this one in that announcement explain how they plan on reaching there: “The Universal Profile ensures the telecoms industry remains at the centre of digital communications by enabling Operators, OEMs and OS Providers to deliver this exciting new messaging service consistently, quickly and simply.”
  • Problem is, they are not the centre of digital communications, so this isn’t about ensuring or remaining. It is about winning back. And you can’t do that if your focus is A2P
• This isn’t about an open platform for innovation. Of a level playing field for all. And that makes it starkly different from the AV1 initiative. It is probably closer to MPEG-LA’s response in a way of a new video codec initiative

Why is Google going into bed with the carriers on this one?

Google had no choice

The Verge had an exclusive interview with Anil Sabharwal, the Google VP leading this effort. This led to the long article about this initiative. The numbers that Anil shared were eye opening as to the abysmal state of Google’s messaging efforts thus far.

I went ahead and placed these numbers next to other announced messaging services for comparison:

A few things to note here:

• Telegram, Facebook Messenger and Whatsapp are all apps users make a decision to install, and they are making that decision en masse
• Apple has upwards of 1.3 billion active devices, which indicate the general size of its iMessage service
• Google Messages is the default app on Android for SMS, unless:
  • Carriers replace it with their own app
  • Handset manufacturers replace it with their own app
  • Users replace it with another app they install
• Google Messages sees around 100 million monthly active users – the table-stakes entry number to be relevant in this market, but rather low for an ubiquitous, default app
• Google Allo has less than 50 million downloads. That’s not even monthly active users
• Google Hangouts stopped announcing its user base years ago, and frankly, they stopped investing in it as well. The mobile app is defunct (for me) for quite some time now, with unusual slowness and unresponsiveness

Google failed to entice its billion+ Android users to install or even use its messaging applications.

Without the numbers, it couldn’t really come up with a strategy similar to Apple iMessage, where it essentially hijacks the messaging traffic from carriers, onboarding the users to its own social messaging experience.

Trying to do that would alienate Google with the carriers, which Google relies on for Android device sales. Some would argue that Google has the klout and size to do that, but that is not the case.

Android is open, so handset manufacturers and carriers could use it without Google’s direct approval, throwing away the default messaging app. Handset manufacturers and carriers would do that in an effort to gain more control over Android, which would kill the user experience, as most such apps by handset manufacturers and carriers do. The end result? More users purchasing iPhones, as carriers try to punish Google for the move.

What could Google do?

1. Double down on their own social messaging app – hasn’t worked multiple times now. What can they do different?
2. Build their own iMessage – alienate the Android ecosystem, with the risk of failing attracting users as they failed in the past
3. Partner with carriers on RCS

Two years ago, Google decided to go for alternatives (1) and (3). Allo was their own social messaging app. Had it succeeded, my guess is that Google would have gone towards approach (2). In parallel, Google acquired Jibe in an effort to take route (3), which is now the strategy the company is behind for its consumer messaging.

The big risk here is that the plan itself relies on carriers and their decisions. We don’t even know when will this get launched. Reading between the lines of The Verge’s article, Google already completed the development and got the mobile client ready and deployed. It just isn’t enabled unless the carrier being used approves. Estimates indicate 6-12 months until that happens, but for which of the carriers? And will they use the stock Android app for that or their own ambitious better-than-whatsapp app?

E2EE can kill this initiative and hurt Google

The biggest risk to Google is the lack of E2EE (end to end encryption).

In each and every regurgitated post of The Verge article and in The Verge itself this is emphasized. Walt Mossberg’s tweet was mentioned multiple times as well:

Bottom line: Google builds an insecure messaging system controlled by carriers who are in bed with governments everywhere at exactly the time when world publics are more worried about data collection and theft than ever.

— Walt Mossberg (@waltmossberg) April 20, 2018

Bottom line: Google builds an insecure messaging system  controlled by carriers who are in bed with governments everywhere at exactly the time when world publics are more worried about data collection and theft than ever.

The problem for Google is that the news outlets are noticing and giving it a lot of publicity. And it couldn’t come at a less convenient time, where Facebook is being scrutinized for its malpractice of how it uses and protects user data in the Cambridge Analytica scandal. Google for the most part, has come unscathed out of it, but will this move put more of the spotlight on Google?

The other problem is that all the other messaging apps already have E2EE supported in one way or another. The apps usually mentioned here are Apple iMessage, Signal and Telegram. Whatsapp switched to E2EE by default two years ago. And Facebook Messenger has it as an option (though you do need to enable it manually per conversation).

Will customers accept using “Chat” (=RCS) when they know it isn’t encrypted end to end?

On the other hand, Russia is attempting to close Telegram by blocking millions of IP addresses in the country, and taking down with it other large services. If this succeeds, then Russia will do the same to all other popular messaging applications. And then other countries will follow. The end result will be the need to use the carrier (and Google’s) alternative instead. Thankfully, Russia is unsuccessful. For the time being.

Who owns the data?

Carriers do.

With RCS, the carriers are the ones that are intercepting, processing and forwarding the messages. In a way, it alludes to the fact that Google isn’t going to be the one reading these messages, at least not from the server.

This means that either Google decided there’s not enough value in these messages and in monetizing them – or – that they have other means to gain access to these messages.

Here are a few alternatives Google can use to accessing these messages:

1. Through licensing and operating the servers on behalf of carriers. Not all carriers will roll their own and may prefer using Google as a service here. Having the messages in unencrypted format on the server side is beneficial for Google in a way, especially when they can “blame” the carriers and regulations
2. Via Google’s Messages app. While messages might be sent via a carrier’s network, the client sending and receiving these messages is developed and maintained by Google, giving them the needed access. This can be coupled with features like backing up the messages in Google Drive or letting Google read the messages to improve its services for the user
3. By coupling features such as Google Assistant and Smart Replies into it, which means Google needs to read the messages to offer the service

Google might have figured it has other means to get to the messages besides owning and controlling the whole experience – similar to how Google Photos is one of the top camera apps in Apple iTunes.

By offering a better experience than other RCS client competitors, it might elicit users to download its stock Chat app on devices who don’t have it by default. Who knows? It might even be able to get people to download and use it on an iPhone one day.

The success of Google here will translate into RCS being a vehicle for Google to get back to messaging more than the means for carriers to gain relevance again.

Ubiquity is here already, but not via SMS or RCS

I’ll put the graph here again – to make a point.

1.5 billion people is ubiquitous enough for me. Especially when the penetration rates in Israel are 100% in my network of connections.

People tend to talk about the ubiquity of SMS and how RCS will inherit that ubiquity.

They fail to take into account the following:

1. SMS is ubiquitous, but it took it many years to get there
2. It is used for marketing and 2FA mostly
3. The marketing part is less valuable
   1. It can be treated as spam by consumers for the most part
   2. It is one way in nature, where social networks are around conversations
   3. Spam and unsolicited messages don’t work that well in social networks
4. 2FA will be shifting away from SMS (see here)
   1. Google does a lot of its 2FA without SMS today
   2. Google can open it up to third parties at any point in time
   3. Apple can do the same with the iPhone
5. The shift towards RCS won’t be done in a single day. It will be done in a patchwork fashion across the globe by different carriers

Think about it.

You can now send out an RCS message from your device. To anyone. If the other party has no RCS installed, the message gets converted to SMS. Sweet.

But what happens when the person you are sending that RCS message is located abroad? Are you seriously happy with getting a payment request from your carrier on a stupid international SMS message, or a full conversation of such for a thing you could have easily used Whatsapp for instead? And for free.

Ubiquity isn’t the word that comes to my mind when thinking about RCS.

The holy grail is business messaging

Consumer messaging is free these days. There is no direct monetary value to be gained by offering this service to consumers. Carriers won’t be able to put that jinni back into its bottle and start collecting money from users. Their only approach here might be to zero-rate RCS traffic, but that also isn’t very interesting to most consumers – at least not here in Israel.

The GSMA already suggested where the money is – in business messaging. They see this as a $74bn opportunity by 2021. The problem is that rolling RCS 6-12 months from now, by only some of the carriers, isn’t going to cut it. Apple Business Chat was just released, vertically integrated, with a lot of thought put into businesses, their discovery process and free of charge.

Then there’s the rest of the social networks opening their APIs towards the businesses, and contact center solutions driving the concept of omnichannel experiences for customers.

Carriers are getting into this game late and unprepared. On top of that, they will try to get money out of this market similar to how they do with SMS. But the price points they are used to make no sense anymore. Something will need to change for the carriers to be successful here.

Will carriers be able to succeed with RCS? I doubt it.

Will google be able to succeed with Chat? Maybe. But it is up to the carriers to allow that to happen.

The post RCS now Google Messages. What’s Next in Consumer Messaging? appeared first on BlogGeek.me.

With a vibrant community world wide, Kamailio project is going to be represented at many events for the rest of the year, among the confirmed at this moment are:

• Hannover Messe – April 23-26, 2018, in Hannover, Germany
• KazooCon – April 30-May 02, 2018, in San Jose, USA
• Kamailio World – May 14-16, 2018, in Berlin, Germany
• CeBIT – June 11-15, 2018, in Hannover, Germany
• CommCon – June 25-29, 2018, in Wotton House, Surrey, UK
• ClueCon – July 23-26, 2018, in Chicago, USA
• AstriCon – October 9-11, 2018, in Orlando, USA

Should you plan to go to any of these events, get in touch with the rest of the community via sr-users mailing list and try to organise meetups with other Kamailio folks!Thanks for flying Kamailio!

Kamailio source tree include a set of few dozen of shell-based unit tests developed several years ago, residing inside test/unit/ of the source code tree. They were more or less not actively maintained during the past few years.Based on the interest from the community and discussions during past IRC development meetings as well as panels at Kamailio World Conference, a new effort was started recently to built a unit testing framework leveraging Docker.The first version has been published on GitHub, being available at:

• https://github.com/kamailio/kamailio-tests

It has only few tests by now, but we hope to grow their number significantly in the near future. As a matter of fact, Giacomo Vacca is going to do an workshop about it at the next Kamailio World Conference, during May 14-16, in Berlin, Germany.The unit tests have been run when releasing a new stable version during the past months. They leverage tools such as sipp or sipsak for generating SIP traffic and testing routing scenarios, but some of them go beyond SIP and detect source code issues such as missing symbols or broken dependencies.The architecture of the unit testing framework is still a moving target, we aim to provide something easy for community members to contribute to as well as require for newly added modules to be accompanied by a set of basic tests.One of the main benefits it would be to have the reports of the issues that can be reproduced submitted along with a unit test. It would make it easier to troubleshoot and then after fixing it, would be tested always before releases in order to avoid regressions.Right now, a good help from community would represent converting the old unit tests to the new framework, afterwards we can decommission test/unit. The conversion should be rather easy, as we still rely on shell and the sip tools like sipp/sipsak … If you want to help here by you need clarifications or get stuck somewhere, just write to mailing list and I would be more than happy to assist. Such contributions should be submitted as pull requests in order to be easy to review:

• https://github.com/kamailio/kamailio-tests/pulls

This post is to open the discussion about the unit testing framework to the broad community. To participate, write us on sr-users mailing list.Looking forward to meeting many of you at Kamailio World Conference 2018, it is only one month away!

Julien Chavanton from Flowroute added recently a new module: acc_jsonThe module builds JSON documents from the accounting records and can send them to mqueue to be consumed by other processes or write to syslog. For example, when using it configured with mqueue, the consumers (e.g., started with rtimer module) can send the accounting JSON document to an external system via HTTP (see http_client or http_async_client modules), rabbitmq, nsq or even as a payload to a new SIP message (see uac module).More details about acc_json module can be read at:

• https://www.kamailio.org/docs/modules/devel/modules/acc_json.html

And do not forget about the next Kamailio World Conference, taking place in Berlin, Germany, during May 14-16, 2018. It is the place to network with Kamailio developers and community members!Thanks for flying Kamailio!

Join Philipp Hancke and me for a free training on WebRTC 1.0, prior to the relaunch of my advanced WebRTC training.

Here’s something that I get at least once a week through my website’s chat widget:

It is one of the main reasons why I’ve created my advanced WebRTC course. It is a paid WebRTC course that is designed to fill in the gaps and answer the many questions developers face when needing to deal with WebRTC.

Elephants, blind Men, alligators and WebRTC

I wanted to connect it to the parable of the six blind man and an elephant, explaining how wherever you go in the Internet, you are going to get a glimpse about WebRTC and never a full clear picture. I even searched for a good illustration to use for it. Then I bumped into this illustration:

It depicts what happens with WebRTC and developers all too well.

If you haven’t guessed it, the elephants here are WebRTC and the requirements of the application and that flat person is the developer.

–

This fits well with another joke I heard yesterday from a friend’s kid:

Q: Why can’t you go into the woods between 14:00-16:00?

A: Because the elephants are skydiving

There’s a follow up joke as well:

Q: Why are the alligators flat?

A: Because they entered the woods between 14:00-16:00

WebRTC development has a lot of rules. Many of which are unwritten.

WebRTC 1.0

There is a lot of nuances about WebRTC. A lot of written material, old and new – some of it irrelevant now, the rest might be correct but jumbled. And WebRTC is a moving target. It is hard to keep track of all the changes. There’s a lot of knowledge around WebRTC that is required – knowledge that doesn’t look like an API call or written in the standard specification.

This means that I get to update my course every few months just to keep up.

With WebRTC 1.0, there’s both a real challenge as well as an opportunity.

It is a challenge:

• WebRTC 1.0 still isn’t here. There’s a working draft, which should get standardized *soon* (=soon started in 2015, and probably ends in 2018, hopefully)
• Browser implementations lag behind the latest WebRTC 1.0 draft
• Browser implementations don’t behave the same, or implement the same parts of the latest WebRTC 1.0 draft

It is an opportunity:

We might actually get to a point where we have a stable API with stable implementations.

But we’re still not there

Should you wait?

No.

We’re 6-7 years in with WebRTC (depending who does the counting), and this hasn’t stopped well over a 1,000 vendors to jump in and make use of WebRTC in production services.

There’s already massive use of WebRTC.

Me and WebRTC 1.0

For me, WebRTC 1.0 is somewhat of a new topic.

I try to avoid the discussions going on around WebRTC in the standardization bodies. The work they do is important and critical, but often tedious. I had my fair share of it in the past with other standards and it isn’t something I enjoy these days.

This caused a kind of a challenge for me as well. How can I teach WebRTC, in a premium course, without explaining WebRTC 1.0 – a topic that needs to be addressed as developers need to prepare for the changes that are coming.

The answer was to ask Philipp Hancke to help out here, and create a course lesson for me on WebRTC 1.0. I like doing projects with Philipp, and do so on many fronts, so this is one additional project. It also isn’t the first time either – the bonus materials of my WebRTC course includes a recorded lesson by Philipp about video quality in WebRTC.

Free WebRTC 1.0 Webinar

Tomorrow, we will be recording the WebRTC 1.0 lesson together for my course. I’ll be there, and this time,  partially as a student.

To make things a bit more interesting, as well as promoting the whole course, this lesson will be given live in the form of a free webinar:

• Anyone can join for free to learn about WebRTC 1.0
• The recording will only be available as part of the advanced WebRTC course

This webinar/lesson will take place on

Tuesday, April 10

2-3PM EST (view in your timezone)

Save your seat →

The session’s recording will NOT be available after the event itself. While this lesson is free to attend live, the recording will become an integral part of the course’ lessons.

The post WebRTC 1.0 Training and Free Webinar Tomorrow (on Tuesday) appeared first on BlogGeek.me.

We have covered the “WebRTC is leaking your IP address” topic a few times, like when I reported what the NY Times was doing and in my WebRTC-Notifier. Periodically this topic comes up now and again in the blogosphere, generally with great shock and horror. This happened again recently, so I here is an updated look […]

The post So your VPN is leaking because of Chrome’s WebRTC… appeared first on webrtcHacks.