The VoIP Peering Puzzle�Part 32: SBC Architectures�Paradial
Oslo, the capital city of Norway, was the home of the Vikings more than a millennium ago. Known as strong-willed, fearless warriors, the Vikings also distinguished themselves as craftsmen, shipbuilders, and explorers. Perhaps the most famous of this clan was Leif Erikson, who is said to be the first European to discover North Americapresumably Newfoundlandaround 1000 A.D.
Fast-forward a thousand years or so, and we discover another band of Nordic warriors in Oslo that had also worked with an Erikson, but this time it was Swedes, who spell their company name Ericsson). These warrior/craftsmen were the core designers of Ericsson's IP telephony team, handling the traffic, management, and service related elements of those product designs.
In 2001, they decided to leave Ericsson and start their own company. From their previous experience, they had learned that firewalls and Network Address Translation (NAT) devices represented a big obstacle to the deployment of IP telephony solutions. They also found that a lack of connectivity prevents IP-based audio and video services from being used by up to 90 percent of an addressable marketwith disappointed customers, lost revenues, and increasing support costs yielding additional downsides for service providers.
This knowledge, together with the experience they had gained with real-time communications systems, plus the SIP and H.323 protocols, gave birth to a product idea: make a generic firewall/NAT traversal solution, with functions that are similar to session border controllers, and that enables all calls to be placed in a secure way, regardless of the network infrastructure or deployed firewalls, and without the need for any network reconfiguration. The company they founded is named Paradial. The firm provides a border solution to both carrier and enterprise customers, and claims to support over 75 million end users worldwide.
Paradials flagship product, the RealTunnel FW/NAT Traversal Client, allows SIP and H.323 real-time applications and protocols to bypass any firewall in a secure way, regardless of type, configuration, or underlying network. This platform automatically and intelligently sets up calls in the most optimal and efficient manner. As its name implies, RealTunnel operates by tunneling the media packets with a TCP stream, and sending that stream to a relay. The relay then extracts the media packets, and sends them on to the destination endpoint.
The RealTunnel client can be deployed in two different ways: It can be integrated with other applications, such as real-time voice, video, or gaming applications; or it can be established as a server situated behind a firewall on a corporate network. All common Instant Messaging features are supported, including chat, voice, video and T.120 application sharing. The key benefit of the RealTunnel system is that it doesn't require any reconfiguration of the firewall or internal network.
The RealTunnel product is based upon a client/server architecture and consists of three key components. The RealTunnel Personal Client can be integrated or deployed with a softphone, has SIP proxy and H.323 proxy interfaces, and is supported on a number of platforms including Windows and Linux. The RealTunnel Enterprise Client is a stand-alone proxy that supports a corporate or enterprise network, and serves multiple endpoints on a LAN. The RealTunnel Server is a media and signaling relay server that is deployed within a service providers infrastructure. The signaling server can handle up to 10,000 concurrent client registrations if TCP is used, and more if UDP is used. The media server can handle up to 250 concurrent voice calls using standard codecs, with a media delay of only about 1 millisecond.
This system has a number of characteristics that can be found in many SBCs: It guarantees connectivity, maintains real-time quality of service for both audio and video, provides security, and is based upon the SIP and H.323 standards. However, the RealTunnel architects took a different approach: a focus on obtaining maximum connectivity from an end-user perspective, whereas most SBC designers concentrate on peering between networks. Their design was centered on achieving maximum call completion,which is crucial for the IP telephony vendors if they are to achieve a successful service uptake. In other words, if you cant complete the call, getting any revenue for that call becomes a moot point.
This perspective was also founded in a (possibly contrarian) belief that session border controllers are superfluous, since ordinary soft switches or SIP Registrars are capable of handling most SBC services. Thus, teaming the RealTunnel product with a traditional softswitch can make for a powerful combination. The RealTunnel designers claim that their product achieves a much higher call completion rates than a more traditional SBC due to its support for UDP, TCP, and HTTPS relay. In addition, standards such as Interactive Connectivity Establishment (ICE), Simple Transversal through UDP Through Network Address Translators (STUN) and STUN Relay (also called TURN, which stands for Transversal Using Relay NAT) are supported within RealTunnel, where SBCs normally only provide support for STUN and UDP relay.
Further details on the RealTunnel architecture can be found at www.paradial.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.