Archive | VoIP Mashup RSS for this section

Andy's 2.0 Telco Top 10

Thanks for the mention Andy, I have been busy with my own projects for the last couple of years but I appreciate the fact you still remember some of the projects I had some significant success with, just a wee bit disappointed you forgot to mention them, that’s what I get for not speaking at eComm I guess 🙂

The list of course is bang-on, considering the source that should be no surprise.

I will in fact see become more active this year as my latest startup “SMB Phone” ramps towards general availability and launch. My last conference calling service provider startup “Lypp” is on auto-pilot and is growing nicely, thanks in part to Jay Phillips and adhearsion. The next stop for me will be at Internet Telephony Expo in Miami where I will be talking a bit about why we chose to build a new ITSP “SMB Phone” serving Microsoft’s new Response Point PBX.

Here is the Response Point Seminar schedule:

Tuesday, February 3rd Presentations:

4. An Integrated Solution: SMB Phone Goes to Market
with Response Point

3:00 pm

SMB Phone is a unique VAR and ITSP. Come learn how they identified Response Point as a key technical and business component in their nation-wide go to market programs focused on SMBs.

Presenter(s): Trent Johnsen, VP Business Development – SMB Phone

Wednesday, February 4th Presentations:

3. Response Point Service Provider Roundtable

Interact with the key members of the Response Point Ecosystem. Service Providers will be represented and open to discuss their service offerings and VAR/Agent programs.

Presenter(s):
Bandwidth.com, Cbeyond, Junction Networks, NGT, Packet8, SMB Phone, TotalTel

If you will be attending the show and would like to schedule a meeting, please email Trent Johnsen or myself or call us toll free: 1.866.473.0516 , say either “Trent” or “Erik”.

37signals + Lypp Mashup Canceled

Due to the fact that there are not nearly enough active applicants to constitute a fair contest we are canceling the 37signals + Lypp mashup contest.

more…

by erik | 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.

Audio Conferencing API

 

Conference Calling and Audio Conferencing APIs are not exactly abundant, likely because conference calling has long been a boring and mundane task that few people enjoy. That smell of martial disdain was not exactly motivating developers to come up with a better solution.

Gaboogie aims to up the happy factor considerably with the upcoming launch of Lypp: Next Generation Conference Calling and version 2.0 of the Lypp API.

The conferencing features for Lypp are vast and the API is dead simple to use, if you know XML you are set.

Stay tuned for more on that during the first couple of weeks of February.

Etel, Ecomm and VoIP Mashups

Etel VoIP Mashup – Virtual Conference App.

Update: Looks like I am not the only one who has had it with old school conferences. Scoble has some great points here!

—- 

Since it is unlikely that my idea of a virtual Etel conference will make it on it's own, here is another thought. Why not have a mashup contest with the target application being a Virtual Conference application that could be used with ANY physical conference or expo?

This new app could be used to provide those of us who can't afford or just simply can't physically be at conferences the opportunity to participate. There would be video and audio of each session streamed live over the net, during Q and A attendees on the net could click a button and their phone would ring. At the other end would be a session host who would take your question, introduce the attendee to the panel and then the attendee would ask the question.

We could also integrate presence and show notes in an very interesting way by making use of Twitter, Pownce etc.

If there is to be another Etel (or Ecomm), I think we should step out of the 20th Century and push the IP communications envelope, that is what the essence of Etel was all about, wasn't it?

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: