Archive | voip api RSS for this section

W3C ORTC CG Meeting 10 underway

w3cScreen Shot 2015-11-20 at 10.57.13 AM

ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!

http://ortc.org/2015/11/04/w3c-ortc-cg-meeting-10-november-20-2015/

The first ORCA CG meeting!

Here are the ORCA Community Group meeting details for our very first CG meeting.

Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)

Location: Hangouts

Agenda
===============
• 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:
http://www.w3.org/community/orca/participants

Looking forward to seeing you!
/Erik

WebRTC, ORTC and OTT Comm

Too many phones!

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.

In order for WebRTC to win, in mobile, web and server-side. We will need a JavaScript friendly object model, not an Offer/Answer model based on telecom of old.  Even if you don’t share the same opinion, you owe it to yourself to take a look at what’s happening in the W3C ORCA Community Group.  For me, (and a bunch of others) there lies the future of WebRTC.

 

/Erik

For disclosure purposes, I am a co-author on the ORTC API and a co-founder at Hookflash .

Stop Talking to Yourself. Go beyond the RTCWEB Silo!

RTCWEB / WebRTC is designed to let two or more browser-enabled devices communicate P2P (peer-to-peer) with audio, video or data. But there’s a big catch. The browsers can’t communicate out of the box unless some undefined “external process” gathers information about each browser and hands the information to the other browser.

This mystical external process is known as “on the wire signaling”. Gathering information from a browser/peer needed to communicate isn’t incredibly difficult for a moderately talented programmer, nor is exchanging the required information. All that would be required is some kind of go-between web server and a socket or two. This solution is relatively simple and there are other companies setting themselves up to provide that kind of service offering.

But that kind of signaling will quickly becomes unwieldy to manage in the real world and misses many critical use cases and components in much larger deployments. The overriding presumption in such a model assumes both ends want to communicate and does not define how they want to communicate, let alone addressing very complex security issues.

So what does make up a robust and complete P2P communication solution?

A well thought out P2P solution should addresses these concerns:

  1. Initiation of communication between peers that are not actively expecting communication
  2. Exchanging the types of communication desired (audio/video/text/etc.)
  3. Allow peers the option to allow or disallow communication
  4. Allow peer to disengage communication at any time gracefully
  5. Changing the nature of the communication at any time (adding or removing media types like audio/video/text, media on hold, transferring sessions to other participants, etc.)
  6. Handle users’ identities so that users on independent systems can interoperate (and identify themselves when communicating)
  7. Handle users logged into multiple locations as the same user
  8. Find users to communicate with by their known identities (social, generic, 3rd party, etc)
  9. Validate the identity of the user you think you are connecting with
  10. Secure communication channels in a way that even servers involved in the “communication setup” are not able to decrypt information exchanged between peers
  11. Handle group conversations amongst peers without needing servers to relay the data
  12. Handle communication to applications outside to the browser (e.g. interoperate with mobile apps)

A well designed P2P platform should be designed to enable users on various websites to talk beyond each respective web silo. Users of one website can find and communicate with users on another website and even to users on mobile devices.

It should work with your existing identity model. Alice and Bob on your website are still known as Alice and Bob in the P2P network. You don’t need to administer and map a separate database of usernames and password that would be required with other legacy signaling protocols.

The network should allow users to locate other users by their social IDs, phone numbers, email addresses or by using your own custom defined identities – social or otherwise. It should be built with strong security in mind. Each user has their own private and public key, which when tied with an identity model yield strong proof of identity with completely private communications between peers.

A developer should be able to take the open source libraries and rapidly build and deploy powerful client applications with all of these features built-in and deploy without the headache of managing a communications network. No web developer I have ever met volunteered to be the one trying to figure out the complex ins-and-outs of everything that a good P2P design will resolve. So, I ask you, do you as a developer really want to be stuck in a little silo of communication, maintaining your own custom communication signalling protocol?

If you are looking to leverage WebRTC in a browser or if you just want to build a powerful communications feature into an app, you owe it to yourself to do the research. Before you get headlong into your project and find out the tech you chose was not up to the challenge, take a look around. Libraries like the one found in the Open Peer project could very well fit the bill.

Authored by Robin Raymond, edited by Erik Lagerway

VoIP over 3G now officially allowed on iPhone & iPad, confirmed.

Now I can get it on the App Store!

UPDATE: It’s looking good folks!

Now I can get it on the App Store!

No more Jail breaking iPhones for VoiP over 3G

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.

Previous Post:
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 PHP (or RoR) rock star for dev lead on exciting new (funded) VoIP-centric web app

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 erik@sipthat.com for info.

VoIP Quality of Service (QOS) for small business, where is it?

Is your VoIP quality the pits?

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.

%d bloggers like this: