bloggeek

To H.265 (=HEVC) or not to H.265? That is the question. And the answer will be determined by the browser vendors.

I gave a keynote at a UC event here in Israel last week. I really enjoyed it. One of the other speakers, made it a point to state that their new top of the line telepresence system now supports… H.265. And 4K. I was under impressed.

H.265 is the latest and greatest in video compression. Unless you count VP9. I’ve written about these codecs before.

If you think about WebRTC in 2016 or even 2017, you need to think beyond the current video codecs – H.264 and VP8. This is important, because you need to decide how much to invest in the media side of your service, and what implications these new codecs will bring to your architecture and development efforts.

I think H.265 is going to have a hard time in the market, and not just because VP9 is already out there, streamed over YouTube to most Chrome and Firefox browsers. It will be the case due to patents.

In March this year, MPEG-LA, the good folks counting money from H.264 patents, have announced a new patent pool for HEVC (=H.265). Two interesting posts to read about this are Jan Ozer‘s and Faultline‘s. Some things to note:

• There currently are 27 patent holders
• Over 500 essential patents are in the pool
• Not everyone with patents around H.265 have joined the pool, so licensing H.265 may end up being a nightmare
• Missing are Google and Microsoft from the patent pool
• Missing are also video conferencing vendors: Polycom, Avaya and Cisco
• Unit cost for encoder or decoder is $0.20/unit
• There’s an annual cap of $25M

What does that mean to WebRTC?

• Internet users are estimated above 3 billion people and Firefox has an estimated market share of around 12%. With over 300 million Firefox users, that places Mozilla way above the cap. Can Mozilla pay $25M a year to get H.265? Probably not
• It also means every successful browser vendor will need to shell these $25M a year to MPEG-LA. I can’t see this happening any time soon
• Google has their own VP9, probably with a slew of relevant patents associated with it. These will be used in the upcoming battle with H.265 and the MPEG-LA I assume
• Microsoft not joining… not sure what that means, but it can’t be good. Microsoft might just end up adopting VP9 and going with Google here, something that might actually look reasonable
• Apple being Apple, if they decide to support WebRTC (and that’s still a big if in 2015 and 2016), they won’t go with the VPx side of the house. They will go with H.265 – they are part of that patent pool
• Cisco isn’t part of this pool. I don’t see them shelling $25M a year on top of the estimated $6M they are already “contributing” for OpenH264 towards MPEG-LA

This is good news for Google and VP9, which is the competing video technology.

When we get to the WebRTC wars around H.265 and VP9, there will be more companies on the VP9 camp. The patents and hassles around H.265 will not make things easy:

• If WebRTC votes for VP9, it doesn’t bode well for H.265
  • WebRTC is the largest deployment of video technology already
  • Deciding to ignore it as a video codec isn’t a good thing to do
• If WebRTC votes for H.265, unlikely as it may seem, may well kill standards based high quality video support across browsers in WebRTC
  • Most browsers will probably prefer ignoring it and go with VP9
  • Handsets might go with H.265 due to a political push by 3GPP (a large portion of the patent owners in H.265 are telecom operators and their vendors)
  • This disparity between browsers and handsets won’t be good for the market or for WebRTC

The codec wars are not behind us. Interesting times ahead. Better be prepared.

 

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Will Patents Kill H.265 or Will H.265’s Patents Kill WebRTC? appeared first on BlogGeek.me.

The newest game in town.

Apple’s Safari. Haven’t used it so can’t say anything. Just that most people I know are really comfortable using Chrome on Macs.

Chrome? Word’s around that it is bloated and kills your CPU. I know. On a machine with 4Gb of memory, you need to switch and use Firefox instead. Otherwise, the machine won’t survive the default tabs I have open.

Firefox? Hmm. Some would say that their Hello service is bloatware. I don’t really have an opinion. I am fine with using Firefox, but I prefer Chrome. No specific reason.

From a recent blog post from Microsoft, it seems like Microsoft Edge is faster than Chrome:

In this build, Microsoft Edge is even better and is beating Chrome and Safari on their own JavaScript benchmarks:

• On WebKit Sunspider, Edge is 112% faster than Chrome
• On Google Octane, Edge is 11% faster than Chrome
• On Apple JetStream, Edge is 37% faster than Chrome

Coming from Microsoft’s dev team, I wouldn’t believe it. Not immediately. Others have slightly different results:

Here’s the rundown (click on an individual test to see the nitty-gritty details):

• SunSpider: Edge wins!
• Octane: Chrome wins!
• Kraken: Chrome wins!
• JetStream: Chrome wins!
• Oort Online: Chrome wins!
• Peacekeeper: Firefox wins!
• WebXPRT: Chrome wins!
• HTML5Test: Chrome wins!

Some already want to switch from Chrome to Edge.

Edge is even showing signs of WebRTC support, so by year end, who knows? I might be using it regularly as well.

–

Edge is the new shiny browser.

Firefox is old news. Search Google for Firefox redesign. They had a major one on a yearly basis. Next in line is their UI framework for extensions as far as I can tell.

Safari is based on WebKit. WebKit was ditched by Google so Chrome can be developed faster. As such, Chrome is built on the ashes of WebKit.

Internet Explorer anyone?

Edge started from a clean slate. A design from 2014, where developers thought of how to build a browser, as opposed to teams doing that before smartphones, responsive design or life without Flash.

Can Edge be the best next thing? A real threat to Chrome on Windows devices? Yes.

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Is Microsoft Edge Going to be the Best Browser Around? appeared first on BlogGeek.me.

All routes are leading towards WebRTC.

Somehow, people are still complaining about adoption of WebRTC in browsers instead of checking their alternatives.

Before WebRTC came to our lives, we had pretty much 3 ways of getting voice and video calling into our machines:

1. Build an application and have users install it on their PCs
2. Use Flash to have it all inside the browser
3. Develop a plugin for the service and have users install it on their browsers

We’re now in 2015, and 3 (again that number) distinct things have changed:

1. On our PCs we are less tolerant to installing “stuff”
   • As more and more services migrate towards the cloud, so are our habits of using browsers as our window to the world instead of installed software
   • Chromebooks are becoming popular in some areas, so installing software is close to impossible in them
2. Plugins are dying. Microsoft is banning plugins in Edge, joining Google’s Chrome announcement on the same topic
3. Flash is being thrown out the window, which is what I want to focus about here

There have been a lot of recent publicity around a new round of zero day exploits and vulnerabilities in Flash. It started with a group called The Hacking Team being hacked, and their techniques exposed. They used a few Flash vulnerabilities among other mechanisms. While Adobe is actively fixing these issues, some decided to vocalize their discontent with Flash:

Facebook’s Chief Security Officer wants Adobe to declare an end-of-life date for Flash.

It is time for Adobe to announce the end-of-life date for Flash and to ask the browsers to set killbits on the same day.

— Alex Stamos (@alexstamos) July 12, 2015

Mozilla decided to ban Flash from its browser until the recent known vulnerabilities are patched.

Don’t get me wrong here. Flash will continue being with us for a long time. Browsers will block Flash and then re-enable it, dealing with continuing waves of vulnerabilities that will be found. But the question then becomes – why should you be using it any longer?

• You can acquire camera and microphone using WebRTC today, so no need for Flash
• You can show videos using HTML5 and MPEG-DASH, so no need for Flash
• You can use WebGL and a slew of other web technologies to build interactivity into sites, so no need for Flash
• You can run voice and video calls at a higher quality than what Flash ever could with WebRTC
• And you can do all of the above within environments that are superior to Flash in both their architecture, quality and security

Without Flash and Plugin support in your future, why would you NOT use WebRTC for your next service?

 

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Now That Flash and Plugins are out the Door, What’s Holding you from Adopting WebRTC? appeared first on BlogGeek.me.

We’re a lot more than I had known.

One of my recent “projects” is co-founding a startup called testRTC which offers testing and monitoring services for WebRTC based services. The “real” public announcement made about this service was here in these last couple of days and through a webinar we did along with SmartBear on the impact of WebRTC on testing.

I actively monitor and maintain a dataset of WebRTC vendors. I use it to understand the WebRTC ecosystem better. I make it a point to know as many vendors as possible  through various means. I thought I had this space pretty much covered.

What surprised me was the barrage of requests for information and demos by vendors with real services out there that came into our testRTC contact page that I just wasn’t aware of. About 50% of the requests from vendors came from someone I didn’t know existed.

My current dataset size is now reaching 700 vendors and projects. There might be twice that much out there.

Why is this important?

• A lot of the vendors out there are rather silent about what they are doing. This isn’t about the technology – it is about solving a problem for a specific customer
• There are enough vendors today to require a solid, dedicated testing tool focused on WebRTC. I am more confident about this decision we made with testRTC
• If you are building something, be sure to let me know about it or to add it to the WebRTC Index

Oh – and if you want to see a demo of testRTC in action, we will be introducing it and demoing it at the upcoming VUC meeting tomorrow.

 

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

The post What I Learned About the WebRTC Market from a Webinar on WebRTC Testing appeared first on BlogGeek.me.

Maybe.

I remember the good old days. I was hired to work on this signaling protocol called H.323. It used an interesting notation called ASN.1 with a binary encoding, capable of using a bit of data for a boolean of information. Life was good.

Then came SIP. With its “simple” text notation, it conquered the market. Everyone could just use and debug it by looking at the network. It made things so much easier for developers. So they told me. What they forgot to tell us then was how hard it is to parse text properly – especially for mere machines.

Anyway, it is now 2015. We live in a textual internet world. We use HTTP to describe our web pages. CSS to express its design and we code using JavaScript and JSON. All of these protocols are textual in nature. Our expectation is that this text that humans write (and read to debug), will be read and processed by machines.

This verbosity of text that we use over the internet is slowing us down twice:

1. Text takes more space than binary information, so we end up sending more data over the network
2. Computers need to work harder to parse text than they do binary

So we’ve struggled through the years to fix these issues. We minify the text, rendering it unreadable to humans. We use compression on the network, rendering it unreadable to humans over the network. We cache data. We use JIT (Just In Time) compilation on JavaScript to speed it up. We essentially lost most of the benefits of text along the way, but remained with the performance issues still.

This last year, several initiatives have been put in place that are about to change all that. To move us from a textual web into a binary one. Users won’t feel the difference. Most web developers most feel it either. But things are about to change for the better.

Here are the two initiatives that are making all the difference here.

HTTP/2

HTTP/2 is the latest and greatest in internet transport protocols. It is an official standard (RFC 7540) for almost 2 full months now.

Its main objective is to speed up the web and to remove a lot of the hacks we had to use to build web pages and run interactive websites (BOSH, Comet and CSS sprites come to mind here).

Oh – and it is binary. From the RFC:

Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.

While the content of our web pages will remain textual and verbose (HTML), the transport protocol used to send them, with its multitude of headers, is becoming binary.

To make things “worse”, HTTP/2 is about to encrypt everything by default, simply because the browsers who implemented it so far (Chrome and Firefox) decided not to support non-encrypted connections with HTTP/2. So the verbosity and the ability to watch messages on the network and debug things has gone down the drain.

WebAssembly

I’ve recently covered WebAssembly, comparing the decisions around it to those of WebRTC.

WebAssembly is a binary format meant to replace the use of JavaScript in the browser.

Developers will write their frontend code in JavaScript or whatever other language they fancy, and will have to compile it to WebAssembly. The browser will then execute WebAssembly without the need to parse too much text as it needs to do today. The end result? A faster web, with more languages available to developers.

This is going to take a few years to materialize and many more years to become dominant and maybe replace JavaScript, but it is the intent here that matters.

Why is it important?

We need to wean ourselves from textual protocols and shift to binary ones.

Yes. Machines are becoming faster. Processing power more available. Bandwidth abundant. And we still have clogged networks and overloaded CPUs.

The Internet of Things won’t make things any easier on us – we need smaller devices to start and communicate. We need low power with great performance. We cannot afford to ruin it all by architectures and designs based on text protocols.

The binary web is coming. Better be prepared for it.

The post Is the Web Finally Growing up and Going Binary? appeared first on BlogGeek.me.

WebRTC has been mentioned with regards to the New York Times. It isn’t about an article covering it – or a new video chat service they now offer.

I was greeted this weekend by this interesting tweet:

WebRTC being used now by embedded 3rd party on http://t.co/AaD7p3qKrE to report visitors' local IP addresses. pic.twitter.com/xPdh9v7VQW

— Mike O'Neill (@incloud) July 10, 2015

I haven’t been able to confirm it – didn’t find the culprit code piece in the several minutes I searched for it, but it may well be genuine.

The New York Times may well be using WebRTC to (gasp) find your private IP address.

In the WebRTC Forum on Facebook, a short exchange took place between Cullen Jennings (Cisco) and Michael Jerris (FreeSWITCH):

Cullen: I’ve been watching this for months now – Google adds served on slash dot for example and many other sites do this. I don’t think it is to exactly get the local ip. I agree they get that but I think there is more interesting things gathered as straight up fingerprinting.

Michael: local ip doesn’t seem that useful for marketers except as a user fingerprinting tool. They already have your public ip, this helps them differentiate between people behind nat. it’s a bit icky but not such a big deal. This issue blows up again when someone starts using it maliciously, which I’m sure will happen soon enough. I don’t get why exactly we don’t just prompt for this the same way we do camera and mic, it wouldn’t be a huge deal to work that into the spec. That being said, I don’t think it’s actually as big of a deal as it has been made either

Cullen: It’s not exactly clear to me exactly how one uses this maliciously. I can tell you most peoples IP address right now 192.168.0.1 and knowing that a large percentage of the world has that local IP does directly help you hack much. To me the key things is browsers need to not allow network connections to random stuff inside the firewall that is not prepared to talk to a browser. I think the browser vendors are very aware of this and doing the righ thting.

My local IP address is 10.0.0.1 which is also quite popular.

In recent months, we’ve seen a lot of FUD going on about WebRTC and the fact that it leaks local IP addresses. I’ve been struggling myself in trying to understand what the fuss is. It does seem bad, a web page knowing too much about me. But how is that hurting me in any way? I am not a security expert, so I can’t really say, but I do believe the noise levels around this topic are higher than they should be.

When coming to analyze this, there are a couple of things to remember:

• As Cullen Jennings points out, for the most part, the local IP address is mostly known. At least for the consumers at home
• We are already sharing so much about ourselves out of our own volition, then I don’t see how this is such an important piece of information we are giving away now
• The alternative isn’t any good either: I currently have installed on my relatively new laptop at least 4 different communication apps that have “forced” themselves on my browser. They know my local IP address and probably a lot more than that. No one seems to care about it. I can install them easily on most/all enterprise machines as well
• Browser fingerprinting isn’t new. It is the process of finding out who you are and singling you out when you surf across the web through multiple websites. Does it need WebRTC? Probably not. Go on and check if your browser have a unique fingerprint – all of the 4 browsers I checked (on 3 devices, including my smartphone’s) turned out rather unique – without the use of WebRTC
• The imminent death of plugins and the commonality of browsers on popular smartphones means that browser fingerprints may become less unique, reducing their usefulness. WebRTC “fixes” that by adding the coupling of the additional local and public IP address information. Is that a good thing? A bad thing?

One thing is clear. WebRTC has a lot more uses than its original intended capability of simply connecting a call.

The post WebRTC on the New York Times – Not as an Article or a Video Chat Feature 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 >>

3CX: Nick Galea

July 2015

Enterprise web meetings

Video Conf

Medium

Voice, Video

WebRTC video conferencing for the enterprise.

[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.]

 

I have been following 3CX for several years. They were one of the first in the enterprise communication solution vendors that offered WebRTC. Recently, they introduced a new standalone service called 3CX WebMeeting. It has all the expected features of an enterprise multiparty video calling service. And it uses WebRTC.

I had a chat with Nick Galea, CEO of 3CX. I wanted to know what are they doing with WebRTC and what are his impressions of it.

Here are his answers.

 

What is 3CX all about?

3CX provides a straightforward and easy to use & manage communication solution that doesn’t lack in functionality or features and is still highly affordable. We recognised that there was a need for a Windows-based software PBX and so this is where 3CX began.

Given the fact that the majority of businesses already use Windows, 3CX provides a solution that is easy to configure and manage for IT Admins. There’s no need for any additional training that can be time-consuming and costly. We also help businesses to save money on phone bills with the use of SIP trunking and free interoffice calls and travel costs can be reduced by making use of video conferencing with 3CX WebMeeting. As a UC solutions provider, we focus on cost savings, management, productivity and mobility, and we help our customers to achieve improvements in all four aspects.

Our focus is on innovation and thus, our development team works nonstop to bring our customers and partners the very best. We are always looking out for the latest great technologies and how we can use them to make 3CX Phone System even better and so of course, WebRTC was a technology that we just had to implement.

 

You decided to plunge into the waters and use WebRTC. Why is that?

To us, unified communications is not only about bringing all methods of communication into one user-friendly interface, but about making those methods of communication as seamless, enjoyable and productive for all involved, whether that be for the organisation that invested in the system, or a partner or client that simply has a computer and internet connection to work with.

Running a business is not an easy feat, and the whole purpose of solutions such as 3CX Phone System and 3CX WebMeeting is to make everyday business processes easier. So, for us, WebRTC was a no-brainer. We believe in plugin-free unified communications and with such technology available for us to leverage, the days of inconvenient downloads and time-consuming preparation in order to successfully (or in some cases, unsuccessfully) hold a meeting are over.

What signaling have you decided to integrate on top of WebRTC?

Signalling is performed through websocket for maximum compatibility. Messages and commands are enveloped in JSON objects. ICE candidates are generated by our server library while SDP are parsed and translated by MCU. This allows full control over SDP features like FEC and RTX in order to achieve best video performance.

 

Backend. What technologies and architecture are you using there?

The platform is based on a web application written on PHP. We developed a custom MCU service (actually it’s a Selective Forward Unit aka SFU). This service allows us to handle a very large number of media streams in real time. Performance is optimized to reduce latency to a minimum. Raw media streams can be saved to disk, then our Converter Service automatically produces a standard video file with meeting recording.

A key component of web application is the MCU Cluster Manager, which is able to handle several MCUs scattered in different areas, distribute load and manage user location preference.

 

Since you cater the enterprise, can you tell me a bit about your experience with Internet Explorer, WebRTC and customers?

So far most people are using Chrome without any complaints so it doesn’t concern me that WebRTC is not supported by Internet Explorer. We haven’t come across any issues with customers as they are aware that this is a limitation of the technology and not the software and actually our stats show that 95% of people connect or reconnect with Chrome after receiving the warning message, so for most users Chrome is not a problem.

 

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

I think that WebRTC will become the de facto communications standard for video conferencing, and maybe even for calls. WebRTC is a part of how technology is evolving and we may even see some surprising uses for it outside the realms of what we’re imagining right now. It’s incredibly easy to use and no other technology is able to compete. It’s what the developers are able to do with it that is really going to make the difference and I believe there is still so much more to come in terms of how WebRTC can be utilised.

 

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

That they should have adopted it earlier :).

 

Given the opportunity, what would you change in WebRTC?

Nothing really but the technology is still growing so I’m looking forward to see what’s in store for WebRTC and how it’s going to improve.

 

What’s next for 3CX?

We’re working on tighter integration between 3CX WebMeeting and 3CX Phone System and integrating our platform more closely with other vendors of third-party apps such as CRM systems and so on.

–

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

The post 3CX and WebRTC: An Interview With Nick Galea appeared first on BlogGeek.me.

Join the webinar on WebRTC and its Impact on Testing to get a clear answer.

I’ve been working recently with some friends on solving an issue for WebRTC that seems to be ignored by most – testing WebRTC services.

We had a concept in mind, and decided to follow through and develop a service for it, naming it testRTC. Since we started, we’ve enhanced the service greatly to include monitoring and analytic due to customers request.

What I noticed in our calls with customers is that there are 3 different paradigms used for testing WebRTC-based services:

1. Not testing at all, assuming things will work out just fine or that customers complaining will just get us to fix bugs
   • I thought only startups with a demo or a proof of concept will be in this category, but was surprised to see large vendors in this category as well
   • Some assume that if they test their product in other ways (SIP/VoIP aspects of it for example), then this would be enough
   • Others assume that things will just work because Google is testing WebRTC in Chrome
2. Testing manually, where you have QA teams (more likely the developer himself) go through the motions of testing the service
   • Which begs the question of how exactly can this scale or work with the continuous deployment nature of WebRTC, where browsers release new versions every 6-8 weeks
3. Framework DIY, where an automation framework is put in place to test WebRTC
   • This usually amounts for a one-time investment that is then never improved upon
   • These frameworks will usually lack functionality, as other priorities related to feature requests and functionality trickle in

You might think that using a solid VoIP testing product would suffice for WebRTC, but the reality is starkly different. While WebRTC is VoIP, it bears little resemblance to it when it comes to testing.

If you wish to learn more, check out what we are doing at testRTC. Or better yet – join SmartBear and testRTC for a free webinar:

WebRTC and Its Impact on Testing – July 8, 2015, 2:00 p.m. EDT

Nikhil Kaul and I will be discussing the challenges WebRTC posts to testing and suggest best practices to meet these challenges. See you there!

The post How do You Test Your WebRTC Service? appeared first on BlogGeek.me.

Time for another update.

Only 4 months have passed since I released my last update to the Choosing a WebRTC API Platform report and things have already changed enough to merit another update.

Some of the things we’ve seen?

• Requestec got acquired by
• Tropo got acquired by Cisco
• Twilio added video and made a slew of interesting announcements
• Acision got acquired by Comverse
• VoxImplant introduced messaging capabilities
• SightCall sets its sights on visual support use cases
• And the list goes on…

The report, as it is, currently covers 19 vendors: AddLive (Snapchat), APIdaze, Apizee, CafeX, Forge (Acision/Comverse), Kandy, OnSIP, ooVoo, OpenClove, Plivo, Requestec (Blackboard), Respoke, SightCall, Sinch, Temasys, TokBox, Tropo (Cisco), Twilio and VoxImplant.

AddLive and Requestec are now out of the game. Others may evaporate by year end. There are other players who are in this market and I am setting my sights on adding.

Which vendors do you think are missing in this report? What topics should I cover beyond those in the current table of contents?

I’d love to get your feedback.

The next update of this report will occur during September timeframe.

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

The post I Need Your Help: Who is Missing from my WebRTC PaaS Report? appeared first on BlogGeek.me.

It took some time, but it finally happened.

Today is the first day in my adult life that I wake up in the morning needing to plan ahead for myself and myself only.

I started this journey three and a half years ago. It started small. With a post: Starting anew.

Two things happened at that time:

1. I left my first full time job – working at RADVISION for 13 years. I did that for another full time job at Amdocs
2. I decided to open my own professional blog (this one), with no clear idea what to do with it

The blog grew nicely and formed into a WebRTC focused site. So much so that I reduced my work at Amdocs to part time and started offering consulting around WebRTC. Today I am completing that step. I have left Amdocs, an employer that was good to me in every way, in order to carve up my own path in the world.

For now, it will mostly be WebRTC. But not only.

It will be consulting. But also entrepreneurship. There is already an established startup I founded with some friends, and another one in the works.

Most of all, it will be exciting. And fun.

If you want to have a chat or get my assistance – I’ll be happy to be of help.

The post I an now Officially a 100% WebRTC… Hermit appeared first on BlogGeek.me.

While you need to give direct access to your APIs, an SDK is a critical piece of your offering.

There was an article on the ProgrammableWeb on Sending.io NOT offering an SDK for their service. I think in most cases, this approach is wrong.

Sending.io decided to offer only an API layer for its customers. You can access their REST APIs, but how you do it is your problem – even when what they give is designed and built for mobile devices.

API and SDK

I’ll start with a quick explanation of the two – at least in the scope of this post. There will be those who will definitely object my definitions here, but the idea is just to make the distinction I need here – and not to pontificate the meaning of the two.

• API – an API is a set of operations you can use to access a backend service of sorts. Assumption is this is a server-side API, where we have a service on some remote server (probably on AWS or whatever other cloud), and that service offers access to it via APIs. You invoke the API by making a remote call from your machine or device to the cloud running the service. Usually these APIs will be REST based, though not always
• SDK – an SDK is a piece of code that gets embedded into the customer’s service. The customer is a developer who decided to use your API, so he downloads your SDK and puts it in his own code. The SDK itself calls the API when necessary to get things done. The result – the customer calls the SDK locally, the SDK calls the API remotely and your service gets used

Why not an SDK?

Back to Sending.io and their reasons – from this article:

• SDKs introduce performance issues
• Reduces control of the customer using it
• Crashing SDKs
• Privacy issues

While this may work in the gaming industry, I think it is not workable in many other industries. Here are my thoughts on this one:

It all boils down to your execution

There are two ways to treat an SDK – as part of your offering or as an afterthought.

If you treat it as an afterthought, then performance issues, crashes and privacy issues will crop more frequently than not.

With most SDKs today built as frontends to a backend REST API, it makes perfect sense that some of them just aren’t written well: Backend developers are good at scaling a service to run in the cloud. For them, considerations of memory and performance of the single session in the same way that a native Android developer thinks about is foreign.

If you really want to offer an SDK, have a pro build it for you.

The customer’s control

Assuming what you have on offer is a closed binary SDK that the customer ends up using, then control may be an issue.

It doesn’t have to be this way.

There are 3 options you can take here, each with its own control points for customers:

1. Offer your SDK as a closed binary, but also give access to the backend API
   • Those who wish to use the SDK to shorten their time to market can do that
   • Those that wish to have more control can use the API directly
2. Offer your SDK in source code format
   • This gives more control to your customer, who can now debug the code
   • The customer may modify the code, and in such cases, you should make it clear your support will be of the backend API only
3. Offer a sample SDK client only
   • Provide a reference written in the native language of choice
   • Don’t offer support for it, but write it in a way that makes it easy to understand and modify

Why an SDK is needed?

There are several reasons that make an SDK so powerful:

1. While REST APIs are simple enough, connecting to them can be quite a hassle
   • Which native library should be used? Have the APIs been tested with these libraries? Having this one decided, implemented and tested makes life easier for customers
   • What authentication mechanism is provided? How do you implement it on your own in the native language? This can eat up many hours, so having that done for customers reduces the friction and the chance of your customer moving to a competitor
   • There’s a flow issue – you need to call API A then API B then check something locally before running API C. Developers never read documentation. Give them a sample to work from in the SDK, and half your problems are solved
2. It might not be REST…
   • There’s a shift towards WebSocket communications in some places. Documenting the spec and having customers follow it isn’t easy
   • Give an SDK instead, and the actual protocol you use for the WebSocket becomes irrelevant to the customer – AND allow you to easily update it in the future
3. You might want to run things in the client side
   • WebRTC, for example, runs on the client side
   • You can’t really offer a backend API and just forget about the client side – there’s a lot of code that ends up there
   • That code has value – especially on mobile

Plan on offering a backend API for your customers?

You shouldn’t just ignore an SDK – especially not if you plan on having developers integrate with your APIs inside mobile apps.

 

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

The post Why an SDK is Critical to your API Offering appeared first on BlogGeek.me.

Friction.

A true story…

I had a meeting the other day. It was with a company that has been offering WebRTC video chat as part of its own services to their own customers for some time now, but internally, they used some other vendor for their own business meetings. My invitation was on that other vendor’s platform.

At the time of the meeting, I opened the calendar invitation, searching for the link to press.

Found it. Clicked it.

Got using my Chrome browser on my home desktop Ubuntu machine to the web page.

Clicked to join the meeting using my browser.

Was greeted with a message telling me Chrome isn’t supported due to a Chrome bug (with a link to a page detailing the issue on Chrome’s bug tracker) AND suggesting me to use Firefox.

Good.

Opened up Firefox, pasted the link to it.

Clicked to join the meeting using my browser.

Was greeted with a message telling me that only Windows and Mac are supported.

Great.

Opened my laptop to join. It runs Windows 8, so no issues there (I hoped).

Clicked the link on the email there, just to get Chrome opened there.

Somehow, the system knew this time that I should be able to use Chrome, so it happily instructed me to wait to download and then run the executable they were sending me.

Ok.

It took a minute or two to get that executable to run and start installing *something*.

But it got lost in all my windows. A bit of searching and I found the pesky window telling me to open the link yet again.

So I did.

It then went into this seemingly endless loop of trying to open up a meeting, failing and reopening.

This is when I noticed that the window being opened was an Internet Explorer one.

I cut the loop short and opened the link to the meeting on Internet Explorer.

It worked.

10 minutes later, frustrated, with another crappy installation of a client lurking around my Windows machine, I got to talk to the people who invited me.

Two were there with video – me one of them – we actually installed and executed that “plugin”.

Others joined by phone.

—

I am a technical person.

I worked in the video conferencing industry.

Why the hell should we use such broken tools and technologies in 2015?

I couldn’t care less if the video conferencing equipment that have been purchased ions ago don’t support VP8 or require conversion of SRTP to RTP or require translation from REST/WebSocket to H.323 signaling. I really don’t.

The only thing I want is to open a browser to a specific URL and have that URL just work.

On Ubuntu please.

—

The service in question?

Wasn’t a new one. They’ve been around for a decade or so.

They started with the desktop, so why can’t they get that experience to work well?

—

Yes. Internet Explorer and Safari are missing. I know. But I couldn’t care less.

If you want to provide a broken plugin experience for IE and Safari, then please do. But wherever possible make it easier for me to use.

It really isn’t hard. I attend a lot of video calls these days. The crushing majority of them are through WebRTC based services. Most of the services I used weren’t built by billion dollar companies.

Get your act together.

Start using WebRTC for your own business meetings.

The post Why I Hate Video Conferencing Plugins and LOVE WebRTC Services appeared first on BlogGeek.me.

Companies care little about standards. Unless it serves their selfish objectives.

The main complaint around WebRTC? When is Apple/Microsoft going to support it.

How can that be when WebRTC is being defined by the IETF and W3C? When it is part of HTML5?

WebAssembly

We learned last week on a brand new initiative: WebAssembly. The concept? Have a binary format to replace JavaScript, act as a kind of byte-code. The result?

1. Execute code on web pages faster
2. Enable more languages to “run” on web pages, by compiling them to this new byte-code format

If the publication on TheNextWeb is accurate, then this WebAssembly thing is endorsed by all the relevant browser vendors (that’s Google, Apple, Microsoft & Mozilla).

WebAssembly is still just a thought. Nothing substantiate as WebRTC is. And yet…

WebAssembly yes and WebRTC no. Why is that?

Why is that?

Decisions happen to be subjective and selfish. It isn’t about what’s good for the web and end users. Or rather, it is, as long as it fits our objects and doesn’t give competitors an advantage or removes an advantage we have.

WebAssembly benefits almost everyone:

• It makes pages smaller (binary code is smaller than text in general)
• It makes interactive web pages run faster, allowing more sophisticated use cases to be supported
• It works better on mobile than simple text

Google has no issue with this – they thrive on things running in browsers

Microsoft are switching towards the cloud, and are in a losing game with their dated IE – they switched to Microsoft Edge and are showing some real internet in modernizing the experience of their browser. So this fits them

Mozilla are trying to lead the pack, being the underdog. They will be all for such an initiative, especially when WebAssembly  takes their efforts in asm.js and build assets from there. It validates their credibility and their innovation

Apple. TechCrunch failed to mention Apple in their article of WebAssembly. A mistake? On purpose? I am not sure. They seem to have the most to lose: Better web means less reliance on native apps, where they rule with current iOS first focus of most developers

All in all, browser vendors have little to lose from WebAssembly while users theoretically have a lot to gain from it.

WebRTC

With WebRTC this is different. What WebRTC has to offer for the most part:

• Access to the camera and microphone within a web browser
• Ability to conduct real time voice and video sessions in web pages
• Ability to send arbitrary data directly between browsers

The problem stems from the voice and video capability.

Google have Hangouts, but make money from people accessing web pages. Having ALL voice and video interactions happen in the web is an advantage to Google. No wonder they are so heavily invested in WebRTC

Mozilla has/had nothing to lose. They had no voice or video assets to speak of. At the time, most of their revenue also came from Google. Money explains a lot of decisions…

Microsoft has Skype and Lync. They sell Lync to enterprises and paid 8.5 billions for Skype. Why would they open up the door to competitors so fast? They are now headed there, making sure Skype supports it as well

Apple. They have FaceTime. They care about the Apple ecosystem. Having access to it from Android for anything that isn’t a Move to iOS app won’t make sense to them. Apple will wait for the last moment to support it, making sure everyone who wishes to develop anything remotely related to FaceTime (which was supposed to be standardized and open) have a hard time doing that

All in all, WebRTC doesn’t benefit all browser vendors the same way, so it hasn’t been adopted in the same zealousness that WebAssembly seems to attract.

Why is it important?

Back to where I started: Companies care little about standards. Unless it serves their selfish objectives.

This is why getting WebRTC to all browser vendors will take time.

This is why federating VoIP/WebRTC isn’t on the table at this point in time – the successful vendors who you want to federate with wouldn’t like that to happen.

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

 

The post How the Politics of Standardization Plays in WebRTC, WebAssembly and Web Browsers appeared first on BlogGeek.me.

Jitsi switching to the Apache open source license is what the doctor ordered.

Blue Jimp, and with it Jitsi, was acquired by Atlassian in April this year. I wrote at the time about Jitsi’s open source license:

The problem with getting the Jitsi Videobridge to larger corporations was its open source license

• Jitsi uses LGPL. A non-permissive license that is somewhat challenging for commercial use. While it is suitable for SaaS, many lawyers prefer not to deal with it
• This reduces the Jitsi Videobridge’s chance to get adopted by enterprise developers who can pour more resources into it
• This may limit Jitsi from building the ecosystem Atlassian wants (i.e – outsourcing some of the development effort to an external developers community)
• Using BSD, MIT or Apache licenses would have been a better alternative. Will Atlassian choose that route? I am not sure
• Did Atlassian leave the open source offering due to legal issues or real intent in becoming an open source powerhouse?

You can read my explanation on open source licenses. If you read the comments as well, you’ll see how complex and mired with landmines this domain is.

Last week, an announcement was made in the jitsi-dev mailing list: Jitsi is switching from LGPL to Apache license:

LGPL, our current license allows everyone to integrate and ship our various jars. Once you start making changes and distributing them however, then you you need to make sure these changes are also available under LGPL, AKA the LGPL reciprocity clause.

What I found interesting weer the next two paragraphs:

As the copyright holder, in BlueJimp we have been been exempt from this reciprocity clause. Even though we rarely use it, we had the liberty to modify our code without making our changes public. No one else had this option.

Switching to Apache ends our advantage in this regard, and allows everyone to use, integrate and distribute Jitsi with a lot less limitations.

Some things to notice here:

• People who made changes to the Jitsi code base had to contribute back the code to Blue Jimp, along with the ability for Jitsi not to act the same – Jitsi maintained a different “license” for itself – this works well when your business model is consulting and customization of the open source project you maintain – not so good for a large enterprise
• Atlassian took a different approach here by switching to Apache:
  • Atlassian internally has the same decision making processes as other large enterprises. LGPL is harder to adopt than Apache, making a switch to the Apache license for Jitsi a reasonable step to take – preferential treatment for Apache license in Atlassian and elsewhere played a key role here
  • It removed the possible nightmare of maintaining all of the existing CLAs (contributor license agreements) – they might have found them inaccurate, requiring a modification in their terms, needing a reassignment to Atlassian, etc – it was a good time to make the switch to Apache anyway
  • It gives a strong signal to the market, and especially to large enterprises that Jitsi is something they can use – if this turns out well, there will be additional contributors to this software package, as it is a popular one in the WebRTC industry
• This switch from LGPL to APL (Apache) changes nothing in the ability of Blue Jimp and Atlassian to modify the base code and not contribute it back to the open source package
  • This kind of a thing has happened before during acquisitions of open source project teams
  • It also happens when competition starts using your own open source against you (think Google’s Android)
  • It is unlikely to happen in the short or medium term, based on the signals coming from Atlassian and their current focus
• This opens up a powerful WebRTC media server (an SFU actually) to a larger number of vendors

All in all, this is a great move to our WebRTC ecosystem. Atlassian is doing the right moves in maintaining the Jitsi community happy and engaged while attracting the larger players in the market. I wouldn’t have done it any other way if I were in their shoes.

 

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

 

The post Why Did Atlassian Switch Jitsi’s Open Source License from LGPL to Apache? appeared first on BlogGeek.me.

While our smartphones aren’t phone anymore, their phone-calling real estate is still a prime asset.

VoLTE stands for Voice over LTE. It has been in the making for quite some time, but haven’t made its grand public appearance yet. While carriers around the globe boast LTE adoption stats, this says NOTHING about the lag of the carrier’s once main service – the humble voice call.

Today, in almost all cases where you open your smartphone greeted with an LTE network, if you make a phone call, it will go over 3G or GSM. Why? Because for voice to traverse LTE it requires VoLTE – or some other workaround means. Once VoLTE makes it into the scene, it will need to replace the voice calls today – and be a part of the smartphone’s dialer.

But there are other means of making calls these days, and I am not talking about Skype buddy lists.

Here is how the different players on the market redefining how we make calls, and trying to win the real-estate of the phone’s dialer by… replacing it.

Apple

In some ways, Apple is dependent on carriers selling its smartphones through contract agreements. So it can’t piss off their channel to market too much. But they can are treading on a very fine line here.

It started with FaceTime. Apple’s video chat service. Which then grew to iMessage, and later an introduction of FaceTime Audio.

Apple controls the iPhone’s UI, which means it decides how the dialer looks like and what functions it exposes to the user.

The end result?

• When you want to send an SMS to someone, Apple will automatically “convert” it to an iMessage if possible
• When you want to make a call to someone, if he uses an Apple device, you have the option to call him – voice or video – using FaceTime

Google

Google has Hangouts. You get it pre-installed in Android devices. Many never use it, but it is there.

Google tried making Hangouts sticky in the past, so they allowed it to receive and send SMS – similar in some ways to how Apple does iMessage, but different as the experience isn’t as seamless.

On a mobile phone, think of Hangouts as a step in the way. Google’s Project Fi, their new MVNO initiative, probably uses Hangouts internally – it does connect with Hangouts as their website explains:

Connect any device that supports Google Hangouts (Android, iOS, Windows, Mac, or Chromebook) to your number. Then, talk and text with anyone—it doesn’t matter what device they’re using.

Google is bulking up its communication chops nicely these past few years, and Fi is the next step. I am certain that part of the tech and learnings that Google gains from Fi will find its way back to their general Hangouts service.

Facebook

Facebook had its share of romance with mobile. From rumors of Facebook smartphones, to a failed Facebook Home app.

For Facebook mobile is critical. Many of its customers use it exclusively on mobile. How do you increase your share in a digital life pie if you are Facebook? You try to control the smartphone experience.

Building a smartphone is hard (ask Amazon), so Facebook tried controlling the home screen by developing a Facebook centric Android launcher. This didn’t work, but wasn’t a failure at the scale of a smartphone launch.

Next up, is their relatively new Hello app. It looks rather innocuous – you receive calls through their Hello app to get a “social ID” – Facebook will match the phone number to a person’s Facebook account to show to you on incoming calls.

The end result?

• Facebook Hello is used as your smartphone’s calling app
• They didn’t miss the opportunity of adding their own dialer in – which enables you to call via Messenger…

Whatsapp (still Facebook)

Whatsapp is a part of Facebook, but it took a very different approach. It simply added voice calling to its app.

If you are interested in understanding the size of Whatsapp, then there’s a good bulleted list on Mobile Industry Review.

Think of this move in the following context:

• As of April 2015, WhatsApp has more than 800 million active users
• Average amount of time spent by users on WhatsApp is 195 minutes a week
• Teenagers use Whatsapp all the time. At least here in Israel. They don’t talk – they text. Faced with the need to escalate a text chat to a voice call – will they switch app and context or just press the phone icon on the Whatsapp page?

What is your dialer now? The traditional phone dialer with its contacts app or Whatsapp?

Why is it important?

Communication is being redefined. Switching from voice and video towards data access and messaging.

This brings with it a bigger change of what is considered prime real estate on one smartphone’s display, and there are non-telco vendors who are positioned nicely to displace the carriers from the dialer as well. Where would that leave the carrier’s efforts with VoLTE?

 

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post How OTTs are Challenging VoLTE’s Prime Asset on Smartphones appeared first on BlogGeek.me.

To paraphrase Seth Godin, WebRTC is about breaking things.

Seth Godin (who you should definitely read) had an interesting post this week, titled Abandoning perfection. It is short so go over and read it. I’ll just put one of the paragraphs of this post here, to serve as my context:

Perfect is the ideal defense mechanism, the work of Pressfield’s Resistance, the lizard brain giving you an out. Perfect lets you stall, ask more questions, do more reviews, dumb it down, safe it up and generally avoid doing anything that might fail (or anything important).

Now that we have it here, why don’t we check on the excuses people (and companies) give for not using WebRTC?

• “Microsoft and Apple don’t support it”
  • Do you have any better idea on how to do video calling in browsers? Because I don’t
  • And there are WebRTC plugins for those who want them in Safari and IE
  • There are also those who can live with Chrome and Firefox use cases only
• “You can’t do multiparty calls with it”
  • This is true for any client side VoIP solution. They require a server
  • And since WebRTC is a technology, it is up to you to come up with the solution and implement server side multiparty
  • Join my webinar next week with TokBox on this subject while you’re at it…
• “There’s no quality of service”
  • No VoIP service has quality of service
  • WebRTC changes nothing in this regard
  • And people are still happy to use Skype (!) for their business meetings
• “Without signaling, it can’t interoperate with anything else”
  • True. WebRTC comes without signaling
  • Which means you can add your own – SIP, XMPP or anything you fancy. To fit your exact need and use case
  • In many cases, interoperability is overrated anyway, and building your own service silo is good enough
• “Mobile First, iOS First. Apple not there, so no way I can use WebRTC”
  • You’ll be surprised how many commercial iOS production apps there are that use WebRTC
  • That’s why I even published a report on WebRTC adoption in mobile apps

Got a lizard brain? Make sure you use the excuses above in the next weekly meeting with your boss. Want to break things and be useful? Check out what WebRTC can do for you.

Oh, and when someone tells you that WebRTC isn’t ready for prime time yet, but will be in 2-3 years – and a lot sooner than you expect – tell him it is ready. Today.

I’ve seen companies using WebRTC daily – in ways that advances their business – adding more flexibility – enabling them to make better decisions – lowers their costs – or allow them to exist in the first place.

Got a good use case that requires real time communications? First check if WebRTC fits your needs – REALLY check. 80% or more of the time – it will.

 

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

Trying to understand how to get your service to mobile with WebRTC? Read my WebRTC Mobile Adoption report, written specifically to assist you with this task.

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

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

Looking for a WebRTC related job? Need the best WebRTC developer out there? You should definitely try out the WebRTC Job Board - satisfaction guaranteed!

The post Why You Should Start Using WebRTC TODAY and Abandon Perfection? appeared first on BlogGeek.me.

Is Comverse becoming a serious WebRTC player?

Comverse is a company in transition. It has been catering the world’s telcos for many years. In recent years, it had its share of issues. Why are they important in the context of this blog?

1. They acquired Solaiemes. But that was in August 2014. Almost a year ago
2. Less than 2 months ago, Comverse sold its BSS business to Amdocs
3. Yesterday, it acquired Acision, for around $210M

What does this say about Comverse?

Comverse is a company searching for their way. Their current focus is digital services with the set of customers being Telcos.

Digital focus means APIs and platforms that enable rapid creation of services.

The interesting part here is that Comverse is getting a sales team and an operation that knows how to sell to enterprises and not only to Telcos. I do hope they will be smart enough to keep that part of the business alive and leverage it.

Open questions include: Will Comverse merge Acision assets with Solaiemes? Try to build one on top of the other?

What does this say about Acision?

Acision got acquired for their SMS and voice business more than for their WebRTC or API platform components. No one gets acquired for that much money for WebRTC. Yet.

It is funny to note that Acision Forge platform, which runs their WebRTC PaaS part, was an acquisition of Crocodile RCS.

Comverse being focused on Telcos, how will they view the Forge platform?

• As something to be sold to carriers or through carriers? This means taking the route that Tropo took in recent years
• Would they try to leverage it and expand their offering to enterprises in other areas?
• Will Comverse management understand the enterprise business enough to try and let it grow unhindered?

Why is this important?

This isn’t the first or last WebRTC related acquisition of the year. We had a few already.

If you are looking to use any vendor for your WebRTC technology, you need to consider the possibility of acquisition seriously.

It also led me to updating my WebRTC dataset subscription service: as of today, its subscribers also receive an updated acquisitions table, detailing all acquisitions related to WebRTC since 2012.

 

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

The post Comverse Acquires Acision, Framing Digital an APIs Around WebRTC appeared first on BlogGeek.me.

I’d expect LinkedIn to add WebRTC already.

Last week, I received an email from LinkedIn. Apparently, they acquired a learning company called Lynda. It did beg the question, with so many WebRTC acquisitions – where is LinkedIn in all this?

The company deals with professionals, revolving around a digital CV. They enable people to connect in order to conduct business. So why do they want me to revert to things like phone calls or Skype in 2015?

They an internal messaging/email system. Not the best one. Probably requires an overhaul to be an effective tool. So where’s the rest of my interactions with people? Where’s the “click here to call” or “schedule a meeting”?

LiveNinja tried being an experts marketplace. An aggregator of people with skillz. You searching for a guitar teacher? A developer for advice? A yoga lesson? Search them on LiveNinja, interact, schedule a meeting. Hell, it even allows you to pay online (taking part of that revenue and giving the rest to the expert). It is now morphing into Katana, leaving its aggregator vision towards embeddable experiences.

Google Helpouts tried and closed shop. Something to do with it trying to be everything for everyone.

But you know what? LinkedIn can be that marketplace for many. Easily. It already is. It just needs to have that integration with real time communication. Be it for communicating between professionals or for conducting job interviews as part of its jobs board.

So where is it exactly? Am I the only one missing a blue “Call me” button in LinkedIn? Should I make do with their posts platform?

There are over 20 different expert marketplaces using WebRTC at the moment. None of them has the reach of LinkedIn. Would be nice if LinkedIn acquired one of them and be done with it.

 

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

The post LinkedIn – Where are Thou with WebRTC? appeared first on BlogGeek.me.

See you on June 24!

Just a quick note before we head into the weekend.

I’ve partnered with TokBox for a webinar on the various use cases where multiparty video calling is desired.

The webinar will address an area I love, which is the various topologies and architectures to choose from when dealing with multiparty video. Badri Rajasekar, CTO of TokBox, will be there with me and we’re planning to have an interesting conversation.

If this topic is close to your heart, or just something you wish to learn more about – register online – it’s free.

See you online on 24 June at 10:00am PDT. And if you can’t make it – just register to watch it offline.

The post Join me for a Free TokBox Webinar to Learn More About WebRTC Multiparty appeared first on BlogGeek.me.

If you are looking for some quick WebRTC recipes, then this is the book for you.

Consider this another post in a series of posts about WebRTC related books. To see previous  reviews, check out the search tag book review.

The WebRTC Cookbook is the second book by Andrii Sergiienko. His first book was WebRTC Blueprints, was a hard core book – the first one with guts to take WebRTC books to the extreme topics at that time.

WebRTC Cookbook takes a more orderly approach, where Andrii picks several topics and explains them briefly, in a step by step manual. He also provides good follow up material for those who wish to learn more.

Things you will find in this book:

• Peer connection related topic, with the interesting bits in the STUN and TURN configuration
• Security issues – HTTPS, TURN server security, firewalls, etc.
• VoIP – integrating with Asterisk and FreeSWITCH
• Debugging – stats, webrtc-internals, Wireshark, …
• Video filters (unfortunately no audio ones)
• Native apps – iOS, Android and OpenWebRTC.io
• Integrating with some of the WebRTC frameworks and services out there
• “advanced” stuff – things you’d want to do to add polish to your service

This is a good book for your WebRTC library. It acts as a nice reference to go to when you need to quickly skim a topic.

 

Kranky and I are planning the next Kranky Geek in San Francisco sometime during the fall. Interested in speaking? Just ping me through my contact page.

The post Book Review: WebRTC Cookbook appeared first on BlogGeek.me.