ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!
Here are the ORCA Community Group meeting details for our very first CG meeting.
Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)
• Introduction to the CG
• Quick review of progress to date
• Overview of meeting objectives
– Existing proposals review
– New proposals & review
– API discussion
• Closing remarks
• Action items
NOTE: If you are on the public mail list but have not yet joined the Community Group but would like to attend the meeting you may certainly do so. However, if you are planning on making a contribution you will need to join the CG and make those contributions on the mail list.
Here is the link to the current CG participants and a link to join:
Looking forward to seeing you!
There’s a lot of noise and plenty of dust getting kicked up around WebRTC these days. Every hour it seems there is another company announcing support for WebRTC or have built an app that uses the technology. In many cases it’s an extension to the existing offer, where WebRTC is leveraged as a web-based SIP softphone for instance.
For the love of Pete, does the world need yet another phone?
What does excite me is when I start thinking about the effects that WebRTC and ORTC will have on rich media OTT (Over The Top) communications moving forward.
If we look at the success of apps like Whatsapp, Tango, Viber, Voxer, Facebook Messenger etc etc these are all OTT applications that have already won in mobile communications. Placing a phone call, is nearly the last thing a teen or twenty-something user is looking to do with their phone. Just by pure observation, we can see this demographic using mobiles devices for messaging and now video chat more and more. Btw, this is the generation that will be leading our Enterprise companies in the not so distant future.
We know this, but we still insist on integrating old tech that does not seem to be accelerating in growth. Why? To answer my own question, “because lots of us continue to buy VoIP phones and SIP PBXs for our business”. And to that I say, good for you! But that is not the real opportunity for those developers who embrace WebRTC and ORTC.
WebRTC & ORTC will allow us to push the envelope and do things we can’t do today. And to do things we can do today but in a much more efficient and enjoyable manner. Maybe RTC will find its way into social news, citizen journalism, or maybe media rich banking, healthcare and CRM apps, in your TV, mobile devices, browsers et al. The possibilities are nearly endless but one thing is quite clear, it’s not going to happen unless we change our current approach.
UPDATE: It’s looking good folks!
In the agreement…
3.3. 23 Because some mobile network operators may prohibit or restrict the use of Voice over Internet Protocol (VoIP) functionality over their network, such as the use of VoIP telephony over a cellular network, and may also impose additional fees, or other charges in connection with VoIP, You agree to inform end-users, prior to purchase, to check the terms of agreement with their operator, for example, by providing such notice in the marketing text that You provide accompanying Your Application on the App Store.
9. Third Party Terms of Agreement: You must state in the EULA that the end-user must comply with applicable third party terms of agreement when using Your Application, e.g., if You have a VoIP application, then the end-user must not be in violation of their wireless data service agreement when using Your Application.
Now that we know VoIP over the cellular data network is allowed, and ATT has said they will support it, and ATT has a cheap unlimited data plan (Listen up Rogers, Telus, Bell!), the iPad and iPhone has just become something I think we should be excited about.
Apparently the new iPhone dev agreement has officially been modified allowing for VoIP over the cellular data networks. Trying to confirm that myself.
If this is the case, the iPad and iPhone just got a whole lot more interesting.
Looking for a contract PHP (or RoR) rock star for dev lead on exciting new (funded) VoIP-centric web app. I expect it will be no more than 6 weeks work. Email firstname.lastname@example.org for info.
VoIP and SIP Trunking over best efforts Internet can cause SMBs to jump off the VoIP bandwagon rather quickly. Most small phone systems today do not have any built-in QOS (Quality of Service) monitoring, and those that do are likely not doing anything more than the typical MOS (Mean Opinion Score) based on historical packets.
MOS results are great when we are trying to see what the results were after the problem was detected and can certainly help with understanding some trends, but it does not do much to help SMBs understand why the QOS they are receiving from their current provider is sub par.
The truth of the matter is, the quality of service the ITSP (Internet Telephony Service Provider) is delivering can be high but there are factors that degrade that quality between the SMB’s LAN and the ITSP’s switch(s).
What can be done about it? Depending on your budget and technical acumen, something can be done or nothing can be done.
Most ITSPs who provide SIP Trunks or Hosted VoIP for business will not provide much more than a service status. Either the service status is “Active” or “Inactive”. This is not because they are intentionally holding back, they simply do not have the tools to be able to deliver more information to their users without breaking the bank. VoIP network tools are expensive and are generally not all that easily extensible.
There are some QOS monitoring tools that are fairly cheap and easily accessible. Some are even free!
VoIP Spear (free and paid) is a great little service created by Henry Fernandes at Toepoke Software. VoIP Spear uses ICMP packets (ping packets) to monitor remote connections. We have been using the service for a couple of months now and have made good use of the historical MOS data that the service provides. The only downfall is that uses ICMP. Most routers these days have ICMP echo turned off by default, mostly due to security concerns and potential inaccuracies. That being said it’s a great tool for acquiring remote MOS data and Henry tells me they are working on an API.
But what about ongoing call testing? Some say the only real way to determine QOS is to run periodic call tests that can report on call quality, connectivity issues, bandwidth, latency, delay, jitter etc. Again, tools exist but are expensive and are generally made to run at the top level of the network for network engineers, not SMB owners. Some router/switch vendors like Adtran do have some devices that will deliver on some MOS scoring and alerting but they again are not cheap, generally they start at $1200 (US) for the basics, which puts it out of range for many Canadian SMBs.
This begs the question, “SMBs should not have to concern themselves with QOS, their service should just work, right?”
Yes, it should just work, much like the legacy telephone networks have for the last hundred years. Why should the business owner be forced to accept dropped calls, broken conversations, 1-way audio, and the like, just because it’s VoIP.
The truth is, they won’t switch if they think the lines might drop or the quality might be sub par. Which might explain why so few SMBs have made the jump to VoIP-based systems and service in North America.
What can be done to increase adoption of VoIP for SMBs in Canada? The first remedy is fairly straightforward, ISPs need to increase broadband to small businesses and provide some application prioritization without dramatically increasing price. Considering ISPs want to deliver their own digital voice/VoIP offers, this might be a ways off.
What about better tools, integrated into the PBXs?
One could integrate some of the QOS monitoring/testing bits directly into the phone systems that are sold and by using open standards, provide a secure interface so the Internet Telephony Service Providers would be able to show QOS to their users via their user portals and the like. This would obviously require the pbx vendor to integrate the client piece and the ITSP would presumably host the web components.
This will allow VoIP service providers to show QOS data and provide controls around that for their own customers. Call testing details could be provided in real-time without spending tens of thousands to extend their current toolset to their users in a manner they will understand. This proactive self-support approach would also reduce inbound support for the service provider and would presumably help sell more PBXs for the vendor.
My rant for the week.