The challenges with secure cross-domain calling
From Guardian Project Wiki
The problem with VoIP peering, or "I SIP you milkshake."
Over the last two months, OSTel has been operating in a private alpha service. In the coming month, it will open in public beta. As a proof of concept of an Open Secure Telephony Network, OSTel gives users access to a free voice service with secure calls. The security of the system prevents tapping and also makes tracing a call more difficult than with other voice services. The users of the system are required to have an account to place calls to other registered users. In this way it opperated much like Skype but without the SkypeIn/Out services.
But the goal of OSTN is not to recreate Skype. If there are other users on another OSTN node operated by a party outside of The Guardian Project, these users should be able to place secure calls to ostel.me without requesting an account on ostel.me. This process is just like the expectation all cellular phone have that their service will allow calls to others outside their own service provider. Sounds simple, right? In the SIP world, it is not simple at all.
The SIP protocol, is used for signalling between OSTel users. It was written for telcos, by telcos. before I continue, I should define "signalling" and "telco". Signalling is the process for one VoIP user to contact another. With telephony, this is done by ringing another user's phone and the other user answering. Traditionally, a telco, or telecommunications company is the party responsible for operating the service that allows you to place calls on a network. Browse on over the the SIP RFC and read the list of authors in the upper right. Ericsson, WorldCom, Neustar, AT&T and Dynamicsoft (aquired by Cisco). These are big players in worldwide telecommunications products and services.
When a telco designs a protocol, they have a responsibility to their stakeholders to ensure operators can measure all usage for all registered users so the usage can be charged tolls. This model doesn't fit nicely into the world most Internet users are acustomed to. Services like Email, XMPP, IRC and the Web typically do not have a per message toll. If we were expeceted to pay for each email we send or each Google Chat IM we recieve, the unaimous response would be diabelief. These protocols were created with the user in mind, not the operator. The user is free to exchange messages with nothing more than Internet service. In contrast, telcos favor the per-message toll model, which in turn favors the operator of the service. The operator is like a gatekeeper, they get in the middle of the user and service. They sheliding the user from the privilege of creating their own account and exchanging messages with services owned by other operators. SMS, voice and fax all have usage tolls, either per-minute or per-message. Both the hardware and the protocol are designed with these usage tolls are a core requirement.
During my research to place a call from one OSTN node to another (or "cross domain calling" or "peering"), in this case ostel.me and a private debuging server I built just for this task, I encountered some aspects of the SIP protocol that make this a challenge. Even the terminology is confusing. When two servers with to pass traffic, they are "peering" but they are also "federated". This is also described as one server having a "gateway" to the other. What all these terms have in common is they require each peer in the network to have a peering configuration with the other. It is expected the operator of each service explicitly configure access to the other.
From the user's perspective, if each operator hasn't set up the peering agreements a call to a user across domains will silently fail. A comparison would be email. A user alice@foo.com who sends email to bob@bar.com only must trust that bar.com has an email server at that domain and a mailbox for the user named bob. No explicit peering agreement need be met between foo.com and bar.com. They are independently operated and traffic can pass implicitly between to two. In the SIP world, the toll infrastructure requires that no traffic to bar.com be allowed unless the apropriate access is configured and the tolls are in place. bar.com must let foo.com SIP from its milkshake.
