Kamailio SecureSIP gateway con rtpengine
Nei post precedenti abbiamo già parlato di rtpengine e di come usarlo con Kamailio per gestire il NAT o la transcodifica audio. In questo articolo invece vediamo come utilizzare Kamailio con il modulo TLS e rtpengine per realizzare un TLS/SRTP proxy, che sul primo leg di chiamata utilizza il SIP sicuro con TLS e SRTP e sul secondo leg utilizza UDP e RTP. In questo modo avremo la possibilità di aggiungere il supporto del Secure SIP anche a media server che supportano il solo trasporto UDP con RTP in chiaro e renderli quindi sicuri. Il protocollo SRTP (Secure RTP) è utilizzato con SIP su TLS e trasporta la voce in pacchetti IP crittografati, in modo da non permettere l’intercettazione e la decodifica dei pacchetti audio.
Configurare Kamailio
Il prerequisito per scenari di questo tipo è avere Kamailio installato e configurato con il modulo TLS e rtpengine installato.
Sul file di configurazione di Kamailio invece dobbiamo attivare rtpengine ed utilizzare la funzione rtpengine_manage() con i flags opportuni.
Attiviamo il modulo rtpengine.
// Enable debug
#!define WITH_DEBUG
// Enable TLS
#!define WITH_TLS
// Enable NAT
##!define WITH_NAT
// Enable RTPENGINE
#!define WITH_RTPENGINE
// Enable call dispatching
##!define WITH_DISPATCHER
#!ifdef WITH_RTPENGINE
loadmodule "rtpengine.so"
#!endif
#!ifdef WITH_RTPENGINE
# ----- rtpengine params -----
modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2223")
#!endif
Utilizziamo la funzione rtpengine_manage() per gestire l’offer verso il media server SIP/UDP e la response verso il client TLS/SRTP.
if (has_body("application/sdp")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection RTP");
}
...
...
t_relay_to_udp("MS_IPADDR","MS_PORT");
...
...
exit;
onreply_route[MANAGE_REPLY] {
...
...
if (has_body("application/sdp")) {
rtpengine_manage("SIP-source-address replace-origin replace-session-connection");
}
...
}
Con queste configurazioni stiamo dicendo a Kamailio di utilizzare rtpengine per modificare il body dell’INVITE ricevuto su TLS ed inoltrarlo al media server su UDP, modificando lo stream da SRTP a RTP. In risposta, rtpengine gestisce la conversione al contrario da RTP a SRTP verso il chiamante.
Analizzando il comportamento di Kamailio all’arrivo di una chiamata su TLS con SRTP, vediamo che l’INVITE ricevuto usa TLS come protocollo di trasporto e nel SDP contiene l’informazione RTP/SAVP come Media Description ed il Media Attribute crypto con la crypto-suite in uso.
L’INVITE in uscita verso il media server invece, utilizza UDP come protocollo di trasporto e contiene nel SDP l’informazione che lo stream utilizzerà RTP e verrà attivato tra media server e rtpengine.
Nella direzione opposta i messaggi di response, in particolare il 200OK, usano SIP/UDP nella direzione media server => Kamailio e TLS/SRTP nella direzione Kamailio => Chiamate.
L’analisi del flusso completo della chiamata mostra chiaramente il comportamento del sistema, con i due leg della chiamata distinti con i flussi audio RTP in chiaro da una parte e SRTP criptato dall’altra parte.
