Introduzione

L'evoluzione tecnologica e la necessità di minimizzare i costi razionalizzando i progetti hanno già da tempo spinto le varie realtà della comunicazione a cercare piattaforme comuni di sviluppo per la fornitura dei servizi. La stessa telefonia mobile di terza generazione ha il suo valore aggiunto nell'integrazione nella fornitura degli stessi, mentre servizi quali Tv, telefonia e collegamento a internet sono ormai così legati tra loro da formare in taluni casi un'unica offerta commerciale.

A questo si è arrivato non senza il superamento di problemi enormi. Se infatti ben presto apparve chiaro come il protocollo IP ed in genere la trasmissione a pacchetto stesse diventando lo standard per il mondo delle comunicazioni, allo stesso modo si manifestò subito il suo limite: la difficoltà di garantire una Qualità di Servizio (QoS) alle applicazioni in tempo reale.

L'Internetional Telecommunication Union (ITU) rilasciò nel 1996 la prima versione della Raccomandazione H.323 con lo scopo di fornire una base per lo sviluppo di applicazioni real time su reti a pacchetto, quindi intrensecamente inaffidabili.

Lo scopo iniziale che si voleva raggiungere nel corso di questo lavoro era la possibilità di mettere a disposizione della facoltà un Laboratorio di Videoconferenza, implementando progetti disponibili in rete e intervenendo, dove necessario, per adattare gli stessi alle esigenze della facoltà.

Oggi è possibile trovare , disponobile gratuitamente, una grande quantità di software Open Source ( col codice sorgente aperto a tutti ) che si basa su questa raccomandazione.

Dopo una prima fase di studio dei protocolli e dei formati di codifica definiti nella Raccomandazione H.323 (Capitolo 1), sono passato quindi alla fase di ricerca in rete di applicazioni consone al nostro obbiettivo. Ho provveduto quindi a testare il loro effettivo funzionamento e a determinarne l'implementazione idonea ( Capitolo 2).

La costruzione di un sito internet di riferimento ha chiuso questa prima parte della tesi e reso fruibile quanto realizzato a chiunque fosse interessato all'argomento (Appendice B).

Da questo punto in poi il lavoro ha preso una strada non prevista in principio. Si è evidenziato infatti un limite strutturale della Raccomandazione H.323 e dei software da noi presi in esame , l'impossibilità di garantire un controllo delle risorse di rete assorbite da queste applicazioni.

Ho deciso di affrontare la questione utilizzando le funzionalità di networking messe ha disposizione dal sistema operativo Linux. Queste sono risultate molto ampie ed efficaci ed hanno rivelato potenzialità ben al di là dei nostri scopi.

L'ultima parte della tesi quindi è stata dedicata allo studio del networking in Linux e alla sua applicazione come sagomatore e limitatore del traffico generato in una videoconfernza H.323.

Sono state individuate due metodologie per affrontare il problema che in seguito abbiamo testato e ottimizzato ai nostri scopi (Capitolo 3).

Infine, affinchè il lavoro non risultasse fine a se stesso, ho cercato di rendere fruibile quanto portato a termine, realizzando script facilmente configurabili per la gestione degli shaper , oltre ad altri script per l'avvio automatico delle applicazioni per la gestione delle conferenze H.323 ad ogni reboot della macchina dove sono stati installati (Appendice A).

Capitolo 1

La Raccomandazione H:323

1.1 Premessa sul Voice over Packet

Con Voice over Packet si intendono l'insieme di studi portati avanti negli ultimi anni per la trasmissione di voce e video su reti a pacchetto come il Voice over IP ( rivolto alle reti private) e la IP-Telephony ( rivolto invece alle reti IP pubbliche).

Il desiderio di utilizzare le reti a pacchetto per servizi real-time nasce di pari passo con lo sviluppo delle potenzialità tecniche dovute al grosso miglioramento delle prestazioni dei processori, delle periferiche di rete dei PC e ancora alla progressiva affermazione delle reti, sia pubbliche che private, basate su protocollo IP .

Aziende che già avevano a disposizione una propria rete privata hanno subito assorbito la novità riscontrando in essa la possibilità di diminuire i costi delle comunicazioni interne e di integrare in questa servizi supplementari come la videoconferenza. Da un punto di vista più ampio lo sviluppo delle applicazioni real-time su reti a pacchetto può essere ormai inquadrato in una richiesta globale del mercato e delle aziende per una rete integrata nei servizi.

Nonostante la rapida affermazione, esistono diversi problemi legati a questa scelta dovuti per la maggior parte al fatto che il protocollo IP, così come la rete internet, sono nati per la distribuzione esclusiva di dati. Tra i più importanti possiamo citare:

• Qualità del servizio (QoS)

• Scalabilità e impatto sulle reti IP

• Integrazione con rete PSTN e reti mobili

• Sicurezza

• Compatibilità

• interoperabilità tra applicativi

Per quel che riguarda QoS gli indici che comportano una sua decadenza sono:

1. Ritardo di trasmissione: è la somma dei vari contributi di ritardo dovuti alla co-decodifica, all'impacchettamento, alla trasmissione e al ritardo di immagazzinamento nel buffer di ricezione. Spesso la somma di questi ritardi può arrivare a 500 msec e causare sovrapposizione del discorso fra gli utenti.

2. Jitter:Seguendo i pacchetti strade diverse per arrivare a destinazione, il ritardo non è costante e si può perdere il sincronismo audio-video.

3. Pacchetti peritale fenomeno comporata l'introduzione di intervalli nella comunicazione o buchi nelle immagini o addirittura disconnessione del collegamento.

4. Fedeltà di riproduzione audio e video.

Per cercare di superare almeno in parte alcuni di questi problemi è stato scelto l'uso del protocollo UDP che pur essendo meno affidabile elimina alcune caratteristiche pericolose del protocollo TCP come la trasmissione del riscontro e la ritrasmissione di pacchetti persi oltre a presentare un maggiore overhead (sempre alla ricerca di una maggiore trasparenza della rete furono introdotti i protocolli RTP-RTCP ma di questi protocollo parleremo più avanti).

Tra i vari problemi del Voice over IP elencati, nel corso di questa tesi verrà posto particolare accento sul problema della scalabilità e dell'impatto di tali applicativi sulle reti IP. Se infatti risulta possibile realizzare strutture di videoconferenza, è anche vero che queste richiedendo trasmissione video e voce di più utenti risultando applicazioni tanto più pesanti al crescere del numero dei partecipanti.

Almeno ad una parte di questi problemi l'ITU cercò di dare una risposta, emanando una raccomandazione ombrello che tenesse conto della situazione di fatto dei vari protocolli usati e cercando di armonizzarli. Il risultato fu nel 1996 la prima versione della Raccomandazione H.323.

1.2 Scopo della raccomandazione.

La raccomandazione H.323 comprende la definizione delle componenti tecniche necessarie per una comunicazione multimediale (audio, video, dati) che si trovi a lavorare, come sottorete di trasporto, una rete a pacchetto (PBN) che potrebbe non garantire una Qualità di servizio (QoS).

Queste reti a pacchetto possono includere Local Area Network, Enterprise Area Network, Metropolitan Area Network, Intra-Network e Inter- Network ( compreso Internet).

Ancora si includono connessioni dial up o connessioni punto-punto su GSTN o ISDN le quali usano una sottorete di trasporto a pacchetto di tipo PPP.

Come anticipato, la prima versione della raccomandazione è del 1996 ed il suo titolo: H.323 visual telephone system and equipment for LANs that provide a nongaranteed quality of service chiarisce come fosse indirizzata esclusivamente alla fornitura del servizio su LAN. Ma dopo soli 2 anni è stata emanata la più completa H.323 Packed based multimedia comunication system rivolta a qualunque tipo di rete a pacchetto.

Lo standard H.323 fa parte della famiglia di raccomandazioni H.32X dell'ITU definite per servizi di di comunicazioni multimediali su differenti reti:

• H.324 per la rete PTSN

• H.320 per la rete N-ISDN

• H.321 e H.310 per la rete B-ISDN

• H322 per reti LAN che forniscono qualità di servizio garantita.

In questo ambito sono stati definiti metodi di codifica del segnale video ( H.26X), del segnale audio (G.7XX) e gli stessi metodi di segnalazione e di controllo (H.221 e h242 per ISDN e H.223 e H.245 per GSTN). La raccomandazione H.323 viene detta raccomandazione ombrello in quanto più che introdurre nuovi protocolli o nuove codifiche si è tentato di armonizzare le indicazioni delle precedenti raccomandazioni della serie H e di prevedere tutta una famiglia di gateway idonei a garantire l'interoperabilità di queste con le entità di videotelefonia in internet.

Lo standard H.323 è ancora in fase di sviluppo. Nel Novembre del 2000 è stata rilasciate la sua quarta versione. Si cerca di coprire tramite l'aggiunta di Annex i buchi non coperti dalle precedenti versioni. L'architettura di un generico endpoint H.323 può schematizzarsi come in figura.

Fig. 1.1

La pila protocollare definita con H.323 deve operare al di sopra dello strato di trasporto della rete sottostante, in questo modo i protocolli H.323 possono essere usati con una qualsiasi rete a pacchetto.

Un terminale H.323 deve fornire capacità di comunicazione audio e opzionalmente video e dati in uno scenario di utilizzo sia punto-punto che all'interno di una conferenza multipunto.

AGGIUNGERE QUALITA' H323 E MULTICAST

Per fare ciò vengono definiti quattro tipi di componenti standard detti H.323 entity i quali definiscono in tutto e per tutto una sottorete, a livello applicativo, interagente con le altre tipologie di rete:

Fig. 1.2

• Terminali (EP)

• Gateway (GW)

• Gatekeeper (GK)

• Multipoint control unit (MCU)

Lo scopo della raccomandazione non include le interfacce di rete, la rete fisica o i protocolli di trasporto usati dalla rete .

3. Componenti H.323

Prima di descrivere i protocolli compresi nella raccomandazione cerchiamo di dare un primo accenno sui componenti che la raccomandazione introduce cercando di focalizzarci sui loro compiti più che sul loro funzionamento.

1. Il Terminale

I terminali sono gli endpoint in cui originano e terminano i flussi di dati e la segnalazione H.323. Questi possono essere PC o telefoni IP USB(??) o ancora qualunque dispositivo dedicato che contenga l'implementazione dei protocolli dello standard H.323. Un terminale H.323 deve supportare obbligatoriamente comunicazioni audio e ,facoltativamente , video e dati.

Per fare ciò tutti i terminali devono supportare i protocolli di controllo per negoziare l'uso del canale (H.245), per l'instaurazione della chiamata (RAS-Q.931) e per la trasmissione stessa dei pacchetti(RTP) più ovviamente i co/decodificatori per i flussi audio e video (dove possibili) e i protocolli relativi allo scambio di dati (T.120), così come mostrato in Fig 1.1.

1. Il Gateway (GW)

I Gateway sono caratteristici di qualsiasi comunicazione tra sottoreti diverse. La connessione tra le due reti avviene tramite traduzione dei protocolli applicativi relativi alle due reti e talvolta anche attraverso la traduzione dei protocolli di trasferimento e la conversione di codifica dei flussi audio/video.

Spesso lo scopo del gateway è quello di interfacciare le caratteristiche di un EP di una rete LAN verso un EP di una rete SCN e vice versa.

In figura è riportata l'architettura di un gateway H.323.

Fig. 1.3

Dalla figura si identificano i due lati dello stack, H.323 e SCN. I due rami sono uniti da uno strato Interworking call control che realizza la traduzione dei protocolli.

Spesso il gateway è implementato come parte di un gatekeeper o di un MCU.

1. Il Gatekeeper (GK)

Il gatekeeper pur non essendo obbligatoriamente presente in una comunicazione multimediale, svolge se utilizzato numerose inportanti funzioni e offre tutta una serie di sevizi a cui altrimenti si deve rinunciare. Lo standard definisce in maniera precisa le funzionalità offerte dal gatekeeper, delle quali alcune obbligatorie e altre opzionali. Tra quelle obbligatorie bisogna citare :

• Address traslation: trasformazione di un numero telefonico (E.164) o di un indirizzo alias in un indirizzo IP e vice versa.

• Admission control: controllo i ammissione di un EP in una zona H.323 (RAS)

• Bandwidth control : controllo di banda (RAS)

• Zone management: controllo dei componenti H.323 appartenenti alla H.323 zone

Una H.323 Zone è definita da una serie di componenti H.323 come terminali, gateway ed MCUs registrati presso uno stesso GK il quale quando presente gestisce tutte le comunicazioni che terminano o si originano da un host registrato presso di lui.

Fig.1.4

Tra le funzionalità opzionali del gatekeeper possiamo elencare:

• Call Control Signaling:in una conferenza punto-punto il gatekeepr può processare i segnali di controllo Q.931 oppure farli scambiare direttamente tra gli EP.

• Call Autorization: il GK può rifiutare una chiamata per motivi ad esempio di mancata autorizzazione . I criteri per determinare queste autorizzazioni sono al di fuori della raccomandazione.

• Bandwidth Mamagement: il GK può rifiutare una chiamata se non c'è abbastanza banda disponibile ma i criteri per definire de la banda è disponibile vanno al di fuori della raccomandazione.

• Call Management: il GK può tenere ad esempio una lista degli utenti occupati in comunicazioni.

1. Il Multipoint Control Unit (MCU)

Uno dei punti di forza della Raccomandazione H.323 è il supporto che fornisce alle applicazioni multimediali multipunto. Il componente fondamentale per questo aspetto è il Multipoint Control Unit il quale permette di costruire architetture di comunicazioni flessibili. Se da una parte può essere considerato un terminale in quanto può generare e terminare flussi audio e video dall'altra la differenza è come agisce su questi. Infatti l'MCU riceve tutti i flussi audio e video dai partecipanti alla conferenza e restituisce a tutti un unico flusso contenente i contributi di ognuno. Per quanto riguarda l'audio le varie comunicazioni vengono sovrapposte come nella realtà mentre per quel che riguarda il video viene spedita un'immagine di formato standard ma comprendente al suo interno riquadri più piccoli con i partecipanti alla videoconferenza . Nel caso siano troppi si può decidere di mandarne solo una parte, per esempio gli ultimi ad aver preso la parola. In realtà fa molto di più in quanto può accordarsi con ogni utente per una tipologia di streaming diverso e quindi dover convertire in formati diversi i flussi relativi ai diversi partecipanti.

Al suo interno sono presenti due parti:

• il Multipoint Controller (MC) che gestisce i segnali di controllo

• il Multipoit Processor (MP) che si occupa di processare i flussi audio\video

Proprio questa dicotomia ed il fatto che l'MCU stesso possa considerarsi un Terminale permettono una vasta gamma di configurazioni possibili per le conferenze.

Possiamo avere infatti 3 tipi di conferenze:

• centralizzate: tutti i flussi audio\video e di controllo vengono spediti da parte dei partecipanti all'MCU il quale gestisce totalmente la situazione.

  
  Fig. 1.6

decentralizzate:i segnali di controllo vengono gestiti dal MC mentre i flussi audio\video vengono spediti da ogni partecipante in multicast.

• ibride: i flussi audio insieme ai segnali di controllo vengono spediti tramite MP e solo i flussi video vengono spediti via multicast.

• mista: alcuni terminali partecipano ad una conferenza centralizzata, altri ad una decentralizzata o ibrida

Fig.1.7

4. Protocolli utilizzati nella Raccomandazione H.323

Come già anticipato l'H.323 è una raccomandazione ombrello che racchiude e collega insieme una serie di protocolli applicativi, specificati poi nel dettaglio in altre raccomandazioni. I più importanti protocolli appartenenti allo standard H.323 sono i seguenti:

• G.7XX - Insieme di codifiche audio

• H.26X - Insieme di codifiche video

• T.120 Protocollo per la trasmissione dati

• RTP/RTCP Protocollo di trasmissione di flussi real-time

• H.225 RAS Registration Admission Status

• H.225/Q.931 Call Signaling Segnalazione per l'instaurazione della chiamata

• H.245 Control Signaling Contrattazione della tipologia della chiamata

Data		Control and Signaling		Audio/Video	Registration
T.120	H.225 Call Signaling		H.245 Conference Control	RTP/RTCP	H.225 RAS
TCP				UDP
Network Layer
Data Link Layer
Physical Layer

Fig. 1.8

1. Codifiche audio

Come anticipato tutti i terminali H.323 devono avere almeno un supporto per la codifica audio. Molti sono i tipi di codifica utilizzabili, la maggior parte dei quali sono stati definiti dall'ITU stessa nella serie G.7XX mentre altri sono stati importati vista la loro popolarità.

Ne citiamo alcuni:

• G.711: codifica PCM a 64 Kbps usata nella PTSN (obbligatorio per qualunque terminale)

Logical Channel Number: Questo campo contiene il numero identificatico del canale logico H.245 - 1.

X bit: Usato per distinguere tra tipo di audio base ed esteso. Se X=0, AuType (vedi il prossimo campo) viene utilizzato; altrimenti (X=1), viene applicato il tipo di audio esteso descritto sotto (per primo il GSM) insieme a differenti strutture di pacchetto.

AuType: Identifica la codifica audio da usare. I seguenti valori sono accettabili per il campo AuType.

No	Codec description	AuType value
1	G.711 A law 64 kbit/s	0001
2	G.711 A law 56 kbit/s	0010
3	G.711 m law 64 kbit/s	0011
4	G.711 m law 56 kbit/s	0100
5	G.723.1	1000
6	G.729	1010
7	Annex A/G.729	1011
8	GSM and others (see below)	X=1

samples: Per le codifiche 1, 2, 3, 4, 6, e 7 questo componente contiene il numero di campioni - 1 per pacchetto audio come definito nella raccomandazione H.245.

session id: Contiene l'identificativo di sessione usato in comune con i protocolli RTP/RTCP.

M bit: Multicast address bit: indica che il seguente è un indirizzo multicast. Mentre molti tipi di indirizzi sono definiti del tipo IPv4 (includendo IPv6 e IPX), le strutture mostrate qui sono valide solo per indirizzi IPv4.

RTCP IP address/port: Contiene il Transport Address per i pacchetti RTCP .

• G.722: codifica ADPCM a 7 KHz con 48/56/64 Kbps

• G.723: tecnica di compressione che arriva ad un bit rate di 5.3/6.3 Kbps basandosi su

MP-MLQ (Multipulse, multilevel quantization)

• G.728/9: codifica a basso ritardo CELP (Code Excited Linear Prediction) con bit rate di

16/8 Kbps

• MPEG 1

• GSM codifica usata nello standard di telefonia mobile a 13 Kbps

Ext. Au Type: Identifica la codifica audio estesa (GSM) da usare come segue:

GSM Full Rate = 000 0011

GSM Half Rate = 000 0100

GSM Enhance Full Rate = 000 0101

La scelta della codifica da utilizzare avviene nella fase di instaurazione della chiamata mediante messaggi H.245 che vedremo tra poco.

1. Codifiche video

I supporti per le codifiche video sono opzionali. Quando presenti la codifica H.261 deve essere obbligatoriamente fra le codifiche supportate. Un'altra codifica importante sono è l'H.263 che supporta trasmissioni a più basso bit rate senza perdita di qualità, ma comporta ovviamente un maggior carico elaborativo integrando la codifica H.261 con tecniche di predizione dei frames.

Lo standard per la trasmissione di immagini in movimento H.261 risulta per molti aspetti del tutto simile all'MPEG, con la significativa differenza di essere stato pensato con una particolare attenzione alla possibilità di essere utilizzato in applicazioni di telecomunicazioni bidirezionali, nelle quali la criticità risiede sia nella codifica che nella decodifica dei dati e c'è la necessità di ridurre al minimo i ritardi dovuti a queste due operazioni. Il risultato di questa attenzione è uno standard più flessibile rispetto all'MPEG, il quale consente la trasmissione di dati con una occupazione di banda che può scendere fino al rate minimo di 64 Kbit/secondo, ovvero un canale base ISDN. Queste caratteristiche rendono lo standard H.261 particolarmente adatto al video-conferencing.

L'H.261 prevede la suddivisione dei frames in I-frames ed P-frames. I primi sono codificati in modo indipendente da qualsiasi altro frame, i secondi sono codificati in relazione al frame precedente, sia che esso sia di tipo I che P.

La scelta di codifica I o P viene eseguita a livello di Macro-blocco (si veda più avanti), e dipende da un algoritmo di confronto (sui valori assoluti delle differenze) tra il MB corrente e quello corrispondente del frame precedente. Il confronto è eseguito non soltanto sulla posizione corrispondente del precedente frame, bensì anche su tutte le posizioni adiacenti fino ad una translazione di 15 pixel nelle 4 direzioni. Estratto il valore minimo della distanza, se tale valore è inferiore ad una certa soglia (il cui valore compete alla scelta dell'implementatore), il MB sarà codificato P, ovvero sarà trasmesso soltanto il vettore bidimensionale di movimento (motion vector), ottenendo così un risparmio evidente rispetto alla trasmissione del blocco. Nel caso invece che il valore della distanza minima ecceda la soglia si sceglierà la trasmissione con codifica I, che risulta molto simile al caso MPEG.

Per evitare un eccessivo deterioramento dell'immagine, oltre a prevedere un meccanismo di retroazione all'interno dell'encoder del tutto simile a quello previsto nello standard MPEG, lo standard H.261 prevede un numero massimo (132) di frames di tipo Inter tra due frames Intra.

I formati di immagine possibili per lo standard H.261 sono il CIF (Common Intermediate Format, 352x288 pixels) ed il QCIF (quarter CIF, 176x144 pixels).

La strutturazione dello stream di dati nello standard H.261 è in qualche modo simile a quella del caso MPEG e consiste in una gerarchia:

• Immagine (Picture)

• Gruppo di blocchi (Group of Blocks = GOB)

• Macro-Blocco (Macro block = MB)

Ogni frame è diviso in MB di 16 x 16 pixel per la compressione, la risoluzione orizzontale è ridotta da 360 a 352 per produrre un numero intero di 22 MB.

Fig 1.9

1. T.120

La Raccomandazione T.120 si occupa di specificare i protocolli per la trasmissione in tempo reale di dati. Questi servizio è necessario nella realizzazione di applicativi di conferenze come lavagne grafiche o scambio di messaggi istantanei.

Come l'H.323, anche il T.120 è una raccomandazione ombrello che racchiude un insieme di standard mirato allo scambio di dati tra terminali diversi appartenenti areti diverse.

Il trasferimento dati mantiene nell'ambito H.323 una certa indipendenza dai flussi audio/video di una conferenza in quanto una trasmissione T.120 può instaurarsi sia indipendentemente, tramite una preventiva instaurazione della chiamata, sia durante una preesistente chiamata audio/video.Inoltre la terminazione di una connessione T.120 non implica la fine di una chiamata.

Vediamo alcuni vantaggi della raccomandazione T.120 rispetto allo scambio di dati tradizionale:

• Supporto per le conferenze multipunto: l'MCU provvede a manipolare i flussi dati così come avviene per i flussi audio/video.

• Indipendenza dalla piattaforma di rete: il protocollo T.120 opera al di sopra dello strato di trasporto.

• Interoperabilità: il T.120 è supportato da tutti gli standard H.32X fornendo un alto grado di interoperabilità.

• Supporto per il multicast.

1. RTP/RTCP

Nel momento in cui si è voluto usare reti a pacchetto per le applicazioni in tempo reale ci si è subito resi conto che il protocollo di strato di trasporto più adatto da usare era quello UDP. Se da un lato questo permetteva una maggiore trasparenza temporale dall'altro rendeva la trasmissione totalmente inaffidabile.

Il Real-Time Protocol (RTP) e il Real-Time Control Protocol (RTCP) sono protocolli di strato applicativo sviluppati dallo IETF ( RFC 1889-1890 ) i quali mirano ad aggiungere funzionalità aggiuntive ai protocolli di strato di trasporto. Spesso vengono introdotti come protocolli di trasporto perchè realizzano funzioni end-to-end per le varie applicazioni multimediali sovrastanti in modo indipendente da quest'ultime.

Nella maggior parte dei casi RTP/RTCP si basano sui servizi del protocollo UDP, ma gli sviluppatori dello standard hanno comunque voluto renderli indipendenti dal protocollo, cosicchè possono essere usati anche con altri protocolli come CLNP (Connectionless Network Protocol), IPX (Internet Packet Exchange), AAL5/ATM ed altri.

Gli obiettivi di maggiore trasparenza e affidabilità nella trsmissione in tempo reale si ottengono ovviamente al costo di una maggiore pesantezza dell'overhead del pacchetto.

Fig . 1.10

Incapsulato nel payload del segmento UDP vi è un header RTP, che contiene le informazioni che permettono alle entità di strato RTP di svolgere le loro funzioni. Oltre all'header vi è poi il payload in cui vi sono le informazioni d'utenete fornite dagli strati applicativi.

Vediamo ora come si compone l'header RTP:

Fig. 1.11

I primi 12 byte sono sempre presenti in ogni pacchetto RTP, mentre i successivi byte sono opzionali:

• Version (V): 2 bits. Versione del protocollo, la più recente è la numero quatro

• Padding (P): 1. Se settato il pacchetto contiene uno o più bit addizionali alla fine del payload non appartenenti all'header.

• Extension (X): 1 bit. Se settato indica la presenza di un header extension.

• CSRC count (CC): 4 bits. Conta il numero di identificatori CSRC che seguono l'header fisso.

• Marker (M): 1 bit. E' usato per permettere il marcamento dei limiti di frame nei pacchetti RTP.

• Payload type (PT): 7 bits. Specifica il formato del payload e gli schemi di codifica e compressione, in modo che gli strati applicativi riceventi siano in grado di interpretare i dati i dati del payload RTP. La tipologia del payload può anche essere cambiata dinamicamente durante la trasmissione. Per adattarsi ad esempio ad una temporanea congestione di rete si potrebbe ricorrere ad una codifica più leggera.

• Sequence Number: 16 bits. Il campo viene incrementato di uno per ognono deo pacchetti RTP inviati . È usato per rimettere nel corretto ordine i pacchetti ricevuti, e per notificare la perdita dei pacchetti.

• Timestamp:32 bits. Contiene l'istante di campionamento del primo byte nei dati RTP. Viene usato per ricostruire l'esatta temporizzazione necessaria per la sincronizzazione dei diversi flussi audio e video e per la valutazione dello jitter.

• Sincronization Source (SSRC): 32 bits.Numero che serve ad identificare univocamente una sorgente di un flusso RTP

Le funzioni del protocollo RTP sono essenzialmente di notifica agli strati applicativi. Infatti le funzioni che contrastano la perdita dei pacchetti come l'uso di tecniche di interpolazione o di variazione di codifica audio o video oppure la sincronizzazione e l'assemblaggio dei vari flussi sono operate dagli applicativi in base alle informazioni ricevute dall'header RTP.

Per aprire una sessione RTP l'applicazione definisce una particolare coppia di indirizzi di destinazione di trasporto (indirizzo di rete più numero di porta per RTP e per RTCP). Lo scambio di questi indirizzi fra i partecipanti alla comunicazione avviene tramite i protocolli sdi segnalazione. In una sessione multimediale voce e video sono associate a separate sessioni RTP con i loro propi pacchetti RTCP che informano sulla qualità di ricezione per ogni sessione. In una comunicazione punto-punto audio/video si hanno quattro sessioni RTP, due per l'audio, una in un verso e una nell'altro, e nellostesso modo due per il video. Ogni Sessione ha i suoi pacchetti RTCP per avere un riscontro sulla qualità dei dati consegnati.

Nella RFC 1889 sono stati definiti cinque pacchetti RTCP usati per convogliare informazioni di controllo:

• RR (Receiver Report): Sono generati dai partecipanti alla conferenza che sono mittenti attivi. Hanno informazioni sulla qualità di ricezione come numero di pacchetti ricevuti o perduti, valutazione dello jitter e uncampo timestamp per la valutazione del ritardo di transito.

• SR (Sender Report): vengono generati dai partecipanti alla conferenza che sono riceventi o mittenti attivi.Oltr ad informazioni sulla qualità come per gli RR, contengono una sezione per il mittente che invia informazioni sulla sincronizzazione, con un contatore di pacchetti e numero di byte inviati.

• SDES ( Source Description Items):

• BYE: indica la fine di una sessione RTP

• APP (Application Specific Function): Per uso sperimentale

Con lo scambio di questi pacchetti di informazione di controllo, RTCP fornisce come servizio principale il monitoraggio di QoS e il controllo di congestione. Le funzioni di miglioramento sono sempre demandae agli strati superiori.

1. H.225 RAS

Come detto anticipatamente l'insieme di un gatekeeper e vari endpoint registrati presso di lui costituisce una H.323 Zone. R.A.S è l'acronimo di Registration, Admition e Status ed è il protocollo che definisce i messaggi per lo scambio di segnalazione di controllo tra gli endpoint (terminali, MCU, gateway) e il gatekeeper in modo da effetuare la registrazione.

I messaggi RAS vengono scambiati con un canale RAS che utilizza un protocollo di trasporto UDP. Questo canale è aperto indipendentemente da una chiamata ed è aperto quindi prima dell'instaurazione di qualunque altro canale ( nel caso di utilizzo del gatekeeper).

Vediamo l'elenco dei segnali H.225 RAS che possono essere usati dai componenti H.323.

Fig. 1.12

• Messaggi di ricerca di un GK

In questa fase l'EP sta cercando un GK a cui registrarsi. Questo può essere fatto manualmente o automaticamente. La determinazione manuale del GK esula dallo scopo di questa raccomandazione ma si può immaginare che l'EP conosca a priori l'indirizzo del suo GK o comunque che abbia una lista di GK possibili.

La ricerca automatica permette un minor costo amministrativo in quanto non richiede il settaggio della lista di GK nel file di configurazione dell'EP ed inoltr in caso di guasto del gatekeeper permette la ricerca di ulteriori GK presso cui registrarsi.

Per prima cosa viene mandato in multicast il messaggio GRQ (Gatekeeper Request) che chiede Chi è il mio GK?. Questo messaggio è spedito utilizzando il well know Discovery Multicast Address dei Gatekeeper 224.0.1.41 e la porta predefinita 1718 .

Uno o più GK riceventi queto messaggio possono rispondere con GCF (GK Confirm) Io potrei essre il tuo GK contenente il Transport Address del canale RAS del GK nel campo rasAdress del messaggio. Se un GK riceve GRQ ma rifiuta quell' EP può mandare il messaggio GRJ (GK Reject). L'EP può scegliere uno dei GK da cui ha ricevuto il GCF.

Fig. 1.13

Un GK per fornir ridondanza può anche indicare l'indirizzo RAS di un ulteriore GK nel campo alternateGatekeeper del GCF. Se nessun GK risponde entro un timeout (oltre 5 s), l'EP può reiterare GRQ o passare alla ricerca manuale.

Alcuni campi comuni ai tre massaggi GRQ/GRJ/GCF sono:

• requestSeqNum : fa riferimento al numero della richiesta GRQ e ogni messaggio GRJ e GCF deve specificare a quale GRQ fa riferimento.

• protocolIdentifier : identifica il protocollo e la versione del componente trasmittente.

• IntegrityCheckValue: porta informazioni utili all'integrità e alla autenticazione del messaggio.

Alcuni campi specifici per ogni messaggio sono invece,oltre a quelli già citati:

• endpointAlias: nel GRQ l'EP può informare ilGK su tutti i suoi indirizzi alternativi.

• enpointType: nel GRQ l'EP specifica il tipo di componente H.323 esso sia.

• autenticationCapability: nel GRQ l'EP dichiara le modalità di autenticazione supportate.

• autenticationMode: nel GCF il GK specifica il modo di autentificazione da usare.

• rejectReason: nel GRJ il GK specifica la ragione del rifiuto.

• Messaggi di registrazione ad un GK

La registrazione è il processo tramite il quale, dopo aver determinato un GK disponibile, l'EP procede al suo abbonamento ai servizi di un certo GK ed entra a far parte quindi della sua H.323 Zone.

Per fare ciò un EP dovrà spedire un messaggio RRQ (Registration Request) al GK scelto usando il RAS Channel Transport Address specificato dal GK nella fase di ricerca. RRQ dovrà contenere a sua volta le infornazione sull'indirizzo del RAS Channel Transport Address dell'EP. Il GK può rispondere con il segnale RCF (Registration Confirm) o on il RRJ (Registration Reject)

Fig. 1.14

RRQ può essere ripetuto periodicamente dallo stesso EP cosicchè il GK deve essere in grado di gestire richieste multiple da parte dello stesso EP confermando agli EP dei essere registrati. Potrebbe anche accadere che un GK riceva richiesta di registrazione da parte di un EP che ha un alias uguale ma Transport Address diverso da uno degli EP già registrati. La gestione della politica da adottare in questi casi è lasciata al programmatore. In genere però il GK dovrebbe tendere a rifiutare registrzioni ambigue. Se un EP non include un alias nel messaggio RRQ il GK ne assegna uno.

Un EP può poi cancellare la sua registrazione spedendo un messaggio URQ (Unregister Request) al GK. Il GK può rispondere con un UCF (Unrigester Confirm) o con un URJ (Unregister Reject). Lo stesso GK può disconnettere un EP con un messaggio di URQ, ma in quel caso l'EP può solo rispondere con un UCF.

Anche in questi messaggi sono presenti i campi requestSeqNum, protocolIdentifier, rasAddress, integrityCheckValue e rejectReason. Caratteristici invece nel RRQ sono i campi:

• discoveryComplete: valore booleano che informa il GK se e stata precedentemente effettuata o meno la procedura di discovery.

• terminalType: indica il tipo di EP che richiede la registrazione(GK,GW,MCU,Terminal)

• terminalAlias: lista di alias tramite i quali l'EP può essere identificato.

• capacity: indica la massima capacità di chiamata dell'EP.

Per quanto riguarda RCF un campo interessante è il preGarantedARQ che elenca gli eventi per i quali e garantita l'ammissione al transito dal gatekeeper dll'EP.

• Messaggi di ammissione ad un GK

Una volta registrato presso un gatekeeper un EP che voglia instaurare una chiamata deve prima richiedere l'ammissione al servizio al GK tramite um messaggio ARQ (Admission Request). Questo messaggio specifica anche la banda richiesta tramite il campo bandWidth. Questo è solo un limite superiore che comprende la banda sia in ricezione che in trasmissione dei flussi audio/video esclusi gli header RTP, gli header di rete e altri overheads. Dati e canali di controllo non soo compresi in questi limiti.Il gatekeeper può ridurre la richiesta di banda nel messaggio di risposta ACF (Admission Confirm).

Ovviamente la conferma o meno dell'ammissione alla chiamata dipende anche dalla disponibilità del destinatario a riceverla. Quindi il GK dovrà assicurarsi che l'EP ricevente non sia occupato e preoccuparsi che anche lui ammetta la chiamata. Questa segnalazione avviene tramite protocollo H.225/Q.931 che vedremo più avanti. La sequenza cronologica dei messaggi sarà come indicato in figura.

Fig. 1.15

QUACCHECOSA DA SCRIVE

Fig 1.16

• Altri messaggi

Tra gli altri messaggi elencati nella tabella 1.? citiamo:

• Location: LRQ/LCF/LRJ permettono ad un EP di chiedere notizie al GK su un altro EP a partire dal suo alias o dal suo Transport Address. Il messaggio LRQ viene ricevuto dal GK che manda un messaggio di risposta LCF contenente i dati relativi all'EP richiesto

• Status: IRQ/IRR/IACK/INAK informano sullo stato della chiamata in corso.I messaggi relativi sono Information Request e Information Request Response oppure Information Request Acknowledge e Information Request Not Acknowledge.

• Bandwidth : BRQ/BCF/BRJ In questo modo vengono gestite le richiesteda parte dell'EP o del GK per una variazione della banda in uso durante una chiamata.

1. H.225/Q.931 Call Signaling

E' il protocollo che definisce i messaggi scambiati al fine di stabilire l'instaurazione di una chiamata tra endpoint. Questi messaggi sono scambiati attraverso il canale H.225 di segnalazione ( Call signaling channel). Questo protocolo si rifà in pratica al protocollo Q.931 definito per il controllo di chiamata in reti ISDN. Infatti i messaggi H.225 utilizzati nell'instaurazione e nell'abbattimento di una chiamata sono identici a quelli usati per una chiamata ISDN.

Nel protocollo Q.931 ogni messaggio deve contenere i seguenti campi :

8 7 6 5 4 3 2 1

Fig. 1.17

• Protocol discrimination: distingue tra i vari standard che possono utilizzare questi messaggi di controllo

• Call reference : identifica la chiamata o l'attività di registrazione/cancellazione richiesta dall'interfaccia di rete di un utente locale alla quale il messaggio si riferisce.

• Message type: Identifica la funzione del messaggio. Si utilizzano 7 degli 8 bit dell'ottetto lasciando l'ottavo per eventuali estensione future. I messaggi utilizzati dall' H.323 sono:

Se nella rete H.323 non è presente un gatekeeper i messaggi sono scambiati direttamente tra i due endpoint interessati alla chiamata. Quando è presente un gatekeeper i messaggi H.225 possono essere scambiati direttamente tra EP oppure indirettamente dopo instradamento da parete del GK. Nel primo caso si parla di direct call signaling nel secondo di gatekeeper-routed call signaling(vedi figure sopra). Il metodo scelto è deciso mediante lo scambio dei segnali RAS tra endpoint e gatekeeper nella fase di admission control.

Il ciclo di vita di una comunicazione segue i seguenti passi:

• Fase A: Call setup

• Fase B: Initial communication and capability exchange

• Fase C: Establishment of audiovisual communication

• Fase D: Call Services

• Fase E: Call Termination

Il protocollo H.225 si occupa della fase A che riguardano l'instaurazione della comunicazione.Vediamo dettagliatamente ogni fase dell'instaurazione della chiamata.

Fase A Call Setup

Il setup della chiamata ha luogo usando i messaggi sopra citati. Grazie alla flessibilità dei componenti e dell'architettura di una rete H.323 sono possibili diversi scenari per l'instaurazione di una chiamata. Analiziamone alcuni.

Setup di base nessuno dei due enpoint registrato presso un gatekeeper

Questa è la situazione più semplice in quanto il gatekkeper non interviene ed i messaggi di controllo e segnalazione vengono scambiati direttamente tra gli endpoint evitando così i messaggi RAS. Questo impone che l'endpoint chiamante conosca a priori l' indirizzo dell'endpoint chiamato.

L' EP 1 (chiamante) spedisce il messaggio Setup (1) verso un ben noto Call Signaling Channel TSAP Identifier dell'EP 2. L' EP 2 risponde con Connect (4) il quale contiene il Control Channel Transport Address da usare per la segnalazione H.245.

Fig. 1.18

I messaggi di Call proceeding e Allerting servono giusto per intasare un po' la rete. Il primo avverte che l'EP chiamato sta iniziando le procedure di connessione mentre il secondo ha una funzione di wait nel caso in cui Connect venga spedito dopo 4 secondi da Setup.

Entrambi gli enpoint registrati sullo stesso gatekeeper

Nel caso in cui il gatekeeper abbia scelto l'opzione direct call signaling la situazione è quella in figura.

Fig. 1.19

L' EP 1 (chiamante) inizia lo scambio ARQ(1)/ACF(2) con il GK. Il GK restituisce a lui il Call Signaling Channel Transport Address dell'EP 2 all'interno del ACF. A questo punto l' EP

chiamante spedisc il messaggio Setup(3) all' EP 2 usando questi Transport Address. Se l'endpoint chiamato desidera accettare la chiamata inizia lui stesso la fase ARQ(5)/ACF(6) col gatekeeper. Se l'EP 2 riceve ARJ da parte del GK allora spedisce il messaggio di Release Complete all' EP 1. Altrimenti se tutto va bene l'EP 2 spedisce il messaggio Connect (8) contenente il Control Channel Transport Address H.245.

Nel caso in cui il GK scelga l'opzione routed call signaling tutti i messaggi H.225 vengono spediti dai due EP al gatekeeper che provvederà lui stesso alla consegna.

Fig. 1.20

Solo l'endpoint chiamante è registrato presso un gatekeeper

Vediamo il caso in cui EP 1 sia registrato presso il nostro GK. Vedremo solo il caso direct call signaling visto che L'intuitiva estensione al caso routed.

Fig. 1.21

EP 1 inizia la fase di scambio dei segnali RAS ARQ/ACF con il GK, quindi spedisce il segnale di seup all'EP 2 usando il ben noto Call Signaling Channel Transport Address. Se l'EP 2 desidera accettare la chiamata risponde inviando il messaggio Connect contenente un H.245 control Channel Transport Address per la segnalazione H.245.

Solo l'enpoint chiamato è registrato presso un gatekeeper

In questo caso l'endpoint chiamante EP 1 non è registrato presso alcun GK quindi per collegarsi all'EP 2 manda direttamente il messaggio Setup. Questo ricevuta la richiesta di connessione prima richiede l'ammissione tramite lo scambio dei messaggi RAS ARQ/ACF coll GK e quindi si connette mandando il messaggio Connect.

Fig. 1.22

Entrambi registrati su differenti gatekeeper

Caso interessante è quando i due enpoint risultino registrati presso differenti GK. In questo caso la situazione è come mostrato in figura.

Fig. 1.23

L'EP 1 inizia la fase di scambio di messaggi RAS col suo gatekeeper (GK 1). I due GK dovrebbero avere tra loro una via di comunicazione aperta tramite la quale mettere in comune le informazioni che riguardano gli EP registrati presso ognuno. In tale situazione nel messaggio ACF del GK 1 si troverà il Channel Transport Address dell'EP 2. A questo indirizzo manderà il messaggio Setup. L'EP 2 ricevuta la richiesta di connessione provvedere a chiedere l'ammissione al servizio al proprio gatekkeeper (GK 2), quindi manderà il messaggio di connessione Connect all'EP 1.

Con quanto detto si chiude la fase A di instaurazione del collegamento. Ora inizia la fase B di contrattazione della qualità del servizio che si desidera sia possibile durante il collegamento. Quindi tipo di codifia sia audio che video da usare , banda disponibile e così via. Questo avviene tramite lo scambio di messaggi H.245.

1. H.245

Una volta che entrambi gli endpoint hanno scambiato i messagi di setup completando la fase A (Call Setup) si passa alla fase B (Initial communication and capability exchange) in cui i due endpoint aprono il canale di comunicazione H.245 Control Channel utile per lo scambio dei segnali di controllo della chiamata.

Il controllo di funzionamento H.245 usa il H.245 Control Channel per trasportare end-to-end i messaggi di controllo che governano le operazioni delle entità, incluse scambio di capacità, apertura e chiusura di canali logici, richieste di modi preferenziali di funzionamento, messaggi di controllo di flusso ed altri comandi.

La segnalazione H.245 è stabilita tra due enpoint, tra un enpoint e un MC, o un endpoint e un GK. Un EP deve aprire un H.245 Control Channel per ogni chiamata a cui l'EP sta partecipando. Nota infatti che un MCU o un GK possono supportare molte chiamate contemporaneamente e quindi devono aprire più canali H.245 di controllo.

Il H.245 Control Channel sarà portato dal canale logico 0 che è da considerarsi permanentemente aperto dall'instaurazione del H.245 Control Channel al suo abbattimento.

La Raccomandazione H.245 specifica una serie di entità protocollari che definiscono lo scambio di messaggi finalizzate ad un certo scopo. Queste sono:

• Master/Slave determination

• Capability Exchange

• Logical Channel Signaling

• Bi-directional Logical Channel Signaling

• Close Logical Channel Signaling

• Mode Request

• Round Trip Delay Determination

• Maintenance Loop Signaling

I messaggi H.245 cadono in quattro categorie: Request, Response, Command e Indication. Le entità protocollari sopra definite usano i segnali appartenenti alle categorie Request e Response. Il primo richiede una azione specifica da parete del riceviture ed una immediata risposta dello stesso. I messaggi Command richiedono una azione senza attendersi una risposta mentre i messaggi Indication sono solo messaggi informativi.

Il primo messaggio H.245 che deve essere scambiato è quello sulle capacità degli EP.

Le capacità di sistema sono scambiate tramite la trasmissione dei messaggi di terminalCapability:

Fig. 1.24

Vengono definite in questo contesto le capacità sia trasmissive che ricettive fornendo all'EP col quale si vuole iniziare la comunicazione le possibili alternative in termini di modalità di codifica e rate degli stream audio/video o dati.

Successivamente l'endpoint supporta la determinazione master-slave utile per definire quale MC sarà il MC attivo nella conferenza. In questo caso più EP vogliono dare vita ad una conferenza. Più EP potrebbero avere al loro interno un controllore di conferenza e per non determinare conflitti bisogna definire chi prenderà la gestione della stessa.

I messaggi usati sono quelli della categoria Master/Slave Determination:

Fig. 1.25

Ogni endpoint specifica nel campo terminalType che tipo di terminale sia. Se posiede un MC integrato o meno e così via secondo la tabella qui riportata.

Fig. 1.26

La determinazione master-slave dovrà essere avanzata (attraverso l'uso dei messaggi MasterSlaveDetermination o MasterSlaveDeterminationACK) nel primo messaggio H.245 dopo che sia iniziata lo scambio di messaggi sulle capacità.

Se una delle due procedure fallisce l'endpoint abbandona la connessione e si entra nella fase E (Call Termination). Altrimenti in caso di successo si passsa alla fase C (Establishment of audiovisual communication).

In questa fase le procedure H.245 vengono usate per aprire i canali logici per lo scambio dei vari flussi informativi.Gli stream audio e video, i quali sono stati trasmessi nei setup dei canali logici del H.245, sono trasportati sopra un identificatore di TSAP dinamico usando un protocollo non affidabile. Le comunicazioni dati vengono invece trasportate usando un protocollo affidabile.

E' anche possibile durante la comunicazione cambiare le specifiche del canale logico se una delle due parti lo richiede, tramite sempre la segnalazione H.245. Quindi ricontrattare capacità, modo di ricezione o trasmissione e così via.

La fase D ( Call Services ) della chiamata racchiude alcuni servizi specifici che possono essere richiesti durante la chiamata come la modifica della banda utilizzabile, anche in questo caso occorre chiudere e raprire il canale logico, o la richiesta di informazioni su uno specifico EP da parte del gatekeeper. In questa fase si opera anche la gestione degli inviti a una videoconferenza come vedremo in un paragrafo a parte.

L'ultima fase è quella dela terminazione di chiamata. Entrambi gli EP possono decidere la terminazione della chiamata, sono possibili le seguenti procedure:

1. Si potrebbe interrompere una trasmissione video alla fine di una immagine completa e quind chiudere il canale logico per il video.

2. Si potrebbe interromperela trasmissione dei dati e quindi chiudere il canale logico per i dati.

3. Si potrebbe interrompere la trasmissione audio e quindi chiudere il canale logico per l'audio.

4. Si può trasmettere il messaggio H.245 endSessionCommand tramite il canale di controllo H.245, indicando che si vuole interrompere la connessione.

5. Si può ricevere un messaggio H.245 endSessionCommand da un altro EP e di conseguenza chiudere il H.245 Control Channel.

6. Se il Call Signaling Channel è aperto si può spedire il messaggio H.225 Release Compete e quindi chiudere il canale.

Se non c'è un GK dopo questi sei passi la comunicazione si interrompe. Nel caso di presenza di GK la situazione invece è quella schematizzata qui sotto.

Fig 1.27

Infatti il GK deve sapere che qualche EP sta rilasciando banda disponibile. Dopo i sei passi sopra citati quindi ogni EP trasmette un messaggio H.225 DRQ (Disneagage Request ) al proprio GK sul canale RAS. A sua volta il GK può decidere la terminazione di una chiamata. In questo caso il primo messaggio è il DRQ da parte del GK all'EP interessato.

Fig. 1.28

1. Esempio di instaurazione e abbattimento di una sessione H.323

Nei paragrafi precedenti sono stati illustrati dettagliatamente i protocolli utilizzati dalla Raccomandazione H.323, ora cerchiamo di riordinare quanto discusso illustrando in un esempio, passo passo , tutte le operazioni che portano all'instaurazione di una chiamata e al successivo abbattimento della stessa. Faremo questo nel caso di due terminali che vogliano instaurare una comunicazione attraverso registrazione presso un gatekeeper.

Supponiamo quindi che il terminale 1 (T1) voglia effettuare una chiamata solo audio verso il terminale 2 (T2) che in seguito effettui lui la chiusura della chiamata:

1. T1 invia il messaggio ARQ sul canale RAS al GK per l'ammissione, all'interno c'è la richiesta del direct call signaling.

2. GK invia a T1 il messaggio ACF di conferma di ammissione , con anche la conferma dell'uso della procedura di direct call signaling.

3. T1 invia a T2 il messaggio si setup sul canale di segnalazione H.225 per la richiesta di connessione.

   
   Fig. 1.29

4. T2 risponde a T1 con un messaggio di call proceding.

5. T2 invia il messaggio di ARQ sul canale RAS al GK per l'ammissione ai servizi del GK.

6. GK invia a T2 il messaggio ACF di conferma si ammissione .

7. T2 invia a T1 il messaggio alerting sul canale H.225 per avvertire della connessione in corso (opzionale nel caso di direct call signaling).

8. T2 invia a T1 il messaggio di connect sul canale H.225 per confermare l'avvenuta connessione. All'interno del messaggio è scritto l'indirizzo IP e porta che il chiamato (T2) fornisce al chiamante (T1) per l'instaurazione della connessione TCP relativa al canale di controllo H.245. Il numero di porta per questa connessione è dinamico.

9. T1 invia a T2 il messaggio di TerminalCapabilitySet sul canale di controllo H.245 per la negoziazione della capacità di connessione.

10. T2 invia a T1 il messaggio di TerminalCapabilityAck sul canale di controllo H.245 per il riscontro.

11. T2 invia il messaggio di TerminalCapabiliySet sul canale di controllo per la negoziazione della capacità di trasmissione.

Fig. 1.30

1. T1 invia a T2 il messaggio TerminalCapabilitySetAck sul canale H.245 per il riscontro.

2. T1 invia a T2 un messaggio OpenLogicaChannel per segnalare l'apertura di un canale logico, questo messaggio è inviato per ogni canale logico unidirezionale da aprire durante la chiamata. All'interno del messaggio sono scritti indirizzo IP di (di T1) e porta che T2 deve usare per inviare i segmenti UDP relativi al protocollo RTCP per quel canale.

3. T2 invia un messaggio OpenLogicalChannelAck per il riscontro positivo sull'apertura del canale. All'interno del messaggio sono scritti l'indirizzo IP (di T2) e le porte che T1 deve usare per per inviare segmenti UDP relativi al RTCP e al RTP.

4. T2 invia ora a T1 un messaggio OpenLogicalChannel per segnalare l'apertura del canale logico unidirezionale. La procedura di instaurazione dei canali logici è simmetrica.

5. T1 invia a T2 un messaggio OpenLogicalChannelAck.

La chiamata è a questo punto instaurata e inizia lo scambio di flussi audio.

1. T1 invia a T2 i flussi audio tramite pacchetti RTP.

2. T2 invia a T1 i flussi audio tramite pacchetti RTP.

3. T1 invia a T2 messaggi di controllo RTCP.

4. T2 invia a T1 messaggi di controllo RTCP.

Alla fine della chiamata T2 inizia la procedura di abbattimento.

Fig. 1.31

1. T2 invia a T1 un messaggio EndSessionCommand nel canale di controllo H.245 per indicare la fine della chiamata.

2. T1 invia a T2 un messaggio di EndSesssionCommand nel canale di controllo per riscontrare la fine della chiamata.

3. T2 invia a T1 un messaggio Release Complete nel canale di segnalazione H.225 per completare la procedura di chiusura della chiamata.

4. T1 e T2 inviano un messaggio DRQ sul camale RAS al GK per il disimpegno delle risorse.

5. Il GK invia a sua volta il messaggio DFC sul canale RAS a T1 e a T2 per il riscontro positivo del disimpegno delle risorse.

Fig. 1.32

1. Fast Start

La procedura di inizializzazione della chiamata è nell'H.323 piuttosto complessa, comprendendo diverse fasi di contrattazione di vari parametri prima dell'instaurazione della chiamata vera e propria. In termini di tempo questo si traduce in una attesa che può anche essere di diversi secondi prima dell'avvio della chiamata. Per cercare di ridurre questa attesa nella Raccomandazione è specificata una procedura rapida di connessione denominata fast start.

In pratica viene eliminata la fase di contrattazione H.245 inglobandola nella segnalazione H.225.Un EP chiamante che desidera iniziare una procedura Fast Start spedisce un messaggio H.225 Setup contenente gli elementi faststart dell'EP chiamante. Questi elementi consistono in una serie di strutture possibili per i canali logici di ricezione e trasmissione, inclusi i parametri necessari per iniziare subito la comunicazione. L' EP chiamante può rifiutare l'uso della procedura Fast Start sia perché semplicemente non la supporta, sia perché non gradisce i parametri e le strutture dei canali logici proposti. Altrimenti sceglie tra i canali proposti quello che più gradisce e lo considera già aperto. Intanto l'EP chiamante si prepara a ricevere traffico su uno qualunque dei canali logici da lui definiti. La comunicazione in due passi può già aver luogo. Eventuali affinamenti della tipologia del servizio possono avvenire durante la comunicazione tramite messaggi H.245.