LoadBalancer networking

LoadBalancer mode lets Kubernetes or your infrastructure allocate addresses for SIP and RTP Services. If KubeVoIP cannot resolve an address yet, it reports a waiting condition until the Service ingress is available.

Use this mode when your cluster or network can provide stable UDP LoadBalancer addresses. Cloud load balancers, MetalLB, and similar controllers can all fit this model as long as they preserve the configured UDP ports.

What gets exposed#

KubeVoIP exposes signaling and media separately:

• SIPGateway owns the Kamailio Service for SIP signaling, normally UDP 5060.
• MediaRelay owns one Service per RTPengine replica. Each replica receives a stable slice of the configured RTP port range.
• NetworkProfile tells KubeVoIP which external address to advertise, or lets KubeVoIP discover addresses from LoadBalancer Service status.

SIP clients and trunks send SIP to the gateway address. Kamailio asks RTPengine to rewrite SDP so media flows through the selected RTPengine replica.

Port preservation#

Do not translate SIP or RTP ports. Public and private ports need to match:

• UDP 5060 to the SIP gateway Service.
• Each RTPengine media range to its matching RTPengine Service.

Port translation can leave SIP clients, providers, or RTPengine advertising one address and port while packets arrive somewhere else.

Waiting for addresses#

If a Service has no status.loadBalancer.ingress address yet, KubeVoIP reports a waiting condition. This is normal on clusters without LoadBalancer support. For example, a plain Kind cluster will usually leave SIPGateway and MediaRelay waiting until you install a LoadBalancer controller or switch to a different networking mode.

Check the current addresses with:

kubectl -n telephony get service main-sip-gateway main-rtpengine-0
kubectl -n telephony get sipgateway main
kubectl -n telephony get mediarelay main

Infrastructure responsibilities#

KubeVoIP renders Kubernetes resources and advertised SIP/RTP addresses. Your infrastructure still owns public DNS, firewall rules, router forwarding, cloud load balancer annotations, and provider-side trunk settings.

For a working first call, run the two-phone quickstart and then come back here before exposing SIP or RTP outside the cluster.