Nelle chiamate B2B (business-to-business) due organizzazioni diverse mettono in comunicazione i propri endpoint attraverso Internet, quasi sempre con entrambi i lati dietro NAT e firewall. Il signaling SIP passa dalla coppia Expressway-C / Expressway-E (traversal client/server), ma il vero problema è il flusso media: RTP/RTCP deve trovare un percorso valido tra due host che non conoscono il proprio indirizzo pubblico. La tecnologia che risolve questo scenario è ICE, appoggiata a STUN e TURN, con l’Expressway-E in DMZ configurato in static NAT.

ICE: candidate gathering

ICE (Interactive Connectivity Establishment) non è un protocollo unico ma un framework che raccoglie più indirizzi candidati per ciascun endpoint e poi verifica quali coppie funzionano davvero tramite connectivity check. I tipi di candidate sono tre:

Candidate Come si ottiene Indirizzo pubblicizzato
host Interfaccia locale dell’endpoint IP privato (LAN)
server-reflexive (srflx) Query STUN all’Expressway-E IP pubblico visto dal NAT esterno
relay Allocazione TURN sull’Expressway-E IP pubblico dell’Expressway-E

ICE ordina i candidate per priority e privilegia i percorsi più diretti: prima host, poi server-reflexive, e solo come ultima risorsa il relay, perché quest’ultimo aggiunge un hop e consuma risorse sul server. Quando i due lati sono dietro NAT simmetrico e nessun percorso diretto è percorribile, il relay TURN vince ed è l’unica coppia che sopravvive ai connectivity check.

Il ruolo di TURN sull’Expressway-E

Il TURN server è una funzione dell’Expressway-E (richiede licenza) che agisce da media relay: alloca una porta pubblica e inoltra l’RTP tra i due endpoint. Il client TURN chiede un’allocation, ottiene un relayed transport address e comunica all’altro lato dove inviare il media. Sull’Expressway-E la porta di ascolto TURN di default è UDP 3478 (o range 3478-3483), mentre il relay port range predefinito è 24000-29999 su un Large system.

In B2B, tipicamente gli endpoint sfruttano ICE passthrough: l’Expressway abilita ICE end-to-end così che gli endpoint negozino direttamente i candidate, usando il TURN dell’Expressway-E come relay quando necessario.

Static NAT e pubblicazione dei candidate corretti

Qui sta il cuore del design. L’Expressway-E in DMZ ha spesso l’interfaccia LAN configurata con un IP privato, mentre il firewall esegue un 1:1 static NAT verso un IP pubblico. Se l’Expressway-E non sa di essere natato, pubblicherà nei candidate (server-reflexive e relay) e negli header il proprio indirizzo privato, che è irraggiungibile da Internet.

La configurazione Static NAT mode: On con la relativa Static NAT address (IP pubblico) sull’interfaccia LAN dice all’Expressway-E di riscrivere gli indirizzi presentati verso l’esterno con l’IP pubblico. Solo così i candidate TURN/STUN riportano l’indirizzo che il peer remoto può effettivamente contattare. Va inoltre garantita la NAT reflection sul firewall (hairpinning) quando anche gli endpoint interni devono raggiungere lo static NAT address.

# Concetto: LAN1 con IPv4 static NAT
IPv4 static NAT mode:    On
IPv4 static NAT address: 203.0.113.10   # IP pubblico
IPv4 address (LAN1):     10.0.1.10       # IP privato in DMZ

Perché signaling “verde” e media muto

Il signaling SIP viaggia sulla traversal zone tra Expressway-C ed E: la sessione si stabilisce, la chiamata “squilla” e sembra connessa. Il media però segue una negoziazione separata (ICE). Se il TURN è attivo ma lo static NAT non è riflesso nei candidate, l’Expressway-E annuncia un relay address privato: i connectivity check ICE dal peer remoto falliscono, nessuna coppia valida viene selezionata e la chiamata resta senza audio/video (one-way o no-media) pur essendo “connessa”. È l’errore di design più insidioso dello scenario B2B.

Trappole tipiche d’esame

  • TURN abilitato ma static NAT non riflesso nei candidate → il relay pubblicizza un IP privato, ICE non trova coppie valide: signaling stabilito ma media assente. La correzione è Static NAT mode: On con l’IP pubblico corretto sull’interfaccia LAN.
  • “La chiamata connette ma senza audio/video” → non toccare il signaling: il problema è ICE/media. Verifica TURN, static NAT e apertura porte relay (UDP 3478 + range 24000-29999).
  • Endpoint dietro NAT simmetrico → i candidate host e server-reflexive falliscono; la risposta corretta è che ICE seleziona il candidate relay (TURN), non un percorso diretto.
  • Firewall che blocca UDP 3478 o il relay range → allocazione TURN impossibile: la risposta è aprire le porte TURN verso l’Expressway-E, non modificare le traversal zone SIP.
  • Ordine dei candidate → a parità di scenario, ICE preferisce host > server-reflexive > relay; il relay è l’ultima scelta, non la prima.