SIP Session Border Controllers and Public Cloud Services
Back to Articles
VoIP SIP Howto Cloud Services AWS NAT

SIP Session Border Controllers and Public Cloud Services

January 25, 2019 4 min
Aivis Olsteins

Aivis Olsteins

By placing SIP Session Border Controller (SBC) on cloud services, one can enjoy benefits available from such setup, like:

  1. No need to worry and be dependant on physical servers
  2. Increase / decrease capacity almost instantly by up-/down-scaling the cloud virtual instances
  3. Increased secuity by fine tuning access groups to individual instances, IP address ranges, protocols and ports
  4. Better utilization of resources by separating different tasks to specialized services
  5. 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:

  1. SIP proxy/RTP proxy becomes single point of contact remote party, thus hiding newtork topology and increasing security
  2. SIP proxy can serve as the load balancer for several SBCs
  3. Related to previous, the setup become smore scalable- it is possible to shut down any instance of SBC for maintenance or upgrade
  4. 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.

 

Share this article

Aivis Olsteins

Aivis Olsteins

An experienced telecommunications professional with expertise in network architecture, cloud communications, and emerging technologies. Passionate about helping businesses leverage modern telecom solutions to drive growth and innovation.

Related Articles

Case Study: Global Communications Company

Case Study: Global Communications Company

A leading communications company used our cloud Voice platform to send 30 million OTP calls per month to their customers, resulting in cost reduction and incrased conversion

Read Article
Bridging The Delay Gap in Conversational AI: The Backpressure Analogy

Bridging The Delay Gap in Conversational AI: The Backpressure Analogy

Conversational AI struggles with the time gap between text generation and speech synthesis. A “backpressure” mechanism, akin to network data flow control, could slow text generation to match speech synthesis speed, improving user interaction.

Read Article
How Voice AI Agents Can Automate Outbound Calls and Unlock New Opportunities for Businesses: A Deeper Dive

How Voice AI Agents Can Automate Outbound Calls and Unlock New Opportunities for Businesses: A Deeper Dive

AI voice agents transform healthcare scheduling by reducing costs, administrative tasks, and no-shows. They offer 24/7 service, multilingual support, proactive reminders, and valuable insights, improving efficiency and patient experiences.

Read Article
How to Fix Your Context: Mitigating and Avoiding Context Failures in LLMs

How to Fix Your Context: Mitigating and Avoiding Context Failures in LLMs

Larger context windows in LLMs cause poisoning, distraction, confusion, and clash. Effective context management (RAG, pruning, quarantine, summarization, tool loadouts, offloading) remains essential for high-quality outputs.

Read Article

SUBSCRIBE TO OUR NEWSLETTER

Stay up to date with the latest news and updates from our telecom experts