VoIP architecture in K8s

Durring intial VoIP servers deployement we faced with issues related to NAT technology used in most Kubernetes deloyments. Here is:

• you cannot dynamically publish UDP ports for RTP streams, this may lead to one-way calls;
• if you use UDP transport for call signalling, then you may faiced issue when before pod is published on port 5060 the orchestration software temporally open port 5060 on host network and inbound UDP packets will create record in conntrackd table. Later when pod is started then UDP flows already present in the conntrackd table cannot reach pod and continues reaching host network;
• for cloud deployments like AWS present different network segments where NAT rules applied by the cloud provider, as example for publishing server in the ineternet, and then no NAT rules applied, as example direct connect links. In this case you need to deploy VoIP servers two times, first time for network segment where cloud NAT rules applied, and second time for segment where no cloud NAT rules applied. As result, you need to double ammount of VoIP servers and use multi-nic K8s solutions like Multus CNI.

To solve this issues we make decision do not use NAT for VoIP application deployment in the K8s. To get this we:

• deploy Internet facing servers on host network;
• use IPv6 for internal needs and for network segments where NAT is applied, if this possible;
• for network segments where no NAT rules applied and deploy RTP strams proxy software like RTPengine.

This allow use same approach used for