Aswath Weblog

Peerio Patent Application

Previously many have taken issue with Popular Telephony’s Peerio and related GNUP. Some have criticized PT because the software was not made available after the public announcement; some have pointed out that the software does not work. One could explain them away by saying that these are execution lapses. Probably they will fix them; if they are incapable, somebody else could be brought in. In other words they are transitory. With this background, a few days back Andy informed us that a patent application filed by PT is now publicly available and that “should go a long way to telling their story and answering some questions.” James feels that the system should work as advertised because “chipmakers [and] the various phone and gateway makers [will not risk] public association with something that turns out not to work.” This entry is an analysis of the patent application as I understand it. Previously, I had questioned the need for and acceptability of a “serverless” architecture. This patent application has not changed my mind.

(In my limited understanding of the patent filing process, submitting the application does not imply much. I could develop a patent application for a perpetual motion machine and can file it, if I am willing to spare the application fee which is something like $100. Secondly, the process is far from granting a patent. Thirdly a patent does not have to describe the full system; only the aspect that is being patented. Accordingly I still have some open questions on the workings of the system.)

Concept of virtual ring

A Peerio network is a virtual ring. All the nodes in the ring have an address. The address space can be ordered. (The patent uses IP address.) This ordering is used to determine the neighbors of a node on the ring. Periodic query traffic (which can be sent in either direction) will maintain the integrity of the ring. If the ring is broken, the ring will be reordered. To reduce the maintenance traffic, the size of the ring is controlled. A ring that exceeds this limit will be split into two rings. A node joins an existing ring by identifying two nodes that “flank” its address. There is also a mechanism to join two rings.

Open questions:

1. The default size of a ring is 6. So there has to be multiple levels of rings. It is not clear how are they formed.
2. How will two rings know that they can merge? Presumably these bridge nodes will coordinate the merging process.

Data Storing

Data is stored in a sub-ring. This way of replicating data in multiple nodes provides for a node failure or leaving a ring. The members of the sub-ring are determined via a hash function or a similar mechanism.

Remark:
This is the first hint that there are classes of nodes. These nodes are special in the sense that they have storage facilities.

Login procedure

A user who wants to use the services of Peerio will go through a login procedure at a Peerio node. The Peerio node can validate the user using the local data or getting data from other nodes. Once a user has successfully logged on, the user information is distributed to other nodes.

Open questions:

1. The ring needs to have user profile for all potential users. Since a ring is organically formed, it is not clear how the first node in the first ring will get the profile for all the users?

Call Establishment

When user A wants to call user B, node A will get the profile of user B from the ring. The profile will give the IP address of node B and the status of user B. Using this information, node A can determine whether to establish a session or not. In the affirmative case, node A will use one of the standard mechanisms (H.323 or SIP) to establish the call. Otherwise node A will collect “voice mail data” and store it in the ring.

Remark:
One of the criteria for not establishing the call is the busy status of user B. This means, Peerio call processing logic has to replicate telephony features like call waiting, multiple call appearances, instead of using those capabilities available in H.323 or SIP. More importantly, these features have implications to user interface. How will the terminal coordinate the user interface projected by Peerio and that by H.323/SIP?

Voice Mail

As I remarked in the Call Establishment section, node A can encrypt the voice mail and store it in the “data store sub-ring”. If the user is logged on when a voice mail was stored, the node will be informed of the arrival of a new message. Otherwise, the user will be notified of stored messages during the login process.

Open questions:

1. How will the system ensure that there is at least one “data store” terminal is available at any given time?
2. What happens if all the terminals that held messages for user A are unavailable when that user logs in?

Call Center Application

Call request for the common user id is forwarded from one terminal to the next in “hot potato” fashion, till a free agent is located.

Sundry observations