Tecnologie e servizi di rete/VoIP

Voice over IP (VoIP) è l'insieme delle tecnologie per trasportare le chiamate vocali, insieme ai dati multimediali, su reti IP.

Commutazione di circuito versus commutazione di pacchetto

Rete telefonica a commutazione di circuito

Nella rete telefonica tradizionale a commutazione di circuito (POTS), la voce è trasportata tramite l'allocazione di circuiti statici in cui la voce è campionata a un bit rate di 64 Kbps (secondo il teorema del campionamento). Utilizzando una tale rete ci sono alcune limitazioni:

• nessuna compressione: non avrebbe senso risparmiare dei bit poiché sono staticamente allocati 64 bit al secondo per ogni telefonata;
• per supportare la comunicazione multimediale o multicanale va allocato un numero intero di circuiti;
• nessuna soppressione dei silenzi: i campioni vocali vengono trasmessi anche durante le pause e i circuiti rimangono allocati;
• nessuna multiplazione statistica: non è possibile condividere dinamicamente della larghezza di banda tra più chiamate a seconda delle loro esigenze;
• è richiesta la procedura di segnalazione (tono di chiamata, tono di occupato, tono di inattività, ecc.) per l'allocazione dei circuiti.

Rete dati a commutazione di pacchetto

In una rete dati a commutazione di pacchetto (IP), la voce viene trasportata dinamicamente tramite i pacchetti, e ciò permette delle nuove funzionalità:

• migliore compressione per un numero di pacchetti più ridotto;
• comunicazione ad alta qualità: il bit rate non è più limitato a 64 Kbps;
• soppressione dei silenzi: non viene trasmesso alcun pacchetto durante le pause;
• multiplazione statistica: l'allocazione della larghezza di banda è flessibile;
• la procedura di segnalazione non alloca più delle risorse statiche;
• nomadicità: l'utente può essere raggiungibile attraverso lo stesso numero di telefono o lo stesso account quando si sposta.

Tuttavia viene introdotto un nuovo problema: le risorse non si possono veramente riservare in una rete a commutazione di pacchetto → è molto difficile garantire la qualità del servizio per le chiamate vocali perché i pacchetti potrebbero arrivare con dei ritardi oppure potrebbero andare persi:

• ritardi: sono stati definiti da ITU alcuni valori di riferimento per i ritardi end-to-end:
  • 0-150 ms: questo è accettabile per l'orecchio umano;
  • 150-400 ms: questo è accettabile solo per le chiamate inter-continentali;
  • > 400 ms: questo non è accettabile e nuoce alla conversazione;
• perdite: l'orecchio umano può tollerare senza problemi al più il 5% di pacchetti mancanti.

TCP o UDP?

I pacchetti UDP e TCP arrivano (teoricamente) al ricevitore nello stesso tempo; l'unica differenza è che il TCP deve attendere i pacchetti di acknowledge → l'UDP sarebbe la scelta più naturale. In realtà Skype spesso utilizza il TCP perché è più semplice passare attraverso NAT e firewall anche se qualche volta potrebbero verificarsi dei piccoli silenzi dovuti ai meccanismi delle finestre a scorrimento.

Migrazione dalla commutazione di circuito alla commutazione di pacchetto

La tradizionale rete a commutazione di circuito (POTS) può essere migrata ad una rete a commutazione di pacchetto basata su IP in modo graduale:

1. rete basata su Telephone over IP (ToIP): i terminali ai margini della rete funzionano ancora in un modo a commutazione di circuito, ma il backbone della rete è basato su IP ed effettua internamente la pacchettizzazione → poiché l'utilizzo di VoIP è nascosto all'utente i servizi multimediali aggiuntivi non sono disponibili all'utente finale.
   I nuovi operatori di telecomunicazioni possono creare le loro reti telefoniche come reti basate su ToIP → gli operatori di telecomunicazioni possono risparmiare denaro costruendo e mantenendo una singola infrastruttura integrata;
2. rete mista: alcuni terminali sono VoIP, altri sono ancora tradizionali;
3. rete IP: tutti i terminali sono VoIP, ma i servizi di rete intelligente (per es. numeri verdi) sono ancora tradizionali, perché funzionano così bene che gli operatori di rete sono restii ad ammodernarli;
4. rete solo IP: tutti i terminali sono VoIP e tutti i servizi di rete intelligente lavorano su IP.

Gateway

Il gateway è un apparato che consente di connettere una rete POTS con una rete IP. È composto da tre componenti:

• media gateway: è in grado di convertire i campioni vocali dalla rete POTS in pacchetti di dati alla rete IP e viceversa;
• signaling gateway: è in grado di convertire i toni di segnalazione dalla rete POTS in pacchetti di segnalazione alla rete IP e viceversa;
• gateway controller: è responsabile della supervisione e del monitoraggio dell'intero gateway, controllando la qualità del traffico, effettuando l'autorizzazione, effettuando l'autenticazione (per addebito), localizzando le destinazioni, e così via.

Il gateway controller da solo è anche utile nelle reti solo IP.

Fasi per la creazione di flussi VoIP

Al lato trasmettitore

Il trasmettitore deve effettuare i seguenti passi:

1. campionamento
2. codifica
3. pacchettizzazione
4. accodamento
5. trasmissione

Campionamento

Il campionamento consente di convertire la voce da un segnale analogico in campioni digitali. Il campionamento è caratterizzato dalla sensibilità (bit), dalla frequenza di campionamento (hertz = 1/s) e dal bit rate teorico (bit/s).

Codifica

Le tecniche di codifica consentono di ridurre il bit rate, ma potrebbero introdurre dei ritardi aggiuntivi dovuti agli algoritmi di codifica.

Le principali tecniche di codifica sono:

• codifica differenziale: ogni campione viene codificato in base alle differenze rispetto al campione precedente e al campione successivo;
• codifica pesata: durante una videochiamata la figura dell'interlocutore deve venire codificata a un bit rate maggiore rispetto all'ambiente circostante;
• codifica con perdita: alcune informazioni audio e video vengono rimosse in modo irreversibile (possibilmente la perdita di qualità non deve essere percepita dai sensi umani).

La complessità è una questione importante quando gli algoritmi di codifica devono essere eseguiti su terminali mobili (come sistemi embedded o dispositivi a bassa potenza non molto performanti). Inoltre alcuni servizi non supportano i dati codificati con una compressione con perdita: per esempio, un fax non supporta la perdita di qualità. Per questi motivi gli operatori di telecomunicazioni preferiscono comunque utilizzare il codec PCM64 con un bit rate costante di 64 Kbps: richiede meno energia per l'elaborazione ed è supportato anche dai fax e dagli altri servizi che utilizzano la rete telefonica.

La voce di chi parla, dopo essere uscita dall'altoparlante del ricevitore, potrebbe tornare indietro attraverso il microfono del ricevitore arrivando all'altoparlante del trasmettitore dopo un ritardo chiamato round trip delay che se significativo potrebbe disturbare chi parla → la cancellazione dell'eco è pensata per evitare che chi parla senta la propria voce.

Pacchettizzazione

Il ritardo di pacchettizzazione dipende dal numero di campioni inserito in ogni pacchetto, che è un compromesso tra ritardo ed efficienza:

• ritardo: se vengono messi troppi campioni in un singolo pacchetto, il pacchetto deve attendere l'ultimo campione prima di essere inviato → se vengono pacchettizzati insieme troppi campioni, il primo campione arriverà con un ritardo importante;
• efficienza: ogni pacchetto IP ha un overhead nella dimensione dovuto alle intestazioni → se vengono pacchettizzati insieme troppo pochi campioni, il bit rate aumenterà in modo significativo a causa dell'overhead delle intestazioni.

Possono essere previste delle tecniche di correzione degli errori basate sulla ridondanza: ogni pacchetto trasporta anche il campione precedente insieme al nuovo campione, così se il pacchetto precedente va perso sarà comunque possibile recuperarne il campione.

Accodamento

Quando il traffico in ingresso supera la capacità del canale in uscita, il router deve immagazzinare i pacchetti in attesa della trasmissione (buffering) → ciò aumenta il ritardo e il jitter. La gestione delle code a priorità affronta queste problematiche: Tecnologie e servizi di rete/Qualità del servizio.

Trasmissione

Al fine di ridurre i ritardi di trasmissione ci sono alcune soluzioni possibili:

• aumentare la larghezza di banda, ma i provider ADSL di solito sono più interessati ad aumentare solo la larghezza di banda in downstream;
• utilizzare il PPP interleaving, cioè suddividere una trama grande in diverse trame PPP più piccole, ma i provider non sempre implementano il PPP interleaving;
• evitare l'utilizzo di altre applicazioni (ad es. trasferimento dati) durante le chiamate vocali.

Al lato ricevitore

Il ricevitore deve effettuare i seguenti passi:

1. de-jitter: i moduli per il de-jitter devono riprodurre i pacchetti alla stessa velocità impiegata per generarli;
2. riordinamento: poiché è a commutazione di pacchetto la rete potrebbe consegnare dei pacchetti out-of-order → è necessario un modulo per il riordinamento;
3. decodifica: gli algoritmi per la decodifica devono implementare alcune tecniche:
   • i pacchetti mancanti vanno gestiti utilizzando delle tecniche di predizione, inserendo del rumore bianco o riproducendo i campioni dell'ultimo pacchetto ricevuto;
   • soppressione dei silenzi: il ricevitore introduce del rumore bianco durante le pause nella conversazione, perché i perfetti silenzi vengono percepiti dall'utente come malfunzionamenti della chiamata. È importante riuscire a interrompere immediatamente il rumore bianco non appena l'interlocutore riprende a parlare.

RTP

Real-time Transport Protocol (RTP) è utilizzato per trasportare i flussi VoIP su UDP.

Funzionalità

Trasmissione in multicast nativa

RTP permette la trasmissione in multicast anche su una rete che non supporta il multicast.
In realtà IP supporta multicast, ma il suo utilizzo richiede che il provider della rete configuri gli apparati di rete per creare un gruppo multicast per ogni flusso VoIP → RTP permette di inviare dati in multicast a livello applicazione in modo plug-and-play senza l'invervento del provider della rete.

Solo le funzionalità essenziali

RTP non specifica le funzionalità che si suppongono essere gestite dai livelli sottostanti, come la frammentazione dei pacchetti e il rilevamento degli errori di trasmissione (checksum).

Indipendenza dai formati di dati

RTP include solo il campo "Payload Type" per specificare il tipo di contenuto del pacchetto e il codec utilizzato, ma non specifica come codificare i dati e quali codec utilizzare (queste informazioni sono specificate separatamente dai documenti "Audio Video Profiles").
È impossibile associare un codice a ogni codec nel mondo → il trasmettitore e il ricevitore devono concordare sui codici da utilizzare per identificare i codec durante l'instaurazione della sessione, e tali codici sono validi solo nella sessione.

Trasporto di dati in tempo reale

Sono permessi pacchetti mancanti → i campi "Sequence Number" e "Timestamp" sono combinati per far ripartire la riproduzione audio/video all'istante di tempo giusto in caso di perdita dei pacchetti.

Differenziazione dei flussi

Una sessione multimediale ha bisogno di aprire una sessione RTP, quindi una connessione UDP, per ogni flusso multimediale (audio, video, lavagna, ecc.).

RTP Control Protocol (RTCP)

Effettua il monitoraggio e il controllo della connessione: la destinazione raccoglie alcune statistiche (informazioni su perdite, ritardi, ecc.) e le manda periodicamente alla sorgente in modo che quest'ultima possa ridurre o aumentare la qualità del flusso multimediale al fine di far funzionare il più possibile il servizio secondo le capacità correnti della rete. Per esempio, il ricevitore può capire che un certo codec ha un bit rate troppo elevato che non è supportato dalla rete, e perciò può passare a un codec avente un bit rate più basso.

Porte non standard

RTP non definisce delle porte standard → i pacchetti RTP sono difficili da rilevare per i firewall e per la qualità del servizio. Tuttavia alcune implementazioni utilizzano degli intervalli di porte statici, per evitare di aprire troppe porte sui firewall e per semplificare la marcatura per la qualità del servizio.

Trasmissione in multicast

Soluzioni tradizionali

• Host unicast.
• 
  Lato TX: $N-1$ flussi.
• 
  Lato RX: $N-1$ flussi.

• Host multicast.
• 
  Lato TX: 1 flusso.
• 
  Lato RX: $N-1$ flussi.

Le soluzioni tradizionali senza il mixer RTP richiedono sempre delle capacità di banda elevate per tutti gli host.

Mixer RTP

Il mixer RTP è un dispositivo in grado di manipolare i flussi RTP per le trasmissioni in multicast: per esempio, in una videoconferenza il mixer per ogni host prende i flussi provenienti dagli altri host e li mescola in un singolo flusso verso quell'host.

• Host unicast con mixer.
• 
  Lato TX: 1 flusso.
• 
  Lato RX: 1 flusso.

Ogni host trasmette e riceve un singolo flusso → il mixer è utile per risparmiare banda: anche un host con una bassa larghezza di banda può unirsi alla videoconferenza. Il mixer dovrebbe essere l'host avente la capacità di banda più elevata, in modo da poter ricevere tutti i flussi dagli altri host e trasmettere tutti i flussi agli altri host.

Intestazione RTP

L'intestazione RTP ha il seguente formato:

2	3	4	8	9	16	32
V	P	X	CC	M	Payload Type	Sequence Number
Timestamp
Synchronization source identifier (SSRC)
Contributing source identifier (CSRC) :::

dove i campi più significativi sono:

• campo CSRC Count (CC) (4 bit): specifica il numero di identificativi nel campo "CSRC";
• flag Marker (M) (1 bit): è usato per marcare il pacchetto come ad alta priorità o a bassa priorità per la qualità del servizio;
• campo Payload Type (PT) (7 bit): specifica il tipo di payload del pacchetto; generalmente contiene il codice corrispondente al codec utilizzato;
• campo Synchronization source identifier (SSRC) (32 bit): identifica il mixer RTP (il mixer M nell'esempio sottostante);
• campo Contributing source identifier (CSRC) (lunghezza variabile): identifica le sorgenti multiple che contribuiscono a un flusso multicast (le sorgenti S₁, S₂, S₃ nell'esempio sottostante).

Le voci dalle sorgenti S₁, S₂, S₃ vengono mescolate in un flusso verso la destinazione D.

H.323

H.323 è una suite di protocolli di segnalazione di livello applicazione standardizzata da ITU. È uno standard molto complesso perché eredita le logiche dagli operatori di telefonia.

Componenti di una rete H.323

Esempio di una rete H.323.

H.323 fu sviluppato originariamente per consentire la comunicazione (audio, video, lavagna condivisa...) tra host connessi ad una LAN aziendale e dispositivi remoti connessi alla tradizionale rete a commutazione di circuito (PSTN):

• gatekeeper: implementa il gateway controller, responsabile dell'autenticazione e della localizzazione degli utenti, di tenere traccia degli utenti registrati, ecc.;
• proxy gatekeeper: il client contatta il gatekeeper indirettamente attraverso il proxy gatekeeper → questo riduce gli sforzi per i dispositivi client a bassa potenza, ma non è obbligatorio;
• Multipoint Control Unit (MCU): implementa il mixer RTP;
• gateway: implementa il signaling gateway e il media gateway, traducendo i canali dati, i canali di controllo e le procedure di segnalazione tra la LAN e la PSTN, ed è visto come terminale H.323 nella LAN e come terminale telefonico nella PSTN.

Successivamente lo standard H.323 è stato esteso su una rete geografica (WAN), permettendo la comunicazione anche con utenti remoti tramite Internet.

La zona di un gatekeeper è costituita dall'insieme dei terminali che esso gestisce. Una zona può coinvolgere livelli di rete diversi, come più LAN separate da router.

Architettura protocollare di H.323

• 
  Pila protocollare di H.323.
• 
  Diagramma a blocchi di un terminale H.323.

La pila protocollare di H.323 è piuttosto complessa perché è composta da diversi protocolli:

• piano dati: consiste dei protocolli RTP e RTCP che stanno su UDP;
• piano di controllo: consiste dei protocolli che stanno su TCP/UDP per la segnalazione:
  • controllore RAS: permette a un terminale di scambiare messaggi di controllo con il gatekeeper:
    • messaggi di Registration: il terminale chiede al gatekeeper di unirsi ad una zona;
    • messaggi di Admission: il terminale chiede al gatekeeper di contattare un altro terminale;
    • messaggi di Status: il terminale dice al gatekeeper se è attivo;
    • messaggi di banda: il controller RAS notifica il gatekeeper sui cambiamenti nella banda, anche mentre è in corso la chiamata, cosicché il gatekeeper potrà negare nuove chiamate se il canale è sovraccarico;
  • controllore chiamate: permette a un terminale di scambiare messaggi di controllo direttamente con un altro terminale;
  • controllore H.245: permette a una coppia di terminali di concordarsi su parametri come i codec;
  • dati: permette a un terminale di inviare messaggi di controllo per la condivisione della scrivania o altri flussi di dati multimediali.

Alla fine il livello H.225 mette insieme tutti i messaggi: permette di creare una sorta di tunnel virtuale affidabile per l'invio di messaggi H.323 sulla inaffidabile rete IP emulando l'affidabilità di un circuito.

Indirizzamento

Ogni terminale è identificato da una coppia (indirizzo IP, porta TCP/UDP), così può essere contattato direttamente attraverso la coppia indirizzo/porta senza la necessità di un gatekeeper.

Se c'è un gatekeeper, le coppie indirizzo/porta possono essere mappate in alias più facili da ricordare per gli utenti (per esempio name@domain.com, numero di telefono E-164, nickname). Poiché sono associati ad account utente, gli alias permettono la nomadicità: un utente continuerà ad essere raggiungibile anche se si sposta cambiando indirizzo IP.

Fasi principali di una chiamata H.323

Una chiamata H.323 avviene in sei fasi principali:

1. registrazione: il terminale chiamante cerca un gatekeeper entro la sua zona e apre un canale RAS usando il controllo RAS;
2. instaurazione della chiamata: il terminale chiamante instaura il canale verso il terminale chiamato usando il controllo di chiamata;
3. negoziazione: vengono negoziati parametri come la larghezza di banda e i codec usando il controllo H.245;
4. trasferimento dati: la voce è trasportata da RTP;
5. chiusura: viene chiuso il canale dati usando il controllo H.245;
6. abbattimento: viene chiuso il canale RAS usando il controllo RAS.

Il gatekeeper può giocare due ruoli:

• gatekeeper routed call: la chiamata passa sempre attraverso il gatekeeper → questo può essere utile per il NAT traversal: il gatekeeper agisce come un server relay;
• gatekeeper direct endpoint: la chiamata va direttamente al punto di arrivo, ma prima i client chiamante e chiamato devono effettuare la fase di Admission con il gatekeeper a scopi di addebito e gestione della banda.

Principali problemi e critiche

• lo standard H.323 non fornisce alcuna assistenza per le tolleranze ai guasti perché prevede solo un singolo gatekeeper → i fornitori hanno sviluppato le proprie personalizzazioni, che sono incompatibili tra di loro, per fornire questa funzionalità;
• lo standard H.323 non fornisce alcun supporto per la comunicazione tra zone diverse → un'azienda non può "unire" la sua zona con quella di un'altra azienda;
• i messaggi sono codificati usando il formato ASN.1: non è testuale, perciò il debug è molto difficile ed è necessario avere a che fare con dettagli di basso livello delle macchine (per es. little-endian);
• la pila protocollare è costituita da molti protocolli, uno per ogni funzionalità.

SIP

Session Initiation Protocol (SIP) è un protocollo di segnalazione di livello applicazione standardizzato da IETF tramite un RFC. Oggi SIP sta crescendo molto più velocemente di H.323, principalmente grazie al suo approccio di seguire la filosofia di Internet ("keep it simple"): per esempio, usa un approccio basato sul testo (come HTTP), così la codifica è facile da capire. L'interazione è client-server.

Funzionalità

Pila protocollare di SIP.

La pila protocollare di SIP è più semplice di quella di H.323 perché SIP è un livello comune nel piano di controllo. SIP copre solo la segnalazione: affida gli aspetti non correlati alla segnalazione, come la gestione della larghezza di banda, ad altri protocolli già esistenti, riducendo la complessità della sua progettazione:

• RTP/RTCP: viene usato per trasmettere e controllare un flusso multimediale;
• SDP: viene usato per notificare delle informazioni di controllo sui flussi multimediali;
• RTSP (Real Time Streaming Protocol): è un protocollo simile a RTP utilizzato per gestire sia i flussi in tempo reale sia altri tipi di risorse (per es. l'avanzamento rapido di un messaggio vocale registrato per una segreteria telefonica);
• RSVP: viene usato per riservare risorse sulle reti IP, tentando di creare una sorta di rete a commutazione di circuito su una a commutazione di pacchetto.

SIP può operare su uno di tre possibili livelli di trasporto:

• UDP: non deve essere tenuta attiva una connessione TCP → adatto per dispositivi a bassa potenza;
• TCP: garantisce una maggiore affidabilità ed è utile per il NAT traversal e per attraversare i firewall;
• TLS (TCP con SSL): i messaggi sono criptati a scopo di sicurezza, ma viene perso il vantaggio dei messaggi testuali.

SIP fornisce alcuni servizi principali alle chiamate vocali:

• localizzazione dell'utente: definisce il terminale di destinazione da contattare per la chiamata;
• capacità dell'utente: definisce i mezzi (audio, video...) e i parametri (codec) da usare;
• disponibilità dell'utente: definisce se il chiamato vuole accettare la chiamata;
• instaurazione della chiamata: stabilisce una connessione con tutti i suoi parametri;
• gestione della chiamata.

La segnalazione SIP può essere usata per diversi servizi aggiuntivi oltre alle chiamate vocali: e-presence (lo stato dell'utente: disponibile, occupato, ecc.), messaggistica istantanea, condivisione di una lavagna, trasferimento di file, giochi interattivi e così via. SIP supporta la nomadicità: a ogni utente è associato un account, così continuerà ad essere raggiungibile anche se si sposta cambiando indirizzo IP.

Componenti di una rete SIP

• Terminale: ogni host deve essere sia client sia server (server per essere raggiungibile).
• Registrar server: è responsabile di tenere traccia delle mappature tra gli host e gli indirizzi IP.

Implementa il gatekeeper: un host deve registrarsi per entrare in una rete SIP.

• Proxy server: gestisce lo scambio di messaggi tra gli host e gli altri server.

Un host potrebbe decidere di parlare solo con il proxy server, delegando ad esso tutte le operazioni richieste per le chiamate SIP.

• Redirect server: è utilizzato per reindirizzare le chiamate in arrivo (per es. un utente vuole essere raggiungibile sul suo cellulare di lavoro solo durante le ore lavorative).
• Media server: è utilizzato per archiviare dei contenuti a valore aggiunto (ad es. segreteria telefonica).
• Media proxy: può essere utilizzato come server relay per attraversare i firewall.
• Location server: è utilizzato per localizzare gli utenti.

Quando un host vuole fare una telefonata chiede al location server di trovare l'indirizzo dell'utente di destinazione.

• AAA server (Authentication, Authorization, Accounting): il registrar server scambia messaggi con l'AAA server per verificare gli utenti (per es. se l'utente è autorizzato a entrare nella rete).
• Gateway: connette la rete IP alla rete PSTN, traducendo i pacchetti SIP in campioni e viceversa.
• Multipoint Control Unit (MCU): implementa il mixer RTP, con le stesse funzionalità come in H.323.

In molti casi una singola macchina, chiamata server SIP (o SIP proxy), implementa le funzionalità di registrar server, proxy server, redirect server, media proxy. Inoltre, il location server di solito è localizzato nel server DNS, e l'AAA server di solito è localizzato nel server AAA aziendale.

Accounting e domini

Ogni utente ha un account SIP, così continuerà ad essere raggiungibile anche se si sposta cambiando indirizzo IP (nomadicità). Gli indirizzi degli account sono nella forma nome_utente@dominio.com; anche i terminali telefonici possono avere degli indirizzi SIP nella forma numero_di_telefono@gateway.

Una rete SIP ha una architettura distribuita: ogni server SIP è responsabile di un dominio SIP (l'equivalente della zona H.323), e tutti gli host che fanno riferimento allo stesso server SIP appartengono allo stesso dominio SIP e hanno lo stesso nome di dominio negli indirizzi di account. A differenza di H.323, un utente può contattare un utente appartenente a un altro dominio SIP: il suo server SIP sarà responsabile di contattare il server SIP dell'altro utente.

Si supponga che un utente americano appartenente al dominio Verizon si sposti in Italia e si colleghi alla rete di Telecom Italia. Per continuare ad essere raggiungibile ha bisogno di contattare il server SIP di Verizon per registrarsi, ma sta usando l'infrastruttura di rete di Telecom Italia → ha bisogno di passare attraverso il server SIP di Telecom Italia SIP server, che è il suo outbound proxy server, come un servizio di tipo roaming, e in questo modo Telecom Italia può tenere traccia delle chiamate dell'utente a scopi di addebito.

Interconnessione di domini

Per interconnettere i domini, è necessario che tutti i registrar server possano essere trovati, poiché essi memorizzano le mappature tra gli alias degli account e gli indirizzi IP → sono necessari due record aggiuntivi nei server DNS per localizzare i registrar server:

• record NAPTR: definisce quale protocollo di trasporto può essere usato per il dominio specificato, specificando l'alias da utilizzare per la query SRV;
• record SRV: specifica l'alias, da utilizzare per la query A/AAAA, del registrar server e la porta per il protocollo di trasporto specificato;
• record A/AAAA: specifica l'indirizzo IPv4/IPv6 dell'alias del registrar server specificato.

La tabella dei record DNS può contenere più di un record SRV/NAPTR:

• più record NAPTR: sono disponibili più registrar server per il protocollo di trasporto specificato, e il campo "Preference" specifica la preferenza d'ordine;
• più record SRV: sono disponibili più protocolli di trasporto per il dominio specificato, e il campo "Priority" specifica la preferenza d'ordine (in ordine: TSL/TCP, TCP, UDP);

oppure può non contenere alcun record SRV/NAPTR:

• nessun record NAPTR: l'host si limita a provare delle query SRV (spesso UDP) e userà il protocollo di trasporto corrispondente alla prima reply SRV;
• nessun record SRV: l'indirizzo del server registrar deve essere configurato staticamente sull'host, e l'host userà la porta standard 5060.

Standard ENUM

Come digitare l'indirizzo di un account su un telefono tradizionale per contattare un utente SIP? Ogni account SIP è associato per impostazione predefinita a un numero di telefono chiamato indirizzo E.164:

1. l'utente digita il numero di telefono sul suo telefono tradizionale;
2. il gateway tra la rete POTS e la rete SIP converte il numero di telefono in un alias con il dominio fisso e164.arpa e interroga il DNS chiedendo se esistono dei record NAPTR:
   1. se vengono trovati dei record NAPTR dal server DNS, il numero di telefono è associato a un account SIP e la chiamata è inoltrata al proxy SIP di destinazione;
   2. se non viene trovato alcun record NAPTR dal server DNS, il numero di telefono corrisponde a un utente nella rete POTS.

Messaggi SIP

Ogni messaggio SIP ha il seguente formato testuale:

1. tipo di messaggio (una riga): specifica il tipo di messaggio;
2. intestazione SIP: contiene informazioni sul flusso multimediale;
3. riga vuota (comportamento come HTTP);
4. messaggio SDP (payload): contiene informazioni di controllo sul flusso multimediale.

Principali tipi di messaggio

Un messaggio SIP può essere di diversi tipi, tra cui:

• messaggio REGISTER: è usato per registrarsi a un dominio, e può essere inviato in multicast a tutti i registrar server;
• messaggio INVITE: è usato per instaurare una telefonata;
• messaggio ACK: è l'ultimo messaggio SIP subito prima dell'inizio del flusso RTP;
• messaggio BYE: è usato per chiudere una telefonata;
• messaggio CANCEL: è usato per annullare una richiesta in sospeso per l'instaurazione di una chiamata;
• messaggi SUBSCRIBE, NOTIFY, MESSAGE: sono usati per la e-presence e la messaggistica istantanea;
• messaggi con codice: includono:
  • 1xx = codici Provisional: si riferiscono a operazioni in corso (ad es. 100 Trying, 180 Ringing);
  • 2xx = codici Success: sono dei codici di successo (ad es. 200 OK);
  • 4xx = codici Client Error: sono dei codici di errore (ad es. 401 Unauthorized).

Principali campi nell'intestazione SIP

L'intestazione SIP può contenere diversi campi, tra cui:

• campo From: contiene l'indirizzo SIP del terminare che vorrebbe iniziare la chiamata;
• campo To: contiene l'indirizzo SIP del terminale che il terminale chiamante vorrebbe contattare;
• campo Contact: è usato dal server SIP per specificare l'indirizzo del terminale chiamato, che può essere utilizzato dal terminale chiamante per contattare direttamente il terminale chiamato;
• campo Via: è usato per tenere traccia di tutti i server SIP attraverso cui deve passare il messaggio (ad es. outbound proxy server);
• campo Record Routing: specifica se tutti i messaggi SIP devono passare per il proxy, utile per il NAT traversal;
• campo Subject: contiene l'oggetto della connessione SIP;
• campi Content-Type, Content-Length, Content-Encoding: specificano informazioni su tipo (in un formato di tipo MIME, ad es. SDP), lunghezza (in byte) e codifica del payload.

SDP

SDP (Session Description Protocol) è un protocollo basato su testo per descrivere le sessioni multimediali: numero di flussi multimediali, tipo di media (audio, video, ecc.), codec, protocollo di trasporto (ad es. RTP/UDP/IP), larghezza di banda, indirizzi e porte, tempi di inizio/fine di ogni flusso, identificazione della sorgente.

SDP viene incluso nel payload di un pacchetto SIP per notificare le informazioni di controllo sul flusso multimediale (per es. il messaggio SIP che trasporta un messaggio di invito a una chiamata telefonica ha anche bisogno di notificare quale codec utilizzare). Siccome SDP è stato progettato un po' di tempo fa, ha alcune funzionalità (come i tempi di inizio/fine di ogni flusso) che sono inutili per SIP, ma SDP è stato semplicemente adottato da SIP senza alcun cambiamento per riutilizzare il software esistente.

Formato dei messaggi SDP

Ogni messaggio SDP è composto da una sezione di sessione e una o più sessioni media (una per ogni flusso multimediale):

• sezione di sessione: iniziante con una riga v=, include i parametri per tutti i flussi multimediali nella sessione corrente;
• sezione media: iniziante con una riga m=, include i parametri per il flusso multimediale corrente.

Fasi di una chiamata SIP

Una chiamata SIP avviene in 4 fasi:

1. registrazione: il terminale chiamante si registra a un dominio;
2. invito: il terminale chiamante chiede di instaurare una chiamata;
3. trasferimento dati: la voce è trasportata da RTP;
4. abbattimento: la chiamata viene chiusa.

Fase di registrazione

L'user agent A vuole registrarsi al dominio A contattandone il proxy SIP:

• 1. 2. query e reply DNS (NAPTR, SRV, A/AAA): A chiede al server DNS l'indirizzo IP del proxy SIP;
• 3. messaggio REGISTER: A chiede al proxy SIP di essere registrato, senza inserire la sua password qui;
• 4. messaggio 401 Unauthorized: il proxy SIP chiede l'autenticazione inserendo un challenge, che viene cambiato a ogni registrazione;
• 5. messaggio REGISTER: A calcola una funzione hash in base al challenge e alla password e invia la stringa risultante al proxy SIP;
• 6. messaggio 200 OK: il registrar server verifica la risposta al challenge e garantisce l'accesso all'utente.

Fase di invito

L'user agent A vuole instaurare una chiamata con l'user agent B attraverso il proxy SIP di B:

• 1. A chiede al suo proxy SIP di contattare B inviando ad esso un messaggio INVITE;
• 2. 3. il proxy SIP di A effettua le query DNS per trovare l'indirizzo IP del proxy SIP di B (NAPTR, SRV, A/AAA);
• 4. il proxy SIP di A invia un messaggio INVITE al proxy SIP di B.
• 5. il proxy SIP di B invia un messaggio INVITE a B;
• 6. 7. 8. B fa squillare il telefono di A inviando, attraverso i proxy SIP, un messaggio RINGING ad A;
• 9. 10. 11. B accetta la chiamata inviando, attraverso i proxy SIP, un messaggio OK ad A;
• 12. A, attraverso i proxy SIP oppure direttamente a seconda del valore del campo Record Routing, notifica B che ha ricevuto il messaggio OK.

Fase di abbattimento

Alla fine della chiamata, dopo aver chiuso il flusso RTP:

• 1. messaggio BYE: B notifica A che vuole chiudere la chiamata;
• 2. messaggio OK: A notifica B che ha ricevuto il messaggio BYE.