The VoIP Peering Puzzle�Part 47: SBC Architectures�TransNexus
TransNexus, Inc., founded in 1997, is a privately held corporation located in Atlanta, Ga. The company started as a VoIP clearinghouse providing interconnect routing, billing, and financial settlement between VoIP carriers.
In 1998, TransNexus, along with Cisco and 3Com, was a major contributor to the creation of the Open Settlement Protocol (OSP)a global standard for secure peer-to-peer VoIP routing, access control, and accounting, now documented by the European Telecommunications Standards Institute (ETSI).
In 2001, TransNexus divested its clearinghouse service business to become a software company, focused on routing, accounting, and security solutions for VoIP service providers. TransNexus serves customers in Asia, the Americas, and Europe, with major customers including wholesale VoIP carriers such as VerizonBusiness, NTT, and Primus Telecommunications.
The flagship product for TransNexus is NexOSS, an Operations Support and Billing Support System (OSS/BSS) platform for VoIP carriers, providing wholesale VoIP peering or SIP trunking services. A key component of the TransNexus OSS/BSS solution is its NexSRS Peering Server, a high performance routing and call detail recording (CDR) collection server, which provides an innovative alternative to the more traditional session border controller.
The NexSRS system can be deployed in two configurations, as a Route Server, or as a Secure Peering Server.
In the first configuration scenario, the NexSRS may be set up as a route server and CDR collection server for a VoIP signaling system such as a softswitch, gatekeeper, SIP proxy, or session border controller. In this implementation, the NexSRS server provides the intelligence and scale for routing features that cannot be provided by the signaling device, such as very large least-cost routing tables. The signaling device, such as a VoIP switch, would send a routing query to the NexSRS, which would perform a route lookup and return a list of IP addresses of the devices that could complete the call. At the termination of the call, the switch would send the call detail record to the NexSRS.
In the second configuration scenario, the NexSRS is used as a secure peering server for authorizing and accounting direct peer-to-peer communications between anonymous VoIP networks. In this case, the Source VoIP device sends a route query to the NexSRS server, which returns a list of IP addresses of devices that can terminate the call. Included with each address is a digitally signed peering token authorizing the call. That peering token is then included in the SIP Invite or Q.931 Call Setup message sent to the Destination VoIP device. Next, the destination VoIP device validates the peering token with the NexSRS servers public key, and if the token is valid, the Destination VoIP device accepts the call. After the call is finished, both the Source and Destination VoIP devices send call detail records to the NexSRS server.
TransNexus claims that the approach they have taken with the NexSRS architecture is a significant improvement over the more standard session border controller designs. The traditional scenario requires all the VoIP signaling and RTP packets to pass through the SBC, which introduces a potential bottleneck into the VoIP architecture. This traditional architecture is basically a re-creation of the switched-star architecture of the legacy telephone network, but with the telephone circuit switch replaced by an SBC. In contrast to that traditional approach, the NexSRS Peering Server uses Public Key Infrastructure (PKI) services to securely control peer-to-peer VoIP sessions. Each VoIP peer has its certificate signed by the trusted certificate authority, and each VoIP peer obtains the public key of the certificate authority. This PKI functionality enables each VoIP peer to validate access tokens digitally signed by a peering server. The certificate authority certificate may be replicated to multiple NexSRS peering servers, which allows those servers to share the load from all VoIP peers. This results in a system with extremely high availability, since any VoIP peer may contact any NexSRS peering server for routing or accounting queries.
In addition, the peer-to-peer access token format, defined by the ETSI OSP standard, includes a rich set of parameters that can be used to define the specific details for each authorized session. These parameters may include: the type of service authorized (voice, video, fax); the amount of service authorized (number of minutes, bytes, or pages); the bandwidth authorized; the Caller ID; the time when the token is valid; and the authorized price and currency for the session.
TransNexus claims that its peer-to-peer approach based on the OSP standard has a number of benefits, including: § No central control point is required, so that communications are truly peer to peer. § Less bandwidth is required, because sessions are not routed into and out of an SBC. § Higher call quality, since peer-to-peer traffic sessions take the shortest path. § Higher network reliability, since the potential single point of failure (the SBC) is not used. In addition, multiple peering servers may be operated in parallel and distributed throughout the network, which also improves system availability. § Lower cost, since an OSP peering server is a web server transmitting XML-based messages via HTTP, with many platform choices for that type of system available. §
Further details on the TransNexus architecture and products can be found at www.transnexus.com. Our next tutorial will continue our examination of vendors SBC architectures.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
Mark A. Miller, P.E., is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.