Kamailio e dSIPRouter davanti ad Asterisk: progettare un SBC VoIP

Quando un’infrastruttura VoIP cresce, il PBX non dovrebbe essere contemporaneamente centralino, firewall SIP, punto di ingresso Internet, router dei carrier e media proxy. Mettere Kamailio/dSIPRouter davanti ad Asterisk separa il bordo SIP dalla logica telefonica interna.

Topologia

Internet / Carrier / PBX remoti
          |
          | UDP 5060 / TLS 5061
          v
Kamailio + dSIPRouter
          |
          +---- RTPengine 127.0.0.1:2223
          |
          +---- PBX backend via TCP/TLS
                  |
                  v
             Asterisk / FreePBX

Nel nostro Edge Kamailio ascolta su UDP 5060 e TLS 5061. La configurazione aggiuntiva è separata in /etc/kamailio/newvoip/tenants.cfg e /etc/kamailio/newvoip/routing.cfg.

Validare Kamailio

kamailio -c -f /etc/kamailio/kamailio.cfg
systemctl status kamailio
ss -lntup | grep -E ':5060|:5061'

Il controllo -c verifica la sintassi, non la raggiungibilità del database o dei peer.

Dominio → backend

dSIPRouter espone Domains, PBX/Endpoints, Carrier Groups, Inbound DID Mapping e Global Outbound Routes. La logica fondamentale è stabilire a quale tenant appartiene il dominio SIP e quale backend deve ricevere la richiesta. In configurazioni più articolate possiamo spostare queste informazioni in database e usarle da Kamailio tramite sqlops, dispatcher, permissions o drouting.

RTPengine

# /etc/rtpengine/rtpengine.conf
interface = 213.226.106.252!172.16.0.150
listen-ng = 127.0.0.1:2223
port-min = 30000
port-max = 40000

La sintassi pubblico!privato permette di usare l’indirizzo locale sul server ma pubblicizzare nell’SDP quello raggiungibile dall’esterno.

rtpengine_manage("replace-origin replace-session-connection");

systemctl status rtpengine
ss -lunp | grep 2223
tcpdump -ni any udp portrange 30000-40000

TLS e mTLS

Per i trunk interni possiamo usare TLS e, quando serve, autenticazione mutua a certificato. Sul lato Asterisk un transport PJSIP tipico è legato alla rete SIP e verifica il certificato del server.

bind=10.0.10.10:5061
cert_file=/etc/asterisk/keys/pbx-newvoip.crt
priv_key_file=/etc/asterisk/keys/pbx-newvoip.key
ca_list_file=/etc/ssl/certs/ca-certificates.crt
verify_server=yes

Sul bordo la CA per i client SIP può essere separata dalle CA pubbliche: un certificato TLS valido non equivale automaticamente a un client autorizzato.

openssl s_client   -connect edge.example.net:5061   -cert client.crt   -key client.key   -CAfile newvoip-sip-client-ca.crt

PBX statico, non necessariamente REGISTER

In una architettura PBX-to-Edge fidata non è obbligatorio far registrare il PBX a dSIPRouter. Un tentativo di REGISTER dal backend può ricevere 404 se l’Edge è configurato per routing statico/trusted.

asterisk -rx "pjsip show registrations"
asterisk -rx "pjsip show endpoints"
asterisk -rx "pjsip show endpoint Linea_Principale"

Carrier, ACL e antifrode

Carrier ed endpoint non devono condividere automaticamente la stessa policy. I carrier possono avere allowlist IP e route dedicate; gli endpoint remoti hanno autenticazione, NAT, limiti e profili antifrode. Prima del provisioning conviene verificare DNS, raggiungibilità, certificati, ACL e profilo associato.

Diagnostica

# Segnalazione in chiaro
ngrep -d any -W byline port 5060

# TLS
tcpdump -ni any tcp port 5061

# Media
tcpdump -ni any udp portrange 30000-40000

# Log
journalctl -u kamailio -f
journalctl -u rtpengine -f

Un INVITE che non raggiunge Asterisk è un problema di routing SIP. Una chiamata che si instaura ma ha audio monodirezionale porta invece a controllare SDP, NAT, RTPengine e firewall sul range RTP.

Riferimenti

Kamailio Documentation · dSIPRouter · RTPengine manual.