SIP Session Border Controllers and Public Cloud Services
Placing SIP servers, like SBC on public cloud services like Google GCP or Amazon AWS can pose significant challenges
By placing SIP Session Border Controller (SBC) on cloud services, one can enjoy benefits available from such setup, like:
- No need to worry and be dependant on physical servers
- Increase / decrease capacity almost instantly by up-/down-scaling the cloud virtual instances
- Increased secuity by fine tuning access groups to individual instances, IP address ranges, protocols and ports
- Better utilization of resources by separating different tasks to specialized services
- Availability of professional support
The large selection of operating systems available by cloud providers allows to install virtually any type of SBC regardless if it is open source or commercial, for small deployment or large installation.
However, there are some issues which many operators face when placing their SIP servers on the cloud and the most important one is the way how these services handle NAT or Newtork Address Translation.
Mainly due to IP v4 Address Exhaustion and other considerations cloud services do not offer dedicated direct public IP addresses to the cloud computing instances. Instead these instances receive IP address from the pool of internal, or private addresses and placed in the internal network. For the services which require public access, a public address is assigned and servers private assigned address is directly and bidirectionally mapped to this public address. This is called 1:1 NAT. Each port or each protocol is directly linked to its counterpart, so for the packet arriving from public network to the public destination address of private server, it is tranparent. The same works on the way out: the outgoing packet passes through the NAT and reaches the destination on the public network. In the process of travelling through the NAT, its source address is rewritten in a way as it appears coming from the public address. It is worth to note that there are plenty of services not requiring public IP address (databases, backend application services, message dispatchers etc), and therefore such a setup really saves precious IPv4 addresses, and adds extra layer of security by denying direct public access.
The problem with SIP services stems from the fact that rewriting source address in the transport (UDP or sometimes TCP) packet is not enough. SIP and SDP packets carry information about call connecion, i.e. where is the opposite endpoint of the call and how it shoud be contacted. SBC placed behind 1:1 NAT usually are not aware about their real external addresses, and therefore will not be able to inform remote party correctly about where to establish the connection. And with many of end users SIP devices being also placed behind NATs (although usually non simmatrical ones), the problem of double traversing NAT becomes rather complex.
One of the solutions in these cases is to place dedicated proxy servers between SBC and clients on public networks. While these proxies are also behind 1:1 NAT on cloud services, they are capable of inspecting SIP and SDP packets, and rewriting source/destination addresses accordingly. Typical setup involves SIP proxy working in tandem with RTP proxy. In such a setup the SIP/RTP proxy pair would be the old point of contact for devices on the public network. They send their SIP packets to SIP proxy, which by looking up its rouing tables, resends it via private address to SBC with modified address both for SIP and RTP connection. SBC sees Proxy as its peer for the dialog and replies back to it with its own connection information. SIP proxy now rewrites the source and destination address and sends it to the remote party. In such way a valid SIP/SDP and RTP session can be established.
{$image1}
This setup has number of advantages:
- SIP proxy/RTP proxy becomes single point of contact remote party, thus hiding newtork topology and increasing security
- SIP proxy can serve as the load balancer for several SBCs
- Related to previous, the setup become smore scalable- it is possible to shut down any instance of SBC for maintenance or upgrade
- Several proxies can be used to achieve full system redundancy
Disadvanatges are not many, the important one perhaps is the fact that from the point of view of SBC all requests appear to be coming from single address (of the SIP proxy) an therefore it is impossible to do IP address based authentication of the endpoints. However, thsi can be solved by modifying SIP proxy to append specially crafted SIP headers with information about remote party address.
Practical setup of SIP/RTP proxy for Amazon AWS using very popular OpenSIPS SIP proxy and RTPproxy are described in our documentation page.
