Tag Archive | thomas howe

Lypp VoIP API, 37signals, Broadsoft Xtended, Ruby on Rails

We are just one day away from opening the doors to the 37signals Highrise + Lypp VoIP Mashup contest, we are all quite excited about what will come of that, the entire post is over here.

Something I read today that I thought was rather "timely" in this regard was Thomas Howe's post regarding his new Ruby Gem built for Broadsoft via Xtended.

For those who don't know, Broadsoft is essentially the leader in the VoIP softswitch department although they really like to be called a Voice Application vendor, I think, Scott will likely correct me on that 😉

At least one person has asked me what I think of BX (Broadsoft Xtended) and what it means to Lypp and specifically the impact it has on the Lypp API.

Here it is..

1. For carriers, the Lypp API is to some degree what Xtended is to Broadsoft, just not for Boradsoft. Our API was written so that we could easily port it to any softswitch, voice application platform, voip switch etc. So if Broadsoft customers or even competition wanted some of the same functionality that is delivered via Xtended they might take a look at the Lypp API.

2. For service providers, Lypp offers a complete service toolkit that not only gives you the API but also delivers the telephony service as well. Think of the Lypp API as the Amazon Web Services of VoIP. The API is free and so is a developer account, you only pay for what you use, just like Amazon Web Services.

3. For application developers, it is a brainless way to bring advanced telephony into existing or new applications (web, mobile, client-server, et al) without investing millions into infrastructure.

The impact Broadsoft Xtended has on Lypp is very positive. Broadsoft has plenty of marketing dollars and the more people that understand what Xtended is the more it will help little companies like Lypp accelerate their own growth.

So to this I say, "Go Broadsoft! Go Lypp! Go Rails!"

by Erik | http://sipthat.com

Ribbit vs. Lypp

VS  

I have had a few people ask me to describe the differences between Ribbit and the Lypp API

——– 

UPDATE: Ike Elliot has some good points about the un-evolution of VoIP 

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.

——– 

UPDATE: Garrett Smith adds some food for thought

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 api@lypp.com requesting a key.

——– 

UPDATE: Luca Filigheddu with some thoughts of differentiation

Luca makes a good point here about the importance of differentiation.

——– 

UPDATE: Moshe Maeir makes a great anaolgy. 

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 🙂

——– 

UPDATE: Thomas Howe reflects on the differences and makes some good points.

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.

VoIP Mashups and Building VoIP Applications

VoIP APIs + Development = VoIP Mashup 

Scoble posted a great video of a Zude demo the other day which looks to have some great promise. It's like a social network mashup within a social network. Make sense?  I am not going to go into greate detail on the service apart from saying that I was impressed with the ease at which I was able to drop code my Zude page and manipulate images with relative ease, 2 of my pet peaves with any existing web app/blog software.

So the social network scene is heating up which is a good thing, Facebook and MySpace need the competition. There has also been some action in the VoIP Mashup scene of late led primarily by Thomas Howe and Company, go Thomas!

VoIP Mashups are not really all that new. VoIP APIs / SDKs / toolkits have been used in combination with other VoIP APIs in many instances over the years to create various telephony applications. Going WAY back I can remember dorking around with the NetMeeting SDK and other toolkits to produce what could be considered an early H.323 version of Skype.

The technology has come a long way since then and SIP now rules the open standards VoIP roost and I believe we are all better off because of it. As I look back on the state of the industry from the mid-late 90's I can see some distinct similarities in the sales and marketing approach of the old school VARs and the VoIP consultants of today.

The multi-port protocols of old and the lack of support for the SDKs that were represented back then are behind us. In their place are some very well designed and thoroughly supported APIs that can deliver just about anything any company would ever dream of when building a new telephony application or integrating VoIP into an existing application.

So what's missing? If today's APIs are so great why do we need consultants to tell us which one is better for our potential projects? One theory is that we as humans are generally pretty damn lazy. As a rule we also like it when others tell us what we should do thereby averting disaster when the dung hits the fan.

Folks, there is no Black Magic required when building or integrating VoIP into your apps. Do your research and talk to as many industry professionals as possible. In some cases you will not need to know anything about VoIP, SIP or H.323 etc. Make an educated decision, then take that API and build something great.

%d bloggers like this: