Lately there have been many discussions and announcements on numbering and addressing in VoIP. The industry is fixated on using E.164 numbers as the addressing mechanism in VoIP even though it creates problems or recreates the PSTN business models; then others follow with attempted partial solutions. We should look at the fundamental issue and address it so that we maintain the promise of VoIP – autonomous communication between the end-points.
As I understand it, Vocaltec used IP addresses when it introduced its VoIP software in 1995 and migrated to E.164 number when it introduced gateways and interconnection to PSTN. In any event, true to its pedigree, H.323 used E.164 numbers as addresses. But SIP used URI based construct for its addressing scheme. Recognizing the flexibility of URI scheme, other protocols like H.323 and MGCP adopted the scheme.
Even though URI allows for alphanumeric characters, FWD restricted the user name part of it to only numerical characters; the domain part was assumed to be fwd.pulver.com. (I remember Pulver taking enormous efforts to point out that FWD does indeed use URIs.) The limited user interface of the standard telephone is the reason for the numerals only restriction. Subsequently, SIPPhone used NANP like structure for their address, with 747 (SIP) as the area code (which was unused at that time). Of course SIPPhone number is not E.164 address because the NANP administrator did not assign it to SIPPhone. Similar scheme was used by other SIP providers. Interconnecting to each other creates a problem because it is not clear how the caller can specify the domain name. The solution is a typical Bellheaded solution – use of access codes. There is only one reason for placing numerals only restriction – limited user interface of the terminals.
When commercial service providers entered the scene, they used valid E.164 numbers because they wanted to accept calls from PSTN (after all there is money to be made from incoming calls). This creates a problem while interconnecting to pther VoIP providers. It is not transparent from the address whether one is terminating in PSTN or in IP. So a simple solution is to interconnect through PSTN. (A cynical explanation is there is money to be made from incoming calls.) Now DUNDi is being proposed to address this problem. This is a technical solution; but I am not sure whether it will be accepted on business grounds, if it means loss of access charges revenue.
Shouldn’t a Nethead try to eliminate the basic restriction rather than come up with adhoc,(even if clever) fixes? How come a Nethead turns into a Bellhead when placed in the “voice” environment?
Now some try to console the incidental benefits of using E.164 address. We are told that it provides a strong identity infrastructure. Even if this true, it does not provide the derivative benefits even in PSTN. Such protections do not easily traverse national boundaries and since the PSTN calling card rates are so low, the economical barriers are very low for people to do mischief across national boundaries. Now that the PSTN allows interconnection from PSTN, PSTN itself has lost the strong identity.
So there is only one reason for sticking to E.164 numbers - the industry is lazy or risk averse in trying to change the UI of the terminal. So as advocates of VoIP, we should strive for improved UI for the terminals and insist on URI based dialing (which will marginalize the service providers). Oh, by the way, do everything to encourage your circle of friend to migrate to VoIP. This means you should not subscribe to additional virtual numbers, because this will take away the economical motivation to get VoIP.
Against this background, there is a proposal called GNUP. It introduces another Naming authority. The interesting aspect of this proposal is to use this one has to use Peerio discovery algorithm. I would imagine this involves royalty payment of some sort. Looks like everybody wants to emulate Bill Gates.
Continuing from an entry of last week…
In an article published last week in Forbes, it is reported that Skype is developing other premium services like voice mail. This is noteworthy. Since their approach is to deploy minimal infrastructure they can not be deploying voice mail server(s); and since by definition voice mail requires an always available storage device, Supernodes can not take on the role of voice mail server. So I am eager to know how they are going to do it.
Meanwhile there is a way for individual users to realize voice mail service by adding limited capability to the end-points. The idea is for the caller to record the message and send it as an email attachment to a specified email id. Since many free email providers allow big attachment and a large disk space, this arrangement is feasible and does not require any premium.
Consider the case of caller A who has sent a SIP INVITE message to caller B: The response message (from caller B, B’s proxy or redirect server) should specify the email id. With this information, Caller A can decide to leave a voice message at any time – immediately or after waiting for a (autonomously decided) period of time. SIP end-points must have the ability to locally record the speech and generate an email to the address specified in the SIP message. Thus voice mail becomes a capability of a product rather than a service (let alone a premium service).
I am in the process of understanding the inner workings of Peerio. Since only limited information is publicly available it has been difficult. So far my understanding is this: it uses some sort of peer discovery protocol, probably something like what is available in Windows XP; once the reach information is made available, one peer can initiate a communication session to another using any of the protocols, like H.323 and SIP. In this understanding, Peerio’s role is limited to identifying the reach information. So any user experience in the communication phase is independent of Peerio. Answer to one of the questions in their website reinforces this:
Q: What is the sound quality of Peerio444™?
A: Sound quality in standard VoIP applications is determined by the voice compression and transmission technology in use (vocoders, protocols, etc.). Peerio444™’s ready-to-use client contains standard vocoders found in the majority of today’s commercial VoIP systems. Peerio444™’s unique modular configuration allows the application to incorporate any set of existing VoIP vocoders and proprietary vocoders from companies such as Global IP Sound (as used by SKYPE).
Then I came across an entry in Ipinferno that is puzzling in light of the previous understanding:
Regarding his free software download, Peerio444, Dmitry (Peerio's CEO Dmitry Goroshevsky) told me that sound quality has been a major problem which is why it has not been made generally available. He told me that an important licensing announcement would be made *soon* which would provide a solution, but would not commit to a schedule for delivering this technology to the marketplace.
But the same entry also has this quote:
Peerio is serverless. This is, according to Dmitry, a fundamental and game changing difference -- and not just for VoIP but for many different kinds of networked applications that will ultimately run on the Peerio infrastructure.
Oh well. Confusion and misunderstandings are part of the learning process.
DUH. Peerio444 is an integrated software with peer discovery component and a softclient. The latter is probably is a custom development whose codec has performance issues. Since softclients like Xten allow IP address based dialing, it might be possible for peer discover client pass the address information to the softclient. This would address the problem. Probably this is what Mr. Goroshevsky was referring.
Recently two companies, Nimcat and Popular Telephony Peerio, have made announcements regarding VoIP technology that does not require a “server”. (Om corectly pointed out that Peerio and Peerio444 are product names and not the name of the company.) It looks like enterprise market is the primary focus. Absence of a centralized server is being advertised as a major benefit. These two companies efforts are getting press coverage as well. Since they are in the preliminary stages of their market activity, only sketchy technical details are available. For example, Peerio says that their system can support 232 232 (Thanks Om, for catching the typo) end-points, suggesting that the discovery protocol uses some sort of id that is 32 bits long. One of their early website had indicated that they are using Microsoft RTC voice engine, which will soon be replaced. (That page is not there now, suggesting that the replacement has taken place.) Interestingly, Microsoft itself has a technology for serverless peer-to-peer networking. Their peer ID is 256 bits long and uses “a multi-level cache and referral system” for peer discovery.
It is suggested that enterprises using this system for voice communication do not have to buy expensive centralized servers like PBX or IP PBX. Granting this benefit, a quick analysis raises some questions that may not stand a careful analysis. Nonetheless, I state them here for your consideration.
The first point is a basic one in that I am not convinced whether an enterprise can avoid a “server”. I am assuming that the Peer ID will be enterprise specific. If this assumption is correct then when a person outside of the enterprise wants to communicate with one that is inside, the outside person has to contact a well known entity, which for all practical purposes is an IP PBX. If this system is used to interconnect to PSTN, it almost assumes most of the functions and cost structure of IP PBX. So I am not sure the real advantage of the serverless architecture.
The second point is whether an enterprise will accept the peer discovery procedure from a social and privacy point of view. In the Microsoft’s system, the peer discovery protocol involves querying intermediate nodes on the status of the target peer. This means one or more intermediate nodes will come to know that peer A is planning to communicate with peer B. One can easily visualize scenarios when this information is sensitive even within an enterprise.
Given these issues, it is useful to understand why a serverless architecture is preferable or in other words, whether centralized servers are inherently evil. Historically PBX vendors have locked customers into their system by having a proprietary interface between the telephone sets and the PBX, thereby increasing the cost of replacing the system with another vendor. This does not mean that centralized servers are inherently bad, especially in the IP domain. Web servers and email servers have been sufficiently commoditized both from capital and operational point of view. In summary, I do not see the downside of an enterprise wide system that is centered on servers, as long as open interfaces are maintained.
For a long time, the conventional wisdom in the industry has been that one of the new services that VoIP can introduce is Unified Messaging. That is, voice mail and faxes can be delivered along with email. Indeed, only today some Congressmen sent a letter to FCC Chairman suggesting that VoIP should be considered interstate service. There they make the point that “IP technology also allows VoIP providers to … forward voice messages to electronic mail addresses…” But a couple of weeks back Verizon announced a new service to PSTN subscribers that included delivering voicemail to an email account. Today SBC announced a similar service for their PSTN subscribers. Looks like PSTN is not that limiting after all.
But the announcement from SBC points out the problem with service providers, especially the incumbents. Their service could cost as high as $10/month (if you are already forking over a lot, then you need to pay only $1 extra; additional 50 MB storage will cost $5 more). But what is needed is a simple internet device that is an answering machine for both PSTN and VoIP, and can send individual messages as an email attachment to a designated email account. Many free email accounts these days offer a large disk space (100-250 MB) and allow a message with a big attachment (10 MB, equivalent to 20 min of PCM voice). That means once the end user has this device there is no need for a service provider and pay monthly toll.
It is not enough to proclaim the rise of stupid networks; we need to develop required intelligent end-points and resist the temptations of APRU. It is time to build the “spinning wheel”.