This article originally appeared in the April 2012 issue of INTERNET TELEPHONY magazine.

While ENUM uses the DNS, a hierarchical distributed database, to store its data, VIPR uses a peer-to-peer distributed database. ENUM is designed around the idea that only the owner of a phone number should be empowered to publish the VoIP route that can be used to reach this number. This design assumes that the owner of this phone number has a motivation to do so, an assumption that falls apart with the realization that the owner of a phone number is rarely the user to whom this phone number is assigned and that the goals of a phone user have very little in common with those of its phone provider, to say the least. And that is without even starting to deal with number portability, which makes the problem of ownership of a phone number even fuzzier.

On the other hand, VIPR is designed around the idea that who owns the phone number does not matter as much as who is currently using it. This idea translates to the PSTN verification protocol, which is the technology used to verify the claim made by a user of a phone number that it is really assigned to her. So instead of attaching the VoIP route to the phone number, VIPR is simply storing enough information to execute the protocol that will provide this proof. And because there is no way to know before running this protocol who is really using this phone number, the VIPR system must grant to anybody the right to store this information. This requires more flexibility on who can store this information, flexibility that cannot be easily found with the DNS. This is why VIPR uses a different type of database for the storage of this information, using a peer-to-peer technology called RELOAD to implement this distributed database.

This is not the first time that a peer-to-peer technology is used for VoIP. The media streams between endpoints have always been sent as much as possible directly because any intermediary adds latency to a call and increases the probability of packet loss. Recently peer-to-peer technologies have also been considered and used for the VoIP signaling, mostly to lower the need of expensive data centers, but the VIPR usage of peer-to-peer technology is different from Skype (News - Alert) or from its open standard equivalent, P2PSIP. Skype and P2PSIP replace the traditional trapezoidal model of VoIP with a new model where the mapping between a user address is stored in the overlay and the VoIP signaling is routed between endpoints through the peer-to-peer overlay. VIPR, on the other hand, uses the overlay only to store the information needed to route the PSTN verification protocol between the source and the destination of a call. Only a successful execution of this protocol will produce the VoIP route than can then be used to make a subsequent call. Note that a peer-to-peer technology can still be used for this call as VIPR leaves the choice to the implementation to use whatever model the user prefers.

One consequence of using peer-to-peer storage is that its capacity is the sum of the capacity of each the computers participating in the overlay. This creates a problem when a user wants to store data that takes more space than available in the overlay. Because a peer-to-peer overlay is open to more or less everybody, it must be designed to contend with users who are less than ethical or even that have nefarious intents. A peer-to-peer overlay like RELOAD is designed with these kinds of issues in mind and can still be safe if a minority of users tries to take advantage of it. But VIPR adds an additional safeguard to RELOAD that requires each user to provide as much storage for other users that it is requiring for itself. This should not be an issue for a user that is using only one phone number, but for an enterprise or a provider that is managing hundreds or thousands of phone numbers; the overlay will enforce a quota rule that in simple terms says: A VIPR domain that is registering twice as many numbers as another domain must contribute twice as much servers to the overlay.

Marc Petit-Huguenin (News - Alert) has held software architect, vice president and CTO positionsat various companies in the VoIP industry since 1998, and participated in thestandardization of Java APIs and Internet protocols. He blogs at http://blog.marc.petit-huguenin.org/.