Many of us have struggled with VoIP Network Monitoring, keeping tabs on our network without having to manually review the health is always a hassle and concern. For every network my team erected we needed to erect a proper monitor. For smaller networks and even VoIP phone systems the traditional Network Monitors were far to expensive to implement and required port mirroring which meant servers had to be deployed in the VoIP network that required monitoring.
So, we created SIPQOS… SIPQOS is a service that allows VoIP network administrators to attach virtual SIP endpoints to their network which send calls to-and-fro and monitors those calls for interruption. It’s a simplistic approach to a complex problem, if the network drops a registration or if a call fails it’s likely (from personal experience at least) that the issue applies to the entire network and other endpoints are experiencing the same problem. SIPQOS won’t take the place of more expensive in-network solutions but it does a great job of providing redundant VoIP network monitoring and SIP-based VoIP phone system monitoring as well.
An excerpt from the announcement we made on the 10th…
VANCOUVER, February. 10 – SIPQOS (pronounced SIP-KWOSS), a new entrant in the VoIP network monitoring market has launched a beta of its remote VoIP network monitoring service today. SIPQOS released the first product to bring the power of remote VoIP network monitoring by combining embedded SIP (Session Initiation Protocol) User Agents, web services and some secret sauce. SIPQOS monitors VoIP networks remotely and alerts network administrators when a problem has been detected.
SIPQOS is doing a great job for us and provides redundant VoIP network monitoring on a production network we run today. It also fills a void where others solutions fell flat, SMS alerts are critical and SIPQOS delivers in spades on that front. Those interested should give it a whirl, it’s free to sign up and the plans after the 30 day trial are cheap by anyone’s standards.
The one thing I might say to Ike is, "you're right, in more ways than one". VoIP has not really come all that far and sometime it complicates life more than it needs to. I think I can help you in one way though Ike, check back in a week and you will see what I mean.
Garrett mentions "Lypp appears to be a solution for mobile professionals that aggregates AIM / AOL, Google Talk / Jabber, iChat MSN and Yahoo! Messenger contacts and allows for group or conference calling via your cellular handset. It also does not leverage the IP network, in favor of the wireless network and or PSTN." I can see why Garrett would think that, the current site says nothing about our Next Generation Conference Calling service, VoIP API or Rails plugin. Keep your ear to the Rails Garrett, that is soon to change 🙂
As a developer Garrett had some comments on the APIs. Garrett mentions that he could not really use either API which I found a little disconcerting. Our goal is to make sure that anyone who understands XML or Rails can use this API. The Lypp API is published here: lypp.com/api and can be accessed by simply sending an email to firstname.lastname@example.org requesting a key.
Luca makes a good point here about the importance of differentiation.
Yes, you are correct Moshe. We are bootstrapping this venture and our poultry investment over the pat year is lunch money when compared to what Ribbit has raised but I think I would still prefer to be driving a Chevy 🙂
Thomas is a smart guy and I have a great of respect for what he is doing in the voip mashup space and what he has done in the past. His comments on my initial post are well taken. On the last comment, I am not opposed to softphones, not at all. It's just that I have seen softphones deployed in almost every scenario imaginable and the take rate in the business community has been low. Mostly due to technical network issues like double firewalls and zero-tolerance VPNs. All that aside, I am very positive about the future of softphones and firmly believe you will see one in the Lypp lign-up, when the time is right.
UPDATE: Andy chimes in by ringing the bell. <ugh>
I think Andy might have slightly missinterpreted my intentions when writing this post but hey, a little spice never hurt anyone 😉
First let me begin by saying I know Ted Griggs and I respect him greatly, he has a great track record for building innovative companies that push the boundaries of technology and communications.
I was the initial designer, sales guy, visionary, president, co-founder and COO at Xten (Counterpath) which since inception has dominated the SIP softphone SDK space. In other words, I think I may know a thing or two about building softphones.
Fyi, Ted and I will be presenting on behalf of our respective companies at Wireless Innovations in April.
With that out of the way, here is why, when I started down this path, I did not choose to reinvent the softphone at the edge of the network.
The edge of the network is a nasty place. Bandwidth issues, carrier packet shaping, lack of end user control and costly redundancy solutions make it nearly impossible to deliver a predictable and reliable telephony service.
Much like turning on the lights when you get to your office, that phone on your desk had better work as expected.
In saying that many professionals use Skype and other softphones, like X-PRO, X-Lite, eyeBeam etc to make calls over the net everyday. But you can bet when it comes time to make the calls that really matter they are not using a softphone on the open Internet, at least not after it suffers major packet loss more than once during a call of significance.
This is also why traditional telephony will be around for decades to come. The PSTN still rules the roost. Setting aside for a moment the unwillingness of the carriers to allow other providers to simply stand up a service that will cannibalize their revenues, reliability and Quality of Service (QoS) is still a major issue.
At Gaboogie we steered away from the softphone or using any VoIP at the edge of the network in our initial plans. We made that decision early on because we believe VoIP at the edge is still not ready for prime time. If you don’t believe you obviously have not tried a best efforts VoIP service in Canada. I have not found a single best efforts offering that does not drops calls, drop packets and well… just generally suck.
So what is Lypp then?
The Lypp API was built to support advanced conferencing and was meant for critical calls for companies that require a dependable service. That does not mean a developer could not use it for more typcial telephony integration, which in fact some are already doing. Using the API directly via XML or by way of the Ruby on Rails plugin developers can add traditinoal telephony and/or conferencing capabilities to their apps in as little as a couple of hours.
We have constructed a very robust network that is redundant and dynamically scalable to handle billions of minutes of call volume per month. Our call back methodology (been around forever) keeps the VoIP in the core of the network. If your landline or cell phone is on, so is our service. Our customers do not suffer from call quality or reliability issues in the same way best effort VoIP service users might.
Developers leveraging the Lypp API can expect a higher degree of call reliability and call quality, more of the time, than any other best efforts VoIP service in North America, period.
Best efforts VoIP, whether you are using a Polycom VoIP handset and an Asterisk PBX or you are using a Ribbit inspired softphone, will likely not match up with the reliability you have come to expect from the legacy telephone networks. However the feature set of POTS (Plain Old Telephone Service) pales in comparison to what VoIP can offer.
Some day we will have the kind of IP infrastructure that will make the edge of the network near bullet proof, but in my humble opinion, we are still a ways off. When we do get there Gaboogie will be ready to leverage its SIP network to the absolute maximum.