Connectivity FAQ
- How can a UM Labs SIP Security Controller help VoIP and UC deployment?
- It is easy to set up and run email and web services, why is VoIP different?
- I thought that STUN, TURN and ICE were all that I needed, is there a better solution?
- I thought that SIP was a standard, why do I need a product to solve the interoperability problem?
- Which VoIP products will work with UM Labs' products?
How can a UM Labs SIP Security Controller help VoIP and UC deployment?
Building a VoIP network, particularly when that network includes components from different vendors and where the network must support remote connections to branch offices, to SIP trunks or to remote users, is not a trivial task. The protocols that drive VoIP are complex and do not mix well with corporate firewalls or other Network Address Translation (NAT) gateways. To add to the challenge, SIP based VoIP products from different vendors may implement a different set of SIP options or may handle basic tasks like answering a call or transferring a call in a subtly different way which can introduce interoperability problems.
The range of SIP Security Controllers from UM Labs is designed to simplify VoIP network deployment by automatically handling the complexities of establishing remote VoIP links and by presenting a standard set of SIP operations to each network component, easing interoperability problems.
At the core of each UM Labs SIP Security controller is a proxy that handles all SIP traffic (phone registration, call set up etc.) and all RTP traffic (voice and video calls). These proxies work together to handle all local Network Address Translation (NAT) requirements, to manage far-end NAT traversal and to mask incompatibilities between products.
Far-end NAT traversal is the task of ensuring that a VoIP call can pass correctly through a remote firewall or other NAT Gateway (such as a DSL router or WiFi hotspot) even if that gateway is not under local administrative control.
It is easy to set up and run email and web services, why is VoIP different?
The answer is because VoIP applications and the protocols that drive them are considerably more complex than web or email. The core protocols that drive web and email (HTTP and SMTP) are each defined by a single RFC document with a small number of supporting documents. At last count there were over 110 RFC documents relating to SIP, one of the core protocols driving VoIP.
Coupled with this higher level of complexity, is the fact that SIP based VoIP systems do not mix well with Network Address Translation (NAT) which means that special handling is needed to get the protocols to pass through a firewall.
Also VoIP systems do not follow the simple client-server model that is the basis for email and web. With email and web, the relationship between a client application and the server is clear. The client, the web browser or email application, connects to a server and requests information. This model holds even when an email application is receiving a message. New inbound messages are held on the server and until the client connects and checks for new messages. This model clearly will not work for VoIP. It makes no sense for a server to keep and incoming call on hold until the client (the user's phone) connects and checks for new calls. All main components in a VoIP network, phones and PBXs must be both clients and servers. While VoIP clients initiate new call, the responsibility of VoIP servers is to accept incoming calls, make the appropriate handset ring and connect the call when the user picks the phone up.
This requirement for VoIP components to operate as clients and servers means that we cannot follow the same implementation guidelines for VoIP that serve well for web and email. This is particularly important when configuring NAT gateways and security devices.
When VoIP services are set up and particularly when VoIP networks and components are interconnected, it is necessary to ensure that the core protocols operate correctly, that the lack of a simple client-server relationship between the components of the VoIP network is taken into account when implementing security controls and that the service can pass through any NAT gateways between those components. These steps make VoIP deployments considerably more complex than email or web.
Installing a UM Labs SIP Security Controller at the network perimeter makes simplifies VoIP deployment because the SIP Security Controller is designed to handle the additional protocol complexity and to work with applications that do not assume a simple client server model. In addition, the SIP Security Controller automatically handles NAT, including navigating calls through remote NAT gateways that are not under local control.
I thought that STUN, TURN and ICE were all that I needed, is there a better solution?
STUN, TURN and ICE are all attempts to handle the NAT and far-end NAT traversal challenges of VoIP. Each is a protocol in its own right, not integrated with the core VoIP protocols. In fact STUN and TURN are generic solutions for NAT traversal and can be used with any application.
While these protocols can be used to help with the far-end NAT traversal problem they need to be separately implemented and configured. The protocols must be implemented in multiple locations, for example in a VoIP gateway and in each phone that connects over a NAT link. If you have phones from different vendors you may need to support multiple protocols, while some phones support TURN others may support STUN or ICE.
If a phone configured to run one of these protocols move to a location when there is no NAT between the phone and the PBX (for example a laptop with a soft-phone is connected to the office LAN) then some care is needed to ensure that the service still works.
UM Labs believe that there is a much better solution that using STUN, TURN or ICE to run VoIP through NAT gateways, that solution is to do nothing!. A UM Labs SIP Security Controller installed at the network perimeter will automatically handle all NAT issues. There is no need to install and configure extra protocols, and no need for any special set up on either the phone or the PBX.
I thought that SIP was a standard, why do I need a product to solve the interoperability problem?
SIP is a standard, but a complex one. As described in the answer to a previous question, there are over 110 RFCs describing the SIP protocol suite. The complexity of the protocol leaves scope for different vendors to handle the same requirement in different ways. These differences are particularly common when more sophisticated products from different vendors are compared. For example Nortel's BCM range of PBXs handles call centre applications (playing a standard welcome message, queuing a call and then connecting the call to an available operator) in a specific way. While this method falls completely within the SIP standard, it is almost certainly different to the method used by Avaya, Cisco or any other vendor. These differences can trigger implementation problems.
A UM Labs SIP Security Controller can mask these problems
Which VoIP products will work with UM Labs' products?
The UM Labs product will work with any vendor with a SIP implementation that conforms to the core SIP standards.
