News from Industry

Someone should build a generic fallback…

If you don’t know Socket.io then here’s the gist of it:

• Socket.io is a piece of JS client code, and a server side implementation
• It enables writing message passing code between a client and a server
• It decides on its own what transport to use – WebSocket, XHR, SSE, Flash, pigeons, …

It is also very popular – as a developer, it lets you assume a WebSocket like interface and develop on top of it; and it takes care of all the mess of answering the question “but what if my browser/proxy/whatever doesn’t support WebSocket?

I guess there are use cases where the WebRTC data channel is like that – you’d love to have the qualities it gives you, such as reduced server load and latency, but you can live without it if you must. It would be nice if we’d have a popular Socket.io-like interface to do just that – to attempt first to use WebRTC’s data channel, then fallback to either a TURN relay for it or to WebSocket (and degrading from there further along the line of older transport technologies).

The closest I’ve seen to it is what AirConsole is doing. They enable a smartphone to become the gamepad of a browser. You get a smartphone and your PC connected so that whatever you do in the phone can be used to control what’s on the PC. Such a thing requires low latency, especially for gaming purposes; and WebRTC probably is the most suitable solution. But WebRTC isn’t always available to us, so AirConsole just falls back to other mechanisms.

While a gaming console is an obvious use case, and I did see it in more instances lately, I think there’s merit to such a generic framework in other instances as well.

Time someone implemented it

The post Where’s the Socket.io of WebRTC’s Data Channel? appeared first on BlogGeek.me.

Links:

http://tldp.org/HOWTO/Traffic-Control-HOWTO/intro.html

Don’t wait up for Apple to get you WebRTC in the near future.

Like many others, I’ve seen the minor twitter storm of our minuscule world of WebRTC. The one in which a screenshot of an official Apple job description had the word WebRTC on it. Amir Zmora does a good job of outlining what’s ahead of Apple with adding WebRTC. The thing he forgot to mention is when should we be expecting anything.

The below are generally guesses of mine. They are the roadmap I’d put for Apple if I were the one calling the shots.

When will we see an Apple WebRTC implementation?

Like anyone else, I am clueless to the inner workings of Apple. If the job postings tell us anything it is that Apple are just starting out. Based on my experience in implementations of media engines, the time it took Google, Mozilla and Microsoft to put a decent release out, I’d say:

We are at least 1 year away from a first, stable implementation

It takes time to implement WebRTC. And it needs to be done across a growing range of devices and hardware when it comes to the Apple ecosystem.

Where will we see an Apple WebRTC implementation?

Safari on Mac OS X. The next official release of it.

• This one is the easiest to implement for with the least amount of headache and hardware variance
• I am assuming iOS, iPhone and iPad get a lot more stress and focus in Apple, so getting something like WebRTC into them would be more challenging

The Safari browser on iPad and iPhone will come next. Appearing on iPhone 6 and onwards. Maybe iPhone 5, but I wouldn’t bet on it.

We will later see it supported in the iOS WebView support. Probably 9-12 months after the release of Safari on iOS.

The Apple TV would be left out of the WebRTC party. So will the Apple Watch.

Which Codecs will Apple be using?

H.264, AAC-ELD and G.711. Essentially, what they use in FaceTime with the addition of G.711 for interoperability.

• Apple won’t care about media quality between Apple devices and the rest of the world, so doing Opus will be considered a waste of time – especially for a first release
• H.264 and AAC-ELD is what you get in FaceTime today, so they just use it in WebRTC as well
• G.711 will be added for good measures to get interoperability going
• VP8 will be skipped. Microsoft is skipping it, and H.264 should be enough to support all browsers a year from now

Will they aim for ORTC or WebRTC APIs?

Apple sets its sights on Google. They now hold Microsoft as best-friends with the Office releasing on iOS.

On one hand, going with ORTC would be great:

• Apple will interoperate with Microsoft Edge on the API and network level, with Chrome and Firefox on the network level only
• Apple gets to poke a finger in Google’s eye

On the other hand, going with WebRTC might be better:

• Safari tends to do any serious upgrades with new releases of the OS. Anything in-between is mostly security updates. This won’t work well with ORTC and will work better with WebRTC (WebRTC is expected to be finalized in a few months time – well ahead of the 1 year estimate I have for the Apple WebRTC implementation)
• Microsoft Edge isn’t growing anywhere yet, so aligning with it instead of the majority of WebRTC enabled browsers might not make the impact that Apple can make (assuming they are serious about WebRTC and not just adding it as an afterthought)

Being adventurous, I’d go for ORTC if I were Apple. Vindictiveness goes a long way in decision making.

Extra

On launch day, I am sure that Bono will be available on stage with Tim Cook. They will promise a personal video call over WebRTC running in WebKit inside Safari to the first 10 people who stand in line in Australia to purchase the next iPhone.

And then again, I might be mistaken and tomorrow, WebRTC will be soft launched on the Mac. Just don’t build your strategy on it really happening.

 

 

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

The post Apple WebRTC Won’t Happen Soon appeared first on BlogGeek.me.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during November 30 – December 02, 2015.The content will be based on latest stable series of Kamailio 4.3.x, released in June 2015, the major version that brought a large set of new features, currently having the minor release number v4.3.3.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:

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

An interesting resource for those relying on NodeJS for various needs and using Kamailio as load balancer in front of Asterisk or eventually other SIP systems (Freswitch, media servers, PSTN gateways, etc…):

• https://www.npmjs.com/package/kamailio-etcd-dispatcher

Practically, this tool can be run along side with Kamailio and each SIP system (e.g., Asterisk), usingEtcd as communication channel to publish what SIP systems are available. Based on this information, the tool instance next to Kamailio is generating the dispatcher.list and instructs Kamailio to reload that file.Etcd is a highly-available key value store for shared configuration and service discovery developed as part of CoreOS project.

The team at ThinQ show how to set up your routing profile, carrier selection, high volume traffic management, and LCR routing.

Founder and CEO Mikhail Rodionov discusses all the projects and code contributions that they have built for Kazoo over the past year.

The Voxter team discuss code contributions to the Kazoo platform, discuss how they are utilizing the platform, and give an in-depth demo of WhApps.

Telnexus CEO Vernon Keenan discuss how he built the Managed Service Provider Telnexus from the ground up and the lessons he has learned in the process.

In a competitive market, high quality voice services alone are rarely enough. Lon Baker speaks about the customer lifecycle, back office systems from Sales to CRM to deployment, and how to drive profitable growth while delivering an excellent customer experience.

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

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.

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.

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.

A clash of worlds.

With the gazillions of devices said to be part of the IOT world, how they interact and speak to each other is going to be important. When we talk about the Internet of Things, there are generally 3 network architectures that are available:

• Star topology
• P2P
• Hubs and spokes

1# – Star Topology

The star topology means that each device gets connected to the data center – the cloud service. This is how most of our interent works today anyway – when you came to this website here, you got connected to my server and its hosting company to read this post. When you chat on Facebook, your messages goes through Facebook’s data centers. When your heat sensor has something to say… it will probably tell it to its server in the cloud.

Pros

• We know how it works. We’ve been doing it for a long time now
• Centralized management and control makes it easier to… manage and control
• Devices can be left as stupid as can be
• Data gets collected, processed and analyzed in a single place. This humongous amounts of data means we can derive and deduce more out of it (if we take the time to do so)

Cons

• Privacy concerns. There’s a cloud server out there that knows everything and collects everything
• Security. Assuming the server gets hacked… the whole network of devices gets compromised
• As the number of devices grows and the amount of data collected grows – so do our costs to maintain this architecture and the cloud service
• Latency. At times, we need to communicate across devices in the same network. Sending that information towards the cloud is wasteful and slower

2# – P2P

P2P means devices communication directly with each other. No need for mediation. The garage sensor needs to open the lights in the house and start the heating? Sure thing – it just tells them to do so. No need to go through the cloud.

Pros

• Privacy. Data gets shared only by the devices that needs direct access to the data
• Security. You need to hack more devices to gain access to more data, as there’s no central server
• Low latency. When you communicate directly, the middleman isn’t going to waste your time
• Scale. It is probably easier to scale, as the more devices out there doesn’t necessarily means most processing power required on any single device to handle the network load

Cons

• Complicated management and control. How do these devices find each other? How do they know the language of one another? How the hell do you know what goes in your network?
• There’s more research than real deployments here. It’s the wild west
• Hard to build real smarts on top of it. With less data being aggregated and stored in a central location, how do you make sense and exploit big data analytics?

3# – Hubs and Spokes

As with all technology, there are middle ground alternatives. In this case, a hubs and spokes model. In most connected home initiatives today, here’s a hub device that sits somewhere in the house. For example, Samsung’s SmartThings revolves around a Hub, where all devices connect to it locally. While I am sure this hub connects to the cloud, it could send less or more data to the cloud, based on whatever Samsung decided to do with it. It serves as a gateway to the home devices that reduces the load from the cloud service and makes it easier to develop  and communicate locally across home devices.

Pros

• Most of what we’d say is advantageous for P2P works here as well
• Manageability and familiarity of this model is also an added bonus of this model

Cons

• Single point of failure. Usually, you won’t build high availability and redundancy for a home hub device. If that device dies…
• Who’s hub will you acquire? What can you connect to it? Does that means you commit to a specific vendor? A hub might be harder to replace than a cloud service
• An additional device is one more thing we need to deal with in our system. Another moving part

But there’s more

In the recent Kranky Geek event, Tim Panton, our magician, decided to show how WebRTC’s data channel can be used to couple devices using a duckling protocol. To keep things short, he showed how a device you just purchased can be hooked up to your phone and make that phone the only way to control and access the purchased device.

You can watch the video below – it is definitely interesting.

To me this means that:

1. We don’t discuss enough the network architectures and topologies that are necessary to make IOT a reality
2. The result will be hybrid in nature, though I can’t say where will it lead us

 

Kranky and I are planning the next Kranky Geek - Q1 2016. Interested in speaking? Just ping me through my contact page.

The post IOT Messaging – Should we Head for the Cloud or P2P? appeared first on BlogGeek.me.

The FreeSWITCH team added some neat new features this week including: expanded support for limit_* functionality in mod_hiredis and the addition of the field conferenceMemberID to the event broadcasted to inform a verto client about joining a conference.

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

New features that were added:

• FS-8375 [mod_conference] Add the field conferenceMemberID to the event broadcasted to inform a verto client about joining a conference.
• FS-8377 [mod_hiredis] Adding expanded support for limit_* functionality

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

• FS-8298 [mod_gsmopen] Fixed a build error
• FS-8362 [Debian] Now if you install with freeswitch-all you will get the default fonts too

The following bugs were squashed:

• FS-8363 [configuration] Don’t register gateways from directory because it registers over what appears to be ipv6 but doesn’t work correctly
• FS-8365 [verto_communicator] Fixed a bug with the chat notifications not going away unless you exited and came back to it
• FS-8336 [verto_communicator] Updating mic and video overlay controls upon receiving member update from live array and use conferenceMemberID when checking if the updated member is the local user
• FS-8307 [mod_conference] Fixed an issue with the order of codecs causing loss of RTP stream
• FS-8280 [mod_conference] Fixed an issue with FS sending redundant stop-recording event notifications
• FS-8130 [mod_conference] Fixed a regression causing excessive mark bit detection in some cases
• FS-8384 [mod_conference] Fixed some locking contention issues between external commands and the video engine
• FS-8338 [core] Fixed an issue when setting the ringback variable with an outbound call via the bridge app, if the inbound leg is stereo the ringback tone is still rendered as mono causing the resulting ringback to be higher pitched and incorrect.
• FS-8366 [core] Fixed a segfault in rxfax
• FS-8275 [core] Fixed an issue with broken RFC2833 DTMF
• FS-8368 [core] Reduce logging for audio/video sync because some call lines were repeating too often for callers in a conference
• FS-8372 [core] Fixed a no media bug caused by sofia sending the wrong response to RTP/SAVPF without DTLS
• FS-8381 [core] Reset jitter buffer if period loss is too high
• FS-8382 [core] Fixed a segfault with inbound-proxy-media enabled
• FS-8378 [mod_esf] [core] Fixed a crash when using esf_page over loopback when transcoding and added tests for esf over loopback. Also refactor a bit to clarify code and get better debug in gdb
• FS-8115 [mod_sofia] Disabled unnecessary session timer re-invites for webrtc
• FS-8370 [mod_rayo] Fixed another place in where a message was freed after being queued for delivery. This resulted in a freed object being serialized, crashing FS
• FS-8287 [mod_opus] Fixed a segfault from refactor

The FreeSWITCH 1.4 branch had a few bug fixes added this week.

The following bugs were squashed:

• FS-8335 [mod_easyroute] Fixed a small error check that results in error message not being displayed
• FS-8370 [mod_rayo] Fixed another place in where a message was freed after being queued for delivery. This resulted in a freed object being serialized, crashing FS

 

Learn to run faster.

WebRTC isn’t yet standardized. It is on the way there. That said, there are already more than 800 different vendors and services out there that are making use of it – many in production, with commercial services.

There are main 3 approaches to a WebRTC-based service:

1. Browser based service, where the user interacts with the service solely through a web browser
2. App based service, where users interact with the service via WebRTC mobile apps
3. Hybrid approach, where the users can interact via a web browser or a WebRTC mobile app

That third alternative is the most challenging. The reason for the challenge isn’t a technical one, but rather one of mind set.

Fippo, who knows about the WebRCT testing service I am a part of, sends me every once in awhile issues he bumps into. This one that he shared with me recently from the webrtc-discuss group was an eye opener: someone running a native C++ app got WebRTC compiled and linked to his own app, and assuming it will work with browsers. And it did. Up until recently:

Chrome 46 started sending UDP/TLS/RTP/SAVPF in the profile field of the m-line as has been announced a while back in https://groups.google.com/forum/#!topic/discuss-webrtc/ZOjSMolpP40

Your library version has to be pretty old to be affected by this (parsing this should have been supported since mid-2014).

Here are some thoughts about this one:

• If you run WebRTC in browsers, your main concern about interoperability is around
  • Browsers changing their APIs and deprecating past capabilities
  • Working the kinks of interoperability across browser vendors
• If you wrap WebRTC in your app and use it there alone, then your concerns are minor – you live in a rather “protected” world where you control everything
• If you connect from an app to a browser with WebRTC, you’ll need to maintain the WebRTC library in your own app
  • Making sure it works with the latest browser
  • Updating and patching it as you move along

It means that mobile apps must run at the speed of the browser – whenever a new browser version gets released, you must be sure it works with your own version of WebRTC in your app. You should probably get your version updated at the same speed (that’s every 6 weeks or even less, once we’ll have 3 full browsers supporting it properly).

What are you to do if that’s your use case? Here are some suggestions:

#1 – DIY only if you can commit

Don’t put someone in your team to port WebRTC on your own.

If you do, then make sure you know this isn’t a one-time effort. You’ll need to make investments in upgrading the ported library quite frequently.

To be on the safe side, I’d suggest putting the ongoing investment (not the initial porting) at around 50% of a developer’s capacity.

Also remember you have two platforms to deal with – Android and iOS.

Can’t commit to the ongoing maintenance effort? This alternative isn’t for you.

#2 – Outsource to an independent developer with care

If you decide to use someone externally, who would take the WebRTC library, port it for you, assist you in integrating and optimizing it to your needs – make sure he will be there for the long run.

Same as you’ll need to invest internally to maintain this code, you’ll need to be able to call upon that person in the future.

Things to consider:

• Placing an exact price of future work of maintenance into the proposal – you don’t want to do the initial work just to find out the price hikes in the future when you need that contractor the most
• Make sure in your agreement with him his availability to you
• Budget appropriately these additional future work

#3 – Use an official product

The other alternative? Use an official product that gets you WebRTC as an SDK to mobile. Frozen Mountain’s IceLink comes to mind as a good solution.

You essentially outsource the headache of maintaining WebRTC’s interoperability with browsers to someone who does that for a living in a product package.

Make sure in the agreement with such vendors that you get regular updates and upgrades – and that these are guaranteed to work with the latest versions of the browsers (and even with the available beta versions of the browsers).

Check how regularly the vendor releases a new SDK and which ones are mandatory to upgrade to due to browser interoperability issues. Plan accordingly on your end.

#4 – Go for a WebRTC API Platform

Have your worries of this whole mess outsourced to someone else. Not only the mobile SDK part, but the whole real time comms platform.

You need to pick a vendor out of a very large set of potential vendors, which is why I’ve written and updated my own report on WebRTC APIs over the years.

Make sure to take a look at how well the vendor you select works with mobile and is committed to upgrading his own support for it.

It ain’t easy

Getting WebRTC to work well for the long run on mobile and web at the same time isn’t easy. It requires commitment as opposed to a one time effort. Be prepared, and make sure you take the approach that fits you best.

At least until WebRTC stabilizes (no reason for this to happen in the coming year), you’ll need to keep running at the speed of the browsers.

 

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

The post WebRTC Mobile to Web? Make Sure You Think at Web Speeds appeared first on BlogGeek.me.

Here’s what to expect during November.

Just wanted to share two things during this weekend.

WebRTC Summit, testing and San Francisco

I am traveling on the first week of November to San Francisco. The idea is to talk about WebRTC testing (and testRTC) at the WebRTC Summit.

I’ll be touching the challenges of testing WebRTC, which is somethings that isn’t discussed a lot out there:

1. Either there’s no challenge or problem and all is well
2. Or we’re still in the exploration phase with WebRTC, with little commercial value to it

I think there needs to be more focus in that area, and not just because I co-founded a WebRTC testing company.

I plan on being at the WebRTC Summit in Santa Clara on November 3-4. Here’s more about my session if you need. I am already filling up my days around that summit with meetings in both Santa Clara and San Francisco – if you wish to meet – contact me and I’ll see if I can still squeeze you in to my agenda.

Virtual Coffee with Tsahi

The first Virtual Coffee event took place a bit over a week ago. The recording of that session still isn’t available, but will be in a week or two.

It went well and I truly enjoyed the experience – the ability to handpick the people who can participate, get them signed in through my membership area on this website, and do it all under my own brand – it was great.

I’d like to thank (again) Drum’s team with their Share Anywhere service. It is as close to what I needed as could be – and easily customizable. Their team is great to work with as well (and no – they haven’t paid for me to say this).

The next session

When? November 11, 13:30 EDT

Where? Online, of course

Agenda:

• Microsoft Edge, ORTC – what you should know about it, and how to prepare for 2016?
• Open Q&A – on the topic above, or on any other topic

Who?

• These sessions are closed sessions. They are available to the following groups
• Employees of companies who have an active subscription for my WebRTC API Platforms report
• And employees of companies who I currently consult

Last but not least

I noticed recently people contacting me and asking me not to share their stories on this blog.

To make it clear – there are three reasons for me to share stories here:

1. I heard or read about it online, in a public setting. So the assumption is that the information is already public and sharable
2. I specifically asked if this can be shared – and got permission. Usually this ends up as an interview on my site
3. I share a story, but not the details about the specific company or the people involved

I put the bread on the table mainly through consulting. This means being able to assist vendors, and that requires doing things in confidence and without sharing strategies, roadmaps, status and intents with others. If you contact me through my site, my immediate assumption is that what you share is private unless you say otherwise.

 

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

The post Upcoming: WebRTC Summit and my Next Virtual Coffee appeared first on BlogGeek.me.

Kamailio and VoIP Wild World from 2600Hz

Daniel Constantin Mierla discusses Kamailio and Kazoo integrations at KazooCon

Why reminisce in the future when we’ve got so much to do in the here and now.

This week Chad wrote a post titled What’s Next for WebRTC? It is a good post, so don’t get this one as a rant or a critique about Chad. It is just the moment I saw the title and some of the words on the accompanying visual (AR, VR, drones, Industrial, Computer Vision, 3D, Connected Cars) – I immediately knew there’s something that bugs me.

It wasn’t about the fact that WebRTC isn’t used for any of these things. It was due to two reasons:

1. We’re still not scratching the surface of WebRTC yet, so what’s the rush with what’s next?
2. I hate it when people stick a technology on anything remotely/marginally related. This is the case for the soup of words I saw in the visual…

The second one, of buzzword abuse, I can only say this: WebRTC may play a role in each and everyone of these buzzwords, but its place in these market will be minuscule compared to the market itself. For many use cases in these markets, it won’t be needed at all.

For the first one, I have decided to write this.

There are many challenges for those who wish to use WebRTC today. This is something I tried to address in the last Kranky Geek event – WebRTC is both easy and hard – depending on your pedigree.

VoIP developers will see it as the easiest way to implement VoIP. Web developers will find it hard – it is the hardest thing that you can add to a browser these days, with many moving parts.

Here’s the whole session if you are interested:

Here’s what I think we should strive for with WebRTC and even ask those who work to make it available for us as a technology:

#1 – Become TCP

TCP works. We expect it to work. There are no interoperability issues with TCP. And if there are, they are limited to a minuscule number of people who need to deal with it. WebRTC isn’t like it today.

WebRTC requires a lot of care and attention. This fresh interview with Dan about the WebRTC standard shows that. You’ll find there words about versioning, deprecation, spec changes, etc. – and the problem is they affect us all.

This brings us to this minor nagging issue – if you want to use and practice WebRTC, you need to be on top of your game and have your hand on the WebRTC pulse at all times – it isn’t going to be a one-off project where you invest in developing a web app or an app and then monetize and bask in the sun for years.

The other alternative is to use a WebRTC API vendor, who needs to take care of all that on his own. This can’t be easily achieved by those who need an on premise deployment or more control over the data. This alternative also speaks louder to developers than it does to IT managers in enterprises, leaving out part of the industry of potential adopters of WebRTC.

The faster WebRTC becomes like TCP the better.

#2 – More success stories of a variety of simple use cases

There are a lot of areas where I see vendors using WebRTC. Healthcare, learning, marketplaces, contact centers, etc.

In many cases, these are startups trying to create a new market or change how the market works today. While great, it isn’t enough. What we really need is stories of enterprises who took the plunge – like the story told by AMEX last year. We also need to see these startups grow and become profitable companies – or larger vendors who acquire technology (I am talking to you Slack, Atlassian and Blackboard) use them in their products.

These stories that I am interested in? They should be able the business side of things – how using WebRTC transformed the business, improved it, got adopted by the end customers.

Where are we?

With all the impressive numbers of WebRTC flying around, we still are in the early adopters phase.

We are also still struggling with the basics.

There are many great areas to explore with WebRTC – the large scale streaming space is extremely interesting to me. So is the potential of where WebRTC fits in IOT – which is even further out than the large scale streaming one. I love to be a part of these projects and those that seek them are at the forefront of this technology.

We’re not there yet.

But we will be.

There’s no stopping this train any time soon.

 

Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

 

The post The What’s Next for WebRTC Can Wait Until We Deal With What’s Now appeared first on BlogGeek.me.