NAT E VOIP: SIP, SDP E RTP – PROBLEMI
SIP utilizza molto spesso gli indirizzi IP nei propri headers, un esempio significativo è il metodo REGISTER.
La richiesta di registrazione viene effettuata da un telefono per rendersi raggiungibile dal SIP proxy, a tale scopo viene utilizzato l’header Contact il quale viene compilato con IP e porta su cui il telefono deve ricevere le richieste SIP (ad es. le INVITE per le chiamate in ingresso).
L’header Contact verrà compilato con l’IP del telefono che, nel caso di un telefono in una LAN, sarà un IP privato.
NAT E VOIP: SIP, SDP – HANDS ON
▸ Register inviata dal telefono:
NAT E VOIP: SIP, SDP – HANDS ON
▸ Register ricevuta dal PBX:
NAT E VOIP: SIP, SDP – HANDS ON
▸ SDP:
IL PROBLEMA CON RTP
Un’altra problematica introdotta dal NAT è legata alla negoziazione dinamica delle porte RTP
Durante lo stabilirsi di una chiamata tramite i messaggi SIP INVITE e 200 OK gli endpoint, tramite una sintassi SDP, negoziano indirizzi IP e porte da utilizzare per l’invio dello stream audio.
Gli indirizzi IP generalmente sono gli IP dei due endpoint (ma non è garantito: potrebbe essere negoziato l’uso di un media server ad esempio), le porte vengono negoziate dinamicamente e non sono predicibili a priori
Nel caso in cui i firewall non siano in grado (o siano impossibilitati a causa dell’uso di SIP/TLS) di aprire le porte richieste dinamicamente è possibile configurare l’apertura delle porte staticamente. In questo caso in genere è bene ridurre il range di porte RTP negoziate.
Se è abilitato il protocollo RTCP ogni conversazione ha bisogno di 2 porte RTP, quindi limitare eccessivamente il range di porte RTP può inficiare il numero di chiamate contemporaneamente gestibili.