I’m still old school enough to think that voice conversations still matter. So I call people, and they call me. When I’m out and about I like to know who has called me back at my office (no I don’t want my cell to ring EVERY TIME someone calls my home number, my cosinity number or my home office number). That way I can see who it is and give them a ring right back if it was really something we needed to discus.

I’ve had a number of solutions in place for this over the last 2 years or so. From IM messages to SMS messages. The problem with IM is the lack of great notification on mobile devices. The problem with SMS is paying 2-5 cents each.

This led me to think – maybe using Twitter and @ messages or DM’s was a better answer.

Before I give you the code let me first explain how this works. If you are not comfortable with Asterisk, Asterisk AGI, and customizing extensions.conf you should probably stop here.

Essentially I’ve created an AGI script in PHP which decides – by evaluating the assigned account from extensions.conf – what message to send and to whom.

Step One is adding the following 2 lines to extensions.conf where you process your incoming calls:

exten => XXXXX,1,Set(CDR(accountcode)=AccountName)

exten => XXXXX,2,AGI,send-twitter-msg.php

XXXXX is your current extension and AccountName is the account we will use in just a moment to figure out who to message and what to say.

Step Two is to create the following script in /var/lib/asterisk/agi-bin/ (call the script send-twitter-msg.php):

Download the script here. – Putting the whole script in the blog doesn’t work very well. There are instructions in the script.

UPDATE 09/16/2009: If the above download doesn’t work for you you can download the file zipped here.

All that is left is to reload extensions on the Asterisk CLI and make a test call. Everything should work.
One thing to test right away is that the AGI script is executable by root. There are two steps to make sure it is. First, check to make sure the correct path to php is in the first line of the script – try “whereis php” or “whereis php5″. Then update the first line as needed.Second, make sure the script is executable – as root try “chmod 700 /var/lib/asterisk/agi-bin/send-twitter-msg.php”

Have fun… if you have any questions drop a comment below and l’ll get back to you.

One of my greatest frustrations with Mac has been the lack of a VoIP SoftPhone. To be completely clear, when I say VoIP SoftPhone I mean that the way you would mean “email client”. I’m not interested in a SoftPhone tied to a particular service provider or network.

This search has been frustrating me for almost two years now. In that time I’ve tried and rejected so many SoftPhones I’ve lost count. I know I’ve been to Pure-Mac’s VoIP page about 600 times. I’ve also been to VoIP-Info’s phones page about 600 times. I’ve tried everything from CounterPath to Ubiquity and had not found any SoftPhone that was both high quality and configurable.

I’m happy to say the search is over. iSoftPhone from Call4Mac is a robust SIP SoftPhone. It supports everything you would expect and enables peer to peer calling on the LAN via Bonjour. Configuration is a snap (see screen-shots below) and the implementation of SIP is flawless. I’ve connected iSoftPhone to OpenSER, SER, Asterisk, BroadVoice, Teliax, and Gizmo with no issues.

Perhaps most importantly, the call quality is excellent. Even over wifi on my MacBook Pro – with the usual complement of just about everything running – the call quality is excellent, even with the built in microphone/speakers. There is a slight echo for the other party, but this is easily overcome by plugging in headphones and using the built-in microphone.

Admittedly – this is for the geek crowd or the SMB IT folks. If you don’t have a SIP server/PBX Skype/Gizmo is still the right choice for you. But having said that, this SoftPhone is as easy to install and configure as the average email client. This makes it ideal for those who have a VoIP account/server and Mac Clients in their house/organization.

2008 was supposed to be the year we began to see real-time web take shape. And while Twitter and FriendFeed have begun to show us some bits of what a real-time web might look like mostly it has been a year of discontent.

While I hate year end/beginning “predictions” (what am I Nostradamus?) I’m predicting 2009 won’t be much better. Why? Well that is the interesting part.

I’ll let you in on a secret (shhh, this is just between you and me). Real-time services on the “web” are nothing new. We have a pretty good idea how they work (and don’t work). We know what the challenges are – and to a large degree how to architect/engineer the solutions. The problem is we aren’t leveraging the work that has already been done.

More after the jump…

For years HTTP, SMTP and POP were the web. Those three combined with the underlying transport layer (TCP/IP) to form the “killer application” web. Web 1.0 and Web 2.0 both were built on this framework and exposed both their incredible power and their weaknesses. We’ve developed a multitude of higher order solutions which leverage the power and compensate for the weaknesses – RSS and AJAX respectively provide an example of each.

What does this have to do with real-time? The foundation upon which the web was built isn’t entirely appropriate for synchronous real-time communication. Which is not to say we can not overcome those limitations by re-visiting or inventing parts of that foundation. We know this because we’ve solved one of the most intensive real-time synchronous problems – two way voice communication over internet protocol (VoIP).

VoIP works because it threw out the foundation from IP up. Those of us involved/following it’s development from the early 1990′s on quickly realized that we couldn’t rely on TCP or any of the available application protocols (such as HTTP) because – while they incorporated important solutions for the transmissions of bulk data in response to specific requests – they were not appropriate for a synchronous exchange of data based on a standing agreement to exchange data (essentially this is what a VoIP phone call is). Other issues included efficient distribution of messages to many subscribers (multicasting), the delivery of many small chunks of data in a time sensitive manner, and the implicit understanding that every bit of data wasn’t critical to overall service quality (statelessness).

Because the door was thrown wide open to re-think the foundation of the web we saw proliferation of methods. Each company, group, and standards body developed and promoted a standard. Each screamed loudly that their standard was THE standard – and nothing happened. This was a 15 year period I refer to as the Protocol Wars. Thankfully, the protocol wars have ended, SIP won – and we have an intelligible way to execute on VoIP.

I believe that the problems of the real-time web are the problems that were faced and solved by VoIP. What I don’t understand is why the real-time web community isn’t working with the VoIP community.

In order to implement the real-time web (as opposed to talking about the real-time web) we will need to address multicasting, time-sensitivity, and communication negotiation. All problems already addressed by VoIP.

In order to implement the real-time web we will need to ensure every service/provider/network speaks the same underlying language (protocol) and implements that language in the same way (standard).

So, given that I believe much of the solution for the real-time web exists (which is different from saying it is complete) why do I believe 2009 won’t be much better? For two reasons:

1. Simply because it appears to me that the real-time community is already beginning to engage in a protocol war.
2. There is little or no interest on either side (VoIP/Real-Time web) in engaging to leverage the work already done.

So, here is my challenge to my friends in both the VoIP and Real-Time Web communities. Get in a room and figure it out. Extend SIP, fix XMPP, or just come up with something new – but don’t ignore one another. Please don’t accept another protocol war for the real-time web – because by the time you finally stop talking about the technology you may find that people have completely lost interest in creating solutions that leverage it.

But most of all, don’t make the mistakes we made with VoIP by focusing on the commodity (who will decide what the servers run) instead of getting on with creating the services you users really want.

Various and sundry links pertaining to today’s video blog:

Dan York’s Blog Post

Today’s nonsense about OAuth on FriendFeed

Video Blog 01-05-2009 OMG Twitter got Hacked and VoIP isn’t dead, it is Irrelevant from Brian Roy on Vimeo.

I’ve said it before – and I’ll say it again. Walled gardens are great for developing a market – but the outcome is inevitable (barring anti-competitive regulation). The walls fall.

Skype announced yesterday that they are introducing a Skype interface (know as a channel driver) for Asterisk. This is great news – it enables Skype to work within the larger VoIP environment.

I’ve applied to have cosinity beta test this solution – it will allow us to use a Skype account as a business “phone number” for page2call. Hopefully Skype won’t attempt to defend their network in the Terms or EULA.

From Techdirt…

With increasing attempts to turn internet access on in the sky, there’s been some concern about people making VoIP calls from airplanes, just as there is a concern over mobile phone use in the sky being too “annoying.” Some of the companies providing internet-in-the-sky have claimed that they would block VoIP calls, but that’s going to be pretty difficult. As we’ve pointed out in the past voice is just data and you can always find a way to disguise the data, such that it won’t be blocked. And, indeed, that seems to be exactly what’s happening. Andy Abramson talks about how he got around AirCell’s VoIP blocking when talking to a friend who was on one of these wired airplanes. There’s always going to be away around those things, so unless Congress really decides to ban all voice calls on phones, why not wait and see if people chatting really is a problem?

[From Voice Is Data: Tech Won't Be Able To Stop VoIP In The Air]

There are two points here worth considering:

1. VoIP is data and any attempt to block it can be worked around
2. Phone calls on planes may not really be a problem

First – saying VoIP is data is (perhaps) the most obvious statement I’ve ever heard. But let’s clarify one thing. Transmitted (by any means, analog, digital or IP) SOUND is DATA. Always has been, always will be. We shouldn’t confuse the fact that it is now on an IP network with some kind of transition to “voice as data”.

The valid point is that because the sound (voice) is being transmitted over an IP network blocking is only as effective as the ability to detect the transmission of sound (voice). If everyone plays be the rules and uses RTP over UDP – it is simple to block. However, there will always be profit in circumnavigating IP blocking technologies – to the extent that there is profit, there will be people willing to create VoIP services that defeat the blocking.

The linked article points out the the reported “hack” is no more than RTP over TCP – which is fairly pedestrian. Imagine when RTP is tunneled over HTTP (I’ve done it) or SSH.

The simple reality is making the network the arbiter of acceptable use is never going to work.

Second, I’m not sure how we got to “people chatting on a plane is a problem”. Not too long ago, every flight seemed to have those air to ground phones in the back of the seat in front of you. People never used them – because the per minute charges were insane. But I’ve been on a flight where someone used that phone… and there was no lynching.

I’m wondering if “no calls via cell or VoIP” on a plane is about social norms and people being rude… or the airline’s inability to charge for it…

From Jeff Pulver’s blog this morning comes news that FWD (Free World Dialup) is going to begin charging for VoIP Service. FWD has long had a very large user base and significant challenges generating any revenue from that base… they’ve seen Vonage, Broadvoice etc create businesses from the basic idea they’ve been working since 2001.

Full post from Pulver’s Blog

I do not see this as a bad thing… FWD will need to generate revenue to survive in the near/mid term. This, however, doesn’t really change the reality that the cost of making a call is on a steady march to 0.

more after the jump…

The challenge is simple – no one has yet found a compelling set of value added services (or features if you insist on the telecom terminology) beyond a base “phone call” that consumers are willing to pay for. That, however, is still the future of revenue in communications – and what we are executing against at cosinity.

At cosinity we are simply taking a different approach – we are not providing phone numbers, connection to the PSTN, SIP trunks or registration. There are 2 reasons for this:

1. There are plenty of CHEAP resources for that – and we have no interest in becoming another minute provider competing on price.
2. If we did that we would have to restrict our services to “our network” to defend the revenue generated by selling minutes.

We are committed to the idea that the application is valuable an the phone call (or other communication mechanism) is a pure commodity. You have phones/phone numbers/devices/etc what you need is applications that make them more USEFUL and deliver real value to you or your business.

Here is what Jeff had to say and a link to the full post.

The email below went out to inform the nearly one million registered users of Free World Dialup of plans to adopt a $30 annual membership fee as of September 1, 2008. Daniel Berninger has responsibility for day to day operations of FWD as CEO, but I wanted to add a few words on the motivation for taking a stand for paid membership.

Yogi Berra said, “When you arrive at a fork in the road, take it.” I don’t know if anyone predicted that the entire VoIP industry would end up with business models dependent on traditional telecom revenues, but it seems hard to deny with Skype, Jajah, Ribbit, and a long list of others chasing per minute revenues. We are risking the exodus of the FWD user base (and inevitable hate mail) to prove there exists an alternative. FWD will move forward in support of communication between paid members and anyone else with VoIP devices connected directly to the Internet. We will provide no services to facilitate interconnection with the telephone network. This represents a recommitment to the work that motivated the FCC to issue the Pulver Order in 2004 recognizing FWD as entirely unregulated. We believe the energies dedicated toward gaming the telephone network would produce much better results if applied to the task of creating services, applications, and content for communication devices directly connected to the Internet. Chasing an experience based on charging per minute immediately erases the prospect for an Internet like experience independent of geography and usage charges. FWD is the only VoIP enterprise going this route, and plentiful options exist for those looking for cheap minutes. I hope people will remember FWD’s 12 years as a free service and wish us luck as we put action to our convictions.

[From Free World Dialup moving to $30 annual membership]

Articles like this make me nervous:

VoIP scam bilking Islanders – from CBC News

Caller ID unreliable

Caller ID on your phone will not help you identify the origin of the caller, said MacLean.

“In some cases, these fraudsters will actually use spoof legitimate-looking numbers,” he said.

“On your caller ID it may appear that there is a legitimate number on there, but it could actually be a totally different number from a totally different place.”

Once the information is stolen, charges can start appearing on your credit card overnight, and you may not find out until you get your next statement. MacLean said several Islanders have already been cheated out of thousands of dollars.

Let’s get realistic here. It isn’t that caller id is unreliable, or even that “spoofing” caller id is inherently bad… it is simply that criminals used caller id and “spoofing” to scam people into doing something they should NEVER DO:

In this latest scheme, when you answer the phone, an automated voice claims to be calling from your bank or credit card company. An offer is made to reduce bank fees or consolidate debts, or the recording might claim to be an alert over a problem with your card.

Then it asks you to punch in your bank or credit card number on the phone.

Needless to say I do not approve of scam artists using caller id as a tool to create confidence in their targets – any more than I approve when they use sweepstakes schemes or any other such misleading tactic. The solution is NOT to outlaw caller id spoofing, sweepstakes or speaking (in the case of slick talking telemarketers that swindle your grandmother out of her life savings). The solution is to outlaw the swindle, scam and fraud.

To be completely transparent, both page2call and callRecord (our communications applications from cosinity) spoof caller id. We do if for a perfectly respectable reason – individuals and small businesses purchase our services to make (and receive) phone calls on their behalf. Who would want page2call if we couldn’t set the caller id to be the phone number for their business?

We are not misleading people, we are providing valuable services – as will many other companies – which use caller id “spoofing”.

Jeff Pulver gives us his thoughts on Verizon’s continued patent assault on VoIP providers.

This case against Cox is significant because rather than seeking the same win it got from Vonage from other similarly situated companies, Verizon is now seeking to expand the breadth of its winning patent portfolio to fixed VoIP. To the extent that Verizon wins here, this could have broad implications for other fixed services using DOCSIS (as Cox and the rest of the cable industry generally use), presumably other fixed VoIP that doesn’t use DOCSIS, and depending on which if any patents are upheld – to VoIP billing systems, routing systems, network management, and other technologies. So while this is the first major suit against a fixed VoIP services, my quick read of the patents suggests that only in a few cases (like the 930 patent) are the patents limited to fixed functionality. Among analysts, there is still speculation as to why Verizon chose to go after Cox cable instead of a cable company like Comcast who presumably uses the same technology, shares a greater competition footprint, and has a larger number of customers.

Jeff’s post contains links to the suit and each disputed patent.

This activity continues to stifle adoption and investment in VoIP services in the US – with the net effect that only the legacy fixed line carriers (with their patent arsenals) are able to effectively able to offer these services. That being said – they have little or no profit motive in innovating voice communications – after all their revenue is generated from fixed PSTN service.

One of the key differences as TeleGeography points out is that in Europe, incumbent service providers have had to compete against VoIP providers and now themselves account for 26% of VoIP subscribers, while in the US incumbents have remained largely on the sidelines in terms of VoIP.

This is – in my opinion – another attempt to shield a business model using legislation. Verizon is not trying to protect their VoIP offering (business model) by enforcing these patents… they are protecting their existing fixed line business model.

Instead of embracing innovation and using their patents to develop superior offerings – and winning in the marketplace – they are using their patents as blunt instruments to blunt the effect of innovation.

The bad news is that Verizon can not – long term – win this battle. All they will do is force the innovation to locales outside the influence of the US patent system. Verizon is doing VoIP providers in Europe and Asia a huge favor and the US consumer a huge disservice.

If you really stop to think about it, voice communications is – by comparison with all of the other communication mechanisms available to us – hopelessly rudimentary.

The reality is – even with the advent of VoIP and services like Vonage, Skype and Gizmo – the basic phone call hasn’t changed very much Alexander Grahm Bell placed the first call in 1876. We have a few more basic features (voicemail, caller id) but still lack many of the basic functions that have made email and instant messaging so valuable.

More after the jump…

The simple reality is that if I were to bring you a communication service today and tell you that:

1. It allows you to communicate with someone – but only if you have a dedicated device.
2. You can only communicate with them in real time – so if they are not available you’ll have to leave them a message.
   1. Of course their only option to reply to the message is to attempt to communicate with you in real time – but if you are not available they can leave you a message.
3. You’ll have no record of these communications.

That is essentially the state of even advanced voice communications today. An email solution with that same feature set would be laughable – as would any communication system except a voice communication system.

This is exactly the state of affairs that precipitated the launch of cosinity – my Social Telephony company. The reality is that voice communication has a wide chasm to cross to even begin to address the needs of the average business person or consumer. The current state is inflexible, lacks critical value generating functions and implements a single use case – point to point real time voice communication.

To understand what the market demands, take a look at your email client. To make things interesting let’s not discuss Outlook/Exchange, but just a simple email client like Mozilla Thunderbird. Here is a quick list of things I can do with Thunderbird I can not do with voice:

1. Connect to multiple mail services (any one I choose).
2. Address by name (imagine having to memorize an IP address to send an email)
3. Save a record of all communications.
4. Organize my communication records.
5. “Share” a communication (forward an email).
6. …

I’m sure you can come up with a few more.

Someone asked me this question the other day

Ok, I get it… voice is lacking some “must have” features found in every other communication mechanism. That doesn’t mean people want those features when they communicate by voice. How can you be sure they want these features?

On it’s face this question sounds perfectly reasonable. Maybe when people talk they do not want the same features as when they email, IM, wiki or blog…

However, on further examination this question falls flat.

• Why does every other communication product have these features? Simple – the market place demanded them.
• Why doesn’t voice? Simple – the market place (until very recently) was not driving voice functionality – it was the realm of the service provider. A single service provider was your only means to obtain these services – where was the stimulus for innovation?
• Why would we assume voice is different? Simple – because it always has been. However, the reality is, whatever brings value in one communication medium is directly applicable to all communication mediums.

The good news is today you have choice – which means “service providers” are again required to compete based on the fundamental laws of supply and demand.

The good news is today you are seeing services – jaxter, GrandCentral, cosinity, Odeo, etc – begin to level the feature playing field. We’re seeing the market begin to demand feature parity across communication mechanisms.

As for me – I could not be more excited… it is a great time to be in voice communications and Social Telephony. I look forward to engaging the market place and bringing feature parity to voice – and beyond that, enabling entirely new utility based on voice communications.