Back in October 2013, the relative early days of WebRTC, I set out to get a better understanding of the getUserMedia API and camera constraints in one of my first and most popular posts. I discovered that working with getUserMedia constraints was not all that straight forward. A year later I gave an update after the […]
The post getUserMedia resolutions III – constraints unleashed appeared first on webrtcHacks.
If you aren’t using AppRTC yet then you should start.
I had a few customers last month who had quality issues with their service. They were trying to understand the root cause of these issues, and at times, the question raised was “is WebRTC up for the task?”
The list goes on.
The fact that now you get a fully implemented media engine in the browser for free is great. The problem is, it gives you (or your developers) the opportunity to blame the browser: It isn’t us. Google’s engineers did such a crap job with X that we just can’t fix it.
More often than not – this won’t be the problem.
When in doubt – check AppRTCGoogle launched AppRTC quite some time ago.
AppRTC is Google’s way of showcasing WebRTC in their simplest version of the “Hello World” program. This being WebRTC, there are many moving parts, but to some extent, AppRTC is rather baseline – especially in its dealings with media.
This makes AppRTC a great baseline reference when you have issues with the media paths of your own service or just want something to compare it with.
Got an issue? Test what happens when you run AppRTC and compare it with your own service. If you see that your service isn’t performing in the same manner, chances are the problem is on your end – and now you can start diverting focus and resources towards searching the problem instead of blaming the browser.
Where to look for the problems?
Google has another great analysis tool – test.webrtc.org
You open the settings, insert your own STUN and TURN server configuration – and start the test.
It will then check the system and network connections to give you a nice view of what the browser is experiencing – something you can later use to understand the environment you operate in.
Why is this important?With WebRTC, it is easy for developers to blame the browser. This isn’t productive.
Your first task should be to create a baseline reference you can trust. One that enables isolating the issues you are experiencing systematically.
AppRTC is a good place to start.
The post Are You Using AppRTC as Your WebRTC Baseline Reference? appeared first on BlogGeek.me.
Our next Kranky Geek event is taking place in India.
Kranky Geek events? We did them twice. Both times in San Francisco. Both were very successful events. In both we didn’t know if these are one time gigs or something we want to continue doing.
Then we sat down to plan 2016, and came up with three planned events. The first one is taking place in Bangalore, India.
As with any Kranky Geek, this one is about developers of real time communications.
Like previous Kranky Geek events, it is free to attend. Sponsors take the burden of enabling us to plan this event and then pay for everything around it.
Google has been taking the lead here and helping us a lot in getting these events off the ground – in a way taking the leap of faith in our ability to manage these events.
IndiaGoogle asked us to do an event in India, so we happily obliged. For me, it would be the first time in India, making the excitement on my end even higher.
India makes sense in a lot of ways. Many of the vendors I end up looking are vendors that are local to India. Others are vendors with large development teams in India who end up doing a lot of the WebRTC development. Kranky Geek India gives me personally a great opportunity to meet many of these people in person.
To make things short:
Where? Bangalore, India
Exact location: MLR Convention Center
Date and time: March 19, 11:00 until we finish
How do I register? here
Our sponsors this time are Google, TokBox and IBM. Expect a large cadre of interesting speakers and topics – some local and some international in nature.
I’d love to see you with us at the event!
The post Join us for Kranky Geek India: March 19 appeared first on BlogGeek.me.
Just making sure you’re not missing out…
If you don’t know, in the last year I’ve been part of a great team of partners. We are building together a WebRTC monitoring and testing service called testRTC. The service is up and running for some time now with an increasing number of customers.
The most crappy part of our service was our website (not the one customers are using, but rather the one potential customers look at). So we updated it recently.
One of the main additions to that website is the new blog there. I’ve got an editorial calendar for it running until March with weekly content that I want to share with you, but felt that BlogGeek.me isn’t the best of places for it – it was too focused on testing or too related to testRTC.
What will you find in our testRTC blog?So some of the content will be relevant to everyone while other parts of it for those using testRTC.
Subscribe now and follow usIf this sounds interesting, I suggest you subscribe to our blog or social media link(s):
The post Subscribe to the New testRTC Blog appeared first on BlogGeek.me.
Dumb pipe or not, data services thrive mainly out of the telecom world these days.
Can Telecom Services survive the Internet?Telecom Services are an interesting notion. For over a hundred years we’ve been taught that Telecom Services=Phone calls. Then messaging was added to it in the form of SMS on mobile. Telecom services themselves assume that their role in life is to sell us our communication services.
This is no longer true.
I remember working on 3G-324M. A circuit switched video protocol, now dead to the world at large. In many of my discussions, people complained about their inability to add services on top of what a carrier provided – there were too many layers of debilitating bureaucracies.
Today? Everything operates over an IP network. Most of us don’t even care if it is cellular, landline, wireless, or whatever – as long as we get our bits on the line – we’re happy.
While we are all happy using VoIP services and discussing how disruptive it is to carriers, we haven’t seen nothing yet.
The wheel has turned. In the past, advantage lay in owning the network and offering managed services on top of the network. Today, and moving forward, advantage lay with those who can operate their service across networks.
This means that carriers are left with their own network, and a DNA of working inside their own managed network – something that makes it harder for them to operate in this new reality.
Here are two areas that drive the message home:
#1 – Google FiGoogle Fi is how mobile phones should operate. It is Google being an MVNO and offering mobile plans to its customers. Instead of buying a plan (and maybe a subsidized handset) from a carrier, you can just purchase a plan from Google – and use a Nexus smartphone.
What makes Google Fi so different is that it operates on 3 different networks:
Read the FAQ for this one – it is quite telling.
Here’s one piece of it:
What happens if I start a call over Wi-Fi and then lose my Wi-Fi connection?
On your Project Fi device, if you start a call over Wi-Fi and then your connection weakens or drops (such as when you leave your home or office), Project Fi seamlessly transitions your call to a cellular network (if one is available) so you can keep talking.
Calling is no longer tied to a cellular network. Fi has 2 cellular network and whatever Wi-Fi you happen to be on. And it decides what to use based on past experience of Google – and is able to change that dynamically mid-call.
Fi is not your typical MVNO. Or your typical VoIP provider. Or your typical carrier.
It is just how things should be.
#2 – Internet of ThingsThe Internet of Things to me is everything but a carrier. The hint to that is in that first word – Internet. You don’t really need a carrier for that – just an IP connection. Any IP connection.
While there are use cases that will necessitate a carrier (or just his SIM cards?), most of them don’t have a carrier as a prerequisite for their existence.
I like this slide of Octoblu – an IOT platform that was acquired by Citrix:
It shows the various players in the IOT space:
Nothing about the underlying network. No one really cares what that ends up being. Which makes sense. For this to work, you need an ubiquitous network. Not necessarily one with high bandwidth or no packet loss – but one that you can assume exist. Which is what we have in most of the modern world now.
Final ThoughtsNo. This isn’t the end of carriers.
Yes. They will still make boatloads of money.
Much like electricity is a utility, access to the Internet is a utility.
The services on top of it though? They don’t necessarily belong to the carriers.
The post Google Fi, Internet of Things and the Bleak Realities of Telecom Services appeared first on BlogGeek.me.
This week mod_vpx saw some cool tweaks and mod_conference saw some improvements to the auto bitrate in personal canvas mode. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Simon Woodhead from Simwood! And, head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
All roads lead to WebRTC.
Java in the browser no longer an optionThis started happening in 2015, and is growing as a trend. Half a year ago we witnessed browsers killing off plugins and Flash with a slew of new security issues getting shunned by browsers for a few days.
This left developers with 4 available alternatives for VoIP in a browser:
Oh and there’s this Java Web Start thing, but seriously – you planning on enticing your customers to INSTALL something on his desktop in 2016?
With Flash and Plugin options becoming deprecated as we move further, it seems that Java will be taking the deprecation plunge as well. Oracle just announced they won’t be supporting their Java plugin moving forward.
You are yet again left with WebRTC.
The real implications aren’t for those using WebRTC, but rather those who are trying to support browsers without WebRTC:
The future of communications is in WebRTC.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post First Plugins, then Flash and now Java – WebRTC is now the only alternative appeared first on BlogGeek.me.
It is. But it really isn’t.
Confused?
Still thinking WebRTC = P2P?There’s so much misunderstanding about WebRTC that it is funny at times. People throw into a conversation sentences like “WebRTC is just peer-to-peer – it can’t do a large conference service like you can with [PLACE-YOUR-COMPANY-NAME-HERE]”.
As with anything else in life, such comparisons are plain wrong. As I always say: WebRTC is just a technology. It is up to you to develop your service on top of it. If that service happens to be a large conferencing service, then why not?
WebRTC being P2P is just as P2P as SIP is. Or H.323. The only difference is that you get to choose your own signaling and your own client. For the first time in history, you get to choose how the topology of your solution will look like from a media and signaling perspective while using a standard specification – and not be bogged down by how people decided to define SIP. Or XMPP. Or whatever.
I had a call with a customer recently. A question that was asked during that call is do I see anyone using WebRTC in mobile just because of cost inefficiencies – not because there’s a browser requirement hiding somewhere in there. The immediate answer I gave was “definitely”. Followed with a few examples to show the point.
WebRTC is P2P? WebRTC is for browsers only? WebRTC only works in Chrome and Firefox?
There are two ways to think of WebRTC:
If you miss that second option of open source media engine then you are missing out on a lot of the use cases out there that are based on WebRTC.
The same applies for server implementations.
There are 3 main components to a WebRTC deployment on the server side:
The first two are mandatory. You’ll have them in all production services with WebRTC no matter what. The media processing one is a bit less obvious, but it is necessary in many use cases. I’ve touched this briefly recently on a post on Dialogic’s blog – oftentimes, you’ll need a server. Be it for recording, multiparty or something else. When that time comes – it isn’t that WebRTC doesn’t cut it for the job because it is P2P – it is that you’ll need to search beyond Google for a solution.
And when you search beyond Google, there are tons of different alternatives:
Next time someone dismisses WebRTC for his project because it is only peer-to-peer – tell them to check his initial hypothesis so he won’t miss out on some of the options he has available to him.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Get Over it: WebRTC isn’t Peer-to-Peer appeared first on BlogGeek.me.
This week mod_kazoo was merged into the build system and mod_conference now allows for multiple member arguments for related API commands. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Randy Resnick from the VoIP Users Conference talking about all things communication! And, head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
Messaging is a platform.
We’re used to messaging. All of us. SMS has been around for ages. And it feels like iMessage, WhatsApp and Facebook messenger were here in the last few decades as well – they are so ingrained in how so many of us behave that we fail to even acknowledge how new they are.
For those of us who have VoIP in their veins – who learned, worked and breathed VoIP in the beginning of the second millennium, messaging is just an extension of VoIP. A buddy list, with the ability to send a message to a buddy.
Some even believe you can charge for messages (RCS – I am looking at you).
The truth of the matter is, that today, messaging is free. It is an expected “utility”, where money is made elsewhere. Facebook spent countless of billions to own WhatsApp – a messaging service with boatloads of users and little by way of features and bells and whistles. Oh – and in most cases and places, WhatsApp never charge its users for the system, and now, it probably never will.
Facebook released earlier this month their “vision” for Messenger in 2016, and Josh Constine did a nice review of it on TechCrunch.
For me, these are the things that are important from these two posts:
Messaging is a lot more than messaging and signaling protocols these days. It is less about the underlying network technology and more about business aspects and usability. It takes away a lot of the power and ego out of the VoIP guys. Just like that, they don’t really know what should be in their core competency. I come from this VoIP background, and I need to struggle with it daily.
What are your messaging plans for 2016?
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Facebook and the Future of Messaging appeared first on BlogGeek.me.
S doesn’t stand for Simple in SFU.
What are you doing about your WebRTC SFU requirements?I have noticed recently that more and more companies are attempting the creation of their own SFU. SFU stands for Selective Forwarding Unit, and it is by far the most popular and cost efficient architecture today for multiparty video with WebRTC. With it, all participants send their video to a single entity (usually in multiple resolutions/bitrates), and that single entity decides (selectively) how to route the incoming video to all the participants.
One such popular framework is the Jitsi Videobridge.
Up until today, an SFU for WebRTC was rather simplistic. You had VP8 to contend with as a developer but that’s about it. Life was good. You built your service and mostly whined about incompatibility between browsers.
Things have changed.
Here are a few things that you need to take into consideration when you either build your own WebRTC SFU or adopt/acquire one from others:
Like any other technology, once you get down to it, there’s more to do than the proof of concept. Consider these aspects at the beginning of your project – and not when you need to seriously rethink your architecture.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post What are the Challenges of DIY your WebRTC SFU? appeared first on BlogGeek.me.
Do you really want to trust companies like Google or Facebook, or other large organizations with your private communications? They rely on employees to dig into and analyze information when a back door is opened to them. They claim to need to be able to sift through information to pinpoint nefarious activities or corporate opportunities, but that means they are subjecting safety to human limitations. And that door is now available for anyone else that finds a key. How many examples of “hackers” accessing private information such as credit card numbers or social security numbers do we need before we stop trusting external organizations to keep us safe. Who holds them accountable if not the user? Wouldn’t we be truly safer by not putting in a back door at all? Weakening encryption to allow one entity in means weakening security across the board. That is why many believe that “if you don’t pay for the service, you’re more than likely the product!” And, as of yet there is not a very reliable way for the average user to counter this idea and monitor proprietary software to ensure they aren’t selling you and your data. Check out what users on a Slashdot forum had to say about the U.K.’s encryption standard and why having a middle man is not a secure option.
Trailrunner7 posted, “The U.K. government’s standard for encrypted voice communications, which already is in use in intelligence and other sectors and could be mandated for use in critical infrastructure applications, is set up to enable easy key escrow, according to new research. The standard is known as Secure Chorus, which implements an encryption protocol called MIKEY-SAKKE. The protocol was designed by GCHQ, the U.K.’s signals intelligence agency, the equivalent in many ways to the National Security Agency in the United States. MIKEY-SAKKE is designed for voice and video encryption specifically, and is an extension of the MIKEY (Multimedia Internet Keying) protocol, which supports the use of EDH (Ephemeral Diffie Hellman) for key exchange.
‘MIKEY supports EDH but MIKEY-SAKKE works in a way much closer to email encryption. The initiator of a call generates key material, uses SAKKE to encrypt it to the other communication partner (responder), and sends this message to the responder during the set-up of the call. However, SAKKE does not require that the initiator discover the responder’s public key because it uses identity-based encryption (IBE),’ Dr. Steven Murdoch of University College London’s Department of Computer Science, wrote in a new analysis of the security of the Secure Chorus standard. ‘By design there is always a third party who generates and distributes the private keys for all users. This third party therefore always has the ability to decrypt conversations which are encrypted using these private keys,’ Murdoch said by email. He added that the design of Secure Chorus ‘is not an accident.'”
For more information click here: http://it.slashdot.org/story/16/01/19/2151215/uk-voice-crypto-standard-built-for-key-escrow-mass-surveillance
Last Thursday we had the first virtual w3c webrtc wg interim meeting. Once we sorted out a few technical details it went quite well!
Meeting Home Page:
https://www.w3.org/2011/04/webrtc/wiki/January_14_2016#Virtual_Interim
Nobody cares anymore.
Nobody cares if you are a silo or federated as long as you’ve got an APIIt used to be important. Interoperability. Federation. Communication across networks, devices and vendors. All useless now.
We’ve got our lowest common denominator: IP, HTTP – the web. We have our point of federation/aggregation – they now call it the home screen of a smartphone.
People got all riled up on my blog last week something about Wire needing to federate – check the comments. My view? Federating wouldn’t move an inch in their user’s base needle.
Today’s openness and messaging is all about being the platform and enabling others to connect to you. How is that achieved? By way of APIs. And by this new stupid word – “Bots” – which most probably stands for automation.
Why is Bots stupid? Because it just means using the API in a certain fashion.
Back to Messaging.
SiloIf you have a service. What happens if it is a silo?
You gain users to it. Slowly or faster. Doesn’t matter that much (though it probably does to you).
One day you want to add more utility to the service – some stickiness – making sure people don’t leave. So you add features. But you understand at some point that going it alone won’t move you fast enough, so you open it up to external developers and services.
You publish an open API.
FederationFederation you say? You make your service accessible to other networks by interacting with them using the same protocol?
Great.
But what does that give you exactly? Same set of features you have, give or take a feature or two. Same utility. No stickiness. No differentiation. Not enough.
So you again wish to add features, but getting out of the core you’ve federated just places you in the position of proprietary features. And again you’ll one day understand it isn’t enough. Faster “innovation” and growth are required on that front – you can’t cater all of your customers’ needs. So you… open up! Slap an API on top of your service.
No one caresTwo alternatives. Same end result.
Time to move on. Nothing here to see.
Just make sure you have a solid infrastructure – and an API on top of it for others to integrate with.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Messaging. Federated? Silo? Does it Matter with an API and Bots? appeared first on BlogGeek.me.
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.