SCUOLA DI SCIENZE
Corso di Laurea Magistrale in Informatica
Un proxy VoIP
basato su PJSIP
a sostegno della mobilita’
Tesi di Laurea in Sistemi Mobili
Relatore:
Chiar.mo Prof.
Ghini Vittorio
Presentata da:
Ciaramella Marco
II Sessione
Anno Accademico 2013/2014
Introduzione
I servizi di Voice over IP stanno portando a un radicale cambiamento nel modo di comunicare della gente.
Oggigiorno, a seguito dell’abbattimento dei costi di un abbonamento Inter-net, molte persone preferiscono telefonare attraverso il servizio VoIP sfrut-tando la propria connessione per evitare costi aggiuntivi.
Questo cambiamento interessa anche le aziende che permettono ai propri clienti un canale alternativo di comunicazione.
A fronte di una rapida diffusione del VoIP fa seguito tutta una serie di possibi-li ottimizzazioni legate alla presenza di dispositivi dotati di diverse interfacce di rete che potrebbero essere sfruttate per garantire una migliore qualit`a nelle comunicazioni over IP durante la mobilit`a.
Ad esempio si potrebbe pensare di cambiare interfaccia di rete su cui tra-smettere in base alla fluttuazione del carico oppure semplicemente perch´e ci si `e disconessi da una rete Wi-Fi e si vuole continuare con quella 3G.
L’infrastruttura ABPS (Always Best Packet Switching) offre un supporto a questo scenario, collocando due proxy, uno locale e un altro esterno, lungo il percorso dell’host mobile.
Con la tesi seguente ho voluto continuare il lavoro svolto da Luca Monta-nari aggiungendo il supporto per il proxy esterno e il supporto a tutta una serie di meccanismi previsti dai clienti VoIP che mancava nella precedente
1 Introduzione 3
Introduzione 4
2 Scenario 7
2.1 VOIP sfruttando diverse interfacce di rete: ABPS-SIP/RTP . 7
2.1.1 Archiettura ABPS . . . 8
2.2 Problemi nello scenario VoIP . . . 9
2.2.1 Cambio di indirizzo IP . . . 9
2.2.2 Firewall e NAT System . . . 9
2.3 Soluzione . . . 12
2.3.1 Cambio indirizzo IP . . . 12
2.3.2 Firewall e Sistemi NAT . . . 12
3 Protocolli per il VoIP 15 3.1 SIP . . . 15
3.1.1 Come funziona SIP . . . 16
3.2 SDP . . . 23 3.3 RTP/RTCP . . . 25 4 Strumenti 27 4.1 La suite PJ . . . 27 4.2 Architettura PJSIP . . . 29 5
5 Precedente implementazione 33
5.1 Funzionamento del proxy pj relay . . . 33
5.1.1 Esempio di funzionamento . . . 34
6 Obiettivi 39 6.1 Limiti della precedente implementazione . . . 39
6.2 Obiettivi . . . 40
6.2.1 Proxy esterno di ABPS . . . 40
6.2.2 Da dove proviene l’INVITE e a chi inoltrarla . . . 41
7 Progettazione 45 7.1 Progettazione dell’outbound proxy . . . 45
7.2 Implementazione dell’outbound proxy . . . 45
7.3 Progettazione del meccanismo di inoltro della INVITE . . . . 46
7.4 Implementazione dell’algoritmo di inoltro della INVITE . . . . 48
7.5 Progettazione del supporto ai keep-alive . . . 48
7.6 Implementazione del supporto ai keep-alive . . . 49
8 Valutazione 51 8.1 Proxy locale . . . 52
8.2 Outbound proxy . . . 56
9 Conclusioni e sviluppi futuri 61 9.1 Discussione sui risultati . . . 61
9.2 Sviluppi futuri . . . 61
Conclusioni 62 A Appendice 63 A.1 pjsip rx data . . . 63
A.2 pjsip tx data . . . 67
Scenario
Il nostro scenario di interesse `e quello in cui un nodo mobile, su cui sono installate pi`u interfacce di rete, si sposta durante una comunicazione VoIP. Il nodo `e in grado di cambiare eventualmente, in modo dinamico, l’interfaccia su cui trasmette a seconda del carico riscontrato o dell’affidabilit`a del canale su cui sta trasmettendo. Il monitoraggio di questi paramentri permette ad applicazioni real-time, e in particolare di telefonia su Internet, di sfruttare la migliore connessione possibile tra quelle disponibili sul dispositivo mobile per sperimentare una comunicazione pi`u interattiva con l’altro end-system.
2.1
VOIP sfruttando diverse interfacce di
re-te: ABPS-SIP/RTP
In letteratura esistono gi`a protocolli che utilizzano le diverse interefacce di rete installate sul nodo mobile, come ad esempio un estensione di MIPv6 [5], chiamata Multiple Care of Address (MCoA) , oppure il Flow Mobility technique (FlowMob). Ma tutti questi protocolli vedono le diverse interfacce di rete come una seconda strada da utilizzare in caso di rottura del canale su cui si sta trasmettendo. Quindi, la decisione di cambiare la tecnologia di comunicazione non `e presa sulla base di particolari QoS (Quality Of Service), ma sulla rottura del canale di comunicazione corrente.
Nel nostro scenario di interesse consideriamo l’infrastruttura denomita ABPS che sta per Always Best Packet Switching [2].
ABPS, a differenza dei protocolli menzionati prima, monitora costantemente lo stato dei canali che fanno riferimento alle interfacce di rete, per decidere, pacchetto per pacchetto, il percorso migliore su cui instradare.
2.1.1
Archiettura ABPS
Nella figura 1, che mostra l’architettura del sistema ABPS a livello ses-sione, notiamo due proxy, i cui ruoli sono:
• Proxy locale: crea un tunnel multipath diretto al Proxy Esterno, at-traverso tutte le interfacce disponibili (come ad esempio 3G o WiFi). Il proxy locale `e in esecuzione sulla stessa macchina del nodo mobi-le. L’applicazione VoIP sar`a quindi configurata in modo da mandare i messaggi al proxy locale. Il proxy quindi inoltrer`a i messaggi ricevuti al proxy esterno usando l’interfaccia scelta dall’infrastruttura ABPS.
• Proxy esterno o outbound proxy: ha la funzione di Back-to-back user agent. E’ un proxy esterno a qualsiasi rete privata, quindi `e ricono-sciuto sulla rete da un suo indirizzo IP pubblico a cui `e possibile fare riferimento per contattarlo direttamente.
La funzione di questo proxy `e di creare un canale logico con il Proxy lo-cale in modo tale da poter riconoscere il mittente dei messaggi ricevuti, indipendentemente dall’interfaccia di rete utilizzata. Il proxy esterno mascherer`a l’indirizzo del proxy locale e inoltrer`a i datagram UDP al Correspondent Node (il destinatario) che vedr`a solo la comunicazione con il proxy esterno senza percepire ci`o che avviene dall’altra parte.
Fig.1 L’architettura di ABPS.
2.2
Problemi nello scenario VoIP
2.2.1
Cambio di indirizzo IP
La problematica relativa al cambio di interfaccia di rete durante un dia-logo VoIP `e dato dal momento in cui il client mobile decide di cambiare interfaccia. Difatti un’azione di questo tipo porterebbe ad avere in uscita dal nodo mobile pacchetti con un indirizzo IP mittente diverso da quello usato poco prima. L’effetto di questo cambio di indirizzo potrebbe causare sul de-stinatario l’eliminazione di tutti i pacchetti provenienti dal nuovo indirizzo poich´e non riconoscerebbe pi`u l’end-system con cui stava dialogando.
2.2.2
Firewall e NAT System
Il problema che invece affligge una qualsiasi comunicazione VoIP `e data dalla presenza dei sistemi NAT e firewall usati per proteggere le reti private e che non permettono ai client VoIP esterni di contattare altri client interni a queste reti.
uscita da una rete secondo delle regole. Il firewall quindi stabilisce una bar-riera tra una rete interna sicura e un’altra rete, ad esempio Internet, che si assume non essere sicura [6].
Il Network Address Translation (NAT) `e stato progettato per la conserva-zioni degli indirizzi IP. Configurando un NAT per una rete privata `e infatti possibile usare indirizzi globalmente non unici per i nodi interni che allo stes-so tempo posstes-sono comunicare con la rete esterna come ad esempio Internet. Questo `e possibile perch´e gli host della rete privata vengono identificati sulla rete esterna da un solo indirizzo IP globalmente univoco.
Il sistema NAT opera su di un router che connette due reti, cio`e la rete pri-vata con quella esterna (ad esempio Internet), e traduce gli indirizzi privati dei nodi interni in indirizzi legali, prima che i pacchetti vengano inoltrati al-l’altra rete. Questo fornisce una sicurezza addizionale andando a nascondere l’intera rete interna dietro quell’indirizzo.
Fig 2. Funzionamento di un sistema NAT.
Quando un nodo collegato a una rete dietro un NAT o un firewall cerca di collegarsi al web e alle e-mail non riscontra nessun problema. Il problema si pone per le applicazioni di peer-to-peer file sharing e servizi di VoIP per cui un client pu`o svolgere anche la funzione di server, cio`e un client in una rete privata diventa un server per un altro client presente sulla rete esterna. Il problema consiste nel fatto che il nodo sulla rete esterna `e impossibilitato a contattare il nodo sulla rete privata o perch´e non ha un IP globale in quanto mascherato dal NAT o perch´e bloccato da un firewall.
2.3
Soluzione
L’infrastruttura di ABPS `e stata progettato allo scopo di supportare le comunicazioni VoIP. Per questo motivo integra una serie di meccanismi per far fronte ai problemi analizzati.
2.3.1
Cambio indirizzo IP
L’approccio adottato da ABPS `e quello di usare due proxy server, uno in esecuzione sul nodo mobile e l’altro esterno in esecuzione su una macchina fissa, detto outbound proxy. Ci`o che si vuole ottenere `e mascherare gli indi-rizzi del nodo mobile all’altro end-system facendogli credere di comunicare con il proxy server fisso. Poich´e l’indirizzo di quest’utlimo rimane sempre lo stesso il destinatario comunicher`a sempre con la stessa entit`a risolvendo cos`ı il problema dei pacchetti scartati a causa di un cambio di identit`a.
2.3.2
Firewall e Sistemi NAT
L’UDP hole punching (foratura) `e una tecnica di NAT traversal e firewall traversal comunemente usata per permettere il passaggio del flusso di da-tagram UDP. Con questa tecnica si stabilisce la connettivit`a tra i due host comunicanti stabilendo lo stato della porta sul server in cui `e in esecuzione un NAT o un firewall.
Le porte possono essere attivate dagli host comunicando con un server esterno con indirizzo pubblico, quindi non protetto da NAT e firewall. La comunica-zione verso un IP pubblico e una porta valida fa attivare nel server con NAT o firewall la porta e si vedr`a quindi costretto ad accettre tutti i pacchetti provenienti da quell’indirizzo IP pubblico e su quella porta.
Una volta impostata la porta sul NAT, lo stato della porta pu`o essere man-tenuto attivo, o dal traffico di dati scambiato dalle due entit`a, oppure in assenza di traffico, dai cos`ı detti pacchetti di keep-alive, che di solito sono pacchetti UDP vuoti o con poche informazioni. Nel caso di ABPS i due proxy hanno la responsabilit`a di mantenere le porte attive sul sistema NAT
o firewall anche in assenza di traffico mentre `e in corso una comunicazione VoIP.
Protocolli per il VoIP
SIP, Session Initation Protocol [7], `e il protocollo usato per l’instaurazione e gestione di un intero ciclo di vita di una sessione VoIP.
Per alcuni aspetti della sessione, SIP si appoggia ad altri protcolli come SDP e RTP/RTCP.
3.1
SIP
Session Initation Protocol [7] serve per iniziare, modificare e terminare sessioni tra uno o pi`u partecipanti.
SIP permette ai partecipanti di essere individuati attraverso il loro indirizzo IP e numero di porta dall’altro end-system. Inoltre consente ai partner di una comunicazione di concordare le modalit`a con cui scambiarsi i dati, il numero di sessioni multimediali, impostare una chat ecc.
Per alcune delle attivit`a descritte SIP si appongia ad altri standard IETF: • SDP, Session Description Protocol [3], viene usato per concordare
le modalit`a con cui scambiarsi i dati. Le informazioni SDP vengono trasportate all’interno dei messaggi SIP come corpo del messaggio. • URI [1], `e lo standard per gli identificativi (indirizzi) dei partecipanti
ad una sessione.
• RTP/RTCP [8] [4] sono i due protocolli usati per la gestione del traffico multimediale come voce, video, immagini, ecc.
3.1.1
Come funziona SIP
SIP `e un protocollo di sessione di tipo testuale in cui le informazioni sono codificate in ASCII e in modo comprensibile all’uomo. Il suo funzionamento `e basato sul meccanismo handshake di Request/Response chiamato transa-zione.
Le entit`a coinvolte in un dialogo SIP sono dette User Agent (UA) che interagiscono attraverso le transazioni.
Ogni transazione inizia con una Request inviata da uno User Agent Client (UAC) a uno User Agent Server (UAS) e termina con una Final Re-sponse inviata nell’altro senso.
Il messaggio di Request specifica nella prima riga il nome del metodo usato nella transazione, come INVITE, CANCEL, ACK, BYE, REGISTER, OPTIONS ecc.
Ad esempio il messaggio seguente `e una richiesta di BYE. BYE sip:alice@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 231 BYE Content-Length: 0
Mentre nella prima riga di una Response `e presente un codice di stato con il seguente significato
• codici 1xx usati per le risposte provvisorie;
Ad esempio una final Response alla Request “BYE” potrebbe essere: SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710
CSeq: 231 BYE Content-Length: 0
Come si pu`o vedere in figura 3, dopo la prima riga con il metodo `e presente un certo numero di headers seguito infine da una riga vuota, dopo la quale pu`o essere presente il corpo del messaggio, ad esempio SDP.
Fig. 3 L’header SIP.
A supporto della comunicazione tra UA `e presente un Registrar server presso cui i client UA si registrano specificando la loro posizione attuale nella rete attraverso una REGISTER Request.
location service che consulter`a quando un UAC far`a richiesta di INVITE. Oltre al Registrar, necessario per poter localizzare l’utente con cui si vuole comunicare, pu`o essere aggiunto un Proxy Server che instrada le Request verso gli UAS e le Response verso gli UAC. Pu`o essere configurato per rispondere direttamente ad una Request operando quindi come UAS. Oppure pu`o rimpiazzare la Request URI con una nuova.
Fig. 4 Interazione tra due client VoIP.
La figura 4 mostra l’interazione tra le componeti descritte dell’infrattura SIP durante una sessione.
SIP URI
{sip|sips}:[user-part@]domain-part[:port][;transport={UDP|TCP|TLS|...}]
le indicazioni su porta e/o trasporto sono consentite solo se la domain-part identifica un host domain-particolare, ad esempio se espressio da un indirzzo IPv4 o IPv6.
La URI pu`o indicare un indirizzo reale (contact-address), cio`e l’indirizzo del-l’entit`a SIP, nel caso in cui sia possibile ricostruire tale indirizzo. Oppure un indirzzo pubblico (address-of-record), se permette di ricostruire gli indirizzi di trasporto di un server in grado di locallizare l’entit`a SIP.
Metodi SIP
L’RFC 3261 definisce i seguenti metodi:
• REGISTER: comunica l’indirizzo IP dell’entit`a SIP al Registrar.
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70
\textbf{To: Bob <sip:bob@biloxi.com>} From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER
\textbf{Contact: <sip:bob@192.0.2.4>} Expires: 7200
Content-Length: 0
Sulla ricezione di questa Register Request, il SIP Registrar associa la URI presente nell’header Contact all’indirizzo presente nell’header To. L’immagine seguente mostra la fase di Request/Response della REGI-STER.
Fig. 5 Le fasi di una richiesta di REGISTER.
Come si pu`o notare nella figura, in un primo momento il Registrar SIP risponde allo UA con una Response di tipo 401 Unauthorized. In questo messaggio, l’header WWW-Authenticate inserito dal Registrar istruisce il client per l’autenticazione usando la digest authentication. Il client dunque combiner`a il parametro nonce con la password dell’utente e calcola il valore MD5 per la stringa risultante.
A questo punto trasmette di nuovo una REGISTER Request, questa volta inserendo l’MD5 appena calcolato. Il Registrar, quindi, cofronta il valore MD5 del client con quello calcolato da lui e se coincide risponde con Response 200 OK e inserisce il client nel location database.
• INVITE: Inizia un dialogo con le relative sessioni oppure modifica le sessioni di un dialogo gi`a iniziato.
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp
La prima riga contiene il nome del metodo (INVITE), seguito da una serie di header descritti di seguito:
– Via Questo campo rappresenta l’indirizzo da cui proviene la Re-quest e sul quale l’utente si aspetta di ricevere la Response. – To Contiene la SIP URI del destinatario a cui `e rivolta la Request
originariamente.
– From Contiene la SIP URI di colui che ha originariamente gene-rato la Request. E’ usato per l’identificazione.
– Call-ID Contiene un identificatore globalmente univoco. La com-binazione del header To, From e Call-ID definisce in maniera uni-voca la sessione SIP tra i due utenti (nell’esempio Alice e Bob), detta dialogo.
– CSeq La Command Sequence contiene un intero e un nome di metodo. Il valore di CSeq `e incrementato per ciascuna nuova richiesta di INVITE dentro lo stesso dialogo.
– Contact Contiene un SIP URI che rappresenta la rotta diretta per conttatare l’utente, di solito `e composto di un username e un nome di domnio. Ma sono permessi anche indirizzi IP al posto di nomi di dominio.
– Max-Forwards Limita il numero di hop che la Request pu`o fare per giungere alla sua destinazione.
– Content-Type Contiene una descrizione del corpo del messaggio. – Content-Length Contiene la lunghezza in byte del corpo del
messaggio.
• re-INVITE: `e un’ulteriore INVITE inoltrata per modificare i para-mentri della sessione impostati con la precedente INVITE.
Il caso della RE-INVITE `e molto comune, in quanto capita che un utente VoIP voglia aggiungere alla conversazinoe vocale anche il video.
Un’operazione di questo tipo implica l’inoltro di una INVITE quando il dialogo `e gi`a attivo.
• ACK Segue immediatamente la transazione INVITE, co`e lo UAC che riceve la Response inoltra una seconda Request con metodo ACK a cui non fa seguito nessuna Response.
ACK sip:bob@186.48.249.1:5060 SIP/2.0 Via: SIP/2.0/UDP 120.146.22.11:5060;.... To: sip:bob@grossaditta.it;tag=bbb... From: sip:alice@grossaditta.it;tag=aaa... Call-ID: ccc...
CSeq: 1 ACK
• BYE La BYE Request termina il dialogo e tutte le sessioni associate.
Attivazione di un dialogo SIP
Dopo che gli utenti si sono registrati presso il loro Registrar presente sul Proxy Server (in realt`a basta che solo il destinatario sia registrato), l’UAC che vuole aprire una comunicazione con uno dei suoi contatti SIP (UAS) invier`a una INVITE Request al Proxy server dello UAS.
Il SIP Proxy dunque cercher`a nel location database i contact address associati allo URI di chi si vuole contattare. Se presente almeno un contact-address, il SIP proxy inoltra l’INVITE all’indirizzo individuato.
Quando l’utente destinatario vede la chiamata e risponde, lo UAS trasmette una Response 200 OK che raggiunge lo UAC mittente transitando negli hop presenti nell’header Via. A questo punto lo UAC `e a conoscenza del contact address dello UAS, poich´e `e presente nell’header Contact della Reponse, e invia un ACK direttamente allo UAS.
A questo punto pu`o iniziare la sessione audio/video/ecc come concordato nella negoziazione SDP.
Fig. 6 Fasi di una sessione SIP.
Nella figura sono mostrate le fasi di una sessione SIP dopo che entrambi gli UA si sono registrati presso il loro Registrar di dominio.
3.2
SDP
SDP, Session Description Protocol, `e il protocollo usato da SIP per ne-goziare i parametri dei flussi mulimediali, come numero di flussi, tipo, porta, codec, ecc.
In particolare il messaggio SDP viene trasportato come corpo del messaggio SIP e contiene:
• il protocollo di trasporto (RTP/UDP/IP, H.320, etc.) • il formato del media (video H.261, video MPEG, etc.) • indrizzo IP remoto per la trasmissione multimediale • porta remota per la trasmissione multimediale
Un messaggio SDP consiste di un insieme di righe di testo della forma type=value e includono
v= (versione del protcollo) o= (identificatore di sessione) s= (nome sessione)
i=* (informazioni sulla sessione) u=* (URI)
e=* (indirizzo email)
c=* (informazioni sulla connessione) b=* (zero o pi`u linee sulla bandwidth) k=* (chiave crittografica)
a=* (zero o pi`u linee di attributi di sessione) m= (nome del media e indirizzo di trasporto)
Ad esempio il contenuto seguente v=0 o=marco.ciaramella 1714 638 IN IP4 151.42.227.124 s=Talk c=IN IP4 151.42.227.124 b=AS:380 t=0 0 m=audio 64494 RTP/AVP 111 110 0 8 104 100 18 3 101 a=rtpmap:111 speex/16000 a=fmtp:111 vbr=on
a=rtpmap:110 speex/8000 a=fmtp:110 vbr=on a=rtpmap:104 AMR/8000 a=fmtp:104 octet-align=1 a=rtpmap:100 iLBC/8000 a=fmtp:100 mode=30 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11
specifica uno streming di tipo audio verso l’indrizzo 151.42.227.124 e por-ta 64494. Il protocollo definisce i campi SDP non estendibili, dunque non sarebbe ammesso aggiungere campi personalizzati.
3.3
RTP/RTCP
Il Real-Time Protocol fornisce i servizi di inoltro per i dati con caratteri-stiche real-time, come ad esempio audio e video interattivi.
RTP si appoggia a un secondo protocollo, RTCP, Real-Time Control Proto-col che monitora la qualit`a del servizio trasportando informazioni riguardanti i partecipanti in una sessione attiva.
RTP `e un protocollo di tipo framework, cio`e `e volutamente incompleto. Per cui pu`o essere esteso secondo le esisgenze richiesta dall’applicazione.
Il formato dei messaggi RTP `e visualizzato nella figura 7. In particoal-re il campo Sequence Number `e incrementato di 1 ad ogni pacchetto RTP trasmesso, e pu`o essere usato dal ricevente per determinare la sequenza di pacchetti persi o per riordinare la sequenza.
Mentre il campo TimeStamp di 32 bit contiene l’istante esatto in cui `e stato campionato l’audio/video secondo un orolgio definito dall’utente, e serve per permettere la sincronizzazione e il calcolo del jitter.
Il campo SSRC `e un identificatore univoco per la sorgente che sta generando i messaggi RTP. Il suo valore dovrebbe essere scelto casualmente in modo da ridurre il rischio di avere lo stesso identificativo per mittente e destinatario durante la stessa sessione RTP.
Il campo CSRC rappresenta una lista di 0 fino a 15 elementi di 32 bit, dove ogni elemento identifica una sorgente che contribuisce alla costruzione del payload contenuto nel messaggio. Ad esempio, per i pacchetti audio, nella lista CSRC saranno presenti gli identificativi SSRC di tutte le sorgenti che verranno mixate per ricostruire il payload da riprodurre.
Strumenti
Il proxy da cui sono partito, `e un proxy stateless scritto con la libreria PJSIP, incluso tra gli esempi della suite PJ e modificato precedentemente da alcuni ragazzi, Luca Montanari prima e Andrea Monzali e Marco Melletti poi.
PJ `e una suite di librerie open source (licenza GPL 2.0) scritte in C che implementa uno stack SIP e uno stack multimediale di supporto al VoIP, instant messaging e comunicazioni multimediali.
La scelta di adoperare tali librerie `e dovuta principalmente alle sua portabi-lit`a. PJ infatti funziona su architetture a 32 bit, 64 bit, big endian e little endian. Questa caratteristica fa di PJ uno strumento utile per scrivere una sola volta applicazioni destinate a un gran numero di dispositivi.
4.1
La suite PJ
La suite `e costituita di diverse librerie:
• PJSIP: rappresenta uno stack SIP che supporta un insieme di features ed estensioni del protocollo SIP.
• PJLIB: rappresentante la libreria a cui le restanti si appoggiano. Si oc- cupa di garantire funzionalit`a di base (es. l’astrazione rispetto
al sistema operativo sottostante). Pu`o essere considerata una replica della libreria libc con l’aggiunta di alcune features come la gestione dei socket, funzionalit`a di logging, gestione thread, mutua esclusione, semafori, critical section, fun- zioni di timing, gestione eccezzioni e definizione di strutture dati di base (liste, stringhe, tabelle, ecc...). • PJLIB-UTIL: anch’essa come PJLIB `e una libreria di appoggio, ma
a differenza della prima implementa funzioni pi`u complesse utili per la crittografia come gli algoritmi: SHA1, MD5, HMAC, CRC32. Ed anche funzioni per il parsing e la manipolazione di testi.
• PJMEDIA: questa libreria si occupa del trasferimento e della gestio-ne dei dati multimediali. Tra le sue caratteristiche principali vi `e la gestione degli stack RTP/RTCP.
• PJSUA: rappresenta il livello pi`u alto fungendo da wrapper verso le altre librerie. Inoltre agevola notevolmente la scrittura di applicazioni.
D’ora in poi mi riferir`o con PJSIP all’intera suite PJ.
4.2
Architettura PJSIP
PJSIP nonostante sia scritta in C, che non `e un linguaggio a oggetti, ha un’architettura fortemente modulare. Tutte le componenti di PJSIP sono implementate come moduli. Il nucleo di questa architettura `e costituito da SIP ENDPOINT che si occupa di:
• allocare la memoria per i moduli;
• temporizza lo heap e schedula gli eventi da notificare ai moduli; • gestisce i moduli di trasporto e controlla il parsing dei messaggi; • inoltra i messaggi SIP dal livello trasporto ai moduli interessati.
Ecco come si presenta la struttura di un modulo:
Fig. 9 La struttura di un modulo di PJSIP.
All’interno della struttura del modulo, troviamo dei puntatori a funzio-ne che sono tutti opzionali: se non vengono specificati, il valore di ritorno sar`a SUCCESSFUL, altrimenti andranno a svolgere i loro rispettivi compiti, descritti qui di seguito:
• ON RX REQUEST() e ON RX RESPONSE() sono i mezzi principali per ricevere i messaggi dall’endpoint SIP o da altri moduli, dove il valore di ritorno `e estremamente importante. Se un callback torna non zero (cioe true), significa che il modulo ha provveduto al messaggio e l’endpoint terminer`a la distribuzione del messaggio ad altri moduli. • ON TX REQUEST() e ON TX RESPONSE() sono chiamati dal
ge-store dei trasporti prima che un messaggio venga trasmesso: in questo modo si da la possibilit`a ad alcuni moduli (ad esempio quello dedito alla firma dei pacchetti) di fare un’ ultima modifica al messaggio. Tut-ti i moduli devono poi resTut-tituire come valore di ritorno PJ SUCCESS, altrimenti la connessione verr`a annullata.
• ON TSX STATE() viene utilizzato per ricevere una notifica ogni volta che lo stato della trasmissione viene cambiato: per esempio a causa del ricevimento di un messaggio, oppure dalla scadenza di alcuni timer o da errori dovuti al trasporto.
PJSIP si basa sul concetto di gerarchia, in cui ogni modulo `e identificato da un valore che ne indica la priorit`a. Questo valore specifica l’ordine con la quale i moduli vengono chiamati: pi`u sar`a basso il valore, maggiore priorit`a avr`a il modulo.
Una volta chiamato un modulo, questo invocher`a le funzioni on rx request() e on rx response() per gestire i messaggi in entrata di tipo Request e Re-sponse rispettivamente, e le funzioni on tx request() e on tx reRe-sponse() per i messaggi in uscita.
Se un modulo invece desidera accedere alla struttura del messaggio, prima del livello trasporto, dovr`a essere impostata una priorit`a maggiore.
Quando arriva un messaggio, questo viene memorizzato all’interno della struttura pjsip rx data e passato all’endpoint. Quest’ultimo distribuisce poi il messaggio a ciascun modulo registrato, chiamando on rx request() oppure on rx response() a partire dal modulo con priorit`a maggiore, cio`e col valore di priorit`a pi`u basso, finch`e uno di loro non restituisce un valore diverso da
zero (cio`e true). In tal caso, l’endpoint interrompe la distribuzione del mes-saggio verso altri moduli, in quanto presuppone che il modulo sia occupato nel trattamento del messaggio.
Il modulo che restituisce true a sua volta pu`o inoltrare ulteriormente il mes-saggio ad altri moduli.
Per quanto riguarda i messaggi in uscita, anche questi vengono rappresenta-ti all’interno di una struttura, che prende il nome di pjsip tx data, la quale contiene anche un buffer contiguo, un pool per la memoria e informazioni di trasporto.
Quando viene eseguita la funzione pjsip transport send() per inoltrare un messaggio, il gestore dei trasporti, chiama le funzioni on tx request() oppu-re on tx oppu-response(), per tutti i moduli, a partioppu-re ovviamente da quello con priorit`a maggiore.
Precedente implementazione
Il mio lavoro di tesi `e partito dal proxy locale implementato da Luca Montanari e successivamente modificato da Andrea Monzali e Marco Mellet-ti, per l’architettura ABPS, chiamato pj relay.
Il proxy client implementato ha il compito di intercettare i messaggi SIP in-vitati dal client UA in esecuzione sulla stessa macchina e modificare i campi di intestazione in modo che facciano riferimenti a lui e non allo UA.
Come client VoIP `e stato usato pjsua facente parte della suite PJ che pu`o essere configurato attraverso un file di configurazione in cui specificare la por-ta per i messaggi SIP e l’indirizzo e porpor-ta del proxy a cui inoltrare i messaggi.
5.1
Funzionamento del proxy pj relay
Il compito del proxy locale, secondo l’infrastruttura ABPS, `e quello di modificare i messaggi in uscita provenienti dallo UA locale, sosituendo la porta con la propria, prima di inoltrarli verso il proxy esterno.
Le informazioni modificate devono essere salvate in modo tale da reinserile per i messaggi in ingresso da inoltrare allo UA locale.
Le informazioni modificate riguardano i campi Via e Contact di SIP visti nel 33
capitolo sui protocolli del VoIP.
5.1.1
Esempio di funzionamento
Come esempio si considera il caso in cui il pjsua sul nodo mobile voglia fare richiesta di INVITE al pjsua esterno.
Secondo il protocollo SIP il messaggio INVITE dovr`a essere inoltrato al pro-xy server del dominio su cui `e registrato il pjsua mobile, o in caso non si fosse registrato, direttamente al proxy server su cui `e registrato il correspondent node
Nel nostro scenario il comportamento atteso sar`a quello di inoltrare il mes-saggio al proxy locale il quale inserir`a se stesso come mittente della INVITE in modo da poter riceve successivamente la Response.
Nella configurazione che ho usato, il client VoIP pjsua usa la porta 4445 per le comunicazioni SIP e come account URI marco.ciaramella.sip1@ekiga.net che ho creato su ekiga.net.
Mentre il proxy client pj relay `e stato configurato per usare la porta 5060. Nella figura viene mostrato l’header di una INVITE Request cos`ı come rice-vuto dal proxy locale.
Fig. 10 Header SIP della INVITE ricevuta dal proxy locale.
L’header Route evidenziato indica che il messaggio era destinato a lui. Dunque il proxy sostituisce le informazioni relative al pjsua e inserisce se stesso come mittente della INVITE Request. Infine inoltra la INVITE al proxy server ekiga.net secondo le specifiche del protocollo SIP.
Nella figura possiamo vedere l’header della INVITE Request in uscita, cio`e poco prima di essere inoltrata al correspondent node e dopo le modifiche fatte dal proxy.
Fig. 11 Header SIP della INVITE dopo le modifiche del proxy locale.
L’header Via evidenziato mostra come il proxy client abbia aggiunto se stesso nella lista dei Via. Mentre l’header Route mostra che il messaggio `e direzionato al proxy server ekiga.net, cio`e verso l’esterno.
Le informazioni relative allo UA interno vengono memorizzate nella strut-tura PJSIP denominata src info e definita nel modo seguente:
s t r u c t s r c i n f o s t r u c t { /∗ s t r u t t u r a p e r l a d e s t i n a z i o n e o r i g i n l e d e i p a c c h e t t i ∗/
DECL LIST MEMBER(s t r u c t s r c i n f o s t r u c t ) ; /∗ p o i n t e r t o t h e n e x t / p r e c e d i n g ∗/ /∗ s t r u c t u r e f o r dynamic a l l o c a t i o n ∗/ p j s t r t username ; p j s o c k a d d r s r c a d d r ; i n t a c t i v e c a l l s ; i n t s r c t y p e ; /∗ s o u r c e t y p e : PERM HOST o r TEMP HOST ∗/ p j t i m e s t a m p t o u c h ; p j p o o l t ∗ p o o l ; } ;
la struttara memorizza nel campo src addr l’indirizzo IPv4 o IPv6 del client e in username l’URI del nome utente SIP.
Le informazioni salvate in questa struttura verrano usate dal proxy sulla ricezione della INVITE Response, facendo quindi il lavoro inverso a quello descritto per la Request in modo che resti trasparente al client VoIP. Que-sto `e necessario poich´e il pjsua deve riconoscere se stesso negli header SIP altrimenti potrebbe scartare tutti i messaggi SIP.
Obiettivi
6.1
Limiti della precedente implementazione
L’implementazione descritta nel precedente capitolo fa riferimento al solo proxy locale dell’architettura ABPS.
Come `e chiaro dalla descrizione dello scenario in cui stiamo lavorando, man-ca la parte di proxy esterno fisso con funzione di Back-to-back user agent che nasconde il nodo mobile. Infatti senza la controparte di server fisso con indirizzo IP pubblico non `e possibile superare sistemi NAT e firewall come descritto nelle tecniche di NAT e firewall traversal. Inoltre, si vorrebbe per-mettere a un utente che non vuole essere contattato, e dunque non visibile sulla rete, di contattare tramite un INVITE un’altro utente precedentemente registrato.
Per come `e stato implementato il proxy pj relay, per`o, una comunicazione dallo UA sul nodo mobile pu`o essere instaurata solo dopo essersi registrato presso il suo Registrar. Se l’UA interno volesse fare INVITE senza prima aver fatto la REGISTER, il proxy sulla ricezione della INVITE Request non sarebbe in grado di capire da che direzione provenga, se da locale (interno) oppure da un UA esterno che sta cercando di contattare il client mobile. Come vedremo pi`u avanti il problema di poter fare INVITE senza esserci re-gistrati sul nostro Registrar si limita al problema di capire da dove proviene
la INVITE, se dallo UA del nostro nodo mobile o dallo UA esterno.
Relativamente alla mancaza del secondo proxy server descritto nel nostro scenario, nella precedente implementazione manca il supporto ai keep-alive.
6.2
Obiettivi
Nella mia tesi ho cercato di far fronte ai limiti analizzati, aggiungendo quella parte dell’infrastruttura ABPS che abbiamo visto mancare nella pre-cedente implementazione.
L’obiettivo della mia tesi `e stato dunque:
• aggiugere il supporto al proxy esterno descritto nel capitolo 2.
• permettere al nodo mobile di poter contattare con una INVITE il correspondent node.
• una volta aggiunto il Back-to-back user agent, aggiungere la gestione dei keep-alive tra proxy locale e proxy esterno in modo da poter bucare eventuali firewall o sistemi NAT tenendo attiva la comunicazione .
• relativamente all’instaurare un dialogo con un UA esterno senza esserci registrati, capire se `e necessario o no usare una seconda porta sui due proxy.
6.2.1
Proxy esterno di ABPS
La parte di proxy esterno dovr`a essere in grado di accettare pi`u di un utente che voglia utilizzare ABPS mentre `e in mobilit`a e dovr`a far comparire se stesso nei messaggi SIP in uscita sulla rete esterna rimanendo trasparente ai client mobili.
Fig.12 La figura mostra il comportamento trasparente che dovrebbe avere il proxy esterno. Al Correspondent Node deve sembrare di comunicare con il
proxy esterno, mentre al nodo mobile di comunicare con il proxy locale.
6.2.2
Da dove proviene l’INVITE e a chi inoltrarla
Il problema di poter fare un INVITE senza che lo UAC si sia preceden-temente registrato `e stato uno dei principali obiettivi di questa tesi. Questo perch´e se i proxy inizialmente non vengono attraversati dalla REGISTER dell’ UAC mobile sucessivamente, sulla ricezione di una richiesta di INVITE, si troveranno a dover gestire un messaggio di cui non hanno alcuna informa-zione sugli utenti interessati.
Abbiamo visto nel capitolo precedente che quando i proxy vengono attraver-sati dalla richiesta di REGISTER del nodo interno, conservano l’username del mittente nella struttura src info. La lista di src info su un proxy come abbiamo detto mantiene tutti gli username passati attraverso lui.
Nel caso in cui l’utente sul nodo mobile si registra, il suo usename verr`a cat-turato dai due proxy lungo la rotta.
Quando si presenta in ingresso una richiesta di INVITE questa pu`o prove-nire o dall’esterno, e cio`e dal proxy server del dominio su cui `e registrato un’ utente che ci sta contattando, oppure dall’interno, e cio`e dal client VoIP sul nodo mobile che sta contattando un host esterno. In entrambi i casi se
`e stata effettuata la richiesta di REGISTER sar`a presente all’interno della lista di src info lo username del destinatario, nel primo caso, o mittente nel secondo. Quindi i proxy sono in grado di capire da dove proviene facendo una ricerca per username nella lista di src info.
Dunque se la ricerca dello username del mittente presente nel campo msg info.from della stuttura pjsip rx data va a buon fine, il proxy pu`o concludere con cer-tezza che la richiesta di INVITE proviene dall’interno, cio`e dallo UA mobile del nostro scenario e quindi pu`o inoltrarla all’esterno, cio`e al Proxy server del dominio dell’utente mittente. Se invece la ricerca dello username del de-stinatario presente nel campo msg info.to della struttura pjsip rx data va a buona fine, il proxy pu`o concludere con certezza che la richiesta di INVITE proviene dall’esterno, e pu`o inoltrarla all’interno verso l’UA mobile.
Quindi il comportamento dei due proxy sar`a il seguente:
• Se la INVITE viene ricevuta dall’outbound proxy, cio`e il proxy esterno, allora:
– se proviene dal proxy sul nodo mobile, lo inoltra verso il Registrar su cui `e iscritto l’utente e specificato nel campo ...
– se proviene dallo UA esterno allora lo inoltra al proxy sul no-do mobile usanno-do l’informazione memorizzata durante la fase di registrazione.
• Se l’INVITE viene ricevuta dal proxy locale, cio`e dal proxy sul nodo mobile, allora:
– se proviene dallo UA interno, lo inoltra all’outbound proxy utiliz-zando l’indirizzo e la porta specificati
– se proviene dallo UA esterno e quindi dall’outbound proxy, lo inoltra allo UA locale.
I client VoIP in genere consento agli utenti di non registrarsi presso un Registrar al fine di evitare di essere visibili sulla rete e di essere contattati.
Nel nostro scenario in cui sono presenti i due proxy di ABPS `e necessario prevedere questo caso in modo da renderlo compatibile con tutti i client in circolazione.
Progettazione
Sulla base degli obiettivi discussi, il mio compito, dunque, `e stato quello di aggiungere l’outbound proxy e tutte quelle funzionalit`a tra i due proxy discusse nello scenario.
7.1
Progettazione dell’outbound proxy
Come ho gi`a detto, la funzionalit`a dell’outbound proxy `e quella di Back-to-back user agent, in grado di creare un canale logico con il Proxy locale e mascherare il suo indirizzo inoltrando i messaggi SIP modificati in maniera tale che dall’esterno appai lui come entit`a SIP. Poich´e il proxy locale come abbiamo visto svolge gi`a la funzione di mascherare le informazioni del client VoIP inserendo se stesso nei messaggi SIP, ho deciso di riutilizzare l’imple-mentazione del pj relay senza apportare modifiche per la gestione delle entit`a SIP.
7.2
Implementazione dell’outbound proxy
La distinzione tra proxy interno e outbound viene fatta a seconda dei parametri passati. Al pj relay viene specificata la modalit`a di proxy interno specificando come parametri l’indirizzo del secondo pj relay con funzione di
outbound. Mentre il pj relay sar`a in modalit`a proxy server se non viene specificato l’indirizzo di un altro pj relay.
Quando il proxy interno riceve un messaggio dal client VoIP locale, lo inoltra all’outbound proxy specificato, mentre quando l’outbound proxy riceve un messaggio dal proxy sul nodo mobile, lo inoltra alla destinazione effettiva. La funzionalit`a dei due proxy, come vedremo, cambia solamente nella gestione dei messaggi di keep-alive.
Quindi come faceva gi`a il proxy interno, l’outbound proxy avr`a il seguente comportamento:
• sulla ricezione di una SIP Request, sostituir`a le informazioni dei campi Via e Contact inserendo se stesso.
• sulla ricezione di una SIP Response, sostituir`a le informazioni che fanno riferimento a lui presenti nel campo Via con l’indirizzo del proxy client. Mentre nel campo Contact rimane il suo indrizzo, poich´e le specifiche SIP dicono che l’indirizzo nel Contact sar`a quello a cui verrano inoltrati i pacchetti RTP/RTCP.
7.3
Progettazione del meccanismo di inoltro
della INVITE
Il problema di dove inoltrare una INVITE senza che l’utente sul nodo mobile sia prima passato attraverso i proxy tramite una REGISTER, pu`o essere affrontato analizzando le informazioni in possesso del proxy e del fatto che un nodo esterno non pu`o inviare una INVITE al nodo mobile se questo non si `e prima registrato.
Infatti l’outbound proxy, a monte della rotta che collega il nodo mobile col mondo esterno, non `e raggiungibile da nessuna richiesta esterna se il suo in-dirizzo non `e stato memorizzato sul Registrar tramite una REGISTER dal nodo mobile.
e To non sono presenti nella lista di src info pu`o provenire solamente dal-l’interno. Infatti se provenisse dall’esterno allora il nodo mobile si sarebbe dovuto registrare precedentemente per il motivo descritto prima. Infatti re-gistrandosi sarebbe passato per i due proxy che avrebbero fissato l’username nelle liste e sul registrar sarebbe stato salvato l’indirizzo IP pubblico dell’out-bound proxy. Dunque se sulla ricezione della INVITE Request i due proxy non vedono n´e mittente n´e destinatario nelle loro liste, possono concludere che certamente il messaggio proviene dal nodo mobile e che quindi va man-dato all’esterno.
Gli altri casi in cui `e presente almeno un’username From e/o To nei proxy possono essere trattati nel modo seguente:
• se `e presente l’username From nelle liste dei proxy allora significa che proviene dal nodo mobile e quindi va inoltrata all’esterno.
• se `e presente l’username To nelle liste dei proxy allora significa che proviene dall’esterno e quindi va inoltrata all’interno.
• il caso in cui sono presenti entrambi gli username al momento non `e gestito, poich´e ci si aspetta che sulla chiusura di un dialogo VoIP venga inoltrata una BYE. Il comportamento dei proxy sulla ricezione della BYE `e di eliminare le informazioni sulla chiamata in corso, identificato dal call-id, rimuovendo gli username coinvolti dalla lista di src info. Quindi su una seconda INVITE si ricomincerebbe da capo.
Diverso `e invece il comportamento in caso di una seconda INVITE (re-INVITE) a seguito di un cambio nei paramentri di comunicazione o dopo che la sessione `e stata interrotta per un guasto. In questo caso il proxy avrebbe entrambi gli username ma per come `e attualmente implementato non sarebbe in grado di decidere nulla a riguardo.
7.4
Implementazione dell’algoritmo di
inol-tro della INVITE
Possiamo scrivere lo pseudocodice dell’algoritmo di decisione sulla dire-zione della INVITE Request:
i f( m i t t e n t e non a p p a r t i e n e a l l a l i s t a s r c i n f o && d e s t i n a t a r i o non a p p a r t i e n e a l l a l i s t a s r c i n f o ) { i n o l t r a INVITE R eq ue s t v e r s o e s t e r n o ; } e l s e i f ( m i t t e n t e a p p a r t i e n e a l l a l i s t a s r c i n f o ) { i n o l t r a INVITE R eq ue s t v e r s o e s t e r n o ; } e l s e i f ( d e s t i n a t a r i o a p p a r t i e n e a l l a l i s t a s r c i n f o ) { i n o l t r a INVITE R eq e us t v e r s o i n t e r n o ; } e l s e{ non g e s t i t o ; }
La direzione viene stabilita nell’header Route leggendo il un campo nei dati ausiliari che il proxy scrive indicando la direzione. Prima dell’inoltro il proxy crea l’header Route in cui speciica l’indirizzo e porta del prossimo hop lungo la rotta.
7.5
Progettazione del supporto ai keep-alive
Nel nostro scenario mobile `e indispensabile trattare anche il caso di ritro-varsi in una rete protetta dai NAT o firewall e che impediscono utenti esterni di contattare il nodo dietro questi sistemi.
Come visto una tecnica di NAT e firewall traversal consiste nel forare il siste-ma di protezione comunicando con un host esterno e con indirizzo pubblico
il quale potr`a successivamente dialogare con l’host protetto.
Il nostro oubound proxy dell’infrastruttura ABPS ha anche questo scopo. Il meccanismo di keep-alive inoltre deve interessare solo i due proxy e solo lungo la rotta dei messaggi SIP. Questo perch´e le comunicazioni RTP/RTCP avvengono su due canali distinti da quello SIP per i quali non `e strettamente necessario mantenere le porte attive poich´e in genere i client VoIP generano un flusso costante di messaggi anche nel caso in cui i due interlocutori smetto-no di parlare. Mentre `e necessario mantenere aperte le porte per il passaggio dei messaggi SIP in quanto dopo l’avvio dello streming sulle porte SIP pu`o non venire trasmesso pi`u nulla per molto tempo. Questo causa un problema nel momento in cui l’UA esterno voglia fare una richiesta di re-INVITE o di BYE poich´e il suo messaggio verrebbe scartato dal NAT o firewall.
7.6
Implementazione del supporto ai
keep-alive
Il meccanismo prevede l’attivazione della trasmissione di datagram UDP vuoti nel momento in cui viene instaurata una comunicazione dopo la rice-zione di una INVITE Response. Il comportamento dei due proxy `e differente ed `e il seguente:
• proxy locale: trasmette i keep-alive verso il proxy server pubblicco cos`ı che possa ricevere le trasmissioni da lui;
• proxy esterno: trasmette i keep-alive verso il proxy locale del nodo mo-bile cos`ı che in caso in cui il proxy sul nodo momo-bile si dovesse disconttere dalla rete per un certo periodo di tempo, il proxy fisso continua a tenere il canale SIP aperto sul sistema NAT o firewall.
L’implementazione prevede anche un numero massimo di trasmissioni di keep-alive quando non `e pi`u attiva la sessione a seguito di un guasto e che
mai pi`u si riattiver`a. Pu`o succedere, infatti, che una sessione si disattivi involontariamente poco prima che un utente abbia fatto BYE e che quindi non venga pi`u riattivata da nessuno degli interlocutori. In questo caso i due proxy credendo che lo stream RTP/RTCP sia ancora attivo continuano con il loro indefinito scambio di keep-alive.
L’algoritmo di inoltro dei keep-alive, dunque, prevede di trasmettere il pros-simo keep-alive se si sta ascoltando del traffico RTP/RTCP in ingresso o in uscita. Dal momento in cui non `e pi`u presente del traffico, l’algoritmo conta il numero di keep-alive trasmessi senza che ci sia in sottofondo lo stream RTP/RTCP. Quando raggiunge un numero massimo di trasmissioni decide che i due utenti si sono disconnessi in modo anomalo e quindi smette di trasmettere.
Valutazione
Il test che ho condotto e riportato in questo capitolo riguarda il nostro scenario di interesse.
Ho, dunque, eseguito un pjsua e il pj relay locale su una macchina connessa a una rete privata e protetta da un sistema NAT. L’outbound proxy, invece, l’ho lanciato su una macchina del laboratorio Ercolani con indirizzo 130.136.4.240, quindi su una rete pubblica. Mentre il secondo pjsua su una macchina sempre del laboratorio, con indirizzo 130.136.4.230. Di seguito ho riportato gli header SIP che mostrano come variano i campi prima e dopo il passaggio attraverso i proxy.
Nel test riportato il nodo mobile non ha eseguito la REGISTER cos`ı che possa essere verificato il corretto funzionamento dell’algoritmo di decisione della rotta e allo stesso tempo il comportamento dell’outbound proxy secondo le specifiche di ABPS.
8.1
Proxy locale
Questa `e la richiesta di INVITE ricevuta dal proxy locale. Si nota come il Via e il Contact facciano riferimento al client pjsua.
Questa `e la richiesta di INVITE dopo la modifica da parte del proxy locale. Si nota come il proxy ha modificato l’header Via inserendo se stesso in modo da poter ricevere la Response in seguito.
La Response INVITE che riceve il proxy interno presenta nell’header Via il riferimento a lui, mentre nell’header Contact il riferimento all’utente che si vuol contattare.
In uscita la Response INVITE si presenta con un Via che contiene il riferi-mento al pjsua e il Contact con il rifeririferi-mento a se stesso, in modo da ricevere il flusso RTP/RTCP.
8.2
Outbound proxy
In ingresso al proxy esterno la richiesta di INVITE si presenta, con un header Via che contiene l’indirizzo pubblico con cui esce la rete privata. Mentre nel Contact `e presente il riferimento al pjsua mobile.
In uscite la richiesta di INVITE presenta negli header Via e Contact il rife-rimento a se stesso. Aver il riferife-rimento al proxy esterno nell’header Contact vuol dire specificare al pjsua esterno che si vuole il traffico RTP/RTCP su questo proxy, come volevamo ottenere.
Per quando riguarda la Response INVITE notiamo che il campo Via presen-ta il riferimento a se stesso, mentre il campo Conpresen-tact il riferimento al pjsua esterno.
Infine in uscita dal proxy esterno la INVITE Response si presenter`a con il Via che fa riferimento al pjsua mobile e il Contact che fa riferimento a se stesso in modo che il proxy mobile inoltri a lui lo stream RTP/RTCP.
Conclusioni e sviluppi futuri
9.1
Discussione sui risultati
Dai risultati che ho mostrato emerge che il comportamento ottenuto ri-specchia quello voluto solo in uno scenario di in cui il nodo mobile si muove all’interno di reti pubbliche.
Di fatti quello dai vari test condotti utilizzando il pjsua in una rete privata `e emerso che i pjsua non utilizzano i proxy per le trasmissioni RTP/RTCP no-nostante siano state specificate nei messaggi SDP gli indirizzi su cui inoltrare lo stream RTP/RTCP. Questo comportamento `e poco chiaro e si `e presentato anche con altri client VoIP.
Il comportamento descritto invece non si `e presentato con il pjsua in esecu-zione in una rete pubblica come quella del laboratorio Ercolani.
Prima di continuare con lo sviluppo dei proxy, sarebbe il caso di verificare il motivo del comportamento anomalo riscontrato nelle reti private.
9.2
Sviluppi futuri
Come ho gi`a accennato, l’algoritmo di decisione per la direzione della INVITE sarebbe da migliorare per supportare le re-INVITE.
Una soluzione potrebbe essere quella di aggiungere nella struttura src info l’informazione sulla posizione dell’utente rispetto al proxy, cio`e se interno o esterno.
Tramite questa informazione l’algoritmo quando verificher`a la presenza di entrambi gli user From e To, controller`a anche la posizione di questi in modo da capire in che direzione `e diretta la INVITE che ha appena ricevuto. Inoltre si consiglia di provare i due proxy insieme a client VoIP diversi da quelli della libreria PJSIP in moda da verificare l’affidabilit`a con software sviluppati da terzi e non strettamente connessi alla suite PJ.
Queste sono le conclusioni.
In queste conclusioni voglio fare un riferimento alla bibliografia: questo `e il mio riferimento [?, ?].
Appendice
A.1
pjsip rx data
s t r u c t p j s i p r x d a t a { /∗ ∗ ∗ t p i n f o i s p a r t o f r d a t a t h a t r e m a i n s s t a t i c f o r t h e d u r a t i o n o f t h e ∗ b u f f e r . I t i s i n i t i a l i z e d when t h e b u f f e r was c r e a t e d by t r a n s p o r t . ∗/ s t r u c t { /∗ ∗ Memory p o o l f o r t h i s b u f f e r . ∗/ p j p o o l t ∗ p o o l ; /∗ ∗ The t r a n s p o r t o b j e c t which r e c e i v e d t h i s p a c k e t . ∗/ p j s i p t r a n s p o r t ∗ t r a n s p o r t ; /∗ ∗ Other t r a n s p o r t s p e c i f i c d a t a t o be a t t a c h e d t o t h i s b u f f e r . ∗/ v o i d ∗ t p d a t a ; /∗ ∗ I o q u e u e key . ∗/ 63
p j s i p r x d a t a o p k e y o p k e y ; } t p i n f o ; /∗ ∗ ∗ p k t i n f o i s i n i t i a l i z e d by t r a n s p o r t when i t r e c e i v e s an i n c o m i n g ∗ p a c k e t . ∗/ s t r u c t {
/∗ ∗ Time when t h e message was r e c e i v e d . ∗/
p j t i m e v a l timestamp ;
/∗ ∗ P o i n t e r t o t h e o r i g i n a l p a c k e t . ∗/
c h a r p a c k e t [ PJSIP MAX PKT LEN ] ;
/∗ ∗ Z e r o t e r m i n a t i o n f o r t h e p a c k e t . ∗/
p j u i n t 3 2 t z e r o ;
/∗ ∗ The l e n g t h o f t h e p a c k e t r e c e i v e d . ∗/
p j s s i z e t l e n ;
/∗ ∗ The s o u r c e a d d r e s s from which t h e p a c k e t was r e c e i v e d . ∗/
p j s o c k a d d r s r c a d d r ; /∗ ∗ The l e n g t h o f t h e s o u r c e a d d r e s s . ∗/ i n t s r c a d d r l e n ; /∗ ∗ The IP s o u r c e a d d r e s s s t r i n g (NULL t e r m i n a t e d ) . ∗/ c h a r s r c n a m e [ PJ INET6 ADDRSTRLEN ] ; /∗ ∗ The IP s o u r c e p o r t number . ∗/ i n t s r c p o r t ; } p k t i n f o ;
/∗ ∗ ∗ m s g i n f o i s i n i t i a l i z e d by t r a n s p o r t mgr ( tpmgr ) b e f o r e t h i s b u f f e r ∗ i s p a s s e d t o e n d p o i n t . ∗/ s t r u c t { /∗ ∗ S t a r t o f msg b u f f e r . ∗/ c h a r ∗ msg buf ; /∗ ∗ Length f o message . ∗/ i n t l e n ;
/∗ ∗ The p a r s e d message , i f any . ∗/
p j s i p m s g ∗msg ;
/∗ ∗ S h o r t d e s c r i p t i o n about t h e message .
∗ A p p l i c a t i o n s h o u l d u s e #p j s i p r x d a t a g e t i n f o ( ) i n s t e a d . ∗/
c h a r ∗ i n f o ;
/∗ ∗ The C a l l −ID h e a d e r a s found i n t h e message . ∗/
p j s i p c i d h d r ∗ c i d ;
/∗ ∗ The From h e a d e r a s found i n t h e message . ∗/
p j s i p f r o m h d r ∗ from ;
/∗ ∗ The To h e a d e r a s found i n t h e message . ∗/
p j s i p t o h d r ∗ t o ;
/∗ ∗ The topmost Via h e a d e r a s found i n t h e message . ∗/
p j s i p v i a h d r ∗ v i a ;
/∗ ∗ The CSeq h e a d e r a s found i n t h e message . ∗/
p j s i p c s e q h d r ∗ c s e q ;
p j s i p m a x f w d h d r ∗ max fwd ; /∗ ∗ The f i r s t r o u t e h e a d e r . ∗/ p j s i p r o u t e h d r ∗ r o u t e ; /∗ ∗ The f i r s t r e c o r d −r o u t e h e a d e r . ∗/ p j s i p r r h d r ∗ r e c o r d r o u t e ; /∗ ∗ Content−t y p e h e a d e r . ∗/ p j s i p c t y p e h d r ∗ c t y p e ; /∗ ∗ Content−l e n g t h h e a d e r . ∗/ p j s i p c l e n h d r ∗ c l e n ; /∗ ∗ ” R e q u i r e ” h e a d e r c o n t a i n i n g a g g r e g a t e s o f a l l R e q u i r e ∗ h e a d e r s found i n t h e message , o r NULL .
∗/
p j s i p r e q u i r e h d r ∗ r e q u i r e ;
/∗ ∗ ” S u p p o r t e d ” h e a d e r c o n t a i n i n g a g g r e g a t e s o f a l l S u p p o r t e d ∗ h e a d e r s found i n t h e message , o r NULL .
∗/ p j s i p s u p p o r t e d h d r ∗ s u p p o r t e d ; /∗ ∗ The l i s t o f e r r o r g e n e r a t e d by t h e p a r s e r when p a r s i n g t h i s message . ∗/ p j s i p p a r s e r e r r r e p o r t p a r s e e r r ; } m s g i n f o ; /∗ ∗ ∗ e n d p t i n f o i s i n i t i a l i z e d by e n d p o i n t a f t e r t h i s b u f f e r r e a c h e s ∗ e n d p o i n t . ∗/ s t r u c t
{
/∗ ∗
∗ Data a t t a c h e d by modules t o t h i s message . ∗/
v o i d ∗ mod data [ PJSIP MAX MODULE ] ; } e n d p t i n f o ; /∗ VIC a u x i l i a r y i n f o u s e d by our p r o x i e s ∗/ s t r u c t { i n t d i r e c t i o n ; /∗ 0 unknown , −1 d a l l ’ e s t e r n o , 1 d a l l ’ i n t e r n o ∗/ } a u x i l i a r y p k t i n f o ; } ;
A.2
pjsip tx data
s t r u c t p j s i p t x d a t a {
/∗ ∗ T h i s i s f o r t r a n s m i s s i o n queue ; i t ’ s managed by t r a n s p o r t s . ∗/
PJ DECL LIST MEMBER(s t r u c t p j s i p t x d a t a ) ;
/∗ ∗ Memory p o o l f o r t h i s b u f f e r . ∗/
p j p o o l t ∗ p o o l ;
/∗ ∗ A name t o i d e n t i f y t h i s b u f f e r . ∗/
c h a r obj name [ PJ MAX OBJ NAME ] ;
/∗ ∗ S h o r t i n f o r m a t i o n d e s c r i b i n g t h i s b u f f e r and t h e message i n i t .
∗ A p p l i c a t i o n s h o u l d u s e #p j s i p t x d a t a g e t i n f o ( ) i n s t e a d o f
∗ d i r e c t l y a c c e s s i n g t h i s member . ∗/
c h a r ∗ i n f o ;
/∗ ∗ For r e s p o n s e message , t h i s c o n t a i n s t h e r e f e r e n c e t o timestamp when
∗ t h e o r i g i n a l r e q u e s t message was r e c e i v e d . The v a l u e o f t h i s f i e l d ∗ i s s e t when a p p l i c a t i o n c r e a t e s r e s p o n s e message t o a r e q u e s t by ∗ c a l l i n g #p j s i p e n d p t c r e a t e r e s p o n s e . ∗/ p j t i m e v a l r x t i m e s t a m p ; /∗ ∗ The t r a n s p o r t manager f o r t h i s b u f f e r . ∗/ p j s i p t p m g r ∗mgr ; /∗ ∗ I o q u e u e a s y n c h r o n o u s o p e r a t i o n key . ∗/ p j s i p t x d a t a o p k e y o p k e y ; /∗ ∗ Lock o b j e c t . ∗/ p j l o c k t ∗ l o c k ; /∗ ∗ The message i n t h i s b u f f e r . ∗/ p j s i p m s g ∗msg ; /∗ ∗ S t r i c t r o u t e h e a d e r s a v e d by #p j s i p p r o c e s s r o u t e s e t ( ) , t o be ∗ r e s t o r e d by #p j s i p r e s t o r e s t r i c t r o u t e s e t ( ) . ∗/ p j s i p r o u t e h d r ∗ s a v e d s t r i c t r o u t e ; /∗ ∗ B u f f e r t o t h e p r i n t e d t e x t r e p r e s e n t a t i o n o f t h e message . When t h e ∗ c o n t e n t o f t h i s b u f f e r i s s e t , t h e n t h e t r a n s p o r t w i l l s e n d t h e c o n t e n t ∗ o f t h i s b u f f e r i n s t e a d o f r e −p r i n t i n g t h e message s t r u c t u r e . I f t h e
∗ message s t r u c t u r e has changed , t h e n a p p l i c a t i o n must i n v a l i d a t e t h i s ∗ b u f f e r by c a l l i n g #p j s i p t x d a t a i n v a l i d a t e m s g . ∗/ p j s i p b u f f e r b u f ; /∗ ∗ R e f e r e n c e c o u n t e r . ∗/ p j a t o m i c t ∗ r e f c n t ; /∗ ∗ Being p r o c e s s e d by t r a n s p o r t ? ∗/ i n t i s p e n d i n g ; /∗ ∗ T r a n s p o r t manager i n t e r n a l . ∗/ v o i d ∗ t o k e n ;
/∗ ∗ C a l l b a c k t o be c a l l e d when t h i s t x d a t a has been t r a n s m i t t e d . ∗/ v o i d ( ∗ cb ) (v o i d∗ , p j s i p t x d a t a ∗ , p j s s i z e t ) ; /∗ ∗ D e s t i n a t i o n i n f o r m a t i o n , t o be u s e d t o d e t e r m i n e t h e network a d d r e s s ∗ o f t h e message . For a r e q u e s t , t h i s i n f o r m a t i o n i s i n i t i a l i z e d when ∗ t h e r e q u e s t i s s e n t w i t h # p j s i p e n d p t s e n d r e q u e s t s t a t e l e s s ( ) and
∗ network a d d r e s s i s r e s o l v e d . For CANCEL r e q u e s t , t h i s i n f o r m a t i o n
∗ w i l l be c o p i e d from t h e o r i g i n a l INVITE t o make s u r e t h a t t h e CANCEL ∗ r e q u e s t g o e s t o t h e same p h y s i c a l network a d d r e s s a s t h e INVITE ∗ r e q u e s t . ∗/ s t r u c t { /∗ ∗ S e r v e r name . ∗/ p j s t r t name ;
/∗ ∗ S e r v e r a d d r e s s e s r e s o l v e d . ∗/ p j s i p s e r v e r a d d r e s s e s addr ; /∗ ∗ C u r r e n t s e r v e r a d d r e s s b e i n g t r i e d . ∗/ u n s i g n e d c u r a d d r ; } d e s t i n f o ; /∗ ∗ T r a n s p o r t i n f o r m a t i o n , o n l y v a l i d d u r i n g o n t x r e q u e s t ( ) and ∗ o n t x r e s p o n s e ( ) c a l l b a c k . ∗/ s t r u c t { p j s i p t r a n s p o r t ∗ t r a n s p o r t ; /∗∗< T r a n s p o r t b e i n g u s e d . ∗/ p j s o c k a d d r d s t a d d r ; /∗∗< D e s t i n a t i o n a d d r e s s . ∗/ i n t d s t a d d r l e n ; /∗∗< Length o f a d d r e s s . ∗/
c h a r dst name [ PJ INET6 ADDRSTRLEN ] ; /∗∗< D e s t i n a t i o n a d d r e s s . ∗/ i n t d s t p o r t ; /∗∗< D e s t i n a t i o n p o r t . ∗/ } t p i n f o ; /∗ ∗ ∗ T r a n s p o r t s e l e c t o r , t o s p e c i f y which t r a n s p o r t t o be used .
∗ The v a l u e h e r e must be s e t with p j s i p t x d a t a s e t t r a n s p o r t ( ) , ∗ t o a l l o w r e f e r e n c e c o u n t e r t o be s e t p r o p e r l y . ∗/ p j s i p t p s e l e c t o r t p s e l ; /∗ ∗ ∗ S p e c i a l f l a g t o i n d i c a t e t h a t t h i s t r a n s m i t data i s a r e q u e s t t h a t has
∗ been updated with p r o p e r a u t h e n t i c a t i o n r e s p o n s e and i s r e a d y t o be ∗ s e n t f o r r e t r y . ∗/ p j b o o l t a u t h r e t r y ; /∗ ∗
∗ A r b i t r a r y data a t t a c h e d by PJSIP modules . ∗/
v o i d ∗ mod data [ PJSIP MAX MODULE ] ;
/∗ ∗ ∗ I f v i a a d d r i s s e t , i t w i l l be u s e d a s t h e ” s e n t −by ” f i e l d o f t h e ∗ Via h e a d e r f o r o u t g o i n g r e q u e s t s a s l o n g a s t h e r e q u e s t u s e s v i a t p ∗ t r a n s p o r t . Normally a p p l i c a t i o n s h o u l d not u s e o r a c c e s s t h e s e f i e l d s . ∗/ p j s i p h o s t p o r t v i a a d d r ; /∗∗< Via a d d r e s s . ∗/ c o n s t v o i d ∗ v i a t p ; /∗∗< Via t r a n s p o r t . ∗/ } ;
[1] T. Berners-Lee, R. Fielding, and L. Masinter. Rfc 3986, uniform resource identifier (uri): Generic syntax, 2005.
[2] V. Ghini, S. Ferretti, and F. Panzieri. always best packet switching for sip services. Pervasive Computing and Communications Workshops, IEEE International Conference on, 0:805–810, 2012.
[3] M. Handley, V. Jacobson, and C. Perkins. SDP: Session Description Protocol. RFC 4566 (Proposed Standard), July 2006.
[4] C. Huitema. Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). RFC 3605 (Proposed Standard), October 2003.
[5] D. Johnson, C. Perkins, and J. Arkko. Mobility support in ipv6. RFC 3775 (Proposed Standard), June 2004.
[6] Rolf Oppliger. Internet security: Firewalls and beyond. Commun. ACM, 40(5):92–102, May 1997.
[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. RFC 3261: SIP: Session Initiation Protocol. Technical report, IETF, 2002.
[8] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RFC 3550: RTP: A Transport Protocol for Real-Time Applications. Technical report, IETF, 2003.
Ringrazio i miei genitori che hanno permesso la mia formazione nelle discipline informatiche.
