News from Industry

What do you know? Peer assisted delivery a-la WebRTC data channel is acceptable.

Whenever write something about the potential of using WebRTC’s data channel for augmenting CDN delivery and getting peers who want to access content to assist each other, there are those who immediately push back. The main reasons? This eats up into data caps and takes up battery.

It was hard to give any real user story besides something like BitTorrent for consumers or how Twitter uses BitTorrent internally to upgrade its servers. Not enough to convince many of my readers here that P2P is huge and WebRTC will be a part of it.

The WebRTC will be a part of it has been covered on this blog many times. P2P is huge is a different story. At least until last month.

Windows 10 was officially released end of July. And with it, millions of PCs around the world got updated. I ran into this article on TheNextWeb by Owen Willions:

by default, Windows 10 uses your internet connection to share updates with others across the internet.

The feature, called Windows Update Delivery Optimization is designed to help users get updates faster and is enabled by default in Windows 10 Home and Pro editions. Windows 10 Enterprise and Education have the feature enabled, but only for the local network.

It’s basically how torrents work: your computer is used as part of a peer to peer network to deliver updates faster to others. It’s a great idea, unless your connection is restricted.

So. Microsoft decided to go for peer assisted delivery and not only a CDN setup to get Windows 10 installation across the wires to its millions of users. That’s 2-3 Gb of a download.

Probably the first large scale commercial use of P2P out there – and great validation for the technique.

I know – they received backlashes and complaints for doing so, but what I haven’t seen is Microsoft stopping this practices. This is another step in the Internet decentralization trend that is happening.

I wonder who will be next.

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

The post If Microsoft can Deliver Windows 10 P2P, Why Can’t we with WebRTC? appeared first on BlogGeek.me.

Grab your copy of my WebRTC PaaS report at a $450 discount.

If you are subscribed to my monthly newsletter, then you already know about this summer sale for two weeks:

• My Choosing a WebRTC API Platform is available at a discount
• $1,500 instead of $1,950
• Time limited until the 17th of August
• Which leaves you 48 hours to purchase it

The reasons?

1. I am heading towards vacation, making August a short month for me
2. In September, the an update to this report will be released
3. This update will include a real membership/subscription service with a few interesting additions:
   1. Online vendor comparison matrix that will be updated periodically
   2. Monthly web meetings to discuss recent changes and any questions you may have on the subject

If you hurry and purchase it in the next two days, you’ll enjoy the lower price point as well as the membership perks – so why wait? Get your copy of the report now.

The post 48 Hours left for the WebRTC PaaS Summer Sale 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 >>

WIT Software: André Silva

August 2015

Telco vendor's offering

Telephony

Medium

Voice, Video

WebRTC at the hands of a telecom vendor.

The Telecom world has its own set of standards and needs. At times, they seem far remote from the way the Internet and WebRTC operates.

How do you bridge between the two? André Silva, Team Leader & WebRTC Product Manager at WIT Software tries to explain in this interview.

 

What is WIT Software all about?

WIT is a software development company specialized in advanced solutions for mobile telecommunications companies. The company has over 14 years of experience and a deep expertise in mobile communications and network technologies including IP Multimedia Subsystem (IMS), mobile voice (Mobile VoIP and Voice over LTE), messaging (SMS, MMS and IM), Rich Communication Suite (RCS) and Multimedia Telephony Services (MMTel). Located in Portugal, UK, Germany and California, the company has over 230 fulltime employees and a blue chip industry client base.

 

You’ve been working in the Telco space offering IMS and RCS products. What brought you towards WebRTC?

Back to 2008, WIT started the development of a Flash-to-SIP Gateway to support voice calls from web browsers to mobile phones. The first commercial deployment was done in 2011, enabling calls from a Facebook App to mobile subscribers connected to the Vodafone Portugal network. This first version included features like enhanced address-book, presence, IP messaging, IP voice calls and video calls.

When Google released the WebRTC project back in 2011, WIT started following the technology and as soon as it got stable we have implemented a new release of our Web Gateway with support for all the browsers in the market, including Chrome, Firefox and Opera that are WebRTC-compliant, but also Safari and IExplorer where we use the Flash-to-SIP capabilities.

 

How are your customers responding to the WebRTC capabilities you have?

Our customers are searching for ways to extend their mobile/fixed networks to web browsers and IP devices, either to extend voice calling with supplementary services and SMS, or to make more services available to off-net users. We are providing our WebRTC Gateway and our RCS capabilities to provide richer messaging and voice calling use-cases for the consumer and the enterprise market.

One of the facts that is much appreciated is the support for non-WebRTC browsers. The conversion of protocols (DTLS-SRTP and RTMP) to RTP is done by our Gateway and it is transparent for the network.

For codec transcoding, we support the standard JSR-309 to integrate with MRF’s in order to support extra codecs that are not natively available in WebRTC.

Recently we just announced a partnership with Radisys that is a leading provider of products and solutions, to address emerging media processing challenges for network operators and solution vendors.

 

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

We are using a proprietary JSON protocol over WebSockets. This is a lightweight protocol that exploits the best of asynchrony of WebSockets and provides the best security for Web Apps.

We have built a Javascript SDK that abstracts all the heterogeneity of the different browsers, and the technology that is used to establish calls. The Javascript SDK loads a Flash plugin when WebRTC is not available in the browser.

 

Backend. What technologies and architecture are you using there?

WIT WebRTC Gateway is a Java-based Application Server that can run in several containers. It can be scaled horizontally over several instances. The Gateway integrates with SIP Servlet Containers, for the integration with standard Media Servers, and with streaming servers, to make the media available over RTMP. Our Media engine copes with the WebRTC media and contains a STUN/TURN server to solve the NAT traversal issues.

 

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

I think WebRTC will become the standard for IP Communications that every VoIP application and server will support, either because they use the WebRTC native APIs, or because they will be improved to also support the extras brought by WebRTC specification.

In 2-5 years I expect to see web developers using the WebRTC JavaScript API to create new applications and just assume that WebRTC is there accessible in every browser, since Microsoft is moving forward to add WebRTC in the new browser.

On the negative side, I also expect browsers to continue having distinct implementations which will force developers to have specific code for each browser. Unfortunately, web development has always been like this.

 

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

WebRTC aims to enable VoIP without plugins. So you need to think about WebRTC alternatives for the cases where it is not available, because from our experience, the end user doesn’t really care what’s underneath the application, they just want it to work.

So, you should not filter the browsers or systems where your application will run and force the user to download a new browser.

 

Given the opportunity, what would you change in WebRTC?

Since H.264 is now one of the video codecs in the specification, a great step would be to add some audio codecs like AMR-WB and G.729 to avoid transcoding with some of the common codecs in existing services.

Also, I would give more focus to the advanced cases that depend on the renegotiation of the WebRTC sessions. We provide supplementary services like call hold, upgrade and downgrade and there are still some limitations in the APIs to allow us to have full control across browsers.

 

What’s next for WIT-Software?

We are creating WebRTC applications that will be launched later this year for the consumer market, and we are preparing a solution for the enterprise market that will leverage the best of WebRTC technology.

Our latest implementation adds support to voice calls between web browsers and VoLTE devices, and this is a major breakthrough for the convergence of Web Apps and new generation mobile networks.

For more information, please visit our product page at http://webrtc.gw

–

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

The post WIT Software and WebRTC: An Interview With André Silva appeared first on BlogGeek.me.

Smarphones are more laptops than phones.

What’s more important to you? That your smartphone is with you so people call call your phone number to reach you and you can call their phone numbers to reach them. Or the fact that you can have your apps and the internet available at your fingers due to that data package you have or the WiFi you are connected to?

For me the answer is simple. I don’t really care much about my phone number anymore. It is there. It is used. There are hours a month that I am “on the phone”, but it isn’t as important as it used to be. Oftentimes, the most important conversations I conduct are done elsewhere.

This special treatment smartphones give GSM calls is getting a bit tired. The notion of call waiting, hold and switching between calls – who cares anymore?

I had a meeting the other day. As usual, it took place on my desktop machine, with a video camera attached. In the middle, the person I talked to had to answer his phone. Say he is busy. On another call he received he decided not to answer. Apparently, that meeting with me was less important than his daughter and more important than the other person.

The other day, I had a meeting. Again, on my desktop. The house phone rang (a novelty here). When it stopped ringing, my smartphone rang. Call was from an international number. I didn’t answer. The current meeting I was already having was important enough. Whoever searched for me pinged me by email as well.

Interactions happen today not only no multiple apps and services. They also happen to us on multiple devices. The concept that we have one number or service, aggregating all of our communication, and needs to handle a calling queue and be prioritized over everything else is no longer valid. It doesn’t fit our world anymore.

Time to let go of that quaint idea of GSM call prioritization. Treat its notifications and app as just another smartphone app and be done with it.

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 It’s Time to Remove GSM Call Prioritization from Smartphones appeared first on BlogGeek.me.

WebRTC is but a technology. Its adoption happens at the edges.

It is interesting to see what people do with WebRTC – what use cases do they tackle and what kind of solutions do they come up with.

Here are a few opposite trends that are shaping up to be mainstream approaches to wielding WebRTC.

1. Aggregation

In many cases, WebRTC is used to aggregate. The most common example is expert marketplaces.

Popexpert and 24sessions are good examples of such aggregators. You open up your own page on these services, state what services you offer and your asking price. People can search for you and schedule a video session with you. Interesting to see in this space LiveNinja who recently shutdown their aggregation service, shifting towards and embedability alternative.

2. Embedablity

The opposite of aggregating everyone into a single domain is to enable embedding the service onto the expert’s own website.

The company will offer a piece of JavaScript code or a widget that can be placed on any website, providing the necessary functionality.

Aggregation of Embedability?

Which one would be preferred, and to whom?

The Vendor in our case, has more power as an aggregator. He is in charge of all the interaction, offering the gateway into his domain. Succeeding here, places him in a position of power, usually way above the people and companies he serves.

The Expert may enjoy an aggregator when he is unknown. Having an easy way to manage his online presentation and being reachable is an advantage. For someone who is already known, or that have spent the time to make a brand of himself online, being aggregated on someone else’s site may dilute his value or position him too close to his competitors – not something you’d want doing.

The Customer on one hand, can easily find his way through an aggregator. But on the other hand, it places the expert or service he is reaching out to at a distance. One which may or may not be desired, depending on the specific industry and level of trust in it.

Ben Thompson has a good read about aggregation theory which I warmly suggest reading.

 

3. Silo

Most WebRTC services live in their own silo world. You envision a service, you build the use case with WebRTC, and that’s it. If someone needs to connect through your service – he must use your service – he can’t get connected from anywhere elsewhere. Unless you add gateways into the system, but that is done for specific needs and monetization.

I’ve talked about WebRTC islands two years ago. Here’s a presentation about it:

WebRTC Islands from Tsahi Levent-levi

WebRTC makes it too easy to build your own island, so many end up doing so. Others are hung up to the idea of federations:

4. Federation

Why not allow me to use whatever service I want to call to you, and you use whatever service you prefer to receive that call?

Think calling from Skype to WeChat. Or ooVoo to Hangouts. What a wonderful world that would be.

Apparently, it doesn’t happen because the business need of these vendors isn’t there – they rather be their own silos.

Who is federating then?

• Some connect to the PSTN in order to “federate” – or to enjoy the network effect of the legacy phone system
• Those who have a network already (federated or not), end up using WebRTC as an access point. That’s what Polycom did recently with their RealPresence Web Suite.
• Solutions such as Matrix, looking to offer a framework that enables federated signaling that is suitable for WebRTC as well

Why is this important?

At the end of the day, WebRTC is a building block. A piece of technology. Different people and companies end up doing different things with it.

 

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

The post WebRTC’s Extremes. Aggregation or Embedability? Federated or Siloed? appeared first on BlogGeek.me.

WebRTC has more to offer in video conferencing than just an access point.

My roots are in video conferencing. I’ve been working in that industry for 13 years of my adult life, most of it spent dealing with signaling protocols and enabling others to build their VoIP solutions. You can say I have a special place in my heart for this industry.

This is why I immediately said yes when LifeSize wanted me to join them for a webinar. We’ve got a mouthful as a title:

Five Advantages WebRTC Brings to Your Video Conferencing Solution

Truth be told – there’s a lot that WebRTC has to offer in the video conferencing space than the mere “additional access point as a browser to our great video conferencing products”. It starts by taking cloud and video seriously, and continues with unlocking the value that a technology like WebRTC can bring to video conferencing solutions.

If you want to learn more, then be sure to join LifeSize and me in this webinar.

When? Aug 18 2015 11:00 am EDT

Register now and join us

The post Upcoming Webinar: Five Advantages WebRTC Brings to Your Video Conferencing Solution appeared first on BlogGeek.me.

Ebbene sì, ne abbiamo combinata un’altra! A seguito delle sempre più numerose richieste dei nostri partner e clienti, abbiamo sviluppato il client 3CXPhone per gli smartphone Windows. Il 3CXPhone per Windows Phone può essere usato unicamente sui dispositivi dotati di Windows 10. Così come gli altri client 3CXPhone per iOS e Android, il nuovo client per Windows Phone vi consentirà di portare con voi il vostro interno aziendale ovunque voi siate! L’aumentata mobilità e produttività, così come i risparmi sulla bolletta sono solo alcuni fra i maggiori vantaggi che gli utenti di Windows Phone potranno toccare con mano.

3CXPhone per Windows 10 è l’unico SIP Phone per Windows Phone e può anche essere usato con altri centralini.

Segui questa semplice procedura per provare il client 3CXPhone per Windows Phone:

• Aggiorna il tuo Windows Phone a Windows Phone 10
• Apri l’icona “Store”
• Digita “3CXPhone” nel campo di ricerca
• Tocca l’app per installarla
• L’URL dello store è: https://www.microsoft.com/en-us/store/apps/3cx-phone/9nblggh1nj7b 

 

Approfondimenti

• Mai più chiamate perse con il nuovo 3CXPhone per Mac
  

  Fedele alla sua reputazione di azienda innovatrice, 3CX è uno dei primi produttori di centralini telefonici ad offrire un client per Mac completo di funzionalità professionali. Con il nuovo aggiornamento del popolare [...]

• 3CX Phone System v14: Preview tecnica
  

  La nuova major release di 3CX Phone System è pronta! Il nostro team Ricerca&Sviluppo c’è riuscito un’altra volta e ci ha fornito una versione straordinaria: pronta per il Cloud e corredata di [...]

• Fring pronto a sbarcare su Windows Mobile
  

  Dopo il recente rilascio della versione 3.20 per i dispositivi basati su OS Symbian, a giorni dovrebbe essere rilasciata la versione per Windows Mobile 5 e 6 del noto client voip e [...]

Adobe Migrating to WebRTC?

The company behind the abomination called Flash? Adobe.

The logic then, is that when Adobe moves to WebRTC, there’s no reason anymore to try and run real time communications related use cases with Flash. Correct?

Well… it is already happening.

Guillaume Privat, Director and General Manager of the Adobe Connect business unit, spilled the beans: Adobe Connect “plans to be ready to support HTML5″ “when WebRTC matures”.

AT&T. Cisco. Microsoft. Comcast. Facebook. And now Adobe. An interesting 2015.

Some thoughts about this partial announcement by Adobe (read it all – it is short and rather interesting):

• Why did Adobe go with WebRTC?
  • The promise of HTML5 content working across desktops and mobile devices
  • Portability – cross platform development and deployment
  • The same thing I always say – if you plan on developing any communication service these days, WebRTC needs to be your first choice and the question should by why you haven’t picked it
• Their future plans are broad, and rather simplistic – use HTML5/WebRTC wherever to bring feature compatibility to what Adobe Connect is capable of today
• Somehow, Adobe places WebRTC as an immature technology. While I see this type of thinking in many places, I believe it is short sighted at best. Those who deem it immature probably aren’t wielding it correctly
• Worse – maturity in WebRTC means “once HTML5 can support large scale collaboration across browsers”
  • Will Microsoft Edge imminent support of it enough?
  • Will Adobe wait until benevolent Apple introduces WebRTC in Safari?
  • Will Adobe be adamant that WebRTC must run on the older Internet Explorer browsers before it is mature enough for Adobe?
  • Or is there some other arbitrary rule at play? Maybe the development time inside Adobe Connect’s team?
• The context of the announcement is odd
  • It resides on a blog that talks about use cases deployed by Adobe Connect and features introduced
  • This announcement is neither
  • It says “we know there’s WebRTC and we plan on using it. One day. When we think it is time. Maybe. If we get there. And browsers support it”
  • Not sure how should I respond to it. Should I use Adobe Connect now that I know they plan on using WebRTC in some far flung future? Should I sit and wait until they do? Should I rejoice? Should I be worried about my existing Adobe Connect integration?

At least we have another incumbent openly validate WebRTC as a technology. I wonder when the rest of the ostriches burying their head in the sand out there will also come to their senses.

Adobe is abandoning Flash. Shouldn’t you be doing the same?

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

The post The Day Adobe Adds WebRTC is the Day we Kill Flash appeared first on BlogGeek.me.

About Slable

Slable provides affordable enterprise I.T. and communication solutions for small-to-medium businesses (SMB) in the Washington, D.C. metropolitan area. Their goal is to eliminate all I.T.-related hassle from work environments of various types ranging from veterinarians to marketing/PR firms. Their network infrastructure enables companies to host their applications on a reliable and secure network so that their customers can focus on what they do best. Slable’s team of 14 employees is able to provide stellar support around the clock for all customers.

Challenges

Slable needed a reliable VoIP platform that could be easily by their customers. Slable’s previous VoIP solution was not powerful enough to handle complex features and began to experience weekly outages, resulting in a loss of faith in their services. Facing the prospect of losing customers, Slable decided to find a reliable VoIP platform that would scale with their growing customer base and provide feature rich applications for advanced users. Slable needed a reliable VoIP platform that could be easily by their customers. Slable’s previous VoIP solution was not powerful enough to handle complex features and began to experience weekly outages, resulting in a loss of faith in their services. Facing the prospect of losing customers, Slable decided to find a reliable VoIP platform that would scale with their growing customer base and provide feature rich applications for advanced users.

2600Hz’s Solution

Implementation

When Slable started researching VoIP platforms, they realized that there
was little focus on SMB customers. Most providers lacked the training and documentation for Slable to implement their solution and had minimums that were too high. 2600Hz was able to provide a reliable platform, partner support, quick onboarding/training and customized solutions for advanced users.

Business Outcome

2600Hz’s customizable platform enhanced Slable’s VoIP capabilities and freed time for customer outreach, service, and support. Slable achieved a better ROI due to prompt support responses, reduced downtime, easy migration, and better tracking of customers.

2600Hz is continuously adding unique and bleeding edge features, creating a one-of-a-kind telecom experience for Slable’s clients. As a result, Slable has been able to grow their VoIP business and are aggressively pushing VoIP in the local Washington, D.C. market with cost-savings and increased features.

Key Improvements

• Comprehensive 
  
• Training 
  
• Competitive Pricing 
  
• True Support 
  
• Customizable Solutions 
  
• Scalability
  
• Mobility
  

The “IP Address Leakage” topic has turned into a public relations issue for WebRTC. It is a fact that the WebRTC API’s can be used to share one’s private IP address(es) without any user consent today. Nefarious websites could potentially use this information to fingerprint individuals who do not want to be tracked. Why is this an issue? Can this be stopped? Can I tell when someone is trying to use WebRTC without my knowledge? We try to cover those questions below along with a walkthrough of a Chrome extension that you can install or modify for yourself that provides a notification if WebRTC is being used without your knowledge.

Creative solutions for leaks

The “IP Leakage” problem Why does WebRTC need a local IP address?

As Reid explained long ago in his An Intro to WebRTC’s NAT/Firewall Problem, peer-to-peer communications cannot occur without providing the peer your IP address. The ICE protocol gathers and checks all the addresses that can be used to communicate to a peer. IP addresses come in a few flavors:

• host IP address – this is the usually the local LAN IP address and is the one that is being exposed that is causing all the fuss
• server-reflexive – this is the address outside the web server hosting the page will see
• relay – this will show-up if you have a TURN server

Why not just use the server reflexive and relay addresses? The host IP address is the If you have 2 peers that want to talk to each other on the same LAN, then the most effective way to do this is to use the host IP address to keep all the traffic local. Otherwise you might end up sending the traffic out to the WAN and then back into the LAN, adding a lot of latency and degrading quality. This is the best address to use for this situation.

Relay addresses require that you setup a TURN server to relay your media. Use of relay means you are no longer truely peer-to-peer. Relay use is typically temporarily to speed connection time or as a last resort when a direct peer-to-peer connection cannot be made. Relay is generally avoided since just passing along a lot of media with no added value is expensive in terms of bandwidth costs and added latency.

This is why the WebRTC designers do not consider the exposure of the host IP address a bug – they built WebRTC on this way on purpose. The challenge is this mechanism can be used in to help with fingerprinting, providing a datapoint on your local addresses that you and your network administrator might not be happy about. The concern over this issue is illustrated by the enormous response on the Dear NY Times, if you’re going to hack people, at least do it cleanly! post last month exemplified this issue.

Why not just ask for when someone wants your local IP address?

When you want to share a video or audio stream, a WebRTC application you use the getUserMedia API. The getUserMedia API requires user consent to access the camera & microphone. However, there is no requirement to do this when using a dataChannel. So why not require consent here?

Let’s look at the use-cases. For a typical WebRTC videochat, user consent is required for the camera permission. The question “do you want to allow this site to access to your camera and microphone” is easy to understand for users. One might require consent here or impose the requirement that a mediastream originating from a camera is attached to the peerconnection.

What about a webinar. Participants might want to join just to listen. No permission is asked currently. Is that bad? Well… is there a permission prompt when you connect to a streaming server to watch a video? No. What is the question that should be asked here?

There are usecases like filetransfer which involve datachannel-only connections without the requirement of local media. Since you can upload the file to any http server without the browser asking for any permission, what is the question to ask here?

Last but not least, there are usecases like peer-to-peer CDNs where visitors of a website form a CDN to reduce the server-load in high-bandwidth resources like videos. While many people claim this is a new use-case enabled by WebRTC, Adobe showed this capability in Flash at MAX 2008 and 2009.

As as side-note, the RTMFP protocol in Flash has leaked the same information since then. It was just alot less obvious to acquire.

There is an additional caveat here. Adobe required user consent before using the user’s upstream to share data — even if peer-to-peer connections did not require consent. Apparently, this consent dialog completely killed the use-case for Flash, at a time when it was still the best way to deliver video. What is the question that the user must answer here? And does the user understand the question?

Photo courtesy flickr user Nisha A under Creative Commons 2.0 What are the browser vendors and the W3C doing about it?

Last week Google created an extension with source code to limit WebRTC to only using public addresses. There have been some technical concerns about breaking applications and degrading performance.
Mozilla is considering similar capabilities for Firefox as discussed here. This should hit the nightly build soon.
The W3C also discussed the issue at their recent meeting in Berlin and will likely address this as part of the unsanctioned tracking group.

 

How do I know if a site is trying to run WebRTC?

We usually have chrome://webrtc-internals open all the time and occasionally we do see sites using WebRTC in unexpected ways? I wondered if there was an easier way to see if a site was covertly using WebRTC, so I asked Fippo how hard it would be to make an extension to show peerConnection attempts. In usual fashion he had some working sample code back to be in a couple of hours. Let’s take a look…

How the extension works

The extension source code is available on github.
It consists of a content script, snoop.js, which is run at document start (as specified in the manifest.json file) and a background script, background.js
The background script is sitting idly and waiting for messages sent via the Message Passing API.
When receiving a message with the right format, it prints that message to the background page’s console and show the page action.

chrome.runtime.onConnect.addListener(function (channel) { channel.onMessage.addListener(function (message, port) { if (message[0] !== 'WebRTCSnoop') return; console.log(new Date(), message[1], message[2]); chrome.pageAction.show(port.sender.tab.id); }); });

Pretty simple, eh? You can inspect the background page console from the chrome://extensions page.
Let’s look at the content script as well. It consists of three blocks.
The first block does the important work. It overloads the createOffer, createAnswer, setLocalDescription and setRemoteDescription methods of the webkitRTCPeerConnection using a technique also used by adapter.js. Whenever one of these methods is called, it does a window.postMessage which is then triggers a call to the background page.

var inject = '('+function() { // taken from adapter.js, written by me ['createOffer', 'createAnswer', 'setLocalDescription', 'setRemoteDescription'].forEach(function(method) { var nativeMethod = webkitRTCPeerConnection.prototype[method]; webkitRTCPeerConnection.prototype[method] = function() { // TODO: serialize arguments var self = this; this.addEventListener('icecandidate', function() { //console.log('ice candidate', arguments); }, false); window.postMessage(['WebRTCSnoop', window.location.href, method], '*'); return nativeMethod.apply(this, arguments); }; }); }+')();';

The code snippet also shows how to listen for the ice candidates in a way which
The second part, inspired by the WebRTCBlock extension, injects the Javascript into the page by creating a script element, inserting the code and removing it immediately.

var script = document.createElement('script'); script.textContent = inject; (document.head||document.documentElement).appendChild(script); script.parentNode.removeChild(script);

Last but not least, a message channel is set up that listens to the events generated in the first part and send them to the background page:

var channel = chrome.runtime.connect(); window.addEventListener('message', function (event) { if (typeof(event.data) === 'string') return; if (event.data[0] !== 'WebRTCSnoop') return; channel.postMessage(event.data); });

There is a caveat here. The code is not executed for iframes that use the sandbox attribute as described here so it does not detect all usages of WebRTC. That is outside our control. Hey Google… can you fix this?

Ok, but how do I install it?

If you are not familiar with side-loading Chrome extensions, the instructions are easy:

1. Download the zip from github
2. Unzip it to a folder of your choice
3. go to chrome://extensions
4. Click on “Developer mode”
5. Then click “Load unpacked extension”
6. Find the webrtcnotify-master folder that you unzipped

View of the WebRTC Notifier extension

That’s it! If you want to see more details from the extension then it is helpful to load the extension’s console log. To do this just click on “background page” by “Inspect views”.

If you are familiar with Chrome Extensions and have improvement ideas, please contribute to the project!

What do I do if I find an offending site?

No one really knows how big of a problem this is yet, so let’s try to crowd source it. If you find a site that appears to be using WebRTC to gather your IP address in a suspicious way then post a comment about it here. If we get a bunch of these and others in the community confirm then we will create a public list.

With some more time we could potentially combine selenium with this extension to do something like a survey of the most popular 100k websites? We are not trying to start a witch hunt here, but having data to illustrate how big a problem this is would help inform the optimal path forward enormously.

{“authors”: [“Chad Hart“, “Philipp Hancke“]}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.

The post How to stop a leak – the WebRTC notifier appeared first on webrtcHacks.

I don’t think so.

There have been at of chatter lately about the NY Times and local IP address use. A rather old Mozilla bug got some attention due to it, with some interesting comments:

Daniel Roesler #106:

I’ve said this before and I’ll say it again. Data channels should require user consent just the same as video and audio (getUserMedia). I haven’t yet heard a good reason on why a silent P2P data channel connection is required.

Eric Rescorla #116:

We are considering adding an extension to restrict the use of WebRTC but are still studying what would be most effective.

Zack Weinberg (:zwol) #117:

I would like to second this observation. I have not attempted to dig into the details of the spec, but it *sounds* like the entire problem goes away if creating any sort of channel requires explicit user authorization.

The rants go on.

What they all share in common? Leak of IP addresses is wrong and shouldn’t be done. Not without a user’s consent.

I’d like to break the problem into two parts here:

1. IP leakage
2. Consent

IP leakage

The issue of leaking a local IP address is disconcerting to some. While I understand the issue for VPN configurations, I find it a useless debate for the rest of us.

My own local IP address at the moment is 10.0.0.3. Feel free to store this information for future dealings with me. Now that you know it – have you gained anything? Probably not.

Oh, and if you have a mobile phone, you probably installed a bunch of apps. These apps are just as complex as any web page – it connects to third parties, it most likely uses an ad network, etc. How hard is it to get the local IP address inside an app and send it to someone else? Do you need special permissions to it? Do users actually approve it in any way? Do you think the NY Times app uses this for anything? How about Candy Crush? Or Angry Birds?

Local IPs are compromised already. Everywhere. They are easy to guess. They are easy to obtain in apps. Why is the web so different? And what huge secret do they store?

Consent

When someone wants access to my camera, microphone or screen – I understand the need for consent. I welcome it.

But when it comes to the data channel I am not so sure. There are differences here. My thinking about it runs in multiple paths.

1. Content

Microphone, Camera and Screen actually give new data to Java Script code to work with. The Data Channel is a transport and not the data itself.

The browser doesn’t ask permission to download 50+ resources from a web page when we only asked for the web page. It doesn’t ask for permission when 40+ of these resources are located at other domains than the one that we asked for. It doesn’t ask for permission when a web page wants to open a WebSocket either. It doesn’t ask for permission when a web page tries to generate other bidirectional methods to connect to our browser – SSE or XHR – it just runs it along.

As we are trying to protect content, permission on the data channel level seems unnecessary.

If we want to protect local IP address exposure, we should find other means of doing that – or accept that in many use cases, they aren’t worth the protection.

2. User experience

For a video call, a request to allow access is fine – there’s a human involved. But for a programmatic interface that’s a bit of an overkill. With many WebRTC data channel use cases targeting CDN augmentation or replacement, would users be willing to take the additional approval step? Would content providers be willing to take the risk of losing customers?

Let’s assume GIS and mapping on the internet adopts the WebRTC data channel – similar to what PeerMesh are doing. Would you be happy with the need to allow each and every web page that has a Google Map on it to have access to the data channel?

Would you want your games to ask you to allow connecting to others when switching to multiplayer?

Do you want Akamai (a CDN) powered websites to ask you to allow them to work to speed up page loads?

This doesn’t work.

Stop thinking about the data channel as a trojan horse – it is just another hammer in our toolbox.

3. Web trends

In many ways, we are at a phase where we are trying to decentralize the web – enabling browsers to reach each other and to dis-intermediate the servers from the communications. FireChat is doing it for awhile now, but they are far from being alone in it.

This kind of decentralization cannot work properly without letting browsers chat sideways instead of via web servers. While we may want in the future to make such connections as low level TCP and other network building blocks, this isn’t the case today.

We need to find other solutions than placing a permission request on every data channel we try opening.

Why is it important?

We need to be able to distinguish between FUD and reality.

Data channels by themselves aren’t a threat. They may change the way browsers operate on the network level, which may expose vulnerabilites, but the solution shouldn’t be disabling data channels or putting manual roadblocks to them on the browser – it should be in better architecting the solution around them.

As WebRTC grows and matures, these issues will be polished out. For now, I still believe WebRTC is the most secure VoIP technology out there to build your services. Trust, on the other hand, will always depend on the web service’s developers.

The post Should WebRTC Data Channels be Explicitly Approved by the User? appeared first on BlogGeek.me.

Kamailio SIP Server v4.2.6 stable is out! This is a minor release including fixes in code and documentation since v4.2.5.Kamailio (former OpenSER) v4.2.6 is based on the latest version of GIT branch 4.2, therefore those running previous 4.2.x versions are advised to upgrade to 4.2.6 (or to 4.3.x series). If you upgrade from older 4.2.x to 4.2.6, there is no change that has to be done to configuration file or database structure comparing with older v4.2.x.Resources for Kamailio version 4.2.6Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.2.x release series is summarized in the announcement of v4.2.0:

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

Note: the branch 4.2 is the previous stable branch. The latest stable branch is 4.3, at this time with v4.3.1 being released out of it. The project is officially maintaining the last two stable branches, these are 4.3 and 4.2. Therefore an alternative is to upgrade to latest 4.3.x – be aware that you may need to change the configuration file from 4.2.x to 4.3.x. See more details about it at:

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

WebRTC monitoring the right way.

When we started out developing testRTC, what we had in mind is a service that helps QA people test their service prior to heading to production. We’ve built a sleek webapp that enables us to simulate virtually any type of a WebRTC use case. Testers can then just specify or record their script and from there run it and scale it in their tests using testRTC. What we quickly found out was that some were looking for a solution that helps them monitor their service as opposed to manually (or even automatically and continuously) testing their latest build.

The request we got was something like this: “can you make this test we just defined run periodically? Every few minutes maybe? Oh – and if something goes awfully wrong – can you send me an alert about it?”

What some realized before we did was that the tests they were defining can easily be used to monitor their production service. There reasoning behind this request is that there’s no easy way to run an end-to-end monitor on a WebRTC service.

The alternatives we’ve seen out there?

• Pray that it works, and wait for a user to complain
• Using Pingdom to check that the domain is up and running and that the server is alive
• Using New Relic or its poor man’s alternative – Nagios – to handle application monitoring. It boils down to testing that the servers are up and running, CPU and memory load look reasonable and maybe a bit of your server’s metrics

But does that mean the service is up and running, or just that the machines and maybe even processes are there? In many cases, what IT people are really looking to monitor is the service itself – they want to make sure that if a call is made via WebRTC – it actually gets through – and media is sent and received – with a certain expected quality. And that’s where most monitoring tools break down and fail to deliver.

This is why a few weeks ago, we’ve decided to add WebRTC monitoring capabilities to testRTC. As a user, you can set it up by defining a test case, indicate from where in the world you want it to run, define the intervals to run it along with thresholds on quality. And that’s it.

What you’ll get is a continuously running test that will know when to alert you on issues AND collect all of the reports. For all calls. The bad ones and the good ones. So you can drill down in post mortem to see what went wrong and why.

If you need something like this, contact us on testRTC – the team would love to show you around our tool and set you up with a WebRTC monitor of your own.

 

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

The post WebRTC Monitoring: Do you Monitor your Servers or Your Service? appeared first on BlogGeek.me.

Each new major version of Kamailio brings a new set of configuration file variables, which adds to the existing long list (see Pseudo-Variables Cookbook), enabling more flexibility or making easier to approach some specific needs.

v4.3 introduced as well several new variables, here we touch few of them.
$var(name) is an old variable, storing the value in private memory, being persistent per process. It is very fast when used in operations (no looking needed), therefore popular across config files. One of its property is that the initial value is 0 (no need to initialize it explicitly) and setting it to $null results in resetting it to value 0.
Requested by community, a new variable class $vn(name) was introduced in v4.3 by pv module, which has the properties of $var(name), but it holds ‘null’. Setting it to 0 requires explicit assignment ‘$vn(name) = 0′ and setting it to ‘$null’ no longer resets the value to 0, but to ‘null’.
The pv module added $sbranch(key), a class of variables that allows to manage all the attributes of outgoing branches, including the first branch corresponding to request URI. It is like a temporary container where to store the attributes before pushing them to the branches. A set of three functions come to help in these operations: sbranch_set_ruri(), sbranch_append() and sbranch_reset(). An use case that is possible now can be setting the Path of a branch (next hops till final destination), including the one for R-URI branch.
Related to XAVP variables, a function named xavp_explode_params() can be now used to take the names and values of a parameters string and add them as XAVPs.
The rr module introduced variables to get the direction of the request – $rdir(name) will return ‘downstream’ if request is from caller to callee and ‘upstream’ if the request is from callee to caller.$rdir(id) is the variant to return 1 for ‘downstream’ and 2 for ‘upstream’. From the same module come $fti and $tti – the From and To tags as for the initial INVITE transaction, no matter of direction for the request. For example, using in config (e.g., as htable key) the dialog 3-tuple identifier (call-id, from-tag, to-tag) is now simpler, no need to care anymore about the direction of the request.

Presence or other IMS modules are among the components introducing new variables, you can see the full list of variables available for Kamailio v4.3 at:

• http://www.kamailio.org/wiki/cookbooks/4.3.x/pseudovariables

What is new in v4.3 is summarized at:

• http://www.kamailio.org/wiki/features/new-in-4.3.x

Enjoy the summer!

Hello, again. This passed week in the FreeSWITCH master branch we had 46 commits. The new features this week are: the addition of getcputime to retrieve FreeSWITCH process CPU usage, added support for 80 ms, 100 ms, 120 ms packetization to mod_opus,  and added H.263 codec support to mod_av.

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

New features that were added:

• FS-7848 [mod_opus] Add support for 80 ms, 100 ms, 120 ms packetization
• FS-7519 FS-7677 [mod_av] Add H.263 codec support
• FS-7885 Add getcputime to retrieve FreeSWITCH process CPU usage
• FS-7889 [mod_conference] Move conference chat to use an event channel so messages only go to the right ‘room’ for the conference and move conference chat functionality to use event_channel.

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

• FS-7860 Prevent a switch_rtp header conflict
• FS-7130 Make /run/freeswitch persistent, so it will start under systemd

The following bugs were squashed:

• FS-7789 [mod_av] Fixed issue with audio dropping out partway through recordings
• FS-7854 Add task_runtime to tasks table in core database
• FS-7856 [mod_av] Fix some segfaults and leaks.
• FS-7866 Fixed a crash when running incorrect var api expansion syntax “eval ${${external_sip_ip}:4}”
• FS-7861 FS-7862 [mod_conference] Fixed a crash and other issues caused by multi canvas feature
• FS-7681 [mod_conference] Factor out conference->canvas and allow per canvas record and play
• FS-7869 [mod_conference] Fixed a deadlock on shutdown after playing video file that will not display video
• FS-7654 Fixed regressions on eavesdropping on channels playing a file and on channels with unlike rates
• FS-7872 [mod_verto] Gracefully fail attempting to transfer 1 legged call
• FS-7874 [mod_conference] Fixed incorrect layout group count
• FS-7870 [mod_conference] Allow jsonapi commands to pass the string id field to pass special ID’s like “last”
• FS-7882 [mod_conference] Allow JSON API commands to send third arg for muting
• FS-7888 [mod_verto] Fixed namespacing problems in javascript library masked by global verto object
• FS-7811 Use more common format CIF for blank image
• FS-7902 [mod_local_stream] Fix for queue filling up when you have a mix of video and non video files
• FS-7891 [mod_spandsp] Allow spandsp dtmf detector to work on rates other than 8k
• FS-7839 Correct firefox > 38 DTLS behavior to match new EC requirements

I don’t know the answer to this one…

I attended an interesting meetup last month. Sergei Koren, Product Architect at LivePerson explained about HTTP/2 and what it means for those deploying services. The video is available online:

One thing that really interest me is how these various transports are going to be used. We essentially now have both HTTP/2 and WebSocket capable of pretty much the same things:

HTTP/2 WebSocket Headers Binary + compression Binary, lightweight Content Mostly text + compression Binary or text Multiplexed sessions Supported Supported Direction Client to server & server push Bidirectional

What HTTP/2 lacks in binary content, it provides in compression.

Assuming you needed to send messages back and forth between your server and its browser clients, you’ve probably been considering using HTTP based technologies – XHR, SSE, etc. A recent addition was WebSocket. While the other alternatives are mostly hacks and workarounds on top of HTTP, a WebSocket essentially hijacks an HTTP connection transforming it into a WebSocket – something defined specifically for the task of sending messages back and forth. It made WebSocket optimized for the task and a lot more scalable than other alternatives.

With HTTP/2, most of the restrictions that existed in HTTP that required these hacks will be gone. This opens up the opportunity for some to skip WebSockets and stay on board with HTTP based signaling.

Last year I wrote about the need for WebSockets for realtime and WebRTC use cases. I am now wondering if that is still true with HTTP/2.

Why is it important?

• BOSH, Comet, XHR, SSE – these hacks can now be considered legacy. When you try to build a new service, you should think hard before adopting them
• WebSocket is what people use today. HTTP/2 is an interesting alternative
• When architecting a solution or picking a vendor, my suggestion would be to understand what transports they use today and what’s in their short-term and mid-term roadmap. These will end up affecting the performance of your service

 

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

The post Who Needs WebSockets in an HTTP/2 World? appeared first on BlogGeek.me.

The new charter for the WebRTC Working Group has been approved. Current members will need to re-join, from the WebRTC WG mail list…

Hi all,

Great news, the new W3C WebRTC Working Group charter [1] has been officially approved by the W3C Director [2].

The revised charter adds a deliverable for the next version of WebRTC, has an updated list of deliverables based on the work started under the previous charter, clarifies its decision policy, and extends the group
until March 2018.

The charter of this Working Group includes a new deliverable that require W3C Patent Policy licensing commitments from all Participants.

Consequently, all Participants must join or re-join the group, which involves agreeing to participate under the terms of the revised charter and the W3C Patent Policy. Current Participants may continue to attend meetings (teleconferences and face-to-face meetings) for 45 days after this announcement, even if they have not yet re-joined the group. After 45 days (ie. September 10, 2015), ongoing participation (including meeting attendance and voting) is only permitted for those who have re-joined the group.

Use this form to (re)join:
https://www.w3.org/2004/01/pp-impl/47318/join

Instructions to join the group are available at:
http://www.w3.org/2004/01/pp-impl/47318/instructions

Thanks,
Vivien on behalf of the WebRTC WG Chairs and Staff contacts

[1] http://www.w3.org/2015/07/webrtc-charter.html
[2] https://lists.w3.org/Archives/Member/w3c-ac-members/2015JulSep/0024.html

To reach out to you.

I’ve been asked recently to write a few more on the topic of WebRTC basics – explaining how it works. This is one of these posts.

There’s been a recent frenzy around with the NY Times use of WebRTC. The fraud detection mechanism for the ads there used WebRTC to find local addresses and to determine if the user is real or a bot. Being a cat and mouse game over ad money means this will continue with every piece of arsenal both sides have at their disposal, and WebRTC plays an interesting role in it. The question was raised though – why does WebRTC needs the browser’s IP address to begin with? What does it use it for?

To answer, this question, we need to define first how the web normally operates (that is before WebRTC came to be).

The illustration above explains it all. There’s a web server somewhere in the cloud. You reach it by knowing its IP address, but more often than not you reach it by knowing its domain name and obtaining its IP address from that domain name. The browser then goes on to send its requests to the server and all is good in the world.

Now, assume this is a social network of sorts, and one user wants to interact with another. The one and only way to achieve that with browsers is by having the web server proxy all of these messages – whatever is being sent from A to B is routed through the web server. This is true even if the web server has no real wish to store the messages or even know about them.

WebRTC allows working differently. It uses peer-to-peer technology, also known as P2P.

The illustration above is not new to VoIP developers, but it has a very important difference than how the web worked until the introduction of WebRTC. That line running directly between the two web browsers? That’s the first time that a web browser using HTML could communicate with another web browser directly without needing to go through a web server.

This is what makes all the difference in the need for IP addresses.

When you communicate with a web server, you browser is the one initiating the communication. It sends a request to the server, when will then respond through that same connection your browser creates. So there’s no real need for your browser to announce its IP address in any way. But when one browser needs to send messages to another – how can it do that without an IP address?

So IP addresses need to be exchanged between browsers. The web server in the illustration does pass messages between browsers. These messages contain SDP, which among other things contains IP addresses to use for the exchange of data directly between the browsers in the future.

Why do we need P2P? Can’t we just go through a server?

Sure we can go through a server. In fact, a lot of use cases will end up using a server for various needs – things like recording the session, multiparty or connecting to other networks necessitates the use of a server.

But in many cases you may want to skip that server part:

• Voice and video means lots of bandwidth. Placing the burden on the server means the service will end up costing more
• Voice and video means lost of CPU power. Placing the burden on the server means the service will end up costing more
• Routing voice and video through the server means latency and more chance of packet losses, which will degrade the media quality
• Privacy concerns, as when we send media through a server, it is privy to the information or at the very least to the fact that communication took place

So there are times when we want the media or our messages to go peer-to-peer and not through a server. And for that we can use WebRTC, but we need to exchange IP addresses across browsers to make it happen.

Now, this exchange may not always translate into two web browsers communicating directly – we may still end up relaying messages and media. If you want to learn more about it, then check out the introduction to NATs and Firewalls on webrtcHacks.

 

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 WebRTC Basics: How (and Why) WebRTC Uses your Browser’s IP Address appeared first on BlogGeek.me.

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.

So You Think You Can Code?

You’ve seen the presentations, you’ve asked your questions, you have the resources, now it is your time to shine by using the sponsor APIs to create something exciting! We want to see what you can do! Bonus points for each API you can incorporate! Go check out the APIs now to get a head start on the competition and get those creative juices flowing! You have less than two weeks to prepare!

Sponsor APIs: FreeSWITCH, Tropo, Kandy, Twilio, Plivo, and more…

IPv6 Round Table

IPv6 and why you should deploy it ASAP: John Brzozowski, Fellow and Chief Architect, IPv6 at Comcast, Bill Sandiford President of CNOC, Member of the board at ARIN.

Flowroute – Jeopardy

Think you know about SIP? Do you know enough to beat the competition? Flowroute is hosting a SIP themed game of Jeopardy! Put your brain to the test and come see how much you really know!

DTMF-u

Do you like all things games? Well, then this is the game for you! But there is a twist! Before you can win the game you must build it! Using your choice of language or API you must build a game! There will be three categories of DTMF-u; Tic-tac-toe, DTMF pattern recognition, or Freestyle. You could build something that plays a random DTMF sequence, receives player input, and then either continues or fails the player. Or maybe a WebRTC based game of tic-tac-toe? Or surprise us! Have fun with it! Creative ways to fail a player may give you bonus points. The top three games will be played by everyone and the winner of each will take home a prize! All gaming bots will be screened via a Turing test to ensure no unintended apocalyptic consequences.

Show and Tell

Alright, now is your chance! You have been playing with the code all day and this is your chance to show off! We want to know what you’ve done and how you did it. Use your creativity and skills as a programmer to impress the judges and win a prize! This is a no holds barred all out free for all! Any language doing anything! Knock our socks off and take home a fabulous prize and a year’s supply of bragging rights!

Raffle Grand Prize!

The grand prize is a laser engraved commemorative FreeSWITCH 1.6 Edition dual-core 13″ Retina MacBook Pro!