Tag Archive | xten

Skype for SIP, it's about time!

+

Back in 2004 I wrote a post relating to the VON Canada Panel I sat on with Niklas Zennstrom. It was an interesting debate on open standards (SIP in this case) and closed networks, specifically Skype. I was quite vocal about how silly I thought Skype was not to include SIP, a few of you picked up on that 😉

It looks like something good came of the eBay purchase as we now see a Skype pushing towards open standards, good stuff!

On a similar note, I heard a rumour that it’s likely Jason Fischl the current CTO at Counterpath (Xten) will be going over to work with Jonathan Christensen (General Manager – Media Platform) at Skype. Jason was an early advocate of SIP in the IETF and works with some of the best minds on the subject: Cullen Jennings, Robert Sparks, Alan Duric come to mind.

This could get interesting.

I will do some testing with SkypeforSIP & Response Point and post the results along with my comments on what this new offer from Skype might mean for Response Point.

Jeff Pulver Comments on FCC's Single National Framework for VoIP

Let me first say that Jeff Pulver’s and his FWD network/service (Free World Dialup) was instrumental in contributing to the early growth of Xten (now called Counterpath). FWD provided the platform where the X-Lite SIP softphone flourished. It was a great litmus test for us and created incredible awareness for our product. I don’t think I ever thanked him properly for that.

VON might be history, but Jeff is far from done.

In his last blog post, Jeff talks about exclusive federal jurisdiction for VoIP and how important this is to the communications industry as a whole.

It’s a good read, here is an excerpt…

Yesterday six major high-tech associations collectively representing the growth engines of the economy (generating billions of economic activity every year, employing millions of workers, and representing thousands of companies) filed a friend of the court brief in support of the FCC’s decision to provide a single national policy framework for VoIP.

This is a big deal, and a part of a broader effort to remove barriers that could determine how and when consumers benefit from the lower prices, new services, and advanced communication features that VoIP can deliver.

Check out the entire post: http://pulverblog.pulver.com/archives/008352.html

Are we ready for a 3G softphone?

It’s been a while since I spent any amount of time thinking about the endpoint world but some recent developments around mobile SIP clients and softphones have my attention once again. The question is, “Are we ready for a 3G softphone?”

With 3G comes plenty of bandwidth and powerful mobile devices. The likelihood that carriers will want to cannibalize their own revenue in order to deliver VoIP on the cheap and/or free is… low, to say the least. With that being said there are rumblings that this is in fact what they are planning.

We all know that Rogers is bringing the iPhone to Canada on a 3G network. The fact that there is now an SDK for iPhone will make it rather easy to create a SIP client for the iPhone. On its own, the iPhone does not have enough of a subscriber base to drive mass adoption of a mobile SIP softphone, but it will certainly help.

I know the boys at Counterpath (Congratulations Donovan!) have been busy with FMC and it would seem as though they would be the carrier’s choice for any mobile 3G SIP softphone solution. Although, It’s not clear if a mobile SIP SDK is just a component within their enterprise offering?

So, what other 3G mobile SIP softphone solutions are there out there and which would qualify as a valid choice for a carrier?

If we search for “mobile sip” we see Nokia leading the charge. Not surprising, Nokia has been the predominant player in embedded SIP clients for years now. They have a bit of a leg up there, owning the device doesn’t hurt, or does it? From a carrier’s perspective one would think that getting further into bed with the device vendor could be troublesome but I guess it could work the other way as well.

Something else that’s interesting is that Google’s Android does not have a SIP stack. Not surprising when you think of it. After all Google Talk is still very limited in it’s telephony abilities. One would expect that with the introduction of Android, this would change.

Truphone would likely be a good choice but they are not a softphone vendor, they are a service provider, plus they currently only support Nokia devices. Although I know they have a version working on iPhone already and it would not surprise me if they were working on something for RIM devices.

So who’s left?

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.

%d bloggers like this: