Results tagged “telephony” from Emerging Communications Blog

Last Tuesday I had the pleasure of interviewing Irv Shapiro via Skype.

The run time is 40 minutes.

Things are going well here at IfByPhone.  We live in crazy times, but given those crazy times, we're just very lucky.  We're lucky because we provide something that, fairly often, saves our customers money.  It's a terrible thing to say but having a depressed economy might actually help us grow faster.

That's quite interesting you say that because yesterday I was talking to a company who expected their worse month ever, in December, and actually it was the best month that they've ever had.  I'm wondering if the things that they do is to use communications to save companies money, you may not be the only one there? [profiting due to the downturn]

I think those organizations that can focus on how their solution can save money will do very well in this economy.  The side effect, which is really a shame, is that no one really wants to be in the business of replacing people with technology. 

Well, that depends on your personality, of course.  Some people may enjoy that. [humor]

[Laughs] Maybe that's the stereotype of Americans, but [Laughs] yeah, hopefully though, what we do is we allow people that are doing rather mundane tasks to do more interesting things. 

A very good example is we have customers that are just mid-sized companies but they're using call centers.  They were routing a hundred percent of their traffic directly to the call center.  Instead, they used our platform to deploy an IVR solution that prescreens the calls.  There is some percent, twenty or twenty-five percent of their calls, that really never need to go to a person, and the end result is that their customers are delighted because they wait in line less time. 

Because the IVR has the ability to handle many more ports or simultaneous calls than their particular center purchase.  So, their customers wait in line less time and for simple questions, dependent on the business, but it could be "Give me the status of my order".  It could be "When is my order going to be delivered?"  It could be "What are your hours of operation?"  An IVR can handle that very, very well with very little customer frustration and save them a lot of money.  Because using a platform such as ours costs them three to five bucks an hour.  A call center is twenty to thirty dollars an hour.  That seems to be a nice space...

Can I give you some skepticism, though?

Mhmm, sure. 

That actually, twenty percent of the calls may not be going to the call center just because as soon as somebody got the IVR tree, they decided to hang up.

No, because we track every call, they know exactly what happened to every call and whether they got to the end point and the IVR delivered the information they want.

Yeah, I don't think you get the average person getting too excited about IVR trees when they call.  Certainly, I deplore it when I get an IVR tree.

Well, once again, the key to success in any technology is to keep it as simple as possible.  If somebody deploys an IVR tree that is more than one to three questions deep, they're probably going to have a problem.  Understand, people want answers quickly and if you can give them answers quickly, you're generally going to be successful. 

Okay, so can I jump in here, kind of with a pretty standard question I've had the last couple of times; that is IfByPhone are sponsoring one of the a.m. breaks.  If it were not for sponsors, the event just wouldn't be possible because the extortionate costs of the venue.  Can I ask then, why IfByPhone has provided such sponsorship?

Because we're selfish, Lee.

Fantastic!

At the last eComm, that was the first telco industry event that IfByPhone had participated in.  It successfully introduced our organization to the telco industry and was very, very successful at creating awareness for our company.  So, from a business perspective, partnering with eComm is just a good business decision, so it was a very selfish decision on our part.

I'm pleased to hear it and I hope I get more selfish decisions, every year.

[Laughs] Okay

So lately, you've been buzzed about "cloud telephony", and excuse my ignorance, but what I'd like to do is firstly get a feel for what you're meaning by cloud telephony, in the first place.  Can you please tell me what you mean?

Sure, what we're doing is we're stealing or borrowing a nomenclature from the general computing world.  In the general computing world, cloud computing is a current buzzword that's used to imply that you take a computing resource that traditionally was in-house at an organization, you put it in a shared data center that is accessible from the Internet, and you share that resource across tens, hundreds, or thousands of organizations.  By sharing that resource across all those organizations, you can invest more heavily in that resource.  You can provide small and mid-sized businesses with a richer computing environment than they could afford on their own.

Cloud computing, in fact, is very, very old and it's really an issue of fashion.  Back when I started in the computer industry, we used to call this "time sharing" and when the early mainframes were very expensive, you used to buy time on a time sharing environment.  Computers became less expensive and companies brought those computers in-house. 

The cost of running in-house computing, however, began to become very expensive, not because of the hardware or necessarily the software, but because of the personnel cost and the maintenance and support costs.  People started moving that out to the Internet and called that cloud computing.

So Lee, "cloud telephony" is the exact same story.  Historically, telephony has always been in the cloud because we have a shared, central facility-based system.  That's what the traditional telcos are often referred to, where there is shared switching equipment that is used to connect all of our telephone calls together. 

Then, in fact, starting very late 1960's, 1970's, and 1980's, a very popular alternative - I know here in the States, I believe in Great Britain, and potentially in Europe also, was something called Centrex.  In Centrex, you had basically a hosted PBX.  You had a PBX at the central switching office that was shared by many companies and partitioned so each company looked like they had their own PBX.  In essence, cloud telephony or the idea of putting telephone resources in a shared facility, accessible by many people, in order to provide richer capabilities to everyone, is a very old concept in the telco industry.

Okay, so you're putting something that is to be shared within a certain location.  How is this resource - in fact, let's keep it elementary still.  Can you give some example of resources that you're referring to, because in cloud computing we're meaning two things.  We're meaning storage and processing.  It's fairly simple.  In cloud telephony, what resources are you meaning?

Okay, so in the telephony world, historically the world is really divided into two domains.  There is the domain of transport, the people that are moving the call about.  Historically, as we're all aware, those were the people that owned the wires on the poles and the wires underground or the wires across the ocean.  Then, there were applications, but in telco, we didn't historically call them applications, necessarily.  They were things like switches, PBX's that you bought and put in your business and that roam switch or that Northern Telecom switch, in addition to providing potentially basic switching of calls, also allowed your business to have voice mail features, to have maybe in IVR (Interactive Voice Response) capability, to have a variety of ways to integrate computer integrated telephony with computer systems, do screen pops; those were applications.

The world of telco is really divided into transport and applications.  Transport costs, for everyone's good, except for maybe the facility-based carriers, transport costs are falling very, very rapidly.  In fact, you and I are using, in essence, free transport right now, on Skype, and potentially a paid service to record it.  That paid service is an application. 

What we've done is we've taken a very rich suite of telephone applications and we've put those in a shared facility in the cloud, meaning that those applications are available to anyone, and can be provisioned and controlled by anyone who has access to that cloud.  The access is over secure links over the Internet, HTTPS.  Those applications include very basic things like voicemail or click-to-call, slightly more sophisticated things like "find me" and "follow me" technologies, a little bit more sophisticated things like recording, and go all the way through to very sophisticated applications that allow you to do interactive voice response and to build those interactive voice response dialogs from any web browser.  We take applications and we put them in the cloud.

Okay, to me this just sounds like normal Internet stuff, as in there are plenty of people who offer API's for speech detects, and so on.  I can call many services, via an API, just like Salesforce.com style, so what I don't understand is why you're calling it cloud telephony when in fact, today, I can access many providers via and API, for many different capabilities our resources.  Is there some difference or are you just rebranding, or what is the case?

I think there is a fundamental difference.  The fundamental difference is we provide two sets of capabilities.  We provide pre-built applications that work with any telephone.  While they're in the same ecosystem in the Internet, so to speak, as Salesforce.com, they do very different things.  They interface with the end user or the customer over a telephone, which is a very different modality of integration.

Number two, we provide any developer who has basic web development skills with the ability, from a programming environment of their choice, PHP, Java, C#, ASP, etc.; we provide them the ability to initiate a call, to monitor a call, and to receive post-call results. 

We allow them to do call control from the web environment.  The ability to do call control, and as part of that call control, to route that call to an IVR environment with TTS, with ASR, with recorded audio, with DTMF decoding, and as part of that environment, to use pre-built building blocks that do significant things.  We think this takes the world of hosted telephony into a slightly different domain and makes it very much like the Salesforce.com of telephony.

I would like to know some example building blocks, if that's okay.

Sure, absolutely, an example building block is a "find me".  As an example, you can use an API call - let's take it a different way.  You can provision; you can go to our website, you can provision a local or toll-free number.  You can say that that local or toll-free number, as soon as a call comes in, does a call back to a web application.  That web application can look at the caller ID of the call coming in and can decide how it wants to route that call.  This is happening in real time.  A call comes in; we do a call to your web server.  It could be on your desk, it could be in a data center.  We tell you a call came in, this caller ID, this ANI, and you tell us what you want to do next. 

You send us a little snippet of XML back that says, "For this particular call, I want to route it to a "find me".  The "find me" has all of the intelligence to do a pre-call screen to ask the caller for their name or whatever information you want, and then to begin doing parallel rings to "n" number of telephones in order to find the recipient.  That list of "n" number of telephones can either be provided on an API call, or can be provisioned from a web interface. 

All of the intelligence to do the pre-screen, to do the parallel ringing, to handle what to do if nobody answers, to handle terminating the rings once somebody has answered, all of that capability is a pre-built building block or module that we make available.  So, instead of having to build that from scratch, every time, that's a building block that many people would use over and over again. 

So, you have a bunch of resources and people can build at that kind of granular level, sort of one-to-one with the resources, but they can also have what I might term "scripts" or what you're calling modules but are probably pre-written to interact with one or more resources.  Is that correct or not correct?

That would be correct, but some of these modules are complete applications.  As an example, one of these modules is a traditional store locator that will do reverse lookup telephone numbers, will find geo-coding data, will interact with the database.  That's an example of an advanced module or building block that we make available. 

Another one of these modules is that instead of sending these calls to a "find me", you can send the call to a call distributor.  A call distributor will look at the number of calls that have been routed to different call centers or locations and based on some fairly sophisticated algorithms, load balancing and other things such as percentage of use and time of day, will distribute the calls - thirty percent to this center, forty percent to this center, thirty percent to this center. 

These modules might be very simple things.  Another module is voicemail.  Anybody nowadays can basically provision voicemail on an Asterisk system, but making that module available in a richer environment to our customers, both from a website where they can provision it with no programming, or via a programmable interface, we're finding is a differentiating environment for us.

Okay, I love that because it overlaps with one of the major conference themes, which is telecoms is becoming software.  To me, you are very clearly in that direction.  I would like to know; I don't mean for you to list it now, but I had a quick look at IfByPhone.com website and I didn't see a list of resources available and a list of modules available.  I mean, are you able to supply that?  This is just purely out of my technical interest. 

Yes, in fact, on the home page, if you go down the front of the homepage or if you click on the navigation on the left side, each one of those is a separate module that is available.  What actually happens when you have an account on the system, and you go to provision a telephone number, depending on what stage of provisioning you're at, you get a pull-down that just tells you what the different modules are.

Finally, we can send you - we actually just had it rewritten; we have a new version coming out shortly, the API Guide that lists every module that's available, depending on the stage or state of the call.  So, some things are available to get routed to.  Some things are available right off a ring.  Some things are available for out dial. 

What's interesting about what we do, Lee, is every one of our modules, so to speak, are available from either a click on a website, meaning effectively we call that environment "preconfigure an API and make it an easy click-to-call", via the API, via a ring coming in - in other words, you provision a telephone number, or an outgoing call.  You provision a scheduled call or you initiate a call with an API.  We make these software building blocks available for a click, a ring, or a dial, which is an interesting environment for our customers.

I'm going to have to throw in a really awkward question but I know you can take it.  Where do you feel the most value is?  I don't mean in terms of hey, what you're selling, but where do you feel - on quite a personal level, where do you feel you have invested most of your time and energy?  What has been the challenging area?  Where do you feel you sacrificed some of your life to build something?  Where is IPR, where was the challenge?

The challenge is something that no one ever sees.  I spent eighteen months, personally coding a third of it, working with a team of developers to build a dynamic VoiceXML CCXML generator.  The guts behind everything we do - we have an ability to put a bunch of parameters in a SQL database.  Those parameters get into that SQL database. Those controls get into the SQL database via a website or an API call.  Then, when a call is processed, we dynamically generate thousands of lines in some case of VoiceXML CCXML because the actual processing of the call, in particular when there is what we call "smart call" or intelligence in the call, is handled by VoiceXML CCXML and it's as close to industry standard as you can get.  Unfortunately, as with any standard, as you're well aware, there is a lot of wiggle room and in particular on the CCXML side, today.

We have the ability to process our calls in a very flexible way.  That's the IP that underlines everything that IfByPhone does.  That's why we're able to extremely rapidly produce an additional building block or enhance a module because the market says we need an enhancement.  What we're doing is we enhance it in one place; we enhance the generator to be able to handle another set of conditions and then it's available to everyone using our platform. 

From a computer sciences point of view, the ability to do a dynamic code generator was a very interesting activity for me.

I can't help but to want to hone in on this.  I don't know how interested others will be, but I want to know more about this dynamic code generator and what's advantageous about it.

Well, what's advantageous about it is we can take advantage of the very latest carrier grade technologies for dial-up processing because we rely on industry standard VoiceXML CCXML.  The challenge is that the VoiceXML CCXML environment is viewed by some as somewhat complex and therefore, our typical customer is not likely to build an IVR from scratch in VoiceXML CCXML.  If you're United Airlines, you are, or you'll hire a consulting firm to build you and IVR for a gazillion dollars.  It's very finely crafted. 

But, if you're a mid-sized company, you can't afford that. 

So, what are the inputs people are giving to this code generator?

As an example, when they craft an IVR, they choose from about fifteen different types of prompt responses.  They literally go to a website and they say, "The next prompt response is 'I want to ask'," and they either use recorded audio or TTS, "I want to ask for your order number, and then in response I want to receive back a ten-digit number and I want to give the user the ability to say that or to use DTMF.  If the ASR doesn't recognize it, I want to re-prompt and recommend they use DTMF..."  That's all done by pointing and clicking on a website.

Okay, so you're getting to put this pretty paint above the call control and the VoiceXML.

That is exactly right.  The same thing would occur for something more mundane, like a "find me".  Using this pretty paint, they're listing a series of telephone numbers and they're determining how long they want to try each number for, whether they want to try them serially or in parallel; when they connect, whether they want to record the call; if they're recording the call, if they want to constrain the length of the recording.  This is all done by filling in a form on a website.

What that means is the guy in your marketing department at your company can now create a telephone interaction because it's no more complex than what they do to set up AdWords in Google.  They can integrate telephony into parts of the businesses without involving telco or IT resources that a small company may or may not have.

Okay, so I have to be awkward to you again.  I'm sorry because it's just your morning and maybe you've not had enough coffee today for a Lee hassle [laughs].  You know what I'm like.  You know I like to get to the bottom of things.  I think to myself, "Surely, there must be lots of people offering paint to draw with in order to generate call control and VoiceXML". 

And ninety percent of them have designed what they built for computer geeks.  So, let's say they built a Java app and it's point and click and drag and it uses terminology like "barging" and "sensitivity" and "multi-modal controls"; my customer would never understand what you're talking about. 

My customer is either a business professional or a web developer.  With all due respect to web developers, most of them are not highly sophisticated coders.  They work in a scripting environment and they're really good at what they do.  But, they're used to fairly simply scripting environments.  Therefore, we built an environment for them that doesn't require that they understand the underlying architecture at all. 

Our user interfaces are application oriented, in other words, they require the specification of the building block, not VoiceXML CCXML oriented.  There is some really nice VoiceXML CCXML, point-and-click, gooey code generator environments designed for enterprises, for very large corporations, and they're designed to be used by programmers.  They just look completely different.

So what are you doing to get developers onboard?  It doesn't sound like you have a developer program; rather, you seem to be going company by company.  Is that correct?

No, we have over three hundred developers and resellers already building applications and reselling our technology.

So, you are reaching out to web developers.

We're reaching out to web developers, very often, that are part of marketing firms and advertising agencies.  They work in-house for a ten-million dollar business.  They're the guy or the gal that built the website.  Or, they're web developers that built a CRM application for the plumbing industry; they know plumbing inside out and they know development well enough to build a CRM for them.  Now, they're adding computer integrated telephony to that CRM by using our hosted services.  Or, we have a web developer that built a scheduling application for beauty salons, hair salons.  This developer has five hundred customers.  Now, they're adding automatic reminder calls to that application.

This is wonderful.  I love that, I mean, that's just fantastic, these little vertical niches where each application developer knows that sub-domain well.

Right, and these application developers tend not to be computer scientists and they're not telco professionals.  If you ask them for the difference between a trunk and a line, they're going to get confused.  They just want to build their little applications and some of them are running very successful businesses, by the way, extremely successful businesses.  We give them the ability to add telco into that equation, as if it's another web component.

So, this sounds to me, the general speak of it, as if it overlaps with Ribbit.  I don't know if you care to distinguish yourself there, with Ribbit who were bought by British Telecom earlier this year.

Sure, Ribbit is a fantastic company.  I've immense respect for the folks there.  They've chosen a particular path.  The particular path included a close relationship with Adobe and a tool set that is designed to be used from Flex.  Our developers have never heard of Flex.  If you're selling to enterprise, that's a wonderful strategy and they [Ribbit] will be very, very successful with it. 

In our environment, we need to pick the least common denominator.  The least common denominator is that everyone in the web world knows what a URL is.  In essence, the way in the web world that you build web service calls that are URL-like, is you use something that the industry has classified as REST.  What it basically comes down to is if you know how to make a request to a URL, with a set of parameters, and receive back a little snippet of XML, then you can do a REST service call. 

So, you used REST instead of SOAP, for example.  Why?

Because our marketplace doesn't need the sophistication and complications.  In fact, the industry, if you look at Google, they started with SOAP, and now they've moved to REST for most of their newer web service calls.  The reason is the average web developer gets REST.  For the average web developer, SOAP is a little more than they need.

In fact, SOAP is very well designed where you have a directory of resources and you want an API that lets you walk that directory and select a resource.  Our developers are doing very simple things.  They're initiating the call.  They're monitoring a call.  They're receiving the CDR from a call.  They know exactly what API they want to call.  They know exactly what method they want to invoke.  There is no need to have all the overhead of directory services and those types of things.  What we need is a secure, reliable, easy to use API.

Okay, if it's complex we won't go into this, but give me some idea of the kind of cost model you're working with developers.  I'm quite interested in the openness that you're giving this.  In fact, you're giving me interest in what you're doing.  Just generally, what's the cost model?

It's free.  You can sign up at PhoneMashup.com for a developer account.  You have full access to the API and a hundred minutes of telephone time, per month, to play with it as much as you want.  It's free.  If you go over a hundred minutes a month, in a developer account, I believe it's 8 cents a minute.  Once you're ready to fully deploy with customers, there are other subscription plans that go as low as three and a half cents 3.5 cents a minute. 

What you're getting for those 3.5 to 8 cents a minute is not only transport but more importantly, you're leasing or renting application server environments.  You're renting our platform.  In the Phone Mashup account that's free, you have access to all of the building blocks I mentioned.  In a full account, a platinum account, which is forty dollars a month, you get access to the production environment of all of the building blocks.  There is no "pick this, pick that; there's another charge".  You get them all.

That's quite interesting.  Now, I'll double check in case you're not, but are you aware that we're doing tutorials at 7:30 p.m. on the nights of this conference?

You know, I wasn't Lee.

Okay, so Ribbit is running a tutorial, Voxeo is running one.  Obviously, I'm left thinking why you guys are not running a one-hour tutorial at eComm.

That's something we should probably pursue.

Okay, we'll take it up after the call.  I've just got one final question on the topic we're covering at the moment.  Obviously, I'm dealing with a lot of companies who offer telecom services in a software fashion.  What concerns me, and it could be my telco background, I'm not sure, I wonder about the quality.  What kind of quality guarantees are in there.  For me, the call I'm processing with a customer could have a lot of value and I don't really care if it's 8 cents a minute or 80 cents a minute.  Could you tell me how you ensure quality, that things don't fall over, that you have call drops, that a call doesn't work, or that a resource is unavailable?

The first thing we do is our server infrastructure is not posted in the basement of our offices.  It's hosted at Equinix Data Centers, our next door neighbors in the data center is AT&T.  We're in one cage; AT&T is in the next cage.  We're peered with top-tier providers such as Level 3, using QoS, all the way from our servers to the end point, or as close as they'll guarantee.  We only use G.711 Codecs because we're selling to businesses and we're not willing to sacrifice quality for additional compression.  All of our resources are either N+1 or N+2+ in some cases.  As an example, the backend databases that sit behind the code generator are actually fully redundant servers that are then mirrored with fully redundant servers.  We have to lose a lot of infrastructure for the IVR generation to stop running.

The challenge for us and everyone else in the industry is our peering partners will not give us the level of service that was historically available in telco.  As an example, Level 3 will only give us a 99% service level agreement.  They won't go above 99%, and in some cases 99.9%.  They won't go above three 9s. 

The way we have to work around that issue is we have to peer with a range of providers in order to ensure that if any single point fails we can still handle your call.  Probably the best testament to that, I'll share one other thing that just went live on our website.  There will be a series of press releases.  One of the spaces that we have a lot of customers in are the voice broadcast space.  The reason is that when we do voice broadcast, it's not a voice blast where it blasts out a message and somebody picks up the phone and blasts out a message.  We can deliver interactive dialogs, such as, "Mrs. Smith, your couch is scheduled to be delivered at 10:00 today; will you be home?  Please say yes or no".  If you don't say yes, we transfer you to a call center and reschedule your appointment. 

For those calls, our competitors that do just blast out calls basically have no guarantees.  People look at their actual results and they find that it was scheduled to go out at 9:00 and it went out at noon or at 15:00 in the afternoon.  We are releasing, effective now; we went live just two days ago, a hundred percent delivery guarantee.  If we don't deliver your call within five minutes of the scheduled time, it's free.  We're very serious about quality.

In that string of conversation, you happened to mention Google Analytics.  Now, that reminds me, sorry for not having paid enough attention, but I heard the name Irv Shapiro with Google Analytics.  We're told that somehow, and again, excuse me for not knowing, that you had linked up it up in a telephony fashion.  I don't know about this, but I know a lot of people were saying what you did was cool.  So, could you tell me what it was you were doing with Google Analytics that people liked so much?

We did something very simple.  When you go and provision a telephone number, using our web interface, you can specify in your Google Analytic account ID.  Every call that comes into that number will get logged to Google Analytics as if it's a page view.  The page will be the name you give it.  It can be "My Main Telephone Number". 

That allows you, if you're in the marketing and advertising space, and you're running a campaign, and you want to monitor web traffic, but you're also running radio commercials, television commercials, or print ads with telephone numbers, you can also monitor all of your traffic that's coming in those phone lines, simultaneously with your web traffic.  You get a complete picture of your campaign.

Hey, that sounds pretty neat.  Can you get a demo of that somewhere?

I'm trying to think if it's available on phone mashup accounts.  I'd have to check to see if it's available on the completely free phone mashup account.  Surely, I'd be happy to do a glance session, like a WebEx session with you, and show you an account that has it activated.

Okay, as far as I understand, you're not a fan of telephone API's? 

I'm a fan of API's being a piece of the equation.  I think it's a very important piece.  An analogy would be, Lee, that Salesforce.com did not release a cloud-computing environment with an API as their first product, and say to people, "Come build something".  Instead, they released an application that delivered value to thousands of businesses, and then they released an API to interface with that application.  Then, they took it a step further and said, "You also can use our platform". 

We've taken the exact same path.  We first released a series of very basic applications, click-to-call, virtual voicemail, etc.  We then began to release an API for interfacing with those building block or components.  Now, if you look at our suite of services, it goes from API's that let you do basic call provisioning, never touching one of our building blocks, or more importantly, because the building blocks or modules exist, you can very quickly deliver to a customer or to a business real business value.  If we were in just the API business, you have to write an awful lot of code to deliver value.

Okay, I understand.  So, how do you think that cloud telephony, as you've called it, will affect the facilities-based carriers?  That's my final question for you.

I think the traditional telco providers, and in fact the newer telco providers, let's say the cable companies, are all in a very interesting position.  They're all scurrying to deliver transport.  Transport pricing is declining so they're very often all in price battles on who can deliver transport least expensively to a given end point.  I believe that cloud telephony application environments such as ours provide these traditional telcos and the newer telcos such as cable companies with an opportunity to deliver suites of services to businesses that are more than transport.  By delivering more than transport, it will give them an opportunity to price in a way that's better for their business, to effectively have a form of premium pricing. 

What makes it interesting is that a traditional telco can do an experiment or a trial, with IfByPhone as an example, very easily, because we're in the same VoIP/SIP mesh environment as everyone else.  No differently than our peering relationship, which are used to deliver calls, a traditional telco could peer with us, could choose to route certain calls to us.  We process the IVR, we do the intelligent "find me", and we do the intelligent voicemail.  At the completion of the call, if there is a transfer or other event, we can route back to their environment and it makes it a very easy integration because of the VoIP/SIP world.

Anyway, I know you said you could only spare fifty minutes with us, and we're just coming up to that, so I'm going to thank you for your time.  Thank you again for the IfByPhone sponsorship of eComm 2009.  Listen, I hope you have a fantastic day, you drink lots of coffee, and you're super productive.

[Laughs] Thanks so much, Lee, and have a good evening.  I appreciate the opportunity.

Whilst in the midst of transit I had the pleasure to have a pre-conference interview via Skype with Matt Ranney of Rebelvox.

Unusually for me, I did not know Matt personally and had not even had a pre-interview call with him. So this was both a live interview and a first meeting. So it's a bit more two-way and with a lot of informal chit-chat, particularly during the first 8 minutes.

The run time is 50 minutes.

Sorry for the slight clicking sound, it was entirely my fault due to playing with a software setting.

Additionally the full transcript is below. To distinguish between us I've indented Matt.

...I just want to jump in and say thanks to RebelVox for sponsoring, either a lunch or a breakfast.  I can't remember which.  You probably know.  Do you, or do we both not know? [laughter]

I believe it's a breakfast.

Okay, breakfast, thanks a lot for that because the ticket prices would be double.  The venues, especially that one is astronomical.  Nobody wants to be paying double the current ticket price.  So thank you very much.  Can I ask you why RebelVox sponsored?

Sure, I attended the first eComm in 2008.  I was blown away.  It was the conference that made the best use of my time in my career of attending conferences.  The content was high.  The schedule was rigid.  People got to the point.  It was a huge fire hose of great information.  That is the world we are playing in, that we at RebelVox are playing in.  We want to see more of that kind of thinking and the kind of people that go to eComm.  Those are our people.  We're happy to be a part of that.

Hey, that was absolutely fantastic, not even scripted [laughter].  Perfect answer [laughter], you've blown me away.

Is that going to be a sound bite and a little quote on your blog now? [laughter]

I think it will need to be.  That was perfect [laughter].  I'm going to need to interview you more. [laughter]

Maybe next time I'll prepare. [laughter]

Yeah, prepare a two pager [laughter].  I should probably get into this, but because we've not spoken, you might find it could turn into a two-way instead of a one-way.  For example, with Martin, because he is a close friend of mine, Martin Geddes that is, I was able to ask him questions I knew were good for him because we'd been chatting together for years.  Wheras we're just getting to know each other here. 

So anyway, I have to say that meeting with yourselves made me laugh because I posted on the blog, about the death of telephony and the you emailed me saying, "Hey, have you been influenced by RebelVox?" [laughter]  And I had to reply to you and say, "No".  I looked into it after you said that and I thought you guys were influenced by me. [laughter]

We all had a good laugh about that. [laughter]

So each end has been laughing about each other end, thinking the same things, and thinking each other had influenced each other.  Then tonight, when I asked you by email what you wanted to speak about, it reminded me so much of a chunk of the opportunities that I helped Martin Geddes highlight, by means of a long interview with him nearly a year ago.  I don't know if you read that interview I had with him?

Yes, I have.

You are a good eComm citizen. [laughter]

The overlap in thinking was just too great to ignore.  It's really interesting stuff.  I read it, start to finish.

Hey, that's pretty awesome.  We should have spoken before but I think from now on, we're going to be doing a bit of speaking.  It's a shame we haven't had a chance to meet up but  I'm sure we will, a bit longer than thirty seconds in passing.

You know, we were in stealth mode for a long time.  We weren't really talking to people about what we were doing.  That explains a lot of why people such as you haven't ever really talked to us because there was really nothing to say, until very recently.  Now, we're ready to tell the world what we're up to.

Maybe I'll say a little about myself here.  I can go on forever so I'll keep it short.  I I was away to say that you don't want pillow talk from me, that does sound a bit outlandish, but I'm allowed to say these things since it's a 2:00 a.m. here. 

Anyway I think you've gathered, since you're clearly in the eComm community, that I have, or had, not sure which to say anymore, built my career in telephony.  I'd been reading the British Telecom Engineer Journals, it was a general post office back then, since I was twelve.  By the time I was fifteen, I was reading the CCITT signaling specs.  But around four years ago, I realized that telephony was dead.  It hit me like a ton of bricks because the thing I love most, I realized, was dead.  It's dead, dead, dead, and dead.  Yes, we're using it every day, or at least most people are.  But it's categorically dead!  There is going to be a massive wakeup to that!

Anyway, so, when I looked at what you had been saying, your proposed talk for eComm 2009, you are also saying that telephony is broken.  I say it's dead because I know, in the long term - well I won't go into it all here, but it is certainly broken.  In the short to medium interim, the money is in fixing it. 

Can you elaborate on why you believe that telephony is broken?

Sure, it's funny that you think I'm not being strong enough by saying broken versus dead [laughter] .  I thought I was being a little too strong by saying broken.  I think that telephony, as we know it, will probably be around for quite some time.  It's just in too many places.  The bit about it, that I think is broken - it's not so much that telephony has really changed in some way that is now broken, it's just that society has sort of changed around this thing that is essentially unchanged since it was invented.

Now that information moves around very easily, and very inexpensively, we can communicate over great distances for the same cost as communicating over short distances.  All of this inexpensive communication in our lives has put crunches on our time.  As Martin points out quite succinctly, time is the new scarcity.  That's exactly right. 

The thing that's broken about telephony is it doesn't respect the time of the people who are talking through it.  That's what we aim to fix. 

Can you give me some examples?  I tend to be a little bit harsh in my questions.  It's because the whole thing interests and excites me.  Can you elaborate on "it doesn't respect people's time"?

Sure, I hate to be regurgitating things I've just read on your blog, but as you point out in something you wrote, "Party A summons party B with a bell, and that's why we call it a 'phone call'".  I want to talk to you, so I ring you.  I wait for you to decide whether you want to talk to me or whether you want me to go away. 

It puts you in this really uncomfortable position, where you might be talking to somebody in real life or might be doing something important.  You might be driving a car, or whatever you might be doing.  I'm saying I don't care.  I demand your attention right now.  There is nothing in between.  It's [telephony] a continuum with only extremes.  We're trying to open up some spaces in between the "you get to talk to me now," or "you don't get to talk to me now". 

The way it doesn't respect your time is, sort of, like it wasn't designed to respect.  This granularity of time wasn't even considered because of the other time it was saving, of travel time.  It used to take a long time to get places.  It used to be a big deal.  You couldn't fly places.  Calling was a lot cheaper than going someplace. 

We have so many different ways of moving information around, now, that time does become more important.  Telephony can respect people's time.  At the moment, it's just ignorant of it. 

I had to smile there because another little question came to my mind.  Have you noticed how the B party still behaves, for the most part, as it had in the past?  Because the A party was the one who bore most of the cost, i.e. because of the scarcity was the networking, they were paying large rental costs, i.e. call cost was higher than the human cost, then  B parties feel obligated to answer.  Yes, the older demographic is still up there, but it's still in the bulk of our society that you must answer a ringing phone, no matter how important the context that you're in.  Do you notice this? [laughter]

Absolutely, the problem is on both ends.  Not only do you sort of have to be interrupted, but then you think, "Geez, A party is already taking the time to call me.  I might as well".  They have sort of forced this obligation of your time and attention on you, out of nowhere.  This is exactly what I mean when I say it doesn't respect people's time.

A lot of the problem is because you don't know what the value of the inbound call is.  You don't know if it is critical to you or if it's something that would be better suited to another channel or another time.  It's completely and utterly blind.  Would you agree?

Yes, it's the same sort of live voice stream, whether it's just chatting, just calling to say hi, some short message, or some long message that's a conversation.  The way you initiate it is the same, in the current model.

If you look into calls, there are so many different types of calls.  For example, in his interview, Martin had been speaking about how a lot of calls are pure rendezvous as he calls it.  They're actually, calls in order to organize the real call, like, "Where are you," "I'll be home in five minutes," "Okay, I'll call you then".  It's kind of funny that we're using calls to do the rendezvous to have the proper calls. 

Then, some calls are just information transfer, like to pass over credit cards.  It's very strange that we're using the system to do all these things in such an inefficient way.

It's funny; I think the ultimate problem is that the only building block you have to work with is the call.  Even after you have something like some other way to set up that call, let's say you get one of those; you can send a text message or you can do some other thing that helps you set up the call.  At the end of the process, you've rendezvoused now.  Now you have a call.  I think even that is going to need to change for the brokenness to go away in telephony. 

Could you expand upon that? 

You and I are now talking on the phone.  We're using fancy computers to do it.  That's really neat, but here we are; we have a full duplex telephone call.  If the call were to drop because the network screws up or if one of us needs to stop for a second and tend to another call, the things that each of us say just sort of go away.  They're live only.  Live is the building block for all of telephony. 

The live, two-way call is the way it all works.  I think that is actually broken.  It should be more flexible in that.  You should be able to have some time-shifting, if you like to call it that.  You should be able to sort of listen whenever you want to listen, to whatever kind of media is headed your way.  

So, calls take on some kind of permanence or semi-permanence, if you want?

That's another way to look at it, as a side effect of doing that this way; you end up having more of a context, more of a history of your interaction.  I think we have to get rid of calls.  I think that's ultimately the problem and why we find all of this so inconvenient.  Once we've completed this rendezvous, we still have a call. 

For some things, of course, a call is the right thing.  For this conversation right now, this is the right medium.  We need to have sort of a two-way...

It's handy. [laughter]

It works very well.  I wouldn't suggest that we should do some sort of asynchronous, wildly delayed scheme, like a 187 milliseconds of latency is pretty nice, halfway around the world.  The thing is; for a tremendous number of different usages of voice to communicate, it's actually not. But it's the only thing we have to work with if you want to talk.  There's really nothing in between - of us talking, if you want to use voice.  There's nothing in between us talking live and us going into each other's voicemail. 

If you take the word telephony, generally telephony means a particular thing, what you're saying is - do you believe that the term telephony will disappear, will cease to have meaning, going forward?

I think that is one possible side effect.  I think telephony is going to be one of these words that ends up being meaningless, like broadband.  Broadband used to mean one thing and now it means fast Internet, I think.  It will take on some sort of different term, or not, or maybe we'll always use it to refer to this kind of old-style of phone calling that we used to do before we figured out something better.

If I just jump back to this rendezvous thing, just looking around the Web here, I have ADHD [not officially, just get bored easy] so I'm looking at a couple of blogs here.  There has been quite a lot of buzz in the blogosphere lately around VoIP is dead, or VoIP is not dead.  I kind had to chuckle to myself because they're arguing about the technique to transmit the media itself.  In the 80s, we went from analog to digital.  In 1990, we went to ATM.  In the early 1990's...

Yeah, it's the plumbing.

It most certainly is.  I was away to say that Idon't remember people getting excited about digital but I did get greatly excited.  Digital actually had a lot of huge promises when ISDN was wrapped in, but operators unfortunately failed [laugher] to realize what could have been the Internet back then.  The same actually happened in the early 1990's [ATM]. 

They're getting exciting about or arguing about the plumbing.  I don't normally share too many personal opinions, believe it or not.  I've been fairly quiet the last four years, but I'll say this; the real revolution is going to be around what I call "person-to-person signaling".  The revolution isn't in the media transport, but actually the signaling. 

A sub-set of that is what Martin had called the "rendezvous process". 

Anyway, you said to me, in the email earlier, "People have attention synchronization challenges in their lives".  Can you tell me how you plan to solve these challenges, or how you are solving these challenges?  I'm sorry.  I don't know if you're already selling [solutions]?

You can't go to the website and buy our software or anything, but yes, this is something we are doing.  What I mean by that is that the synchronization of attention is really the critical aspect or barrier to communication happening.  Sure, one way you can synchronize attention is with these improved signaling schemes and then you end up with this rendezvous.  And then, you've got full attention.  I think it needs to be a broader spectrum than that.  Yes, I completely agree with that and I'm totally on board with your improved, human-to-human signaling, but I think that the signaling actually is the media.  It's not necessarily just in service of getting some live call going.  It is the content.  If that content is best relayed in a live way then that's how the people will use it.  They should be able to get what they want.  The signaling, in and of itself, has value as content.

Actually, that's a topic we should really focus on if we do another interview before this conference.  That is a very exciting topic.  It takes a lot of time to go into that.  I'm sure you'll agree because [laughter] obviously, you know what I'm talking about.  We really should focus on that for another conference interview.  It's a whole talk in itself.  It's a terribly exciting area.  You've spurred me on with some excitement by bringing that up [laughter].  It's one of these other things where I kind of thought I was on my own, or fairly on my own.  That will be a lot of fun, to discuss that, because I've been doing a lot of thinking about it.

I would love to do that.

Do you want to say how you're solving those challenges? 

I'm sort of dancing around the issue a bit, but the signaling, the messages, or the content you can deliver to somebody else, becoming the purpose of what you're doing, runs into a problem with voice.  Because the ways in which voice is currently delivered are pretty awkward.  You have to get a circuit, call people, allocate a bunch of resources, get your QOS going; or get your time slices [TDM, or whatever it is that you need to so you can talk to somebody, even if you ultimately end up with voice mail.  That's still what you need.

What we're doing is throwing away the requirements for circuits, reserved resources, and all of those sorts of things.  We're pushing the complexity of managing that kind of stuff all the way out to the edges.  You have these powerful devices now, your iPhones and what have you, with relatively speaking, very powerful computers on board.  They have multitasking operating systems and advanced networking capabilities.  None of these things is really being used to kind of change the way that voice works; they're being used to run applications.  That's neat and that's great, but we're going to harness the power of these smart devices to process your voice, to deliver communications with your voice, in a way that is kind of separate from the requirements imposed by the network. 

Once we're free of that, we're free of requirements, strictly, of people's dedicated attention.  You can have a more arbitrarily time-shifted way to listen to incoming voice or video.  You can send things without waiting for the person on the other end to acknowledge, basically without waiting for the network, without waiting for anything.  We're respecting the sender's time by letting them talk immediately, and respecting the receiver's time by not necessarily interrupting them, allowing them whatever level of participation they want, at that time.

Even though it's 2:00 a.m. here, and I'm fairly tired, as you might hear in my voice [laughter]; I don't have the usually spritely thing on.  But I have to say I'm really glad you came along to the 2008 eComm conference [laughter]. 

Why is that?

You're very much in tune.  You're certainly thinking ahead.  I know the direction, from what I'm hearing.  I mean I know these areas well and we should really do some more chatting again, and record it, but maybe some offline?  I tell you; it's terribly exciting things.  It is so good to begin feeling that other people have noticed the same things.  Because the industry has been so stagnant for so long.  I'll be honest with you; I don't read that much in comms, blogs, and news just because I'm bored stiff.  That's not going to win me many friends I guess, so maybe I shouldn't have said that? [laughter[

I'm with you [laughter]. 

I'm very very bored with comms [publications].  It's been rehashing the same old stuff for so long, and yet, the opportunity has never been bigger.  Maybe I'm just really fortunate; I was lucky enough that Cisco said they would pay for an engineering doctorate for me.  It was around the time I realized that telephony was dead.  So I then spent seven days a week, twelve hours a day, fourteen hours a day, contemplating the future of telephony.  I know I spent three years at it.  I must admit; it might sound a bit extreme, but it actually destroyed my life [laughter].  I can say I destroyed my life for three years [laughter], thinking about the future of telephony.  It was head breaking. 

I've not been public, or so public at least about the conclusions I've came to.  I've only kind of dabbled with mentioning things publicly, for various reasons.  It would actually take so much time to get some of this stuff out.  It was radical conclusions I came to.  It's really good to hear others who are getting into the same conclusions.  I would actually like, at some point, to begin saying where I see things longer term.

But anyway let me get a bit more down to Earth here.  The economy is dire.

That's putting it mildly.

I'm being very polite tonight [laughter].  Communications and transport are the two backbones of an economy, and yet, the communications we have today, predominately telephony, is so inefficient.  It's incredible; we can drive massively increased efficiency.  That's why it will happen.  That's why telephony has to die.  Efficiency will always win if you believe that globalization will keep on trundling on.

Today, for example, I wanted to post speakers [of the hifi kind].  I'm in the U.K., so I called Parcel Force, which is a courier.

[laughter] By "post", you mean ship physically?  That very doesn't mean anything to Americans.

Ship, yeah I'm sorry [laughter].  It's like the old car hire and car rental.  It confuses the hell out of people.  I've started saying motorway or freeway because if you say dual carriageway, people start off, "Where are the horses?" [laughter] At least I'm not calling taxis hackney carriages. [laughter]

I do like how you used "outwith".  Is that where the accent goes?  Is it on "out", or is it on "with"?

I'm confused.

In your blog post, you used a word that I've never seen before, which is apparently a Scottishism, you jammed the words out and with together, as one word.

I actually thought I'd wiped all Scottishness out of my speaking.  Not only working in the States, I had a couple of ladies who were Americans.  I soon realized that they didn't understand a lot of the things I said, not because they didn't hear the words but because the words are not in an English dictionary [laughter].  I wasn't aware of that one.  I need to look into it.   

I thought for sure it was a typo, but Google to me the truth, which was, nope - Scottishism.

Yeah, yet another one.  There are also three hundred words for rain [laughter].  I can tell you exactly what - if I could use some Scottish words for rain, you will know exactly what type of rain it is.  You will know the speed, how quickly you'll get wet, just by one word.  In Scots, you can also say a word that begins with "f" and ends with "k" and you can say that in three hundred different ways, in order to have whole conversations with that one word.

That's weird; I have no idea what that word could be, but I would love it if you would tell me about your experience with Parcel Force.

Sure. I called them after being at the website.  I got a deep, IVR tree that took me three minutes to traverse, including the ringing time.  At the end of the three minutes, and this happens often, it told me to dial another number (surprise).  But it only told me once.  I didn't have a pen.  I wasn't at a PC at that point.  Guess what; I had to redial, traverse the same old IVR tree, to hear that number again.  I noted it down, dialed a new number, got to large IVR trees, then I got hold music.  I had no idea how long I was going to wait, so I just hung up.  I actually didn't bother getting a price from that company.  I went to a company I already know because it's a lot quicker time-wise.  That was me trying to establish a session about trying to obtain a piece of information, via telephony.  It was burning up so much of my time that it was cheaper for me to over spend on a company I already knew, than to engage a new company.

Are you able to highlight any inefficiency which you can see, other than kind of what you mentioned earlier?

Sure, in your world, what would have been the ideal interaction on your phone, with Parcel Force?

I dial a number and somehow magically I'm through to the right person who can actually answer the question I had, without playing about, without putting me on hold, and without passing me around or making me push buttons - speed of information.

For example, one way that your interaction with Parcel Force could have gone is that you could have found them.  You could have gotten your device or whatever it is that you talk telephonically into, and you could've said, "I want to post some speakers.  Here is where they're going.  How much is that?"  You could go do something else.  You could do whatever else it is that you wanted to do [laughter[.  Then that communication could get routed through the Parcel Force whatever, call center or however it is that they do this; somebody will answer that.  Maybe they have some way to scan it for key words, and more efficiently get it to the right person on their end, but they can give you an answer.

The problem is that you have made a live phone call into some system.  The only way they can interact with you is "live".  You would like to get to a person, but what they would like you to do is hang up because people are really expensive.  So that's a big inefficiency that we want to fix.

I like that.  I would have liked to have been able to inject voice into that company; I ask a question within thirty seconds and I don't care if it takes an hour for them to come back to me with the answer.  In what you mentioned, would you be suggesting going voice to text, then process the text for semantic meaning, to help in the routing process?

[laughter[ I'm definitely suggesting that.  Computers can parse text and act on text very well.  Even if they don't get the full meaning, chances are they can at least get your message into the right bin, wherever it's supposed to go, oops I can't use "bin" as that means trash, right? They get it to wherever it's supposed to go having converted to text, and still maintaining the original voice, to the extent that it's useful.

Not only that, but even if they get it in the wrong pigeon hole [laughter], whoever receives it can say, "This is in the wrong pigeon hole; send it here," and the machine can learn. 

Yes, but you can't really do that if you have a phone call.  Someone dials in, they have this long - they say calls are recorded.  But, the whole call may be recorded but how do you separate out the part when you're talking about this, versus the part when you're talking about that?  As you put it, injecting voice into that company with a very specific request, encapsulated within the boundaries of that voice injection.  You allow it to be converted to text in a very meaningful way. 

We've actually highlighted two areas tonight, which I want to say are exceptionally exciting.  I might not sound exceptionally excited [laughter[ because of the time here and because I need to catch up with this much later on.

The first one is that there is a revolution around the signaling.  It's not to do signaling on IP [laughter], the change of transmission of signaling.  It's the fact that you go person-to-person.  It's taken the signaling from a circuit level to a sociological level.  It's actually, where sociology intersects with computer science.  The whole rendezvous thing is a subset. 

Secondly, what you've raised is absolutely fantastic which is you cannot process the media in a call.  It's fairly unprocessible, as you say, they record it, but you can't understand it, you can't parse it.  Once you parse it, can understand it, it becomes terribly exciting input to play with, to build cool apps, better things, and make things more efficient.

Is that a direction that RebelVox is looking at?

Yes, we're looking at it in terms of enabling those sorts of things to be built.  We're not trying to define all of the different, actual uses of something like that.  We're trying to say, "You can put your voice into the system, in a way that makes it much more useful than the current system you have.  You can map this onto your business process in the ways you, the business owner, know best.  We're going to give you the tools, this platform that can make all these kinds of things possible.

You mentioned business processes.  I can say this; eComm 2009 will have a lot of talk about making business process more effective with communications.  That's a really nice area to be looking into.  You're really going to love the next eComm because I know the talks that are lined up.

I'm looking forward to it.

If I think about this, and I look at what you guys have been doing, you have also been looking at emergency services, in particular, tactical radio.  Is that correct?

That is correct.  The origins of RebelVox sort of come from the tactical world.  My business partner was a Special Forces communications sergeant in the U.S. Army Special Forces.  He served in Afghanistan.  He ran into a number of very challenging communications problems that were the origins of what we're doing here.  They sort of boil down to, you can't be on more than one channel at a time. We thought about that and how could you fix that? That's where we realized what the problem was.  Of course, you could build a radio that is literally on more than one channel at a time, but that's not a very useful thing to have because you only have one brain.  You can't give live attention to multiple, other people, at the same time.  That's where we went with it, this sort of attention synchronization. 

It turns out that most of the tactical radio communications don't have to be strictly live.  They're transfers of information.  The way those systems are used is almost always an information transfer.  You press the button; you transfer some information to somebody else.  You're not even expecting it to be full duplex communication because most of them aren't. 

The problem of synchronizing your attention across more than one channel or more than one conversation at a time led us to realize this problem in the tactical communication space because it's dangerous.  People's lives hang in the balance of communications being effective.  Everybody has these same sorts of attention synchronization problems.  You and I both have this problem; we just don't notice it.  The consequences are not so dire for failing.  No one dies if I don't answer my phone.  It's sort of inspired by tactical communications but we think it's applicable to anybody who talks into a device to somebody else on the other end.

I totally get what you're saying.  It's applying what you learned from looking at telephony to the tactical radio side of the house?

When we talked to people in the tactical communication space, they always say, "Wow, when can I have this on my cell phone?" [laughter] It's pretty interesting.  That's part of the unique perspective that we're coming at this from.  It's understanding that tactical communications mindset and bringing some of those elements into commercial telephony in a way that saves everybody time.

We've been on this call for forty-five minutes.  We were actually meant to do fifteen.  Because it's the early hours here and I need to get up for a plane also, I'm going to need to shoot off this call.  I can say this; it was really fantastic having this chat with you.  If it's okay with you, what I will do is I will not edit it, possibly me even describing words in Scots you can say [laughter], and just put it out there.  I think there has been valuable content on our meeting call, our first call together.  I think it will serve as a basis to link to.  You and I should really do a little bit of speaking offline and probably do this again once you and I are more in sync.  So far, it's been fantastic.

I totally enjoyed this conversation.  I just want to say thanks for staying up late [laughter] .  I appreciate you willing to be a little flexible in your schedule.  It made it possible to actually talk.  Thanks.

It's no problem.  I tend to find that most of the people I speak to are in the PST time zone so I often find I'm up in the early hours.  I really appreciate the enthusiasm I got with the speaking proposal from RebelVox.  I thought that was fantastic.  I don't want to go back in this whole interview again, but I have to say it to you; how long have you guys been researching it?  It sounds like you guys have been doing serious research.

Two of us have been thinking about this problem for almost five years, now.

Hey you were doing it the same time as me [laughter] and also Martin. We've been like these nodes around the world thinking about similar things.  This is so great.

That's really very funny.  We've been talking about this for about five years.  It sort of came together as a company about a year and a half ago.  We built up a team and started working on building it.  I've been sort of poking around, kind of as you describe, but not as anguished [laughter].  My investigation was more fun.  I didn't have a lot invested in the telephony world, but I was really curious about how to save time.  I realized that every time somebody called me on the phone I just felt as if I had travelled back in time to when it was novel that people could call me on the phone.  I've just been trying to figure out how we could make this better.

A good word used there was "anguished".  Imagine being me for a little while; you grew up as a kid, your love is the telephone and telephony, the heart of telephony, the intelligence, the nervous system is Signaling System No.7 (SS7), so you decide you want to become the world's top expert in it.  You believe you've become that [laughter].  You think you've gotten where you wanted to be and then as soon as you get there, it suddenly slaps you right in the face that that very thing is actually dead.  Anguish is a good word!  But actually, the opportunity I learned from those three years which must have overlapped what you were speaking about.  The opportunities I see are absolutely tremendous.  This is just a part of it.  So I really do look forward to chatting with you a bit offline.  On that, I better get going.  Thanks again, for your time.

Sure thing, I really enjoyed it.  Talk to you later.

Thank you.

• "Telephone company telephony" will be eliminated. This is where huge money will be lost long term.
• In the medium term what was the "telephone company telephony" will be broken up into voice enabled vertical application "contexts." This is where money will be made.
• In the long term devices, software and networks will become increasingly sociologically aware. This is where a lot of money will be made.