In a standard OSTN configuration, the Fully Qualified Domain Name (FQDN) of the server running Freeswitch is a core dependency to operate the service. For example, the domain ostel.me was first configured as a DNS record, a server was bootstrapped with ostel.me as the local hostname and a Freeswitch cookbook was run using the Chef automation system. Because the domain was configured both in DNS and locally, the cookbook has enough information to automatically build an operational OSTN node.
Once the node is operational, accounts are provisioned on the node and users install the OSTel Android application on their mobile handsets. Users may place secure calls to other users within the domain ostel.me.
This week I reached a milestone. I placed a call from a user at ostel.me to a user on a second private debugging domain. Both domains were configured as an OSTN node and two handsets were registered, one on each node. This kind of cross domain calling is something that is rare in the VoIP world when compared to other communications protocols on the Internet, for example email and XMPP. This is due in part to the complexity of the SIP protocol. I’m documenting the extended details on the wiki.
I configured both servers to register to each other, establishing a two way link between them. This is called VoIP peering. The more nodes in the network, the more peering relationships must exist. For example, this picture illustrates the relationships between a fully interconnected network with four nodes, named A, B, C and D.
Four Node Peering Network
The implementation of this kind of peering network differs for each application. Once the peering configuration is completed by the operator of each node, they must also enable cross domain calling in the Freeswitch dialplan. In Freeswitch, the peers create a “gateway” to route calls to a non-local domain. When a non-local call is placed, Freeswitch will attempt to find a gateway to that domain. If it exists, it will route the call to the other server, which will in turn ring the handset belonging to the registered username.
Cross Domain SIP Call
The user interface to place this type of call in the OSTel app is experimental due to our security requirements. In my test, the non-local domain was debug.ostel.me. To place a call from bob@ostel.me to alice@debug.ostel.me I had to type a fully qualified SIP URI into the OSTel dialer interface. It looks like sip:alice@debug.ostel.me;transport=tls. The transport=tls attribute is due to the secure SIP requirement. Without that, the app will try and connect to debug.ostel.me over the insecure SIP port, which is not open on an OSTN node.
This test proved that cross domain SIP calling is possible but as I’ve shown above, there are significant hurdles on both the user and operator side. Some of these hurdles may be overcome by using a SIP application other than Freeswitch, some may be solved on the client side, others with DNS. It’s great to have a secure voice service with a network of trusted peers. I’m looking forward to future research and development to remove the hurdles to create these peering agreements. Eventually we’ll all have the ability to call our friends email addresses.