News from Industry

Yes.

It is a question I get from time to time, especially now, that I am a few months into the WebRTC testing venture as a co-founder with a few partners – testRTC.

The logic usually goes like this: the browsers already support WebRTC. They do their own testing, so what we end up getting is a solid solution we can use. Fippo would say that

If life was that easy… here are a few things you need to take care of when it comes to testing the most simple of WebRTC services:

#1 – Future proofing browser versions

Guess what? Things break. They also change. Especially when it comes to WebRTC.

A few interesting tidbits for you:

• Google is dropping HTTP support for GetUserMedia, so services must migrate to HTTPS. Before year end
• The echo canceller inside WebRTC? It was rewritten. From scratch. Using a new algorithm. That is now running on a billion devices. Different devices. And it works! Most times
• WebRTC’s getStats() API is changing. Breaking its previous functionality

And the list goes on.

WebRTC is a great technology, but browsers are running at breakneck speeds of 6-8 weeks between releases (for each browser) – and every new release with a potential to break a service in multitude of ways – either because of a change in the spec, deprecation of capability or just bugs.

Takeaway: Make sure your service works not only on the stable version of the browsers, but also on their beta or even dev versions as well.

#2 – Media relay

Your service might be a P2P service, but at times, you will need to relay media through TURN servers.

The word on the street is that around 15% of sessions require relay. To some it can be 50% and to others 8% (real numbers I heard from running services).

Media relay is tricky:

• You need to configure it properly (many fall at this one)
• You need to test it in front of different firewall and NAT configurations
• You need to make it close to your users (you don’t want a local session in Paris to get relayed through a server in San Francisco)
• You need to test it for scale (check the next point for more on that)

Takeaway: Don’t treat WebRTC as a browser side technology only, or something devoid of media handling. Even if the browser does most of the heavy lifting, some of the effort (and responsibility) will lie on your service.

#3 – Server scale

Can your server cater for 200 sessions in parallel to fit that contact center? What about a 1000?

What will happen if you’ll have a horde effect due to a specific event? Can you handle that number of browsers hitting your service at once? Does your website operate in the same efficiency for the 1000th person as it does for the first?

This relates to both your signaling server, which is no part of WebRTC, but is there as part of your service AND your media server from my previous point.

Takeaway: Make sure your service scales to the capacities that it needs to scale. Oh – and you won’t be able to test it manually with the people you have with you in your office…

#4 – Service uptime

You tested it all. You have the perfect release. The service is up and running.

How do you make sure it stays running?

Manually? Every morning come in to the office and run a session?

Use Pingdom to make sure your site is up? Go to the extreme of using New Relic to check the servers are up, the CPUs aren’t over loaded and the memory use seems reasonable? Great. But does that mean your service is running and people can actually connect sessions? Not necessarily.

Takeaway: End-to-end monitoring. Make sure your service works as advertised.

The ugly truth about testing

The current norm in many cases is to test manually. Or not test at all. Or rely on unit testing done by developers.

None of this can work if what you are trying to do is create a commercial service, so take it seriously. Make testing a part of your development and deployment process.

And while we’re at it…

Check us out at testRTC

If you don’t know, I am a co-founder with a few colleagues at a company called testRTC. It can help you with all of the above – and more.

Leave us a note on the contact page there if you are interested in our paid service – it can cater to your testing needs with WebRTC as well as offering end-to-end monitoring.

 

Need to test WebRTC?

 

The post Do you Need to test a WebRTC P2P Service? appeared first on BlogGeek.me.

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

Fone.Do: Moshe Maeir

October 2015

SMB phone system

Telephony

Small

Voice

Disrupting the hosted PBX system with WebRTC.

[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

 

There’s no doubt that WebRTC is disrupting many industries. One of the obvious ones is enterprise communications, and in this space, an area that has got little attention on my end (sorry) is the SMB – where a small company needs a phone system to use and wants to look big while at it.

Moshe Maeir, Founder at Fone.do, just launched the service out of Alpha. I have been aware of what they were doing for quite some time and Moshe took the time now that their service is public to answer a few of my questions.

 

What is Fone.do all about?

Fone.do is a WebRTC based phone system for small businesses that anyone can set up in 3 minutes. It replaces both legacy PBX systems that were traditionally based in your communications closet and also popular Hosted PBX systems. Businesses today are mobile and the traditional fixed office model is changing. So while you can connect a SIP based IP phone to our system, we are focused on meeting the needs of the changing business world.

 

Why do small businesses need WebRTC at all? What’s the benefit for them?

You could ask the same question about email, social networks etc. Why use web based services at all? Does anyone want to go back to the days of “computer programs” that you downloaded and installed on your computer? Unfortunately, many still see telephony and communications as a stand alone application. WebRTC changes this. Small businesses can communicate from any place and any device as long as they have a compatible platform.

 

What excites you about working in WebRTC?

Two things. Not sure which is more exciting. First of all. If I build something great – the whole world is my potential market. All they need is a browser and they are using our system in 3 minutes. The other exciting aspect is that telephony is no longer a closed network. Once you are on the web the potential is unlimited. You can easily connect your phone system to the wealth of data and services that already exist on the web and take communications to a new level. In fact, that is why we hired developers who knew nothing about telephony but were experienced in web development. The results are eye opening for traditional telecom people.

 

I know you’re a telecom guy yourself. Can you give an example how working with web developers was an eye opener to you?

There are many. The general attitude is just do it. With legacy telecom, everything has the accepted way of doing things and you don’t want to try  anything new without extended testing procedures. A small example – in the old VoIP days writing a “dial plan” was a big thing. When we came to this issue on Fone.Do, one of the programmers naturally googled the issue and found a Google service that will automatically adapt the dial plan based on the users’ mobile number. 1-2-3 done.

 

Backend. What technologies and architecture are you using there?

Our main objective was to build an architecture that will work well and easily scale in the cloud (we are currently using AWS). So while we have integrated components such as the Dialogic XMS and the open source Restcomm, we wrote our own app server which manages everything. This enables us if we need to freely change back end components.

 

Can you tell us a bit about your team? When we talked about it a little of a year ago ago, I suggested a mixture of VoIP and web developers. What did you end up doing and how did it play out?

All our developers are experienced front end and backend web programmers with no telecom experience. However, our CTO who designed the system has over 15 years of experience in Telecom, so he is there to fill in any missing pieces. There were some bumps at the beginning, but I am very happy we did it this way. You can teach a web guy about Telephony, but it is very hard to get a Telecom guy to change his way of thinking. Telecom is all about “five nines” and minimizing risk. Web development is more about innovation and new functionality. With todays’ technology it is possible to innovate and be almost as reliable as traditional telephony

 

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

Adoption is slower than I expected, but eventually I see it as just another group of functions in your browser that developers can access as needed.

 

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

WebRTC is here. It makes your user experience better – so what are you waiting for?

 

What’s next for Fone.do?

We recently released our alpha product and we are looking to launch an open beta in the next couple of months. Besides a web based “application”, we also have applications for Android and iOS.

–

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

The post Fone.do and WebRTC: An Interview With Moshe Maeir appeared first on BlogGeek.me.

The Next Wave - KazooCon 2015 from James Solada

CTO Karl Anderson discusses the state of Kazoo. This includes integrations with FreeSWITCH, erlang, and Kamailio. Reseller milestones include the release of whitelabeling, webhooks, migration, carriers, debugging, account management and more.

Detecting and Managing VoIP Fraud from James Solada

This is an overview of VoIP fraud, different types of fraud and what telecommunication carriers are doing to combat this issue. Types of fraud include International / Premium Number Fraud, Impersonation / Social Engineering, Service Degradation / Denial of service. Presented by Mark Magnusson at KazooCon 2015. 

Telecom Rating and Limits from James Solada

James Aimonetti discusses VoIP Rates, Routing, and Services at KazooCon 2015.

Billing Data with Kazoo from James Solada

Product Director Aaron Gunn discusses billing options for SaaS and IaaS customers. This includes CDR API, AMPQ, and integrating VoIP billing platforms.

Tuning Kazoo to 10,000 Handsets - KazooCon 2015 from James Solada

People love to talk about scale. Some vendors pitch that their systems easily support 100,000 simultaneous calls, or 500 calls per second, etc. The reality is, in the real world, people’s behaviors vary and the feature sets they use can cut these numbers down quickly. For example, ask that same vendor claiming 100,000 simultaneous calls if it can be done while call recording, call statistics and other features are turned on at the same time, and you’ll usually get a very different, cautious, qualified response.

In this presentation, we’ll show you how to set up your infrastructure to support 100,000 simultaneous calls.

http://www.slideshare.net/2600hzmarketing/tuning-kazoo-to-10000-handsets-kazoocon-2015

People love to talk about scale. Some vendors pitch that their systems easily support 100,000 simultaneous calls, or 500 calls per second, etc. The reality is, in the real world, people’s behaviors vary and the feature sets they use can cut these numbers down quickly. For example, ask that same vendor claiming 100,000 simultaneous calls if it can be done while call recording, call statistics and other features are turned on at the same time, and you’ll usually get a very different, cautious, qualified response.

In this presentation, we’ll show you how to set up your infrastructure to support 100,000 simultaneous calls.

HTTP/2 is too good to pass.

If you don’t know much about HTTP/2 then check this HTTP/2 101 I’ve written half a year ago.

In essence, it is the next version of how we all get to consume the web over a browser – and it has been standardized and deployed already. My own website here doesn’t yet use it because I am dependent on the third parties that host my service. I hope they will upgrade to HTTP/2 soon.

Watching this from the sidelines, here are 4 good reasons why you should be using HTTP/2. Not tomorrow. Today.

#1 – Page Load Speed

This one is a no-brainer.

A modern web page isn’t a single resource that gets pulled towards your browser for the pleasure of your viewing. Websites today are built with many different layers:

• The core of the site itself, comprising of your good old HTML and CSS files
• Additional JavaScript files – either because you picked them yourself (JQuery or some other piece of interactive code) or through a third party (Angular framework, ad network, site tracking code, etc.)
• Additional JavaScript and CSS files coming from different add-ons and plugins (WordPress is fond of these)
• Images and videos. These may be served from your server or via a CDN

At the time of writing, my own website’s homepage takes 116 requests to render. These requests don’t come from a single source, but rather from a multitude of them, and that’s when I am using weird hacks such as CSS sprites to reduce the number of resources that get loaded.

There’s no running away from it – as we move towards richer experiences, the resources required to render them grows.

A small HTTP/2 demo that CDN77 put in place shows exactly that different – they try loading 200 small images to a page in either HTTP/1.1 or HTTP/2 shows the improved load times of the page.

HTTP/2 has some more features that can be used to speed up web page serving – we just need to collectively start adopting it.

#2 – Avoiding Content Injection

In August, AT&T was caught using ad injection. Apparently, AT&T ran a pilot where people accessing the internet via its WiFi hotspots in airports got ads injected to the pages they browsed over the internet.

This means that your website’s ads could be replaced with those used by a third party – who will get the income and insights coming from the served ads. It can also mean that your website, that doesn’t really have ads – now shows them. The control freak that I am, this doesn’t sound right to me.

While HTTP/2 allows both encrypted and unencrypted content to be served, only the encrypted variant is supported by browsers today. You get the added benefits of encryption when you deploy HTTP/2. This makes it hard to impossible to inject 3rd party ads or content to your site.

#3 – Granularity

During that same August (which was the reason this post was planned to begin with), Russia took the stupid step of blocking Wikipedia. This move lasted less than a week.

The reason? Apparently inappropriate content in a Wikipedia page about drugs. Why was the ban lifted? You can’t really block a site like Wikipedia and get away with it. Now, since Wikipedia uses encryption (SPDY, the predecessor of HTTP/2 in a way), Russia couldn’t really block specific pages on the site – it is an all or nothing game.

When you shift towards an encrypted website, external third parties can’t see what pages get served to viewers. They can’t monetize this information without your assistance and they can’t block (or modify) specific pages either.

And again, HTTP/2 is encrypted by default.

#4 – SEO Juice

Three things that make HTTP/2 good for your site’s SEO:

1. Encrypted by default. Google is making moves towards giving higher ranking for encrypted sites
2. Shorter page load times translate to better SEO
3. As Google migrates its own sites to HTTP/2, expect to see them giving it higher ranking as well – Google is all about furthering the web in this area, so they will place either a carrot or a stick in front of business owners with websites

 

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

The post 4 Good Reasons for Using HTTP/2 appeared first on BlogGeek.me.

Hello, again. This past week in the FreeSWITCH master branch we had 90 commits! Most of the features for this week went toward the verto communicator and are: created a source map file, created the reset banner action, floor and presenter badges, and locked icon in floorLocked status, added an About screen with version information and links to FS.org and added a link to Confluence with documentation for VC, and made mute/unmute audio/video clickable. Other features this week include: refactoring the local_stream API to be more consistent and add auto complete, compatibility with Solaris 11 process privileges, improvements to the way FEC info is detected within frames by adding support for ptimes higher than 20 ms for FEC detection and improvements to jitter buffer debugging in mod_opus.

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

New features that were added:

• FS-8243 [mod_opus] Improve the way FEC info is detected within frames by adding support for ptimes higher than 20 ms for FEC detection
• FS-8161 [mod_opus] Keep FEC enabled only if loss > 10 ( otherwise PLC is supposed to be better)
• FS-8179 [mod_opus] Improvement on new jitter buffer debugging (debug lookahead FEC)
• FS-8254 [verto_communicator] Create a source map file
• FS-8263 [verto_communicator] Created the reset banner action, floor and presenter badges, and lock icon in floorLocked status
• FS-8288 [verto_communicator] Added an About screen with version information and links to FS.org and added a link to Confluence with documentation for VC
• FS-8289 [verto_communicator] Make mute/unmute audio/video clickable
• FS-8287 [mod_local_stream] Refactor local_stream API to be more consistent and add auto complete
• FS-8195 [core] Compatibility with Solaris 11 process privileges

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

• FS-8236 Fixed build without libyuv on compilers that error on unused static function and fixed ifdefs for building without libyuv
• FS-8239 [mod_av] Fixed the default value to avoid failed build on CentOS 7
• FS-8255 [Debian] Fixed codename changes since Jessie was released as stable
• FS-8271 [Debian] Simplify package building for the default case
• FS-8270 [Debian] Fix for package installation failing if /etc/freeswitch/tls is missing
• FS-8285 [Debian] Removed heart attack inducing warning message when updating deb packages
• FS-7817 Removed use of _NONSTD for Windows builds of spandsp, so (hopefully) eliminate compatibility problem

The following bugs were squashed:

• FS-8221 [verto_communicator] Fix number in call history
• FS-8223 [verto_communicator] Fixing members list layout when callerid is too long
• FS-8225 [verto_communicator] Avoid duplicate members when recovering calls
• FS-8214 [verto_communicator] Better handling calls in VC, answering them respecting useVideo param
• FS-8291 [verto_communicator] Fixed contributors url
• FS-8229 [verto_communicator] Changing moderator actions bullet menu color to #333
• FS-8219 [verto_communicator] Fix for camera not deactivating after init or after hangup
• FS-8245 [verto_communicator] Fix for Video Resolutions available in “Video Quality” drop down not always correct
• FS-8251 [verto_communicator] Factory reset now clears all local storage
• FS-8257 [verto_communicator] Fixed configuration provision url because configuration doesn’t work with `grunt serve` and non pathname urls
• FS-8273 [verto] [verto_communicator] Clear the CF_RECOVERING flag in a spot that was missed
• FS-8260 [verto_communicator] Prompt for banner text
• FS-8232 [mod_conference] Conference sending too many video refresh requests
• FS-8241 [mod_conference] Fix for conference stops playing video when local_stream changes source
• FS-8261 [mod_conference] Fixed the conference segfaulting when trying to reset the banner
• FS-8220 [core] Fix for DTMF not working between telephone-event/48000 A leg and telephone-event/8000 B leg
• FS-8166 [core] Mute/unmute while shout is playing audio fails because the channel “has a media bug, hard mute not allowed”
• FS-8252 [core] Fixed a crash in rtp stack on dtls pointer
• FS-8283 [core] Handle RTP Contributing Source Identifiers (CSRC)
• FS-8275 [core] Fix for broken DTMF
• FS-8282 [core] Fix for sleep is not allowing interruption by uuid_transfer
• FS-8240 [mod_local_stream] Fixed a/v getting out of sync when running in the background and added video profile parameter for recording 264 and made it default
• FS-8216 [mod_av] Fixed a regression in hup_local_stream from last commit
• FS-8274 [mod_av] Fixed a memory leak caused by images not being freed in video_thread_run
• FS-7989 [fixbug.pl] Escape double quotes from summary and added more debugging data
• FS-8246 [mod_json_cdr] Use seconds as default value for delay parameter
• FS-8256 [mod_opus] More FMTP cleanup
• FS-8284 [mod_opus] Use use-dtx setting from config in request to callee.
• FS-8234 [mod_opus] Send correct (configured) fmtp ptime,minptime,maxptime when originating call

 

And, this past week in the FreeSWITCH 1.4 branch we had 6 new commits merged in from master. And the FreeSWITCH 1.4.23 release is here! Go check it out!

The following bugs were squashed:

• FS-8190 [mod_event_socket] When using nixevent, freeswitch stops sending us certain custom event that were NOT part of the nixevent command
• FS-7673 [mod_v8] ODBC NULL value incorrectly evaluated
• FS-8215 Fixed the accuracy of MacOSX nanosleep
• FS-8269 [mod_sms] Fixed a build issue
• FS-8244 [mod_dptools] Fixed a compilation issue

 

 

Some aspects are now table stakes for WebRTC API Platforms.

There are 20+ vendors out there who are after your communications. They are willing to take up the complexity and maintenance involved with running real time voice and video that you may need in your business or app. Some are succeeding more than others, as it always has been.

So how do you as a potential customer going to choose between them?

Here are a few things I’ve noticed in the two years since I first published my report on this WebRTC API space:

1. Vendors are finding it hard to differentiate from one another. Answering the question to themselves of what they do better than anyone else in this space (or at least from the vendors they see as their main competitors) isn’t easy
2. Vendors often times don’t focus. They try to be everything to everyone, ending up being nothing to most. You can see what they are good for if you look from the sidelines, feel how they pitch, operate, think – but they can’t see it themselves
3. Vendors attempt to differentiate over price, quality and ease of use. This is useless.

Table Stakes

Most vendors today have pretty decent quality with a set of APIs that are easy. Pricing varies, but usually reasonable. While some customers are sensitive to pricing, others are more focused on getting their proof of concept or initial beta going – and there, the price differences doesn’t matter in the short to medium term anyway.

The problem is mainly vendor lock-in, where starting to use a specific vendor means sticking with it due to high switching costs later on. But then, savvy developers use multiple vendors or prepare adapter layers to abstract that vendor lock-in.

Vendors need to think more creatively at how they end up differentiating themselves. From carving a niche to offering unique value.

My Virtual Coffee

This is the topic for my first Virtual Coffee session, which takes place on October 14.

It is something new that I am trying out – a monthly meeting of sorts. Not really a webinar. But not a conference either.

Every month, I will be hosting an hour long session:

• It will take place over a WebRTC service – I am dogfooding
• It will cover a topic related to the WebRTC ecosystem (first one will be differentiation of WebRTC API Platform vendors)
• It will include time for Q&A. On anything
• Sessions will be recorded and available for playback later on
• It is open to my consulting customers and those who purchased my report in the past year

If you are not sure if you are eligible to join, just contact me and we’ll sort things out.

I’d like to thank the team at Drum for letting me use their ShareAnywhere service for these sessions – they were super responsive and working with them on this new project was a real joy for me.

Virtual Coffee #1 Title: WebRTC PaaS Growth Strategies How WebRTC API vendors differentiate and attempt to grow their business When: Oct 14. 13:30 EDT (add to calendar) Where: Members only What’s next?

Want to learn more about this space? The latest update of my report is just what you need

 

The post How NOT to Compete in the WebRTC API Space appeared first on BlogGeek.me.

Kamailio SIP Server v4.3.3 stable is out – a minor release including fixes in code and documentation since v4.3.2 – configuration file and database compatibility is preserved.Kamailio (former OpenSER) v4.3.3 is based on the latest version of GIT branch 4.3, therefore those running previous 4.3.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.3.x.Resources for Kamailio version 4.3.3Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.3.x release series is summarized in the announcement of v4.3.0:

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

Some people are fidgeting on their chairs now, while others are happier than they should be.

I’ll start by a quick disclaimer: I like Google. They know when you acquire companies to fit my schedule – just got back from vacation – so I actually have time to cover this one properly.

Let’s start from the end:

Google and Apple are the only companies that can make RCS a reality.

To all intent and purpose, Google just gave RCS the kiss of life it needed.

Google just acquired Jibe Mobile, a company specializing in RCS. The news made it to the Android official blog. To understand the state of RCS, just look at what TechCrunch had to say about it – a pure regurgitation of the announcement, with no additional value or insights. This isn’t just TechCrunch. Most news outlets out there are doing the same.

* Dataset subscribers have the acquisitions table updated with this latest information

Why on earth is Google investing in something like RCS?

RCS

RCS stands for Rich Communication Suite. It is a GSMA standard that has been around for a decade or so. It is already in version 5.2 or so with little adoption around the world.

What is has on offer is an OTT-style messaging capabilities – you know the drill – an address book, some presence information, the ability to send text and other messages between buddies. Designed by committee, it has taken a long time to stabilize – longer than it took Whatsapp to get from 0 to 800. Million. Monthly active users.

The challenge with RCS is the ecosystem it lives in – something that mires other parts of our telecom world as well.

Put simply, in order to launch such a service that needs to take any two devices in the world and connect them, we need the following vendors to agree on the need, on the priority, on the implementation details and on the business aspects:

• Chipset vendors
• Handset vendors
• Mobile OS vendors
• Telco vendors
• Telcos

Call it an impossible feat.

In a world where Internet speeds dictate innovation and undercut slower players, how can a Telco standard succeed and thrive? The moment it gets out the door it feels old.

Google and Messaging

Google has many assets today related to messaging:

• Android, the OS powering 1.4 billion devices, where 1 billion of them call home to Google’s Play service on a monthly basis
• Hangouts, their own chat/voice/video service that is targeted at both consumers and enterprises. It is part of Android, but also works as an app or through the browser virtually everywhere
• Firebase, a year-old acquisition that is all about powering messaging (and storage) for developing apps

As Kranky puts it, they were missing an iMessage service. But not exactly.

Google thrives from large ecosystems. The larger the better – these are the ones you can analyze, optimize and monetize. And not only by building an AdWords network on top of it.

The biggest threats to Google today, besides regulators around the globe, would be:

1. Apple, who is doing its darnedest today to show off their better privacy policies compared to Google
2. Facebook, who is vying after Google’s AdWords money with its own social network/ads empire
3. Telcos, who can at a whim decide to shut off Google’s ambitions – by not promoting Android, making it hard for YouTube or other services to run, etc.

Getting into RCS and committing to it, as opposed to doing a half witted job at an RCS client on vinyl Andorid, gives Google several advantages:

• It puts them at the good side of Telcos, which can’t be bad
• Improves Android’s standing as an ecosystem, and making it easier for Google to force the hands of handset manufacturers and chipset vendors in adjacent domains
  • Maybe getting the codecs they want embedded as part of the device for example?
  • Forcing improvements on mobile chipset designs that offer better power management/performance for all messaging apps
• Opens the door to deeply integrating Hangouts with RCS/Telco messaging
• Enabling Google to become the gateway to the telco messaging space
  • Got a device running Android? An RCS client is already there and running
  • Don’t have Android? Connect through your browser from everywhere
  • Or just install that Google RCS app – it already has a billion downloads on it, as opposed to a measly 5,000 downloads of an operator-brand app
• Becoming the glue between consumer and enterprise
  • Hangouts may well be a consumer type of a product, but it is part of the Google Apps offering to enterprises
  • Carriers are struggling in monetizing consumer services these days besides connectivity, and Google is fine with giving consumers a free ride while making money elsewhere
  • Google is struggling with getting into the enterprise space. Hangouts is marginal compared to Microsoft Lync/Skype and Cisco
  • Offering direct connectivity to the carrier’s messaging for consumers can bridge that gap. It increases the value of RCS to the enterprise, making Google a player that can integrate better with it than competition

Why Acquire Jibe?

Beside being a nice signal to the market about seriousness, Jibe offers a few advantages for Google.

1. They are already deployed through carriers
2. Their service is cloud based, which sits well with Google. It means traffic goes through Jibe/Google – something which places Google as the gateway between the customer and the Telco – a nice position to be in

In a way, Jibe isn’t caught up in the old engineering mentality of telco vendors – it provides a cloud service to its customers, as opposed to doing things only on premise. While Google may not need the architecture or code base of Jibe Mobile, it can use its business contracts to its advantage – and grow it tenfold.

When your next RCS message will be sent out, Google will know about it. Not because it sits on your device, but because it sits between the device and the network.

Why will Telcos Accept this?

They have no choice in the matter.

RCS has been dead for many years now. Standardization continues. Engineers fly around the world, but adoption is slow. Painfully slow. So slow that mid-sized OTT players are capable of attracting more users to their services. It doesn’t look well.

And the problem isn’t just the service or the UI – it is the challenge for a carrier to build the whole backend infrastructure, build the clients for most/all devices on its network and then launch and attract customers to it.

Google embedding the client front end directly into Android and a part of the devices means there’s no headache in getting the service to the hands of customers and putting it as their default means of communications.

Google offering the backend for telcos in a cloud service means they no longer have to deal with the nasty setup and federation aspects of deploying RCS.

Only thing they need to do is sign a contract and hit the ground running.

An easy way out of all the sunk costs placed in RCS so far. It comes at a price, but who cares at this point?

The End Game

There are three main benefits for Google in this:

1. Selling more Google devices
   • If these devices come equipped with RCS, and their backend comes from the same Telco and operated by Google, then why should a Telco promote another device to its customers?
   • It isn’t limited to Android versus an iOS device – it also relates to Chrome OS versus Windows 10
   • When mobility needs will hit tablets and laptops and the requirement to be connected everywhere with these devices will grow, we might start seeing Telcos actually succeeding in selling such devices with connectivity to their network. Having RCS embedded in these devices becomes interesting
2. The next billion
   • Facebook and Google are furiously thinking of the next billion users. How to reach them and get them connected
   • With RCS as part of the messaging service a Telco has on offer, they are less dependent on third party apps to connect
   • With Google having both RCS and Hangouts, it increases the size of their applicable users base and the size of their ecosystem
3. Carrier foothold
   • Carriers are reluctant when it comes to Google. They aren’t direct competitors, but somehow, it can feel that way at times – Google Fiber and Google Fi are prime examples of what Google can do and is doing
   • This is why having cloud services owned by Google and connected to the heart of a Telco is enticing to Google. It gives them a better foothold inside the carrier’s network

Where’s WebRTC?

Not really here. Or almost not. It isn’t about WebRTC. It is about telecom and messaging. Getting federated access that really works to the billions of mobile handsets out there.

Jibe has its own capabilities in WebRTC, a gateway of sorts that enables communicating with the carrier’s own network from a browser. How far along is it? I don’t know, and I don’t think it even matters. Connecting Jibe RCS cloud offering to Google Hangouts will include a WebRTC gateway. If it will or won’t be opened and accessible to others is another question (my guess is that it won’t be in the first year or two).

An interesting and unexpected move by Google that can give RCS the boost it desperately needs to succeed.

 

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

The post Android Does… RCS !? What About WebRTC? Hangouts? appeared first on BlogGeek.me.

We’re preparing for #KazooCon! Are you ready for the Unified Communications Revolution on Monday? If you have not purchased tickets, do so right now…only five tickets remain http://ow.ly/SPQgr

The SmartPBX App combines comprehensive PBX functionality with user-friendly interface. Set up new users in minutes, manage all of your accounts, reduce installation and labor costs, and provide business-specific user features. All services are controlled via API’s, allowing you to extend the App functionality as needed. Within the interface you have the ability to create, manage, and remove services for your users.  

2600Hz offers a true Unified Communications solution, providing telco solutions that can be deployed by anyone in the continental United States. The SmartPBX App is highly scalable, redundant and clustered, providing increased functionality and time-savings when compared to traditional VoIP telecom carriers. Remotely manage your entire product offering within the SmartPBX Dashboard and quickly diagnose and solve most issues that may arise.

See SmartPBX at Work

So what Features Make 2600Hz’s SmartPBX Different?

Total Administrator Visibility - The SmartPBX dashboard provides a comprehensive overview of your entire product offering. Within the dashboard, review the total users, devices, main numbers and conference numbers. Have peace of mind knowing that your network is working properly just by looking at the dashboard.

Manage All Users & Features - Create users and manage all their settings within the Users tab of SmartPBX. Add Users, attach Phone Numbers, Devices and assign specific User Features within the UI. Manage what features your users can access including Ring Groups, Caller ID, Call Forwarding, Hot Desking, Voicemails, Faxbox, Conference Bridge, Find Me, Follow Me, Music-On-Hold and Inbound Call Recording.

Purchase, Port and Assign Phone Numbers - Provide each user with their unique direct-dial phone and extension number. Assigning and managing numbers within the UI is extremely easy, and you can purchase a number in seconds.

Provision Devices - Provision Yealink, Polycom and Cisco devices in minutes with our built-in auto- provisioning system. The UI comes pre-populated with these manufacturers and devices are continuously being added. Bring in your own devices or allow users to bring in their own. Devices can be provisioned remotely, users just need to provide their MAC and IP address, then plug in and reset their device.

Call Handling and Virtual Receptionist - Create customized greetings and call routes to give businesses that professional touch. Set up a main business phone number and utilize the pre-built Virtual Receptionist to handle inbound calls. Virtual Receptionist will professionally and automatically transfer calls to an appropriate department or person. Set time-of-day routing and holidays, effectively managing business hours.

Conference Numbers - Create a direct-dial conference number. Pre-programmed room numbers and conference room PINs allow access to the conference.

Billing and Transaction Services - Easily add credit cards on file and change accordingly. Create and set limits for users that include inbound and outbound trunks, and per minute credits.

Call Logs - Diagnose call delivery problems with ease. Every call is tracked and call problems can be reported with a single click.

The FreeSWITCH 1.6.2 release is here! This is the release of the Video/MCU branch!

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.2.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation (Please Note the updated location for 1.6 packages)

And we’re dropping support in packaging for anything older than Debian 8.0 and anything older than Centos 7.0 due to a number of dependency issues on older platforms.

New features that were added:

• FS-8094 [verto_communicator] Added googEchoCancellation, googNoiseSuppression, and googHighpassFilter settings to the UI enabled by default
• FS-8107 [switch_ivr_menu] Adding CUSTOM esl events menu::enter and menu::exit when a call enter and exit an ivr menu
• FS-6833 Allow Freeswitch to initiate late offer calls
• FS-8075 [mod_hiredis] Add conf file to spec file too and updates for limit release case
• FS-8053 Handle a=sendonly, a=sendrecv, a=recvonly to change who is sending video during a call

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

• FS-7966 [Windows] Build now uses visual studio 2015 and builds successfully, but is still missing video functionality
• FS-8124 [verto_communicator] Adding option –debug to grunt build, dist app will be generated without minified code.
• FS-7168 [Debian] Update packages so that FS core libraries are setup as runtime dependencies
• FS-7697 Chown the /etc/freeswitch/tls directory so that the freeswitch user can have read/write for TLS certificate generation
• FS-7966 [Windows] Explore use of nuget for wix build dependency
• FS-7967 [build] SmartOS compatibility
• FS-8072 [Debian] Fixed a missed space

The following bugs were squashed:

• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-7988 [filebug.pl] Moved -askall to -terse so old -askall behavior is default and old default is now -terse
• FS-8029 [jitterbuffer] Fixed robotic sound when using jitterbuffer
• FS-8103 [mod_rayo] Fixed handling of malformed requests
• FS-8108 [mod_lua] Removed legacy mod_lua, the regular mod_lua works with system lua now
• FS-8082 [mod_rayo] Fixed a segfault
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8116 [verto] Fixed device enumeration hanging on init
• FS-8118 [verto] Fixed calls not properly rejecting video when video is offered but only audio is accepted
• FS-7994 [verto_communicator] Using factory for group calls in history
• FS-8117 [verto_communicator] Calling verto.iceServers upon useSTUN changing on ModalSettings, correctly check for STUN setting in localStorage, and fixed ignoring useSTUN settings
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8088 [verto_communicator] Fixed members list being destroyed after switching conferences and ending the first conference
• FS-8130  Port video buffer to also support audio and remove original STFU jitter buffer, add some more resilience to video packet loss, add codec control mechanism for both call-specific debug and codec/call specific parameters, make opus function better in packet loss and latent situations, use new codec control prams to make jitter buffer lookahead FEC optionally enabled or disabled mid-call, and add a parameter to allow jitter buffer lookahead to be enabled.
• FS-8131 [mod_voicemail] Fixed issues with allowing an empty password change and then locking out the user
• FS-8136 [mod_h26x] Do not load passthru video codecs by default
• FS-8140 [mod_sofia] Fixed a user_name typo in sofia_handle_sip_i_invite
• FS-8142 Fixed  a thread cache thread-safety and caching
• FS-8075 [mod_hiredis] Fix for failover when you pull power on redis, while redis clients under load test
• FS-8144 [mod_opus] Readability and code formatting cleanup
• FS-8126 [switch_core] Fixed the pruning of a media bug causing all media bugs on a session to be pruned
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8147 [mod_erlang_event] Fixed the process spawning segfault
• FS-8149 [mod_xml_cdr] Fixed curl dependency in makefile
• FS-1772 [mod_voicemail] Fixed the reset of voicemail greeting to default to allow entering 0 to restore the default greeting

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

• Tarballs: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.4.23.tar.bz2
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-7752 [mod_rayo] Increase maximum number of elements from 30 to 1024 to allow adhearsion to create large grammars to navigate IVR menus.

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

• FS-8055 [build] Add confdir variable to freeswitch.pc

The following bugs were fixed:

• FS-7135 [mod_sofia] Fixed response to re-invite with duplicate sdp (such as we get from session refresh) when soa is disabled to include an sdp. Fixed t.38 fax failure on session refresh
• FS-7903 [proxy_media] Fix Codec PROXY Exists but not at the desired implementation. 0hz 0ms 1ch error when using proxy media.
• FS-8056 [mod_voicemail] Fixed a segfault on vm_inject, regression from FS-7968
• FS-7968 [mod_voicemail] Fixed verbose events
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8082 [mod_rayo] Do not remove items from hash while iterating
• FS-8103 [mod_rayo] Handle where finishes unexpectedly before start event is received
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-8142 Fixed thread cache thread-safety and caching
• FS-8185 [core] Allow xml preprocessor to expand variables where the resulting value is much longer than the original size
• FS-8167 [mod_lua] Fixed a segfault caused by using api:execute or session:execute and not quoting the first argument like api:execute(log, “Second argument”) instead of api:execute(“log”, “Second argument”)
• FS-8169 Fixed uuid_displace on stereo channels can lead to memory corruption causing a crash
• FS-8114 Fixed opus and telephone event payload types colliding on REFER

 

Hello, again. This past week in the FreeSWITCH master branch we had 57 commits! Some of our features for this week are: added reset button to default settings, auto-provision/config support, No Camera option, and splash screen feature in the verto communicator.

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

New features that were added:

• FS-8095 [verto_communicator] Added reset button to default settings
• FS-8095 [verto_communicator] Do not reset name and email upon logout
• FS-8102 [verto_communicator] Added auto-provision/config support
• FS-8205 [verto_communicator] Added splash screen feature
• FS-8193 [verto communicator] Added No Camera option
• FS-8183 [verto_communicator] Add google API logins, moved google ClientID to config file where it belongs, and tweaks to the CSS
• FS-8089 [verto_communicator] Opening members list when start conference
• FS-8204 [verto] Added stereo audio support for opus on FireFox and add sprop-stereo
• FS-8042 FS-8182 [mod_sofia] Added ping time (in ms) to sip_registrations table, displays as part of the show commands that show registration details, add force_ping=true user var to force options ping on individual registered endpoints
• FS-8130 Added support for timestamp based counting for jitter buffer in audio mode

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

• FS-8230 FSRTC – calling localStream.stop when it’s available or localStream.active = false to make it work on newer chrome canary
• FS-7697 [Debian] Moved chown of /etc/freeswitch/tls to postinst
• FS-7909 [Debian] Removed explicit set of WorkingDirectory
• FS-7130 [Debian] Use systemd RuntimeDirectory for /run/freeswitch

The following bugs were squashed:

• FS-8196 [verto_communicator] Fixed sidebar layout when user is moderator and added nowrap to white-space
• FS-8200 [verto_communicator] Ending screenshare if user hangup call and screenshare is now for all instead of only mods
• FS-7980 [verto_communicator] Fixed video padding-top
• FS-8224 [verto_communicator] Allowed CallerID to be set from login settings
• FS-8213 [verto] Added support to skip permission checks
• FS-8202 [verto] Stopped peer when ending screen share
• FS-8210 [verto] Fix for module being unloaded while it is in use
• FS-8190 [mod_event_socket] When using nixevent, freeswitch stops sending us certain custom event that were NOT part of the nixevent command
• FS-7673 [mod_v8] ODBC NULL value incorrectly evaluated
• FS-8031 [RTP] Fix for Firefox giving up because we replied to their stun
• FS-8130 [mod_conference] Add jb_video_low_bitrate for a bit rate to ask for when the jitter buffer is taxed
• FS-8211 [mod_conference] Fixed video recordings of layouts with overlap having flickering video
• FS-7911 [mod_conference] Fixed a memory leak
• FS-8130 Fixed a regression in bridged channels with jitterbuffers
• FS-8215 Fixed the accuracy of MacOSX nanosleep
• FS-8216 [mod_av] Fixed for occasional lip sync problems when recording

And, this past week in the FreeSWITCH 1.4 branch we had 8 new commits merged in from master. And the FreeSWITCH 1.4.23 release is here!Go check it out!

New features that were added:

• FS-8042 FS-8182 [mod_sofia] Added ping time (in ms) to sip_registrations table, displays as part of the show commands that show registration details, add force_ping=true user var to force options ping on individual registered endpoints

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

• FS-7130 [Debian] Use systemd RuntimeDirectory for /run/freeswitch
• FS-7909 [Debian] Removed explicit set of WorkingDirectory

The following bugs were squashed:

• FS-8169 Fixed uuid_displace on stereo channels can lead to memory corruption causing a crash
• FS-8167 [mod_lua] Fixed a segfault caused by using api:execute or session:execute and not quoting the first argument like api:execute(log, “Second argument”) instead of api:execute(“log”, “Second argument”)
• FS-8185 [core] Allow xml preprocessor to expand variables where the resulting value is much longer than the original size
• FS-7911 [mod_conference] Fixed a memory leak

Lots of Node. Little of WebRTC.

It has been quite some time since my last WebRTC book review. So when I got an indication that there is another book with WebRTC inside it, I had to read it. Which is what got me to Multiplayer Game Development with HTML5 by Rodrigo Silveira.

The promise of WebRTC in this book? Learning to “create peer-to-peer gaming using WebRTC”. I was intrigued. Spent reading it a few hours – and was happy about it, even though the WebRTC part of it was limited in its value.

This book takes the reader into a “Hello World” implementation of an online HTML5 multiplayer game. It is done by taking a step by step approach to implementing the classic snake game. First in HTML5, using a backend. And then by building on top of it all the rest.

The book itself is focused on Node.js development of the game, taking care to explain and use concepts of authoritative game servers – servers that make the main decisions in a game. It connects that to responsiveness and fluidity of the game, etc.

To those interested in real time communications, this is an interesting book. It has a lot of the same thought processes of developing signaling protocols and implementing their backend, dealing with responsiveness, latency and causality of message passing. It also handles the game lobby – the place where you connect players – you can view this as a conferencing server (the signaling part of it).

Rodrigo mentions WebRTC almost in passing – as a way of reducing latency by making use of the data channel in WebRTC, but that’s about it. There’s no real discussion or example of how to integrate it in a multiplayer game where you have an authoritative server and clients that communicate directly with each other at the same time.

That said, I felt the book is an interesting one for those developing WebRTC – and it wasn’t because of the WebRTC parts of it.

If you are interested in architecture, design, signaling or just programming – this book is a really interesting read.

I warmly recommend it.

The post WebRTC Book Review: Multiplayer Game Development with HTML5 appeared first on BlogGeek.me.