Svolgiamo
alcuni esperimenti relativi al VoIP SIP. Per concentrarci sulla
segnalazione SIP e RTP, scegliamo di non utilizzare componenti di
autenticazione, né di sfruttare il supporto offerto dal DNS.
Presso il Wiki del progetto Sapientel, è stata stilata una tabella di comparazione dei softphone SIP disponibili in forma libera, e tra quelli, scegliamo di usare Twinkle,
che scarichiamo mediante Synaptics. La scelta di Twinke è dettata dalla
sua implementazione diretta degli standard, senza mascherarli troppo
dietro interfacce utente oltremodo semplificate. Inoltre, sembra
offrire caratteristiche interessanti, come la conferenza a tre,
svariate funzioni di controllo chiamata, confidenzialità del media, e
possibilità di eseguire degli script in corrispondenza alla ricezione
della chiamata.
Ora, possiamo provare a chiamare i nostri colleghi, con AoR labint@suonome.labint.
Se catturiamo il traffico, possiamo verificare come viene comunque
fatto il tentativo di interrogare il DNS, ma non trovando nessun RR di
tipo SRV, lo UA Twinkle rinuncia al tentativo di usare il Registrar
del dominio di destinazione, e procede ad inviare allo stesso la
chiamata in modo diretto. Per abbattere la chiamata, usiamo il tasto .
In questo caso (hold), viene eseguito un re-INVITE da parte di alice, nel cui nuovo SDP la sessione viene dichiarata sendonly, e che quando accettato da bruno, produce un SDP di risposta che dichiara (dal suo punto di vista) la sessione receiveonly. Lo sviluppo attuale di Twinkle non sembra (ancora) prevedere l'invio di una musica di attesa, però ci starebbe bene...
In questo caso alice, dopo aver chiamato bruno, decide di trasferire la chiamata verso sip:test@ing.uniroma1.it. In questo caso il capture svela deiparticolari interessanti: dopo aver messo, come al solito, brunoon hold, alice clicca sul trasferimento di chiamata, e sceglie di voler effettuare un blind transfer, indicando la nuova URI di destinazione: il risultato è che bruno riceve un REFER, che nella intestazione refer-to, indica la nuova URI. Lo UA di bruno risponde al REFER con un 202 Accepted, e dopo un pò, bruno
(l'umano) risponde affermativamente alla finestra di notifica che gli
propone il trasferimento, causando l'emissione di un INVITE verso la
nuova URI. Per alice, l'invio del REFER sottindente la sottoscrizione alle notifiche relative allo stato della nuova chiamata, ed infatti bruno inizia a tenere informata alice della evoluzione della nuova chiamata, per mezzo di messaggi NOTIFY, nel cui body sono contenute le risposte che bruno riceve per la nuova chiamata. Finché bruno non termina il dialogo con alice, con un BYE.
Nel caso ci si trovi a dover interagire con un IVR, può capitare di dover immettere dei toni da tastiera. In questo caso, il capture ci mostra come questocorrisponda ad inviare, nei pacchetti RTP, un diverso payload type, che contiene la rappresentazione letterale del tasto premuto.
notiamo innanzitutto che nella barra dei menù è presente la voce Telephony, in cui troviamo la voce SIP, che se selezionata, genera un rapporto riguardante il numero di messaggi SIP presenti, suddivisi per tipo;
invochiamo (ancora dal menù Telephony) l'opzione Voip Calls: osserviamo che sono individuate due distinte chiamate, la prima verso bruno e la seconda verso test, complete di istanti di inizio, e di durata. Proviamo a
selezionarle entrambe, e chiedere il grafico: ci viene mostrato un diagramma temporale in cui le chiamate sono separate mediante colori, ed i flussi RTP riassunti in un unico evento;
selezionarne una (ad es., la seconda) o entrambe, e richiedere il player. Ci viene data l'opportuntità di simulare un jitter buffer
della dimensione desiderata, in modo da poter verificare l'effetto (in
termini di pacchetti persi) al variare della sua dimensione.
Selezionando Decode ci appare una nuova
finestra che mostra la forma d'onda audio corrispondente nei due versi,
e selezionandone una (o più), ci viene data anche la possibilità di ascoltare
il segnale corrispondente. Eventualmente, è possibile modificare la
dimensione del jitter buffer, e valutare l'effetto risultante. Provare
ad esempio con un jitter buffer di 0, 1, o più msec.
ancora mediante il menù Telephony, scegliamo questa volta RTP, Show all streams, ed osserviamo che ne sono individuati 6, ossia due direzioni per tre comunicazioni, considerando come nuovo quello iniziato dopo il re-invito, dato che in quel caso sono presenti due Contributing Sources
scegliamo ora l'unico flusso contenente segnale, il quarto, e richiediamo Analyze: per ogni pacchetto, ci viene mostrato il ritardo rispetto al precedente, ed il calcolo del jitter corrispondente, ottenuto in accordo alla RFC 3550 eseguendo una media recursiva relativa agli scostamenti tra i ritardi dei pacchetti, ed il loro ritardo medio;
scegliendo ora Graph, possiamo apprezzare visualmente l'evoluzione del valore stimato per il jitter.
Proviamo ora, sempre con wireshark attivo, a chiamare un nostro collega, alla URI sip:suonome@sip.labint. In base alle intestazioni Server e UserAgent, determiniamo quali risposte ci vengono inviate dal Registrar, e quali dallo UA chiamato.
Il proxy SIP che possiamo scaricare con Synaptic, è OpenSER. Dopo averlo fatto, dobbiamo abilitarne il funzionamento, per cui editiamo un primo file di configurazione (sudo gedit/etc/default/openser), e modifichiamo una delle prime linee come
RUN_OPENSER=yes
e quindi possiamo lanciare OpenSER, con il consueto sudo service openser start, e controllare l'esito con il comando sudo service openser status. Nel caso non sia in esecuzione, proviamo a determinare perché.
Risoluzione problemi
Come sempre, è più probabile che ci sia qualcosa che non va piuttosto che vada, e di seguito sono riportate alcune dritte relative a problemi effettivamente incontrati.
Quando tutto è a posto, possiamo tornare a commentare le tre linee con
cui abbiamo attivato la modalità di debug, e lanciare di nuovo sudo /etc/init.d/openser start.
Dal TCP al VoIP, dal DNS all'Email alla crittografia, tutto ciò che accade
dietro le quinte di Internet, completo di cattura del traffico.
Scopri
come effettuare il download,
ricevere gli aggiornamenti,
e contribuire!
.
all'estrema destra del nome del profilo
