Gli UAs coinvolti gestiscono direttamente il Call Signaling senza l'intervento del SIP Proxy Server, come mostrato in figura 3.1.
![\includegraphics[scale=1]{fig/sip_call_direct}](img1.png)
Gli UAs coinvolti gestiscono il Call Signaling attraverso il SIP Proxy Server, come mostrato in figura 3.2.
![\includegraphics[scale=1]{fig/sip_call_routed}](img2.png)
L'evoluzione delle reti di telecomunicazione ha introdotto alcune importanti innovazioni nel campo della telefonia, non più relegata nelle reti a commutazione di circuito ma integrata con altri servizi nelle reti a commutazione di pacchetto. L'insieme delle tecnologie che descrivono la trasmissione digitale della voce nelle reti a commutazione di pacchetto (solitamente di tipo IP) viene identificato con VoIP, acronimo di ``Voice over IP''. Come nella telefonia tradizionale, la trasmissione della voce è gestita attraverso i messaggi di segnalazione. Esistono differenti protocolli, ciascuno definisce un tipo diverso di rete VoIP con caratteristiche proprie che non è direttamente compatibile con le altre. Queste possono comunque essere interconnesse fra loro mediante sistemi Gateway multiprotocollo. I protocolli di segnalazione più diffusi sono SIP, H.323 ed SCCP mentre i protocolli comuni di trasmissione della voce sono RTP/RTCP. Il passaggio dalla telefonia tradizionale al VoIP non è ancora stato completato ma è in corso anche in Italia, dove i principali operatori telefonici si sono già mossi da tempo assieme a nuove società e realtà OpenSource che intendono offrire servizi simili. Queste raggiungono l'utenza in modo diretto attraverso la rete Internet. Con l'introduzione del VoIP, si rende inoltre possibile l'implementazione di nuovi servizi come la comunicazione video e la mobilità del proprio identificativo, un username di livello applicativo che può essere utilizzato da qualsiasi punto della rete dopo la procedura di autenticazione.
Le reti telefoniche tradizionali sono a commutazione di circuito e sono state definite ed implementate per il trasporto della voce. Quando si intende avviare una comunicazione, gli switch interni della rete commutano per creare un circuito logico diretto tra sorgente e destinazione della chiamata. Per tutta la durata della comunicazione gli interlocutori dispongono di un canale dedicato non accessibile ad altri utenti, indipendentemente dal fatto che le parti siano coinvolte in una conversazione attiva oppure rimangano silenzio. Si ha così un'allocazione statica delle risorse di rete ed ogni circuito garantisce una larghezza di banda pari a 64 Kb/s in entrambi i sensi della comunicazione. L'allocazione statica delle risorse ed il circuito diretto tra le due parti permettono al segnale vocale di avere una qualità garantita per tutta la durata della comunicazione. Tuttavia, questo corrisponde ad avere una bassa percentuale di utilizzazione della rete. Infatti, durante una comunicazione vocale gli interlocutori assumono a turno il ruolo di trasmettitore mentre gli altri (solitamente) rimangono in silenzio, nel ruolo di ricevitore. La banda riservata viene quindi utilizzata per meno della metà del periodo della conversazione, comportando un grande spreco di risorse. Inoltre questo tipo di reti non è in grado di fornire con la dovuta rapidità e facilità le nuove funzionalità richieste nel settore delle telecomunicazioni: basandosi su un'infrastruttura centralizzata e proprietaria che fa generalmente capo ad un unico produttore, non consente lo sviluppo di nuovi servizi in tempi rapidi poiché tali funzionalità possono essere implementate solamente dallo stesso produttore dei dispositivi il quale, avendo molto spesso più clienti, non potrà rispondere con la dovuta celerità alla domanda di tali applicativi. La trasmissione dati è consentita ma l'infrastruttura, non sviluppata originariamente per fornire questa funzionalità, non è adatta, traducendosi in un ulteriore spreco di risorse. Alla luce del fatto che ormai il traffico dati ha superato il traffico voce, si può considerare la rete telefonica tradizionale ulteriormente inadeguata. Questi motivi portano a concludere che è necessario operare dei cambiamenti profondi nell'organizzazione dell'infrastruttura telefonica, al fine di far convergere su un unico tipo di rete le trasmissioni voce,video e dati.
Il VoIP identifica un insieme di tecnologie che hanno come scopo la trasmissione della voce e di altri tipi di informazioni multimediali attraverso le reti dati, solitamente di tipo IP. La rete IP è a commutazione di pacchetto: le informazioni vengono trasportate tramite unità minime di trasporto, i datagrammi IP. Questi sono in grado di essere instradati nella giusta direzione in base alle informazioni contenute negli stessi, senza richiedere la presenza di alcun canale logico preimpostato. Così facendo non si ha l'allocazione statica delle risorse, perciò su una linea di collegamento possono transitare contemporaneamente anche pacchetti appartenenti a flussi differenti, permettendo una gestione migliore delle risorse di rete. I pacchetti IP appartenenti ad uno stesso flusso possono essere instradati in modo differente fra sorgente e destinazione, non viene garantita la loro ricezione e possono giungere a destinazione in disordine. Inoltre, non viene fornito alcun tipo di QoS2.1. E' compito dei protocolli che utilizzano la rete di preoccuparsi di queste caratteristiche come meglio credono: limitando l'utilizzo della rete in qualche modo per implementare il Servizio di QoS, riordinando i pacchetti IP ricevuti e richiedendo la trasmissione di quelli persi. Per quanto riguarda il VoIP, la mancanza di una preallocazione statica della banda favorisce l'utilizzo di nuove tecniche al fine di ridurne l'utilizzo. Ad esempio, si possono impiegare algoritmi di codifica audio che permettono un utilizzo della banda pari a 5.3 Kb/s (ITU G.723.1) oppure a 8 Kb/s (ITU G.729) con un degrado accettabile della qualità audio percepita dall'utente, oppure algoritmi di soppressione del silenzio che permettono di sospendere la trasmissione dati se l'utente non ne produce, rimanendo in silenzio. Questo comporta una riduzione dell'utilizzo della banda superiore al 50% rispetto alla rete telefonica tradizionale. Si noti che la rete IP non richiede la fase di CallSetup presente invece nelle reti telefoniche tradizionali, utilizzata per instaurare il canale logico fra sorgente e destinazione. Questo si traduce in una più veloce instaurazione della chiamata. La convergenza delle trasmissioni voce,audio e dati su un unico tipo di rete consentono inoltre una riduzione dei costi di gestione e manutenzione dell'intera infrastruttura. Il VoIP viene utilizzato in modo differente a seconda del tipo di utente, possiamo identificare tre classi:
Il VoIP viene inteso come tecnologia utilizzata in modo diretto tra gli utenti senza l'intervento degli operatori telefonici tradizionali. Terze parti possono fornire ulteriori servizi come localizzazione, autenticazione ed interconnessione con la rete telefonica tradizionale ma la loro presenza non è strettamente necessaria. I benefici ricadono direttamente sull'utente e si traducono in una riduzione dei costi, consentendo anche la presenza di servizi aggiuntivi in modo dinamico ed indipendente dagli operatori telefonici. In questo ambito vengono maggiormente utilizzati il protocolli di segnalazione H.323 e SIP.
Il VoIP viene inteso come tecnologia utilizzata in modo diretto dagli operatori telefonici ed il suo utilizzo è spesso del tutto trasparente per gli utenti. I benefici ricadono direttamente sull'operatore telefonico e si traducono in una riduzione dei costi di manutenzione e gestione dell'infrastruttura di rete. Il VoIP viene solitamente introdotto seguendo una di queste modalità:
Il VoIP viene integrato con l'infrastruttura telefonica già esistente mediante l'utilizzo di Gateway che interconnettono i due tipi di rete. Il posizionamento di questi Gateway è critico: più sono vicini all'utente finale e più alto sarà il loro numero, con ricadute sui costi di gestione. La tendenza è di posizionare questi Gateway in una posizione tale da utilizzare la tecnologia VoIP soltanto tra le centrali telefoniche di grandi dimensioni. Questa soluzione è completamente trasparente per l'utente, che continua ad utilizzare lo stesso telefono senza alcun servizio aggiuntivo. In questo ambito viene maggiormente utilizzato il protocollo di segnalazione H.323.
Il VoIP viene trasportato direttamente dalla linea ADSL oppure mediante collegamento in fibra ottica. Questa soluzione impone una sostituzione del telefono tradizionale con un telefono VoIP, consentendo però anche l'implementazione di nuovi servizi. In questo ambito vengono maggiormente utilizzati i protocolli di segnalazione H.323 e SIP.
Il VoIP viene inteso come tecnologia utilizzata in modo diretto dalle aziende che lo utilizzano nelle comunicazioni interne, affidandosi solitamente ad un Gateway2.2 per raggiungere la rete telefonica tradizionale. I benefici ricadono direttamente sull'azienda e si traducono in una riduzione dei costi di gestione dell'infrastruttura di rete, prima separata per il trasporto di voce e dati. In questo ambito vengono utilizzati i protocolli di segnalazione H.323,SIP ed SCCP.
I protocolli di segnalazione utilizzati nel VoIP definiscono un insieme di procedure che forniscono almeno le seguenti funzionalità:
Permette di accedere alle informazioni di localizzazione degli utenti registrati.
Permette di notificare la propria presenza, fornendo la propria posizione nella rete.
Permette di richiedere,accettare oppure modificare una comunicazione.
Permette di concordare e rendere noti alle parti coinvolte nella comunicazione i parametri di trasmissione dei flussi multimedia.
Il protocollo di segnalazione SIP[11], acronimo di ``Session Initiation Protocol'', nasce in ambito IETF nel 1999 con la creazione del SIP Working Group in collaborazione con il MMUSIC Working Group. La proposta giunge dall'esperienza di MBone dove si erano implementati alcuni applicativi audio/video, i quali utilizzavano delle semplici primitive di segnalazione che sono state poi sviluppate ed ampliate. SIP nasce come alternativa ad H.323, protocollo di segnalazione precedentemente definito e proposto da ITU-T, ponendo a suo vantaggio la semplicità. E' un protocollo di segnalazione di livello applicativo che ha come obiettivo l'instaurazione, la modifica e la terminazione di una comunicazione audio,video oppure dati. Tra le caratteristiche peculiari di SIP vi è l'idea di distribuire l'intelligenza del network nei sistemi periferici quando possibile, ottenendo così un servizio scalabile. Viene utilizzato congiuntamente con altri protocolli sviluppati in ambito IETF come SDP per concordare i parametri di trasmissione dei flussi multimedia, RTP/RTCP come protocollo di trasporto dei flussi multimedia e RSVP per l'implementazione di una forma di QoS. Non specifica il tipo di rete sottostante ma viene solitamente trasportato da IP, utilizzando come protocolli di trasporto UDP e TCP. Esistono estensioni che permettono la cifratura del Signaling, le trasmissioni RTP/RTCP sono comunque non cifrate.
SIP utilizza lo schema di indirizzamento URI, definendo due differenti tipi di indirizzi:
Il più semplice ed il più diffuso nei network SIP, di default il protocollo di trasporto è UDP ma può essere utilizzato anche TCP. Sono possibili vari parametri attraverso i quali si possono fornire ulteriori informazioni sul contatto. La porta UDP e TCP di default è 5060 ma può essere cambiata, fornendone una differente nell'indirizzo. Possono essere presenti anche altri parametri, che descrivono ulteriormente le caratteristiche del contatto. Esempi:
Equivalente agli indirizzi sip, le informazioni vengono però trasportate con TLS[2], il Transport Security Layer. Esempi:
I componenti del network SIP sono molteplici e ciascuno assolve ad un particolare compito:
Indica qualsiasi device in grado di accettare oppure richiedere una comunicazione. Si compone di due entità logiche:
Inoltra le richieste verso il network SIP (richieste scatenate dall'utente).
Inoltra le risposte alle richieste provenienti dal network SIP.
Indica un particolare tipo di device che, quando riceve una richiesta SIP, la riformula e la ritrasmette come una nuova richiesta. Le risposte alla richiesta vengono quindi riformulate e ritrasmette nella direzione opposta. Permette di implementare il servizio Anonymizer e Application Layer Gateway (ALG).
Identificano un insieme di sistemi che accettano richieste SIP e sono in grado di rispondere. Un SIP Server non dovrebbe essere confuso con un UAS oppure con la natura Client/Server del protocollo, che descrive le operazioni in termini di Client (coloro che generano richieste) e Server (coloro che rispondono alle richieste). I SIP Server discussi in questa sezione sono entità logiche, le attuali implementazioni possono operare come un differente tipo di Server a seconda della situazione. Questi forniscono differenti servizi e funzionalità agli UAs, gestendo ciascuno soltanto un sottoinsieme di richieste. Devono supportare TCP,TLS ed UDP come protocollo di trasporto. Si noti che il protocollo utilizzato per interconnettere un Server con un servizio di localizzazione oppure un database non è definito in SIP. Le entità logiche definite sono:
Riceve le richieste SIP, ritrasmettendole ad altri componenti del network. Quando riceve le risposte, si occupa di trasmetterle nella direzione opposta. Viene utilizzato per implementare il servizio di Call Forwarding e di Autenticazione. I messaggi generati sono percepiti dall'UA di destinazione come trasmessi dal Proxy stesso che viene visto come un UA, piuttosto che da qualche applicazione nascosta dietro di esso. Esistono due tipi di Proxy:
Ciascuna richiesta SIP viene eseguita considerando unicamente il contenuto del singolo messaggio. Non vengono mantenute internamente informazioni sullo stato delle sessioni esistenti, richiedendo quindi meno risorse. Questo comporta un certo spreco delle risorse di rete e non permette l'implementazione di alcuni servizi come l'autenticazione.
Ciascuna richiesta SIP viene eseguita considerando le informazioni ottenute dalle richieste precedenti. Vengono mantenute internamente informazioni sullo stato delle sessioni esistenti, richiedendo quindi più risorse ma consentendo alcuni servizi aggiuntivi:
Il suo compito è fornire informazioni circa la localizzazione di ciascun utente registrato. Risponde alle richieste ma non le ritrasmette, ritornando direttamente una risposta contente l'indirizzo verso il quale ritrasmettere la richiesta. Si appoggia ad un Database oppure ad un Location Service per l'operazione di localizzazione dell'utente. L'informazione di localizzazione è trasmessa come messaggio di risposta di tipo 3xx (Redirect) che, dopo l'ulteriore ricezione del messaggio ACK, conclude la transazione.
Il suo compito è accettare oppure rifiutare l'ingresso di un UA nel network SIP. Accetta soltanto richieste SIP di tipo REGISTER, rispondendo altrimenti con il messaggio 501 not implemented. Le informazioni della registrazione vengono rese disponibili al Redirect Server. Nella richiesta di registrazione il campo dell'header To contiene il nome della risorsa che si sta registrando ed il campo dell'header Contact contiene una lista dei suoi indirizzi alternativi. Il Registration Server solitamente richiede all'UA di autenticarsi. Questo permette di avere un minimo di sicurezza riguardo l'identità dell'utente, garantendo l'identità del contatto. Una richiesta Register può essere utilizzata dall'UA per modificare le informazioni che lo riguardano, permettendogli di ricevere una lista di URI già registrate, quindi di eliminarne oppure aggiungerne.
Si occupa di interconnettere il network SIP con altri tipi di network come la rete telefonica tradizionale. Svolge quindi le funzioni di adattamento per il trasporto dei flussi multimedia e del Signaling.
La segnalazione SIP viene trasportata dai messaggi SIP. Questi hanno la stessa struttura dei messaggi definiti dal protocollo HTTP/1.1, utilizzano la codifica UTF-8[13] e vengono definiti mediante la notazione ABNF[1]. Si dividono in richieste (Request) e risposte (Response), vengono così definiti:
SIP-message = Request / Response
Request = Request-Line *( message-header ) CRLF [ message-body ]
Response = Status-Line *( message-header ) CRLF [ message-body ]I due tipi di messaggio sono molto simili e differiscono sintatticamente soltanto nella parte iniziale. A questa segue una sequenza di campi che compongono l'header. Infine, segue il corpo del messaggio che è opzionale e utilizzato principalmente soltanto durante l'instaurazione delle comunicazioni multimedia. Segue la discussione estesa di ciascun tipo di messaggio.
Questi messaggi vengono trasmessi al fine di richiedere l'esecuzione di una certa operazione. Sono così definiti:
Request = Request-Line *( message-header ) CRLF [ message-body ]
Request-Line = Method SP Request-URI SP SIP-Version CRLFDescrizione di Request-Line:
Indica il tipo di operazione richiesta.
Indica il destinatario (cioè chi dovrebbe processare l'operazione).
Indica la versione del protocollo SIP.
Richiede l'apertura di una sessione, chiamata anche Dialog. Nella richiesta INVITE è solitamente presente il corpo del messaggio, utilizzato per trasportare i messaggi di tipo SDP[3]. Questi contengono le informazioni necessarie per la ricezione di uno o più flussi multimedia. Il corpo del messaggio può però anche contenere informazioni di tipo differente che permettono di gestire ad esempio la crittografia. E' compito dell'UA che intende richiedere l'apertura di una sessione generare il campo header Call-Id ed il local-tag presente nel campo header From. Questi, assieme al remote-tag fornito dall'UA contattato nel campo header To, costituiscono l'identificativo univoco della sessione. Tutti i messaggi appartenenti a questa sessione dovranno avere questo identificativo. I campi header più importanti per questo tipo di richiesta sono: Call-ID, From, To, CSeq. Il valore del campo header CSeq in questo tipo di messaggio viene solitamente impostato a 1. Un INVITE trasmesso all'interno di una sessione già esistente è chiamato re-INVITE e permette di rinegoziare oppure modificare i parametri della sessione. Il CSeq viene incrementato per questo tipo di richiesta, che viene considerata un comando all'interno del Dialog. Se un re-INVITE viene rifiutato oppure fallisce in qualche modo, la sessione continua ad esistere con i parametri precedentemente concordati. Un re-INVITE non può essere trasmesso durante l'instaurazione della sessione. In questo caso, si deve utilizzare il metodo UPDATE.
Richiede la registrazione dell'UA presso un SIP Registration Server. Particolare importanza ha il campo header Contact, questo infatti contiene l'URI che si intende registrare e che verrà utilizzata per contattare l'UA. Il campo header Expires può essere utilizzato per imporre un periodo di validità della registrazione, che di default per le URI sip e sips è di 1 ora. Il CSeq viene incrementato per questo tipo di richiesta. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq, Expires. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato.
Richiede la terminazione di una sessione esistente. Una sessione è considerata esistente se ad un INVITE precedentemente trasmesso segue una risposta 2xx oppure quando, alla trasmissione del messaggio 200 OK, segue la ricezione di un messaggio ACK. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato.
Conferma l'avvenuta ricezione di una richiesta INVITE. Questo tipo di messaggi può contenere il corpo e viene solitamente utilizzato analogamente a quanto accade nelle richieste di tipo INVITE. I messaggi di tipo ACK non possono essere utilizzati per modificare i parametri della sessione che sono già stati trasmessi nel messaggio INVITE corrispondente, a tale scopo occorre utilizzare un messaggio di tipo re-INVITE come precedentemente discusso. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Richiede di cancellare l'esecuzione di una richiesta precedentemente trasmessa. Solitamente, viene utilizzato per interrompere una ricerca oppure un tentativo di chiamata. Può essere generato in seguito alla ricezione di una risposta 1xx, questa indica che la richiesta è stata ricevuta ma non ancora eseguita completamente. Questo tipo di richiesta ha senso soltanto quando si intende cancellare l'esecuzione di una richiesta INVITE, l'unica che può richiedere un certo tempo per l'esecuzione. Un UA può accettare la cancellazione dell'esecuzione della richiesta, rispondendo con un messaggio 200 OK seguito da un messaggio 487 Request Terminated. Se la richiesta CANCEL è stata trasmessa troppo tardi e l'operazione è stata ormai eseguita, l'UA può terminare la sessione (che ormai esiste) con una richiesta BYE. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Richiede le capacità di un UA. La risposta può contenere i campi header Allow, Accept, Accept-encoding, Accept-language, Supported. A questo tipo di richiesta si può rispondere con una risposta 200 OK nella quale tramite i campi header precedentemente citati verranno trasmesse le informazioni richieste. In caso di errore, l'UA è tenuto a rispondere con un messaggio 4xx oppure 6xx. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Richiede ad un altro UA di accedere all'URI specificata nel campo header Refer-To. Se l'URI è di tipo sip oppure sips, questo tipo di richiesta implementa il servizio Call Transfer. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq, Refer-To.
Richiede la sottoscrizione al fine di ricevere notifiche attraverso richieste di tipo NOTIFY circa un particolare evento. La sottoscrizione implica la creazione di una sessione, chiamata anche Dialog. Il messaggio contiene il campo header Expires, il quale indica il termine di validità della sottoscrizione. La sottoscrizione può essere rinnovata all'interno dello stesso Dialog prima della sua scadenza. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq, Expires.
Fornisce informazioni riguardo l'esistenza di un certo evento. Questo tipo di richieste viene trasmessa all'interno di un Dialog, precedentemente creato con la richiesta SUBSCRIBE. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Permette una forma di Instant Messaging (IM) testuale e rudimentale tra gli UAs. Il testo viene trasmesso nel corpo del messaggio. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Fornisce ulteriori informazioni riguardo il Call Signaling. Il valore del campo header CSeq in questo tipo di messaggio viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Conferma l'avvenuta ricezione di una risposta 1xx. Si noti che ACK può essere utilizzato soltanto per confermare la ricezione di risposte 2xx, 3xx, 4xx, 5xx e 6xx. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Richiede di modificare i parametri di una sessione in fase di creazione. Il valore del campo header CSeq in questo tipo di messaggio non viene incrementato. I campi header più importanti per questa richiesta sono: Call-ID, From, To, CSeq.
Questi messaggi vengono trasmessi al fine di rispondere ad un messaggio di richiesta. Sono così definiti:
Response = Status-Line *( message-header ) CRLF [ message-body ]
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLFDescrizione di Status-Line:
Indica la versione del protocollo SIP.
Identifica il tipo di risposta in modo univoco.
Descrive il tipo di risposta in modo testuale, fornendo eventualmente ulteriori informazioni utili per il debugging.
Indica lo stato di esecuzione della richiesta.
Indica che la richiesta è stata eseguita con successo.
Indica che la richiesta non è stata eseguita e viene suggerito un differente indirizzo dove trasmettere la richiesta.
Indica che la richiesta è fallita a causa di un errore da parte del client.
Indica che la richiesta è fallita a causa di un errore da parte del server.
Indica che la richiesta è fallita a causa di un errore da parte della rete SIP.
La classe di risposte 1xx viene utilizzata per indicare che la richiesta è stata ricevuta e si è ad un certo punto nella sua esecuzione. Un device può trasmettere un qualsiasi numero di risposte 1xx prima di trasmettere la risposta finale (2xx,3xx, 4xx, 5xx e 6xx). Solitamente, la prima risposta 1xx ricevuta dall'UA conferma la ricezione della richiesta INVITE e quindi ne termina la ritrasmissione. Per questa ragione i Server che trasmettono la risposta 100 Trying riducono il numero di ritrasmissioni di richieste INVITE, riducendo così anche l'utilizzo delle risorse di rete.
Informa l'UA che la richiesta è stata ricevuta correttamente e che la si sta processando.
Informa l'UA che la richiesta INVITE è stata ricevuta correttamente e che si sta allertando l'utente. Questo tipo di risposta è molto importante per l'interworking con la rete telefonica tradizionale.
Indica che la chiamata è stata trasferita ad un differente UA. Con questa viene implementato il servizio di Call Forwarding.
Indica che la chiamata è stata eseguita correttamente ed è stata inserita in una lista di attesa. La Reason-Phrase può essere utilizzata per fornire ulteriori informazioni, come il tempo di attesa stimato. Con questa viene implementato il servizio Call Center.
Indica lo stato della chiamata, stabilendo anche un Dialog. è particolarmente importante per l'interworking con la rete telefonica tradizionale, permettendo all'UA di ricevere l'audio di ringing, busy oppure un messaggio preregistrato. Questo perché nella rete telefonica tradizionale lo stato della chiamata è solitamente comunicato all'utente tramite segnali sonori trasmessi all'interno del circuito già esistente.
questa classe di risposte indica che l'operazione è stata eseguita con successo.
Indica che l'operazione è stata eseguita senza errori. Quando viene trasmesso questo tipo di risposta per accettare una richiesta INVITE, il corpo del messaggio può contenere un messaggio SDP contenente i parametri di ricezione dei flussi multimedia.
Indica che l'UA ha ricevuto e compreso la richiesta, ma che ancora non è stata eseguita per un qualche motivo.
Questa classe di risposte è utilizzata per reindirizzare l'operazione verso una differente destinazione. Viene utilizzata per implementare i servizi di Call Forwarding. Particolare attenzione deve essere tenuta per evitare situazioni di loop. A tale fine viene impiegato il campo header Via.
Indica che la localizzazione dell'URI richiesta ha ritornato più indirizzi. Il messaggio contiene campi header Contact, il loro ordine è significativo e dovrebbero essere tentati in sequenza dal primo all'ultimo.
Indica che l'URI richiesta è disponibile altrove, suggerendo nel campo header Contact una nuova URI da utilizzare permanentemente per questo contatto.
Indica che l'URI richiesta è al momento disponibile altrove, suggerendo nel campo header Contact una nuova URI da utilizzare temporaneamente per questo contatto. Può essere inoltre presente un campo header Expires che ne indica la durata di validità.
Indica l'URI di un SIP Proxy Server che ha l'autorizzazione necessaria per contattare l'UA. Il chiamante dovrebbe ritrasmettere la richiesta al SIP Proxy Server, il quale la ritrasmetterà all'UA. Con questo sistema viene implementato il servizio di Call Screening (filtering delle chiamate).
Indica che l'utente desidera essere contattato in modo differente, suggerendo come nel campo header Contact.
Questa classe di risposte è utilizzata dai client per indicare che la richiesta non può essere soddisfatta a causa di una condizione di errore interna. Segue un elenco di possibili valori:
Questa classe di risposte è utilizzata dai Server per indicare che la richiesta non può essere soddisfatta a causa di una condizione di errore interna. Segue un elenco di possibili valori:
Questa classe di risposte è utilizzata dai server per indicare che la richiesta non può essere soddisfatta a causa di una condizione di errore nella rete. Segue un elenco di possibili valori:
I campi Header seguono la prima linea Request-Line oppure Status-Line e sono così definiti:
Message-header = ``name'' HCOLON ``value''Descrizione:
Indica il nome del campo header.
Indica il valore del campo header.
è obbligatorio in tutti i messaggi SIP e viene utilizzato per identificare la sessione, assieme al localtag presente nel campo From ed al remotetag presente nel campo To. Il suo valore è una stringa case-sensitive. Il Call-ID è sempre creato dall'UA che inizia la procedura di chiamata e non viene mai modificato. La sua rappresentazione compatta è ``i''. Esempi:
è utilizzato per identificare chi ha generato la richiesta oppure la risposta, a seconda del tipo di messaggio. Per richieste e risposte future, si deve utilizzare questo contatto (rendendo in alcuni casi la comunicazione più diretta, con meno hop). Deve essere presente nelle richieste INVITE e nelle risposte 200 OK per questo motivo. La sua rappresentazione compatta è ``m''. Esempi:
Indica la dimensione in byte del corpo del messaggio. La sua rappresentazione compatta è ``l''. Esempi:
Indica il tipo di contenuto del corpo del messaggio, è un campo obbligatorio in presenza del corpo del messaggio.
Esempi:
Indica il Command Sequence number ed il metodo al quale si riferisce il comando. Questo permette di rilevare una sequenza errata di comandi oppure di riconoscere il comando al quale si riferisce la risposta. Si noti che entrambi gli UA coinvolti nella comunicazione gestiscono un proprio CSeq, quindi in una comunicazione abbiamo sempre due CSeq crescenti (locale e remoto). Esempi:
Indica il numero massimo di Proxy e Gateway attraverso i quali può essere inoltrato il messaggio. Viene impiegato per rilevare situazioni di loop e per implementare applicazioni simili a traceroute nelle reti IP. Esempi:
Indica l'URI di chi ha originato la richiesta. Può contenere anche il localtag, utilizzato per costruire l'identificatore del Dialog. La sua rappresentazione compatta è ``f''. Esempi:
Indica il soggetto della sessione. La sua rappresentazione compatta è ``s''. Esempi:
Indica l'URI alla quale è indirizzato il messaggio. Può contenere anche il remotetag, utilizzato per costruire l'identificatore del Dialog. La sua rappresentazione compatta è ``t''. Esempi:
Indica i nodi intermedi attraverso i quali è stato inoltrato il messaggio. Viene impiegato per procedure di debugging ed al fine di prevenire situazioni di loop. Esempi:
Il protocollo SDP[3], acronimo di ``Session Description Protocol'', nasce in ambito IETF nel 1998 con il MMUSIC Working Group (Multiparty Multimedia Session Control) e descrive il formato dei messaggi SDP, questi hanno il compito di annunciare e quindi rendere disponibili i parametri di trasmissione dei flussi multimedia, solitamente trasportati utilizzando i protocolli RTP/RTCP. SDP è stato originariamente sviluppato per le reti multicast e soltanto in seguito è stato introdotto per annunciare le trasmissioni unicast. Le informazioni trasportate da SDP sono le seguenti:
Il messaggio SDP utilizza la codifica UTF-8[13] ed è costituito da una sequenza di campi, ciascuno dei quali definito mediante la notazione ABNF[1]. La sintassi dei campi è la seguente:
t=vNon sono ammessi spazi prima e dopo il carattere ``='', t indica il tipo di campo ed è composto da un solo carattere mentre v ne indica il valore che è terminato dalla sequenza di caratteri speciali ``\n'' oppure ``\r\n''. L'ordine dei campi segue regole ben precise e predeterminate, questo semplifica la procedura di parsing e permette la rilevazione di possibili errori. Il messaggio si compone di tre sezioni, l'ultima di queste può ripetersi tante volte quante sono le trasmissioni che si intendono annunciare. Le sezioni sono presenti in questo ordine:
Vengono fornite informazioni relative all'intera sessione. Sono presenti i seguenti campi (* indica che il campo è opzionale), alcuni dei quali vengono descritti in modo esteso:
indica la versione SDP, 0 (l'unica versione definita).
Indica l'indirizzo verso il quale avviene la trasmissione se non diversamente specificato nelle sezioni Media description, solitamente viene specificato un indirizzo IPv4. Non viene qui specificata la porta UDP, presente invece nelle sezioni Media description.
Vengono fornite informazioni relative al tempo di inizio e fine della trasmissione. Sono presenti i seguenti campi (* indica che il campo è opzionale), alcuni dei quali vengono descritti in modo esteso:
Questo campo indica il tempo di inizio e fine della trasmissione.
Vengono fornite informazioni relative ai parametri di ciascuna trasmissione. Sono presenti i seguenti campi (* indica che il campo è opzionale), alcuni dei quali vengono descritti in modo esteso:
Descrive il tipo di dati e la codifica utilizzata. Viene inoltre specificata la porta UDP verso la quale avviene la trasmissione.
Indica l'indirizzo verso il quale avviene la trasmissione, solitamente viene specificato un indirizzo IPv4. Questo indirizzo, se presente, sostituisce quello annunciato nella sezione Section Description.
Indicano ulteriori attributi associati alla trasmissione. In particolare, l'attributo di nome rtpmap permette di mappare un certo valore del campo payload type presente nell'header fisso dei messaggi RTP con un determinato tipo di dati.
v=0
o=Michele 123456 654321 IN IP4 192.168.2.8
s=A conversation
c=IN IP4 192.168.2.8
t=0 0
m=audio 7078 RTP/AVP 0 111 110 3 8 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:111 speex/16000/1
a=rtpmap:110 speex/8000/1
a=rtpmap:3 GSM/8000/1
a=rtpmap:8 PCMA/8000/1
m=video 9078 RTP/AVP 97 98 99
a=rtpmap:97 theora/90000
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 MP4V-ES/90000In questo messaggio sono presenti una sezione Session description, seguita da una sezione Time description ed in fine due sezioni Media description. Vengono annunciate una trasmissione audio ed una trasmissione video.
I messaggi SDP vengono trasportati nei messaggi SIP come corpo del messaggio, in questo caso il campo header Content-Type avrà come valore ``application/sdp''. Solitamente è presente nelle richieste di tipo INVITE, ACK ed UPDATE oppure nelle risposte 200 OK. Alcuni campi nel messaggio SDP non hanno alcun senso ma devono comunque essere presenti per rispettare le regole imposte dal protocollo. In particolare, si utilizzano questi valori per i campi ``s'' e ``t'':
s=-
t= 0 0
Il network SIP di riferimento è descritto nella figura 3.3. Esistono due differenti modelli di segnalazione che differiscono in base al ruolo che il SIP Proxy Server ricopre nelle fasi che coinvolgono la comunicazione:
Gli UAs coinvolti gestiscono direttamente il Call Signaling senza l'intervento del SIP Proxy Server, come mostrato in figura 3.1.
Gli UAs coinvolti gestiscono il Call Signaling attraverso il SIP Proxy Server, come mostrato in figura 3.2.
Il network SIP di riferimento è descritto nella figura 3.3. In questo network SIP si è deciso di differenziare il modello di Call Signaling a seconda del tipo di chiamata. Se la chiamata è completamente interna oppure esterna, viene utilizzato il Direct Signaling, eventualmente assieme al SIP Registration/Redirect Server. Se la chiamata proviene oppure è diretta verso Internet, viene utilizzato il Proxy Routed Signaling. In questo secondo caso, il SIP Server agisce come un SIP Registration/Proxy Server.
Seguono due esempi.
La raccomandazione H.323[9] nasce in ambito ITU-T nel 1996 con la creazione dell'ITU-T Study Group 16 (SG16). Non definisce alcun protocollo ma descrive invece come un certo insieme di altre raccomandazioni e protocolli debbano collaborare per costituire un network H.323. Questi protocolli di segnalazione sono di livello applicativo ed hanno come obiettivo l'instaurazione, la modifica e la terminazione di una comunicazione multimedia. Le raccomandazioni più importanti sono:
Definisce le procedure di segnalazione per il controllo del terminale e della chiamata.
Definisce come avviene la comunicazione dei parametri di trasmissione dei flussi multimedia.
H.323 utilizza due differenti schemi di indirizzamento:
Il più semplice ed il più diffuso nei network H.323. Esempi:
Permette di associare un Alias al terminale, che deve essere univoco all'interno della zona (quindi verrà risolto in modo univoco dal Gatekeeper di riferimento per la zona). Esempi:
I componenti del network H.323 sono molteplici e ciascuno assolve ad un particolare compito:
Indica qualsiasi device in grado di accettare oppure richiedere una comunicazione. E' il nodo terminale di qualsiasi comunicazione e rappresenta l'interfaccia fra l'utente ed il network. Deve supportare almeno il codec audio definito nella raccomandazione G.711. In maniera opzionale, un terminale può supportare altri Codec audio definiti in altre raccomandazioni come G.723.1 e G.729. Il codec video è un componente opzionale in un terminale H.323. Se presente, deve essere in grado di codificare e decodificare un segnale video implementando almeno la raccomandazione H.261. Il canale dati è un elemento opzionale in un terminale H.323. Se presente, deve necessariamente trasmettere le informazioni seguendo le procedure definite nella raccomandazione T.120.
Sono sistemi che accettano richieste H.323 e sono in grado di rispondere, fornendo differenti servizi e funzionalità ai terminali. Ciascun Server è in grado di gestire soltanto un sottoinsieme di funzionalità:
Quando presente, regolamenta e limita l'acceso alle risorse del network H.323. Il controllo esercitato dal Gatekeeper consiste nel fornire oppure negare l'autorizzazione ai terminali controllati che intendono eseguire un qualche tipo di operazione nel network H.323. Le sue principali funzionalità sono le seguenti:
Permette la risoluzione degli indirizzi Alias H.323 ed E.164. Questa funzionalità è implementata mantenendo le informazioni riguardanti le registrazioni precedentemente effettuate in un qualche modo non definito da H.323. Un Gatekeeper, anche se generalmente opzionale, è invece assolutamente necessario se sono presenti dei Gateway Server che ad esempio interconnettono il network H.323 con reti ad esempio SIP.
Permette di limitare l'accesso al network H.323. Questa funzionalità viene implementata dal Gatekeeper con i messaggi ARQ,ACF e ARJ.
Permette di controllare l'utilizzo della capacità trasmissiva del network H.323 potendo così cercare di garantire la qualità del servizio. Questa funzionalità viene implementata dal Gatekeeper con i messaggi BRQ, BCF e BRJ. Per aumentare il controllo del Gatekeeper sull'utilizzo delle risorse utilizzate, può eventualmente gestire anche il Call Signaling. In questo modo potrà ottenere anche informazioni riguardo ciascun flusso multimedia.
Permette di gestire l'interconnessione tra più zone H.323.
Si occupa di gestire le conferenze multiutente. Il Multipoint Control Unit (MCU) è costituito da due componenti: Il Multipoint Controller (MC) ed il Multipoint Processor (MP). Mentre la presenza del primo è obbligatoria, il secondo è opzionale. Il Multipoint Controller (MC) si occupa di gestire i canali di controllo H.245, ricevendo e ritrasmettendo i flussi multimedia dei partecipanti. Il Multipoint Processor (MP) si occupa invece di elaborare i flussi multimedia, permettendone la ricodifica in un differente formato oppure unendoli. Questa funzionalità permette di adattare la trasmissione alle risorse di rete di ciascun terminale. Le tipologie di conferenza supportate da un sistema MCU sono quattro:
Il MCU riceve dai partecipanti il Signaling H.245 e i flussi multimedia, ritrasmettendoli.
Il MCU riceve dai partecipanti soltanto il Signaling H.245 mentre i flussi multimedia vengono trasmessi e ricevuti in modalità multicast direttamente tra i partecipanti.
I partecipanti comunicano sia in modo centralizzato che decentralizzato. Ad esempio, in una singola conferenza si può avere la trasmissione dei flussi audio centralizzata e la trasmissione dei flussi video decentralizzata.
Alcuni partecipanti partecipano in modo centralizzato mentre altri in modo decentralizzato.
Si occupa di interconnettere il network H.323 con altri tipi di network come la rete telefonica tradizionale. Svolge quindi le funzioni di adattamento per il trasporto dei flussi multimedia e del Signaling. Si compone di due parti logiche:
Permette l'adattamento del Signaling.
Permette l'adattamento dei flussi multimedia.
Nei network H.323 si possono individuare delle aree amministrative, chiamate zone, definite come insieme di componenti H.323 (Gateway, Terminali, MCU) gestite da un singolo Gatekeeper. I limiti di una zona possono essere basati su limiti amministrativi, struttura di naming, confini geografici, ecc. Le chiamate all'interno di una zona sono gestite da un unico Gatekeeper, mentre le chiamate che coinvolgono differenti zone sono gestite da più Gatekeeper.
La raccomandazione H.225.0 definisce le procedure di segnalazione che i componenti del network H.323 devono utilizzare. Queste si dividono in:
Questo insieme di procedure permette al Gatekeeper di coordinare e gestire le comunicazioni tra i componenti nel network H.323, fornendo le seguenti funzionalità:
Descrive come i terminali si debbano registrare al Gatekeeper, al fine di annunciare la loro presenza. Durante la registrazione viene indicato il canale logico H.225.0 che deve essere utilizzato per il Call Signaling e l'indirizzo alias H.323 col quale si desidera essere riconosciuti. Questa funzionalità viene implementata con i seguenti messaggi:
Trasmesso dal terminale al Gatekeeper, richiede la registrazione.
Trasmesso dal Gatekeeper in risposta ad un messaggio RRQ, conferma l'avvenuta registrazione.
Trasmesso dal Gatekeeper in risposta ad un messaggio RRQ, rifiuta la registrazione.
Trasmesso dal terminale al Gatekeeper, richiede la deregistrazione.
Trasmesso dal Gatekeeper in risposta ad un messaggio URQ, accetta la deregistrazione.
Trasmesso dal Gatekeeper in risposta ad un messaggio URQ, rifiuta la deregistrazione. Ad esempio, se il terminale è al momento impegnato in una conversazione, deve prima terminare questa per deregistrarsi.
Trasmesso dal terminale all'indirizzo multicast 224.0.1.41 porta UDP 1718, viene utilizzato nella procedura di Gatekeeper discovery per richiedere quali Gatekeeper siano disponibili.
Trasmesso dal Gatekeeper come risposta ad un messaggio GRQ, indica che il Gatekeeper è presente ma non disponibile per la registrazione del terminale. Può fornire però una lista di altri Gatekeeper.
Trasmesso dal Gatekeeper come risposta ad un messaggio GRQ, indica che il Gatekeeper è presente e disponibile per la registrazione del terminale.
Descrive come i terminali debbano contattare il Gatekeeper per richiedere oppure accettare una comunicazione. In generale, i terminali sono identificati all'interno del network H.323 tramite un indirizzo alias H.323. Occorre quindi una procedura per la loro localizzazione, intesa a risolvere questo tipo di indirizzi. In presenza di un Gatekeeper, è quest'ultimo a occuparsi di tale operazione. Oltre al chiamante, anche il chiamato deve ottenere il permesso dal Gatekeeper per poter iniziare la comunicazione. Qualsiasi comunicazione, in presenza di un Gatekeeper, richiede quindi la sua esplicita autorizzazione in entrambe le direzioni. Per terminare la comunicazione, nuovamente occorre ottenere il permesso dal Gatekeeper. La notifica di terminazione di una comunicazione è molto importante per il Bandwidth Control ed in generale migliora l'utilizzo delle risorse di rete. Questa funzionalità viene implementata con i seguenti messaggi:
Trasmesso dal terminale (inizio procedura di chiamata) oppure dal Gatekeeper (inizio procedura di accettazione chiamata in ingresso), richiede di partecipare ad una comunicazione.
Trasmesso dal terminale oppure dal Gatekeeper, indica che la richiesta è stata accettata, specificando inoltre il canale logico H.255.0 che deve essere utilizzato per il Call Signaling.
Trasmesso dal terminale oppure dal Gatekeeper, indica che la richiesta è stata rifiutata
Trasmesso dal Gatekeeper verso altri Gatekeeper oppure verso l'indirizzo multicast 224.0.1.41:1718, richiede informazioni riguardo la risoluzione di un alias H.323.
Trasmesso dal Gatekeeper come risposta ad un messaggio LRQ, contiene le informazioni richieste.
Questa procedura descrive come i terminali informano il Gatekeeper circa il loro stato. Questa funzionalità viene implementata con i seguenti messaggi:
Trasmesso dal terminale oppure dal Gatekeeper, richiede un qualche tipo di informazione.
Trasmesso in risposta ad un messaggio IRQ, contiene le informazioni richieste.
Questo insieme di procedure permette ai terminali di richiedere, accettare e terminare una comunicazione. Queste funzionalità vengono implementate con i seguenti messaggi:
Trasmesso come risposta ad messaggio Setup, indica che la richiesta è stata ricevuta e la si sta processando.
Trasmesso per iniziare la procedura di chiamata. In presenza di un Gatekeeper, segue la trasmissione e ricezione dei messaggi ARQ e ACF.
Trasmesso per indicare al chiamante che si sta allertando il chiamato in qualche modo.
Trasmesso per terminare la comunicazione, non prevede alcuna risposta.
Trasmesso come risposta di un messaggio Setup, indica che la richiesta è stata accettata e quindi che l'utente ha accettato la chiamata.
Trasmesso dal Gateway per indicare che il sistema sta processando la richiesta.
Trasmesso per trasferire la richiesta. Viene utilizzato per implementare il servizio Call Forwarding.
I messaggi della raccomandazione H.225.0 sono definiti utilizzando la notazione ASN.1 e sono trasmessi utilizzando il protocollo di trasporto TCP, incapsulati in pacchetti Q.931[4], questi a loro volta incapsulati in pacchetti TPKT[10]. Il protocollo TPKT permette di riconoscere nel flusso l'inizio e la fine dei singoli pacchetti Q.931. Il formato dell'header dei pacchetti TPKT è il seguente, definito come struttura C:
struct h323_tpkt_hdr
{
u_int8_t vrsn; // indica la versione TPKT. L'attuale è 3
u_int8_t reserved; // riservato per scopi futuri
u_int16_t length; // lunghezza del messaggio che segue immediatamente
};
// segue il messaggioL'header TPKT è immediatamente seguito dal pacchetto Q.931. Questo ulteriore Layer è previsto per semplificare l'interworking con le reti ISDN. I messaggi sono infine codificati in ASN.1 Packet Encoding Rules (PER)[6].
La raccomandazione H.245 definisce come devono essere concordati i parametri di trasmissione dei flussi multimedia, fornendo queste funzionalità:
Permette di assegnare il ruolo di Master ad uno dei terminali partecipanti alla chiamata. Gli altri terminali assumono il ruolo di Slave. l'importanza dell'assegnazione di questi ruoli si manifesta nella risoluzione di possibili conflitti quando più terminali inizializzano contemporaneamente la procedura per uno stesso evento.
Permette di assicurare che il ricevente sia in grado di decodificare il flusso multimedia che riceve.
Permette l'apertura e la terminazione di un canale logico. A ciascun canale logico è associato un flusso multimedia.
Trasmesso per richiedere l'apertura di un canale logico.
Trasmesso in seguito alla ricezione di un messaggio Open Logical Channel, indica che la richiesta è stata accettata. Nel caso di una comunicazione bidirezionale, il messaggio contiene anche i parametri della trasmissione dei flussi multimedia nella direzione opposta.
Trasmesso in seguito alla ricezione di un messaggio Open Logical Channel, indica che la richiesta è stata rifiutata.
Trasmesso per richiedere la terminazione di un canale logico.
Trasmesso in seguito alla ricezione di un messaggio Close Logical Channel, rifiuta la richiesta.
Il network H.323 di riferimento è descritto nella figura 3.6.
Esistono differenti modelli di segnalazione che differiscono in base al ruolo che il Gatekeeper ricopre nelle fasi che coinvolgono la comunicazione:
I terminali coinvolti gestiscono direttamente il Call Signaling ed il Signaling H.245, senza l'intervento del Gatekeeper (che si occupa soltanto del RAS Signaling), come mostrato in figura 3.7. Il RAS Signaling non è comunque obbligatorio.
I terminali coinvolti gestiscono direttamente il Signaling H.245 lasciando gestire il Call Signaling al Gatekeeper, come mostrato in figura 3.8.
Il Gatekeeper si occupa sia del Call Signaling che del Signaling H.245, come mostrato in figura 3.9.
Il protocollo SCCP, acronimo di ``Skinny Client Control Protocol'' e proprietario Cisco, è stato sviluppato originariamente dalla Selsius Corporation e poi acquisito da Cisco negli anni '90. Come ricordo del suo passato, il nome di default degli IP Phone Cisco è SEP (Selsius Ethernet Phone) seguito dal MAC address. Il punto di forza di SCCP sono i requisiti richiesti dai client, molto inferiori rispetto ai terminali H.323 ed dagli UAs SIP. In SCCP si è deciso di concentrare la complessità e quindi l'intelligenza in un server, il Call Manager. In questo modo è stato possibile per Cisco sviluppare dei client funzionali ma semplici e quindi meno costosi e più competitivi rispetto alle soluzioni H.323 e SIP. Il Call Manager integra un Gateway H.323, questo permette l'interconnessione della rete SCCP con una rete H.323. Viene qui analizzato in modo parziale perché il documento di specifica del protocollo non è pubblico e non è stato possibile recuperarlo in alcun modo. Le informazioni sono state ottenute in modo diretto attraverso l'analisi di tracciati di rete oppure studiando il codice sorgente dell'applicazione OpenSource Wireshark. Non esistono estensioni che permettono la cifratura del Signaling e delle trasmissioni RTP/RTCP.
SCCP utilizza lo schema di indirizzamento definito in E.164[7].
I componenti del network SCCP sono due:
Indica l'unico componente client del network, questo device è in grado soltanto di informare il Call Manager circa il suo stato e di eseguire le operazioni richieste sempre dal Call Manager, dal quale dipende completamente.
Indica l'unico componente server del network. Sincronizza e coordina le comunicazioni tra i client, implementando anche la funzionalità di Gateway SCCP-H.323, come presentato in figura 3.10.
I componenti dell'architettura comunicano scambiandosi messaggi definiti dal protocollo SCCP. I messaggi sono trasmessi utilizzando il protocollo di trasporto TCP oppure UDP, porta 2000. I messaggi SCCP sono ``codificati'' in strutture definite nel linguaggio C, il Byte Order è Little-Endian. Sono un'eccezione i campi che rappresentano indirizzi IPv4, codificati in Network Byte Order. Il parsing, utilizzando il linguaggio C, si riduce quindi alla sola inizializzazione di un puntatore se l'architettura del device utilizza il Byte Order Little-Endian, come l'architettura Intel. Il formato dei messaggi viene definito mediante strutture C. I messaggi SCCP sono composti da un header che svolge la stessa funzione del protocollo TPKT utilizzato in H.323, così definito:
struct SCCPPrefix {
UINT32 length; //Length of the SCCP message to follow
UINT32 type; //Unused, must be set to zero
};Questo header permette di riconoscere l'inizio e la fine di ciascun messaggio all'interno del flusso TCP. Il tipo di messaggio che segue (che identifica la struttura C da considerare) è indicato nei 32 bit che seguono l'header e che rappresentano anche il primo campo della struttura C da considerare. Questo campo è sempre presente. Stranamente, non viene utilizzato il campo type di SCCPPrefix che è stato probabilmente definito a tale scopo. Attraverso i messaggi SCCP, vengono implementate le seguenti funzionalità:
Questa funzionalità viene implementata con i seguenti tipi di messaggio:
Trasmesso dal client, richiede la registrazione al Call Manager.
Trasmesso dal client, richiede la deregistrazione al Call Manager.
Trasmesso dal Call Manager, conferma l'avvenuta registrazione.
Trasmesso dal Call Manager, rifiuta la registrazione.
Trasmesso dal Call Manager, conferma l'avvenuta deregistrazione.
Trasmesso dal client, informa il CallManager che una cifra è stata premuta sul keypad.
Trasmesso dal client, informa il CallManager che un qualche tasto è stato premuto.
Trasmesso dal Call Manager, informa il client circa l'identità dei client coinvolti in una comunicazione.
Trasmesso dal Call Manager, informa il client circa lo stato della comunicazione.
Trasmesso dal Call Manager, informa il client che un canale di ricezione deve essere aperto, richiedendo verso quale porta UDP attivare la trasmissione.
Trasmesso dal client, informa il Call Manager circa lo stato di apertura del canale di ricezione ed indica la porta UDP verso la quale attivare la trasmissione.
Trasmesso dal Call Manager, indica al client che deve chiudere il canale.
Trasmesso dal Call Manager, indica al client che deve iniziare la trasmissione del flusso multimedia, indicando l'indirizzo IPv4 e la porta UDP di destinazione.
Trasmesso dal Call Manager, indica al client di terminare la trasmissione.
Il network SCCP di riferimento è descritto nella figura 3.11.
Esiste un unico modello di segnalazione, i Client dipendono completamente dal Call Manager. Questo detiene qualsiasi tipo di informazione sullo stato di ciascun componente, permettendo il controllo completo delle comunicazioni e del network SCCP. Nella figura 3.12 viene mostrato il Call Signaling di una conversazione tra i Client 0123 e 045.
Viene di seguito descritto ogni istante, dove CL1 è il Client che ha come identificativo 0123, CL2 è il Client che ha come identificativo 0456 e CM è il Call Manager:
I protocolli RTP/RTCP[12], nati in ambito IETF nel 1996, descrivono un insieme di funzionalità che permettono il trasporto di dati Real Time senza occuparsi in alcun modo del QoS. Si noti che RTP non richiede necessariamente RTCP ma la sua presenza può essere determinante per ottenere migliori prestazioni, solitamente quindi si utilizzano assieme. RTP/RTCP non fa parte del livello di trasporto ma dell'applicazione, lo sviluppatore deve quindi implementare i protocolli RTP/RTCP integrandoli nell'applicazione stessa. Vengono anche utilizzati assieme ai protocolli di segnalazione VoIP come SIP, H.323 ed SCCP per il trasporto dei flussi multimedia. Le informazioni trasportate possono essere cifrate ma di fatto non succede mai. E' stato definito un nuovo protocollo nel 2004, SRTP, acronimo di ``Secure RTP''. Questo dovrebbe sostituire il protocollo RTP e richiede la cifratura del traffico, non è però ancora molto applicato.
I protocolli RTP/RTCP sono designati per essere indipendenti dal tipo di rete sottostante e dal protocollo di trasporto, vengono comunque utilizzati solitamente in reti IP utilizzando come protocollo di trasporto UDP. L'indirizzo IP che può essere unicast oppure multicast e la porta UDP costituiscono quindi l'indirizzo delle trasmissioni RTP/RTCP.
Sono definiti quattro componenti:
La presenza di questo sistema è trasparente e permette di cambiare la codifica dei dati trasmessi per adeguarsi alle risorse di rete dei partecipanti alla comunicazione. E' così possibile diversificare la qualità delle informazioni trasmesse a seconda della banda disponibile per la ricezione del flusso multimedia cambiando il codec utilizzato oppure riducendo la quantità di dati trasportati.
La presenza di questo sistema è trasparente e permette, in presenza di ostacoli fra il Sender ed il Receiver, la trasmissione e la ricezione delle trasmissioni RTP creando e gestendo un tunnel tra i due punti. Gli ostacoli possono essere apparati di rete come Firewall e Gateway IP.
Indica il device sorgente che trasmette la sequenza di pacchetti RTP, in modalità unicast oppure multicast.
Indica il device destinazione che riceve la sequenza di pacchetti RTP, in modalità unicast oppure multicast.
Il protocollo RTP (Real Time Protocol) si occupa della trasmissione dei dati Real Time. Le sue caratteristiche sono le seguenti:
Il pacchetto RTP consiste in un header fisso RTP, seguito da un eventuale lista di CSRC (Contributing SouRCes) inserita dai Mixer. Seguono i dati trasportati. Il formato dell'header fisso RTP è strutturato come segue:
![\includegraphics[scale=0.6]{fig/sip_network1}](img3.png)
![\includegraphics[scale=1]{fig/sip_scenario1}](img4.png)
![\includegraphics[scale=1]{fig/sip_scenario2}](img5.png)
![\includegraphics[scale=0.6]{fig/h323_network1}](img6.png)
![\includegraphics[scale=1]{fig/h323_call_direct}](img7.png)
![\includegraphics[scale=1]{fig/h323_call_routed1}](img8.png)
![\includegraphics[scale=1]{fig/h323_call_routed2}](img9.png)
![\includegraphics[scale=0.6]{fig/sccp_cm_h323}](img10.png)
![\includegraphics[scale=0.6]{fig/sccp_network1}](img11.png)
![\includegraphics[scale=1]{fig/sccp_routed_call}](img12.png)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I campi hanno il seguente significato:
Il modello di trasmissione prevede un certo numero di Sender, ciascuno dei quali può trasmettere più flussi RTP verso un insieme di Receiver. Ciascun flusso RTP identifica una sessione RTP. La trasmissione può avvenire in modalità unicast oppure multicast. Per ciascun flusso di dati Real Time viene creata una sessione RTP per il trasporto. Quindi, se il Sender intende trasmettere più flussi di dati Real Time, dovrà creare più sessioni RTP. Questo vincolo è motivato dal fatto che ogni singolo Receiver può essere interessato soltanto alla ricezione di alcuni flussi RTP. Per ciascuna sessione RTP viene inoltre creata una sessione RTCP di controllo.
Il protocollo RTCP (Real Time Transport Protocol) si affianca al protocollo RTP e si occupa di trasmettere informazioni aggiuntive riguardo la sessione RTP, come:
Sono definiti cinque differenti tipi di pacchetti RTCP, ciascuno contenente un differente tipo di informazioni. Sono definiti i seguenti pacchetti:
Fornisce le statistiche di spedizione effettuate dai sender RTP.
Fornisce le statistiche di spedizione effettuate dai receiver RTP.
Fornisce le informazioni circa l'identità dei Sender e Receiver.
Indica che il Receiver intende terminare la ricezione del flusso RTP.
indica un differente tipo di informazioni definito in un qualche modo. Viene utilizzato per implementare le estensioni.
La sequenza di dati dati Real Time viene trasmessa come sequenza di pacchetti RTP ed i Receiver sono tenuti a trasmettere periodicamente i pacchetti RTCP. Questi, contenenti anche statistiche sulla qualità della ricezione, permettono al Sender di monitorare la qualità del servizio. Al crescere del numero di Receiver di una sessione RTP, cresce il numero di pacchetti RTCP che sono tenuti a trasmettere verso il Sender. Questo implica un aumento dell'overhead, ponendo il problema di come gestirne la scalabilità. RTCP dovrebbe dedicare per i propri pacchetti non più del 5% della banda utilizzata per i pacchetti RTP, aggiustando dinamicamente il tempo che intercorre tra la trasmissione dei pacchetti RTCP. In questo modo si riduce la frequenza di trasmissione dei pacchetti RTCP, risolvendo il problema.