protocollo RTP. Sviluppo della struttura di una rete con commutazione di pacchetto sull'esempio di JSC "Moscow State Telephone Network"

Una delle tendenze più importanti nell'evoluzione delle moderne telecomunicazioni è lo sviluppo della telefonia IP - una varietà di nuove tecnologie che forniscono la trasmissione di messaggi multimediali (voce, dati, video) attraverso reti di informazioni e computer (ICN) costruite sulla base dell'IP (protocollo Internet) inclusi locale, aziendale, globale reti di computer e Internet. Il concetto di telefonia IP include la telefonia Internet, che consente di organizzare la comunicazione telefonica tra abbonati Internet, tra abbonati di reti telefoniche pubbliche commutate (PSTN) su Internet, nonché la comunicazione telefonica tra PSTN e abbonati Internet tra loro.

La telefonia IP ha una serie di indubbi vantaggi che garantiscono il suo rapido sviluppo ed espansione del mercato della telefonia informatica. È vantaggioso per gli utenti finali a cui vengono fornite comunicazioni telefoniche a un pagamento al minuto piuttosto basso. Per le aziende con filiali remote, la tecnologia IP consente di organizzare le comunicazioni vocali utilizzando le reti IP aziendali esistenti. Invece di diverse reti di comunicazione, ne viene utilizzata una. Un vantaggio incondizionato della telefonia IP rispetto a un normale telefono è anche la capacità di fornire servizi aggiuntivi attraverso l'uso di un computer multimediale e di varie applicazioni Internet. Pertanto, con la telefonia IP, le aziende e gli individui possono espandere le capacità di comunicazione includendo moderne videoconferenze, condivisione di applicazioni, strumenti come una lavagna e altro ancora.

Quali standard e protocolli internazionali regolano i principali parametri e algoritmi per il funzionamento delle comunicazioni hardware e software utilizzate nella telefonia IP? Ovviamente, come suggerisce il nome, questa tecnologia è costruita sulla base del protocollo IP, che però non viene utilizzato solo per la telefonia: è stata originariamente sviluppata per la trasmissione di dati digitali in un IVS con commutazione di pacchetto.

Nelle reti che non forniscono una qualità del servizio garantita (queste includono le reti costruite sulla base del protocollo IP), i pacchetti possono andare persi, il loro ordine di arrivo può cambiare, i dati trasmessi in pacchetti possono essere distorti. Per garantire una consegna affidabile informazioni trasmesse in queste condizioni, vengono utilizzate diverse procedure del livello di trasporto. Quando si trasmettono dati digitali, a questo scopo viene utilizzato il TCP (Transmission Control Protocol). Questo protocollo garantisce una consegna affidabile dei dati e ripristina l'ordine originale dei pacchetti. Se viene rilevato un errore in un pacchetto o il pacchetto viene perso, le procedure TCP inviano una richiesta di ritrasmissione.

Per le applicazioni di conferenza audio e video, i ritardi dei pacchetti hanno un impatto molto maggiore sulla qualità del segnale rispetto ai singoli artefatti dei dati. Le differenze di latenza possono portare a pause. Per tali applicazioni è necessario un diverso protocollo di livello di trasporto che preveda il ripristino della sequenza originale dei pacchetti, la loro consegna con il minimo ritardo, la riproduzione in tempo reale ad orari precisi, il riconoscimento del tipo di traffico, multicast o comunicazione bidirezionale... Questo protocollo è il protocollo di trasporto in tempo reale RTP (Real-Time Transport Protocol). Questo protocollo regola il trasferimento di dati multimediali in pacchetti attraverso l'ICS a livello di trasporto ed è integrato dal protocollo di controllo del trasferimento dei dati RTCP (Real-Time Control Protocol). Il protocollo RTCP, a sua volta, fornisce il controllo della consegna dei dati multimediali, il controllo della qualità del servizio, il trasferimento delle informazioni sui partecipanti alla sessione di comunicazione in corso, il controllo e l'identificazione, ed è talvolta considerato parte del Protocollo RTP.

In molte pubblicazioni dedicate alla telefonia IP, si nota che la maggior parte delle apparecchiature di rete e del software speciale per questa tecnologia è sviluppata sulla base della raccomandazione del settore della standardizzazione delle telecomunicazioni dell'Unione internazionale delle telecomunicazioni (ITU-T) H.323 (incluso TAPI 3.0, NetMeeting 2.0, ecc.). Come si confronta H.323 con RTP e RTCP? H.323 è un ampio quadro concettuale che include molti altri standard, ognuno dei quali è responsabile di diversi aspetti del trasferimento delle informazioni. La maggior parte di questi standard, ad esempio gli standard di codec audio e video, sono ampiamente utilizzati non solo nella telefonia IP. Per quanto riguarda i protocolli RTP / RTCP, costituiscono la base dello standard H.323, sono focalizzati sulla fornitura di tecnologie esattamente IP e sono alla base dell'organizzazione della telefonia IP. Questo articolo è dedicato alla considerazione di questi protocolli.

2. Concetti di base

Il protocollo di trasporto in tempo reale RTP fornisce la trasmissione end-to-end in tempo reale di dati multimediali come audio e video interattivi. Questo protocollo implementa il riconoscimento del tipo di traffico, la numerazione della sequenza dei pacchetti, il lavoro con timestamp e controllo della trasmissione.

L'azione del protocollo RTP si riduce all'assegnazione di timestamp a ciascun pacchetto in uscita. In ricezione, i timestamp dei pacchetti indicano in quale sequenza e con quali ritardi devono essere riprodotti. Il supporto RTP e RTCP consente al nodo ricevente di disporre i pacchetti ricevuti nell'ordine corretto, ridurre l'effetto del jitter di ritardo del pacchetto sulla qualità del segnale e ripristinare la sincronizzazione tra audio e video in modo che le informazioni in entrata possano essere correttamente ascoltate e visualizzate dagli utenti.

Si noti che lo stesso RTP non dispone di alcun meccanismo per garantire la trasmissione tempestiva dei dati e la qualità del servizio, ma utilizza servizi di livello inferiore per garantire ciò. Non impedisce l'out-of-order dei pacchetti, né implica che la dorsale sia completamente affidabile e inoltri i pacchetti nell'ordine corretto. I numeri di sequenza inclusi in RTP consentono al destinatario di ricostruire la sequenza dei pacchetti del mittente.

RTP supporta sia la comunicazione bidirezionale che il trasferimento di dati a un gruppo di destinazioni se il multicast è supportato dalla rete sottostante. RTP è progettato per fornire le informazioni richieste dalle singole applicazioni e nella maggior parte dei casi è integrato nel funzionamento dell'applicazione.

Sebbene RTP sia considerato un protocollo di livello di trasporto, di solito viene eseguito su un altro protocollo di livello di trasporto, UDP (User Datagram Protocol). Entrambi i protocolli contribuiscono alla funzionalità del livello di trasporto. Va notato che RTP e RTCP sono indipendenti dal trasporto sottostante e dai livelli di rete, quindi RTP / RTCP può essere utilizzato con altri protocolli di trasporto adatti.

Le unità di dati del protocollo RTP / RTCP sono chiamate pacchetti. I pacchetti generati secondo il protocollo RTP e utilizzati per trasmettere dati multimediali sono chiamati pacchetti di dati e i pacchetti generati secondo il protocollo RTCP e utilizzati per trasmettere le informazioni di servizio necessarie per il funzionamento affidabile della teleconferenza sono chiamati pacchetti di controllo o pacchetti di servizio (pacchetti di controllo). Un pacchetto RTP include un'intestazione fissa, un'estensione dell'intestazione variabile opzionale e un campo dati. Un pacchetto RTCP inizia con una porzione fissa (simile alla porzione fissa dei pacchetti di informazioni RTP) seguita da blocchi di lunghezza variabile.

Al fine di rendere il protocollo RTP più flessibile e utilizzabile per varie applicazioni, alcuni suoi parametri sono volutamente indefiniti, ma prevede il concetto di profilo. Un profilo è un insieme di parametri per i protocolli RTP e RTCP per una specifica classe di applicazioni, che determina le caratteristiche del loro funzionamento. Il profilo definisce l'uso dei singoli campi di intestazione del pacchetto, tipi di traffico, aggiunte di intestazione ed estensioni di intestazione, tipi di pacchetto, servizi e algoritmi di sicurezza delle comunicazioni, specifiche sull'utilizzo del protocollo sottostante, ecc. Profilo RTP per conferenze audio e video con controllo minimo). Ogni applicazione di solito funziona con un solo profilo e il tipo di profilo viene impostato selezionando l'applicazione appropriata. Nessuna indicazione esplicita del tipo di profilo per numero di porta, ID protocollo, ecc. non fornito.

Pertanto, una specifica RTP completa per un'applicazione specifica dovrebbe includere documenti aggiuntivi che includono una descrizione del profilo e una descrizione del formato del traffico che definisce come il traffico di un particolare tipo, come audio o video, verrà gestito in RTP.

Le caratteristiche della trasmissione di dati multimediali durante le conferenze audio e video sono discusse nelle sezioni seguenti.

2.1. Audioconferenza di gruppo

Per una conferenza audio multicast sono necessari un indirizzo multicast multiutente e due porte. In questo caso, una porta è necessaria per lo scambio di dati audio e l'altra è utilizzata per i pacchetti di controllo RTCP. L'indirizzo multicast e le informazioni sulla porta vengono trasmesse ai partecipanti previsti alla teleconferenza. Se è richiesta la privacy, i pacchetti di informazioni e controllo possono essere crittografati come definito nella sezione 7.1, nel qual caso deve essere generata e distribuita anche una chiave di crittografia.

L'applicazione di audioconferenza utilizzata da ciascun partecipante alla conferenza invia i dati audio in piccoli blocchi, ad esempio 20 ms. Ogni blocco di dati audio è preceduto da un'intestazione RTP; l'intestazione ei dati RTP vengono alternativamente formati (incapsulati) in un pacchetto UDP. L'intestazione RTP indica quale tipo di codifica audio (ad esempio, PCM, ADPCM o LPC) è stata utilizzata per formare i dati nel pacchetto. Ciò consente di modificare il tipo di codifica durante la conferenza, ad esempio, quando compare un nuovo partecipante che utilizza una linea di comunicazione con larghezza di banda ridotta, oppure quando la rete è congestionata.

In Internet, come in altre reti di dati a commutazione di pacchetto, i pacchetti a volte vengono persi e riordinati, e anche ritardati per tempi diversi. Per contrastare questi eventi, l'intestazione RTP contiene un timestamp e un numero di sequenza che consentono ai destinatari di risincronizzarsi al loro stato originale in modo che, ad esempio, porzioni del segnale audio vengano riprodotte dall'altoparlante continuamente ogni 20 ms. Questa ricostruzione della sincronizzazione viene eseguita separatamente e indipendentemente per ciascuna sorgente di pacchetti RTP nella teleconferenza. Il numero di sequenza può essere utilizzato anche dal ricevitore per stimare il numero di pacchetti persi.

Poiché i partecipanti a una teleconferenza possono unirsi e abbandonare la conferenza mentre è in corso, è utile sapere chi sta attualmente partecipando alla conferenza e quanto bene i partecipanti alla conferenza stanno ricevendo l'audio. A tal fine, ogni istanza dell'applicazione audio durante la conferenza emette periodicamente messaggi sulla porta di controllo (porta RTCP) per le richieste di tutti gli altri partecipanti sulla ricezione di pacchetti con l'indicazione del loro nome utente. Il messaggio di ricezione indica quanto bene viene ascoltato l'altoparlante corrente e può essere utilizzato per controllare gli encoder adattivi. Oltre al nome utente, possono essere incluse anche altre informazioni di identificazione per il controllo della larghezza di banda. All'uscita dalla conferenza, il sito invia un pacchetto RTCP BYE.

2.2. Videoconferenze

Se la teleconferenza utilizza sia segnali audio che video, questi vengono trasmessi separatamente. Per la trasmissione di ciascun tipo di traffico, indipendentemente dall'altro, la specifica del protocollo introduce il concetto di sessione RTP (si veda l'elenco delle abbreviazioni e dei termini utilizzati). Una sessione è identificata da una coppia specifica di indirizzi di trasporto di destinazione (un indirizzo di rete più una coppia di porte per RTP e RTCP). I pacchetti per ogni tipo di traffico vengono trasmessi utilizzando due diverse coppie di porte UDP e/o indirizzi multicast. Non esiste una connessione RTP diretta tra le sessioni di comunicazione audio e video, tranne che l'utente che partecipa a entrambe le sessioni deve utilizzare lo stesso nome canonico nei pacchetti RTCP per entrambe le sessioni in modo che le sessioni possano essere collegate.

Uno dei motivi di questa separazione è che ad alcuni partecipanti alla conferenza dovrebbe essere consentito di ricevere un solo tipo di traffico, se lo desiderano. Nonostante la separazione, la riproduzione sincrona dei media sorgente (audio e video) può essere ottenuta utilizzando le informazioni di temporizzazione che vengono trasportate nei pacchetti RTCP per entrambe le sessioni.

2.3. Capire mixer e traduttori

Non tutti i siti sono sempre in grado di ricevere dati multimediali nello stesso formato. Si consideri il caso in cui i partecipanti dalla stessa posizione siano collegati tramite una linea a bassa velocità alla maggior parte degli altri partecipanti alla conferenza che hanno accesso alla rete a banda larga. Piuttosto che costringere tutti a utilizzare una larghezza di banda più stretta e una codifica audio di qualità inferiore, una struttura di comunicazione a livello RTP chiamata mixer può essere collocata in un'area di larghezza di banda stretta. Questo mixer risincronizza i pacchetti audio in ingresso per ripristinare gli intervalli di 20 ms originali, mescola questi flussi audio ricostruiti in un unico flusso, esegue la codifica segnale sonoro per larghezza di banda stretta e trasmette un flusso di pacchetti su un collegamento a bassa velocità. In questo caso, i pacchetti possono essere indirizzati a un destinatario oa un gruppo di destinatari con indirizzi diversi. Per fornire una corretta indicazione della sorgente dei messaggi agli endpoint riceventi, l'intestazione RTP include mezzi per i mixer per identificare le sorgenti coinvolte nel pacchetto misto.

Alcuni dei partecipanti all'audioconferenza potrebbero essere connessi tramite linee a banda larga, ma potrebbero non essere raggiungibili tramite conferenze IP multicast (IPM). Ad esempio, potrebbero trovarsi dietro un firewall a livello di applicazione che non consentirà alcuna trasmissione di pacchetti IP. Per tali casi, non sono necessari mixer, ma altri tipi di comunicazioni a livello RTP, chiamati traduttori. Dei due traduttori, uno è installato all'esterno del firewall e dall'esterno inoltra tutti i pacchetti multicast ricevuti tramite la connessione sicura all'altro traduttore dietro il firewall. Il traduttore dietro il firewall li ritrasmette come pacchetti multicast al gruppo multiutente limitato alla rete interna del sito.

Mixer e traduttori possono essere progettati per diversi scopi. Esempio: un mixer video che ridimensiona le immagini video di individui in flussi video indipendenti e li compone in un unico flusso video, simulando una scena di gruppo. Esempi di broadcast: connettere un gruppo di host utilizzando solo protocolli IP/UDP con un gruppo di host che accettano solo ST-II, o transcodificare il segnale video pacchetto per pacchetto da singole fonti senza risincronizzazione o mixaggio. I dettagli del funzionamento di mixer e traduttori sono discussi nella sezione 5.

2.4. Ordine dei byte, allineamento e formato timestamp

Tutti i campi dei pacchetti RTP/RTCP vengono trasmessi in rete per byte (ottetti); il byte più significativo viene trasmesso per primo. Tutti i dati del campo di intestazione sono allineati in base alla sua lunghezza . Gli ottetti designati come opzionali hanno valore zero.

Il tempo assoluto (Wallclock time) in RTP è rappresentato utilizzando il formato di timestamp Network Time Protocol (NTP), che è un conteggio del tempo in secondi relativo a zero ore il 1 gennaio 1900. Il formato completo del timestamp NTP è un numero a virgola fissa a 64 bit senza segno con una parte intera nei primi 32 bit e una parte frazionaria negli ultimi 32 bit. Alcuni campi con una rappresentazione più compatta utilizzano solo i 32 bit centrali: i 16 bit inferiori della parte intera e i 16 bit superiori della parte frazionaria.

Le prossime due sezioni di questo articolo (3 e 4) trattano rispettivamente i formati dei pacchetti e le caratteristiche dei protocolli RTP e RTCP.

3. Protocollo di trasferimento dati RTP

3.1. Campi di intestazione fissi RTP

Come notato sopra, un pacchetto RTP include un'intestazione fissa, un'estensione dell'intestazione variabile opzionale e un campo dati. L'intestazione fissa dei pacchetti RTP ha il seguente formato:.

I primi dodici ottetti sono presenti in ogni pacchetto RTP, mentre il campo identificatore CSRC (contributing source) è presente solo quando inserito dal mixer. I campi hanno i seguenti scopi.

Versione (V): 2 bit. Questo campo identifica la versione RTP. Questo articolo discute la versione 2 di RTP (il valore 1 è stato utilizzato nella prima bozza di RTP).

Imbottitura (P): 1 bit. Se il bit di riempimento è impostato su uno, il pacchetto contiene uno o più ottetti di riempimento alla fine che non fanno parte del traffico. L'ultimo ottetto dell'imbottitura contiene l'indicazione del numero di tali ottetti da ignorare successivamente. Il riempimento può essere richiesto da alcuni algoritmi di crittografia a dimensione di blocco fissa o per trasportare più pacchetti RTP in un'unica unità dati di protocollo di livello inferiore.

Estensione (X): 1 bit. Se il bit di estensione è impostato, l'intestazione fissa è seguita da un'estensione dell'intestazione con il formato specificato in.

Contatore CSRC (CC): 4 bit. Il contatore CSRC contiene il numero di identificatori di origine CSRC da includere (vedere l'elenco delle abbreviazioni e dei termini utilizzati) che seguono l'intestazione fissa.

Indicatore (M): 1 bit. L'interpretazione del marker è determinata dal profilo. Ha lo scopo di consentire la marcatura di eventi significativi (ad es. limiti di frame video) nel flusso di pacchetti. Il profilo può introdurre bit marker aggiuntivi o determinare che non è presente alcun bit marker modificando il numero di bit nel campo del tipo di traffico (vedere).

Tipo di traffico (TP): 7 bit. Questo campo identifica il formato del traffico RTP e ne determina l'interpretazione da parte dell'applicazione. Il profilo definisce la mappatura statica predefinita tra valori PT e formati di traffico. Ulteriori codici del tipo di traffico possono essere determinati dinamicamente tramite mezzi non RTP. Il mittente di un pacchetto RTP in un dato momento fornisce un unico valore per il tipo di traffico RTP; questo campo non è destinato al multiplexing di singoli flussi multimediali (vedi).

Numero di sequenza: 16 bit. Il valore del numero di sequenza viene incrementato di uno con ogni pacchetto di dati RTP inviato e può essere utilizzato dal ricevitore per rilevare la perdita di pacchetti e ricostruirlo alla sua sequenza originale. Il valore iniziale del numero di sequenza viene scelto a caso per complicare i tentativi di crackare la chiave in base ai valori noti di questo campo (anche se la crittografia non viene utilizzata dalla sorgente, poiché i pacchetti possono passare attraverso un traduttore che utilizza la crittografia) . Timestamp: 32 bit. Il timestamp riflette il punto di campionamento per il primo ottetto nel pacchetto di informazioni RTP. Il tempo di campionamento dovrebbe essere ottenuto da un timer che incrementi i suoi valori in modo monotono e lineare nel tempo per garantire la sincronizzazione e il rilevamento del jitter (vedere la sezione 4.3.1). La risoluzione del timer dovrebbe essere sufficiente per la precisione di temporizzazione desiderata e la misurazione del jitter di arrivo del pacchetto (un report del timer per frame video di solito non è sufficiente). La frequenza di temporizzazione dipende dal formato del traffico trasmesso ed è impostata staticamente in una specifica di profilo o formato di traffico, oppure può essere impostata dinamicamente per formati di traffico definiti tramite mezzi non RTP. Se i pacchetti RTP vengono generati periodicamente, devono essere utilizzati i tempi di campionamento nominali determinati dal timer di campionamento, non i valori del timer di sistema. Ad esempio, per un segnale audio a velocità fissa, è desiderabile che il sensore di marca temporale venga incrementato di uno per ciascun periodo di campionamento. Se un'applicazione audio legge blocchi contenenti 160 campioni da un dispositivo di input, allora il timestamp dovrebbe aumentare di 160 per ciascuno di tali blocchi, indipendentemente dal fatto che il blocco sia trasmesso in un pacchetto o scartato come pausa. Il valore iniziale del timestamp, così come il valore iniziale del numero di sequenza, è una variabile casuale. Diversi pacchetti RTP consecutivi possono avere timestamp uguali se sono generati logicamente contemporaneamente, ad esempio, appartengono allo stesso frame video. I pacchetti RTP consecutivi possono contenere timestamp non monotoni se i dati non vengono trasmessi in ordine di campionamento, come nel caso dei frame video MPEG interpolati (tuttavia, i numeri di sequenza dei pacchetti saranno ancora monotoni durante la trasmissione).

SSRC: 32 bit. Il campo SSRC (sorgente di sincronizzazione) identifica la sorgente di sincronizzazione (vedere l'elenco delle abbreviazioni e dei termini utilizzati). Questo identificatore viene scelto a caso in modo che non ci siano due sorgenti di sincronizzazione all'interno della stessa sessione RTP con gli stessi identificatori SSRC. Sebbene sia improbabile che più fonti scelgano lo stesso identificatore, tutte le implementazioni RTP devono essere preparate per rilevare e risolvere tali collisioni. La sezione 6 discute la probabilità di collisione insieme a un meccanismo per risolverli e rilevare i loop del livello RTP in base all'unicità dell'identificatore SSRC. Se la sorgente cambia il suo indirizzo di trasporto originale, allora deve anche scegliere un nuovo identificatore SSRC in modo che non venga interpretato come una sorgente in loop.

Elenco CSRC: da 0 a 15 elementi, 32 bit ciascuno. L'elenco CSRC (contributing source) identifica le sorgenti incluse del traffico contenuto nel pacchetto. Il numero di identificatori è specificato dal campo CC. Se ci sono più di quindici fonti incluse, solo 15 di esse possono essere identificate. Gli ID CSRC vengono inseriti dai mixer quando si utilizzano gli ID SSRC per le origini di inclusione. Ad esempio, per i pacchetti audio, gli SSRC di tutte le origini che sono stati mischiati al momento della creazione del pacchetto sono elencati nell'elenco CSRC, fornendo un'indicazione corretta delle origini del messaggio al destinatario.

3.2. Sessioni RTP

Come accennato in precedenza, in accordo con il protocollo RTP, diversi tipi di traffico devono essere trasmessi separatamente, in diverse sessioni RTP. Una sessione è definita da una coppia specifica di indirizzi di trasporto di destinazione (un indirizzo di rete più una coppia di porte per RTP e RTCP). Ad esempio, in una teleconferenza composta da segnali audio e video codificati separatamente, ogni tipo di traffico deve essere inviato in una sessione RTP separata con un proprio indirizzo di trasporto di destinazione. Audio e video non dovrebbero essere trasmessi nella stessa sessione RTP e separati in base al tipo di traffico o ai campi SSRC. Intercalare i pacchetti con Vari tipi traffico, ma utilizzando lo stesso SSRC, causerebbe alcuni problemi:

Se uno dei tipi di traffico cambia durante una sessione, non ci saranno mezzi generali per determinare quale dei vecchi valori è stato sostituito da quello nuovo.
SSRC identifica un singolo valore di intervallo di tempo e lo spazio del numero di sequenza. L'interlacciamento di più tipi di traffico richiederebbe intervalli di sincronizzazione diversi se le frequenze di clock dei diversi flussi sono diverse e spazi di numeri di sequenza diversi per indicare il tipo di traffico a cui si riferisce la perdita di pacchetti.
I messaggi del mittente e del destinatario RTCP (vedere la sezione 4.3) descrivono solo un valore di intervallo di tempo e lo spazio del numero di sequenza per l'SSRC e non contengono un campo del tipo di traffico.
Il mixer RTP non è in grado di combinare flussi interlacciati di diversi tipi di traffico in un unico flusso.
I seguenti fattori ostacolano la trasmissione di molti tipi di traffico in un'unica sessione RTP: l'uso di diversi percorsi di rete o distribuzione di risorse di rete; ricevere un sottoinsieme dei dati multimediali quando richiesto, ad esempio solo audio se il segnale video ha superato la larghezza di banda disponibile; implementazioni del ricevitore che utilizzano processi separati per diversi tipi di traffico, mentre l'utilizzo di sessioni RTP separate consente implementazioni di processi singoli o multipli.

Utilizzando SSRC differenti per ogni tipo di traffico, ma trasmettendoli nella stessa sessione RTP, si possono evitare i primi tre problemi, ma non gli ultimi due. Pertanto, la specifica del protocollo RTP impone che ogni tipo di traffico abbia la propria sessione RTP.

3.3. Modifiche all'intestazione RTP specifiche del profilo

L'intestazione del pacchetto di informazioni RTP esistente è completa per l'insieme di funzioni richieste in generale per tutte le classi di applicazioni che potrebbero supportare RTP. Tuttavia, per meglio adattarsi a esigenze specifiche, l'intestazione può essere modificata tramite modifiche o aggiunte definite nella specifica del profilo.

Il bit marker e il campo del tipo di traffico contengono informazioni specifiche del profilo, ma si trovano in un'intestazione fissa perché si prevede che molte applicazioni ne abbiano bisogno. L'ottetto che contiene questi campi può essere sovrascritto dal profilo per soddisfare requisiti diversi, ad esempio, con più o meno bit di marker. Se sono presenti bit marker, DEVONO essere posizionati nei bit più significativi dell'ottetto, poiché i monitor indipendenti dal profilo possono essere in grado di osservare la correlazione tra i modelli di perdita di pacchetti e il bit marker.

Le informazioni aggiuntive necessarie per un particolare formato di traffico (ad esempio, il tipo di codifica video) dovrebbero essere riportate nel campo dati del pacchetto. Può essere posizionato in un punto specifico all'inizio o all'interno dell'array di dati.

Se una particolare classe di applicazioni necessita di funzionalità aggiuntive indipendenti dal formato del traffico, il profilo con cui operano queste applicazioni dovrebbe definire campi fissi aggiuntivi immediatamente dopo il campo SSRC dell'intestazione fissa esistente. Queste applicazioni saranno in grado di accedere rapidamente direttamente a campi aggiuntivi, mentre i monitor o i registratori indipendenti dal profilo saranno ancora in grado di elaborare i pacchetti RTP interpretando solo i primi dodici ottetti.

Se si ritiene necessaria una funzionalità aggiuntiva comune a tutti i profili, allora una nuova versione RTP per modificare l'intestazione fissa permanente.

3.4. Estensione dell'intestazione RTP

Per consentire alle singole implementazioni di sperimentare nuove funzionalità indipendenti dal formato del traffico che richiedono informazioni aggiuntive da trasportare nell'intestazione del pacchetto di informazioni, RTP fornisce un meccanismo di estensione dell'intestazione. Questo meccanismo è progettato in modo che l'estensione dell'intestazione possa essere ignorata da altre applicazioni di comunicazione che non la richiedono.

Se il bit X nell'intestazione RTP è impostato su uno, viene aggiunta un'estensione dell'intestazione di lunghezza variabile all'intestazione RTP fissa (dopo l'elenco CSRC, se presente). Tieni presente che questa estensione dell'intestazione è solo per un uso limitato. L'estensione dell'intestazione del pacchetto RTP ha il seguente formato:

L'estensione contiene un campo di lunghezza a 16 bit che indica il numero di parole a 32 bit al suo interno, esclusa l'intestazione di quattro ottetti dell'estensione (quindi la lunghezza può essere zero). È possibile aggiungere solo un'estensione all'intestazione fissa del pacchetto di informazioni RTP. Per consentire a ciascuna delle numerose implementazioni interoperabili di sperimentare in modo indipendente diverse estensioni di intestazione o per consentire a una particolare implementazione di sperimentare più di un tipo di estensione di intestazione, l'uso dei primi 16 bit dell'estensione è indefinito, lasciato agli identificatori distintivi o parametri. Il formato di questi 16 bit deve essere determinato dalla specifica del profilo con cui operano le applicazioni.

1999
2000

Il problema più urgente sta diventando sempre più la mancanza di spazio degli indirizzi, che richiede un cambiamento nel formato dell'indirizzo.

Un altro problema è la mancanza di scalabilità del routing, fondamento delle reti IP. La rapida crescita della rete provoca la congestione dei router, che oggi sono costretti a mantenere tabelle di routing con decine o centinaia di migliaia di voci, nonché a risolvere il problema della frammentazione dei pacchetti. È possibile facilitare il lavoro dei router, in particolare, aggiornando il protocollo IP.

Insieme all'introduzione di nuove funzioni direttamente nel protocollo IP, è consigliabile assicurare una sua più stretta interazione con i nuovi protocolli introducendo nuovi campi nell'intestazione del pacchetto.

Di conseguenza, si è deciso di aggiornare il protocollo IP con i seguenti obiettivi principali:

creazione di un nuovo schema di indirizzamento esteso;
migliorare la scalabilità della rete riducendo le funzioni dei router di dorsale;
garantire la protezione dei dati.

Espandere lo spazio degli indirizzi... Il protocollo IP risolve il potenziale problema della carenza di indirizzi espandendo la larghezza dell'indirizzo a 128. Tuttavia, un aumento così significativo della lunghezza dell'indirizzo è stato realizzato in gran parte non per eliminare il problema della carenza di indirizzi, ma per migliorare l'efficienza del reti basate su questo protocollo. L'obiettivo principale era cambiare strutturalmente il sistema di indirizzamento, ampliarne le funzionalità.

Invece dei due livelli esistenti della gerarchia degli indirizzi (numero di rete e numero di nodo), IPv6 propone di utilizzare quattro livelli, il che implica l'identificazione della rete a tre livelli e un livello per l'identificazione del nodo.

Ora l'indirizzo è scritto in forma esadecimale, con ogni quattro cifre separate l'una dall'altra da due punti, ad esempio:

FEDC: 0A96: 0: 0: 0: 0: 7733: 567A.

Per le reti che supportano entrambe le versioni del protocollo IPv4 e IPv6, è possibile utilizzare la tradizionale notazione decimale per i 4 byte inferiori ed esadecimale per quelli superiori:

0: 0: 0: 0: FFFF 194.135.75.104.

All'interno del sistema di indirizzamento IPv6, esiste anche uno spazio di indirizzi dedicato per l'uso locale, ovvero per le reti al di fuori di Internet. Ci sono due tipi indirizzi locali: per reti "piatte", non subnettate (Link-Local), e per reti suddivise in subnet (Site-Local), che differiscono per il valore del prefisso.

Modifica del formato delle intestazioni dei pacchetti. Ciò può essere realizzato dal nuovo schema organizzativo delle "intestazioni nidificate", che prevede la divisione dell'intestazione in quella principale, che contiene il minimo necessario di informazioni, e quelle aggiuntive, che possono essere assenti. Questo approccio apre ampie possibilità per estendere il protocollo definendo nuove intestazioni opzionali, rendendo il protocollo aperto.

L'intestazione del datagramma IPv6 di base a 40 byte ha il seguente formato (Figura 2.4).

Campo Classe di trafficoè equivalente nello scopo al campo Tipo di servizio e il campo Limite di luppolo- campo Tempo di vivere protocollo IPv4.

Campo Etichetta di flusso consente di isolare ed elaborare in modo mirato singoli flussi di dati senza la necessità di analizzare il contenuto dei pacchetti. Questo è molto importante in termini di riduzione del carico sui router.

Campo Intestazione successivaè analogo al campo Protocollo IPv4 e definisce il tipo di intestazione che segue l'intestazione principale. Ogni successiva intestazione aggiuntiva contiene anche un campo Intestazione successiva.

2.3.3. protocollo TCP

Protocollo di controllo trasmissione di informazioni (Transmission Control Protocol - TCP) è stata sviluppata per supportare la comunicazione interattiva tra computer. Il protocollo TCP garantisce l'affidabilità e l'affidabilità dello scambio di dati tra processi su computer che fanno parte di una rete comune.

Sfortunatamente, il protocollo TCP non è adatto alla trasmissione di informazioni multimediali. Il motivo principale è la presenza di controllo sulla consegna. Il monitoraggio impiega troppo tempo per trasmettere informazioni più sensibili al ritardo. Inoltre, TCP fornisce meccanismi per controllare la velocità di trasmissione per evitare la congestione della rete. I dati audio e video, tuttavia, richiedono bit rate rigorosamente definiti che non possono essere modificati arbitrariamente.

Da un lato, il protocollo TCP interagisce con il protocollo applicativo applicazione personalizzata, e dall'altro - con un protocollo che fornisce funzioni di "basso livello" di instradamento e indirizzamento dei pacchetti, che, di regola, viene eseguito da IP.

La struttura logica del software di rete che implementa i protocolli della famiglia TCP/IP in ogni nodo di Internet è mostrata in Fig. 2.5.

I rettangoli rappresentano i moduli che elaborano i dati e le linee che collegano i rettangoli rappresentano i percorsi di trasferimento dei dati. La linea orizzontale nella parte inferiore della figura indica Rete Ethernet che viene utilizzato come esempio di un ambiente fisico.

Riso. 2.5.

Per stabilire una connessione tra due processi su diversi computer della rete, è necessario conoscere non solo gli indirizzi Internet dei computer, ma anche i numeri di quelle porte TCP (socket) che i processi utilizzano su questi computer. Qualsiasi connessione TCP su Internet è identificata in modo univoco da due indirizzi IP e due numeri di porta TCP.

TCP può gestire pacchetti danneggiati, persi, duplicati o fuori servizio. Ciò è ottenuto attraverso un meccanismo per assegnare un numero di sequenza a ciascun pacchetto trasmesso e un meccanismo per controllare la ricezione dei pacchetti.

Quando TCP trasmette un segmento di dati, una copia di quei dati viene inserita in una coda di ritrasmissione e viene avviato un timer per attendere un riconoscimento.

2.3.4. Protocollo UDP

Lo User Datagram Protocol (UDP) viene utilizzato per scambiare datagrammi tra processi di computer situati in un sistema unificato di reti di computer.

UDP si basa su IP e fornisce ai processi applicativi servizi di trasporto non molto diversi da quelli dell'IP. Il protocollo UDP prevede la consegna dei dati non garantita, cioè non richiede conferma della sua ricezione; inoltre, questo protocollo non richiede l'instaurazione di una connessione tra la sorgente e il destinatario dell'informazione, cioè tra moduli UDP.

2.3.5. Protocolli RTP e RTCP

Concetti basilari

Si noti che la stessa RTP non dispone di alcun meccanismo per garantire la trasmissione tempestiva dei dati e qualità del servizio ma utilizza i servizi sottostanti per fornire questo. Non impedisce l'out-of-order dei pacchetti, né implica che la dorsale sia completamente affidabile e inoltri i pacchetti nell'ordine corretto. I numeri di sequenza inclusi in RTP consentono al destinatario di ricostruire la sequenza dei pacchetti del mittente.

RTP supporta sia la comunicazione bidirezionale che il trasferimento di dati a un gruppo di destinazioni se il multicast è supportato dalla rete sottostante. RTP è progettato per fornire le informazioni richieste dalle singole applicazioni e, nella maggior parte dei casi, è integrato nel funzionamento dell'applicazione.

Blocchi di dati del protocollo RTP / RTCP sono chiamati pacchetti. I pacchetti generati secondo il protocollo RTP e utilizzati per trasmettere dati multimediali sono chiamati pacchetti di dati e i pacchetti generati secondo il protocollo RTCP e utilizzati per trasferire le informazioni di servizio necessarie per un funzionamento affidabile teleconferenze sono chiamati pacchetti di controllo o pacchetti di controllo. Un pacchetto RTP include un'intestazione fissa, un'estensione dell'intestazione variabile opzionale e un campo dati. Un pacchetto RTCP inizia con una porzione fissa (simile a una porzione fissa pacchetti informativi RTP) seguito da elementi strutturali che hanno lunghezza variabile.

Al fine di rendere il protocollo RTP più flessibile e utilizzabile per varie applicazioni, alcuni suoi parametri sono resi volutamente vaghi, ma prevede il concetto di profilo. Un profilo è un insieme di parametri per i protocolli RTP e RTCP per una specifica classe di applicazioni, che determina le caratteristiche del loro funzionamento. Il profilo definisce: l'uso di campi di intestazione dei singoli pacchetti, tipi di traffico, aggiunte ed estensioni di intestazioni, tipi di pacchetti, servizi e algoritmi di sicurezza delle comunicazioni, specifiche dell'utilizzo del protocollo di livello inferiore, ecc. Ogni applicazione di solito funziona con un solo profilo e il tipo di profilo viene impostato selezionando l'applicazione appropriata. Non vi è alcuna indicazione esplicita del tipo di profilo per numero di porta, identificatore di protocollo, ecc.

Pertanto, una specifica RTP completa per un'applicazione specifica dovrebbe includere documenti aggiuntivi che includono una descrizione del profilo e una descrizione del formato del traffico che definisce come verrà gestito un tipo specifico di traffico, come audio o video, in RTP.

Audioconferenza di gruppo

L'audioconferenza multicast richiede un indirizzo multicast multiutente e due porte. In questo caso, una porta è necessaria per lo scambio di dati audio e l'altra è utilizzata per i pacchetti di controllo RTCP. L'indirizzo multicast e le informazioni sulla porta vengono trasmesse ai potenziali partecipanti teleconferenze... Se è richiesta la segretezza, le informazioni e i pacchetti di controllo possono essere crittografati, nel qual caso devono anche essere generati e chiave distribuita crittografia.

Su Internet, come in altre reti di dati a commutazione di pacchetto, i pacchetti a volte vengono persi e riordinati, e anche ritardati per tempi diversi. Per contrastare questi eventi, l'intestazione RTP contiene un timestamp e un numero di sequenza che consentono ai destinatari di risincronizzarsi al loro stato originale in modo che, ad esempio, porzioni del segnale audio vengano riprodotte dall'altoparlante continuamente ogni 20 ms. Questa ricostruzione della sincronizzazione viene eseguita separatamente e indipendentemente per ciascuna sorgente di pacchetti RTP in teleconferenze... Il numero di sequenza può essere utilizzato anche dal ricevitore per stimare il numero di pacchetti persi.

Dal momento che i partecipanti teleconferenze può entrare e uscire durante la conferenza, è utile sapere chi sta partecipando in questo momento e come i partecipanti alla conferenza ricevono i dati audio. A tal fine, ogni istanza dell'applicazione audio durante la conferenza emette periodicamente messaggi sulla porta di controllo (porta RTCP) per le richieste di tutti gli altri partecipanti sulla ricezione di pacchetti con l'indicazione del loro nome utente. Il messaggio di ricezione indica quanto bene viene ascoltato l'altoparlante corrente e può essere utilizzato per controllare gli encoder adattivi. Oltre al nome utente, possono essere incluse anche altre informazioni di identificazione per il controllo della larghezza di banda. All'uscita dalla conferenza, il sito invia un pacchetto RTCP BYE.

Videoconferenze

Se in teleconferenze vengono utilizzati entrambi i segnali audio e video, vengono trasmessi separatamente. Per la trasmissione di ogni tipo di traffico, indipendentemente dall'altro, la specifica del protocollo introduce il concetto di sessione RTP. Una sessione è identificata da una coppia specifica di indirizzi di trasporto di destinazione (un indirizzo di rete più una coppia di porte per RTP e RTCP). I pacchetti per ogni tipo di traffico vengono trasmessi utilizzando due diverse coppie di porte UDP e/o indirizzi multicast. Non esiste una connessione RTP diretta tra le sessioni di comunicazione audio e video, tranne che l'utente che partecipa a entrambe le sessioni deve utilizzare lo stesso nome canonico nei pacchetti RTCP per entrambe le sessioni in modo che le sessioni possano essere collegate.

Capire mixer e traduttori

Non tutti i siti sono sempre in grado di ricevere dati multimediali nello stesso formato. Si consideri il caso in cui i partecipanti dalla stessa posizione siano collegati tramite una linea a bassa velocità alla maggior parte degli altri partecipanti alla conferenza che hanno accesso alla rete a banda larga. Piuttosto che costringere tutti a utilizzare una larghezza di banda più stretta e una codifica audio di qualità inferiore, una struttura di comunicazione a livello RTP chiamata mixer può essere collocata in un'area di larghezza di banda stretta. Questo mixer risincronizza i pacchetti audio in ingresso per ripristinare gli intervalli di 20 ms originali, mescola questi flussi audio ricostruiti in un singolo flusso, codifica il segnale audio per una larghezza di banda stretta e trasmette il flusso di pacchetti su un collegamento a bassa velocità. In questo caso, i pacchetti possono essere indirizzati a un destinatario oa un gruppo di destinatari con indirizzi diversi. In modo che l'indicazione corretta possa essere fornita agli endpoint riceventi fonte di messaggi L'intestazione RTP include un mezzo per identificare le sorgenti coinvolte nel pacchetto misto per i mixer.

Alcuni dei partecipanti all'audioconferenza potrebbero essere connessi tramite collegamenti a banda larga, ma potrebbero non essere raggiungibili tramite conferenze IP multicast (IPM). Ad esempio, potrebbero trovarsi dietro un firewall a livello di applicazione che non consentirà alcuna trasmissione di pacchetti IP. Per tali casi, non sono necessari mixer, ma altri tipi di comunicazioni a livello RTP, chiamati traduttori. Dei due traduttori, uno è installato all'esterno del firewall e dall'esterno inoltra tutti i pacchetti multicast ricevuti tramite la connessione sicura all'altro traduttore dietro il firewall. Il traduttore dietro il firewall li ritrasmette come pacchetti multicast al gruppo multiutente limitato alla rete interna del sito.

Protocollo di controllo RTCP

Tutti i campi dei pacchetti RTP/RTCP vengono trasmessi in rete per byte (ottetti); il byte più significativo viene trasmesso per primo. Tutti i dati del campo di intestazione sono allineati in base alla loro lunghezza. Gli ottetti designati come opzionali hanno valore zero.

Protocollo di controllo RTCP (RTCP - Real-Time Control Protocol) si basa sulla trasmissione periodica di pacchetti gestione a tutti i partecipanti a una sessione di comunicazione utilizzando lo stesso meccanismo di distribuzione di RTP. Il protocollo di livello inferiore deve fornire il multiplexing di informazioni e pacchetti di controllo, ad esempio, utilizzando diversi numeri di porta UDP. RTCP ha quattro funzioni principali.

La funzione principale è quella di fornire feedback valutare la qualità della distribuzione dei dati. È una funzione intrinseca di RTCP come protocollo di trasporto ed è collegata alle funzioni di controllo del flusso e della congestione di altri protocolli di trasporto. Il feedback può essere direttamente utile per la gestione della codifica adattiva, ma gli esperimenti con il multicast IP hanno dimostrato che il feedback del destinatario è importante anche per la diagnosi dei difetti di propagazione. L'invio di rapporti di feedback sull'acquisizione dei dati a tutti i partecipanti consente di osservare i problemi per valutare se sono locali o globali. Con il meccanismo di distribuzione IPM per entità come i fornitori di servizi di rete, è anche possibile ricevere informazioni di feedback e agire come monitor di terze parti nella diagnosi dei problemi di rete. Questa funzione di feedback è fornita dai rapporti del mittente e del destinatario RTCP.
RTCP mantiene un identificatore di origine dati RTP persistente a livello di trasporto chiamato "nome canonico" (CNAME). Poiché l'ID SSRC può cambiare se viene rilevato un conflitto o il programma viene riavviato, i destinatari hanno bisogno del CNAME canonico per tenere traccia di ogni collaboratore. I destinatari richiedono anche CNAME per mappare il set le informazioni fluiscono da un determinato partecipante a più sessioni RTP associate, ad esempio durante la sincronizzazione dei segnali audio e video.
Le prime due funzionalità richiedono che tutti i peer inviino pacchetti RTCP, quindi, per consentire la scalabilità dei numeri peer, l'RTP deve essere controllato dalla velocità. Quando inviato da ciascun partecipante teleconferenze pacchetti di controllo a tutti gli altri partecipanti, ognuno può stimare autonomamente il numero totale dei partecipanti.
Una quarta funzione RTCP, facoltativa, deve fornire informazioni sul controllo della sessione (ad esempio, l'identificazione del partecipante) che si rifletteranno nell'interfaccia utente. Questo è molto probabilmente utile nelle sessioni "liberamente controllate" in cui i membri si uniscono e lasciano un gruppo senza controllo della proprietà o negoziazione.

Le funzioni da uno a tre sono necessarie quando RTP viene utilizzato in multicast IP e sono consigliate in tutti gli altri casi. Gli sviluppatori di applicazioni RTP sono incoraggiati a evitare meccanismi solo bidirezionali che non si adattano per ospitare più utenti.

Tariffa pacchetto RTCP

RTP consente a un'applicazione di scalare automaticamente la rappresentatività di una sessione di comunicazione da pochi partecipanti a diverse migliaia. Ad esempio, in un'audioconferenza, il traffico dati è essenzialmente autolimitante perché solo una o due persone alla volta possono parlare e, nella distribuzione di gruppo, la velocità dei dati su qualsiasi collegamento rimane relativamente costante, indipendentemente dal numero di partecipanti. Tuttavia, il traffico di gestione non è autolimitante. Se i rapporti di ricezione di ciascun partecipante vengono inviati a velocità costante, il traffico gestionale crescerà linearmente con l'aumento del numero dei partecipanti. Pertanto, deve essere previsto un meccanismo speciale per ridurre la frequenza di trasmissione dei pacchetti di controllo.

Per ogni sessione, si presume che il traffico dati soddisfi un limite aggregato, chiamato larghezza di banda della sessione, condiviso da tutti i partecipanti. Questa larghezza di banda può essere riservata e limitata dalla rete. La larghezza di banda della sessione è indipendente dal tipo di codifica del supporto, ma la selezione del tipo di codifica può essere limitata dalla larghezza di banda della sessione di comunicazione. Il parametro della larghezza di banda della sessione dovrebbe essere fornito dall'applicazione di gestione della sessione quando richiama l'applicazione multimediale, ma le applicazioni multimediali possono anche impostare un valore predefinito basato sulla larghezza di banda dei dati del singolo mittente per il tipo di codifica selezionato per la sessione.

I calcoli della larghezza di banda per il controllo e il traffico dati si basano sui protocolli di trasporto e livello di rete sottostanti (come UDP e IP). Le intestazioni Data Link Layer (DLC) non vengono prese in considerazione nei calcoli, poiché un pacchetto può essere incapsulato con diverse intestazioni di livello DLC mentre viene trasmesso.

Il traffico di controllo dovrebbe essere limitato a una parte piccola e nota della larghezza di banda della sessione: abbastanza piccola da non pregiudicare la funzione principale del protocollo di trasporto, ovvero la trasmissione dei dati; noto in modo che il traffico di gestione possa essere incluso nella specifica della larghezza di banda data al protocollo prenotazione delle risorse, e in modo che ogni partecipante possa calcolare autonomamente la propria quota. Si presume che la porzione della larghezza di banda della sessione assegnata a RTCP debba essere impostata al 5%. Tutti i partecipanti alla sessione devono utilizzare la stessa quantità di larghezza di banda RTCP in modo che l'intervallo del pacchetto di controllo calcolato sia lo stesso. Pertanto, queste costanti devono essere impostate per ogni profilo.

L'algoritmo per il calcolo dell'intervallo tra l'invio di pacchetti RTCP compositi per la condivisione della larghezza di banda assegnata per il traffico di controllo tra i partecipanti ha le seguenti caratteristiche principali:

I mittenti condividono almeno 1/4 della larghezza di banda del traffico di controllo, come nelle sessioni con un numero elevato di destinatari, ma con un numero ridotto di mittenti; non appena stabilita la connessione, i partecipanti ricevono in breve tempo i CNAME dei siti trasmittenti;
è richiesto che l'intervallo stimato tra i pacchetti RTCP sia di almeno 5 secondi al fine di evitare burst di pacchetti RTCP eccedenti la banda consentita quando il numero di partecipanti è ridotto e il traffico non è livellato secondo la legge dei grandi numeri;
l'intervallo tra i pacchetti RTCP varia casualmente da metà a un intervallo e mezzo calcolati per evitare la sincronizzazione involontaria di tutti i partecipanti. Anche il primo pacchetto RTCP inviato dopo l'accesso a una sessione viene ritardato in modo casuale (fino alla metà dell'intervallo RTCP minimo) se un'applicazione viene avviata in più siti contemporaneamente, ad esempio quando si annuncia l'inizio di una sessione;
per adattarsi automaticamente alle variazioni della quantità di informazioni di controllo trasmesse, viene calcolata una stima dinamica della dimensione media del pacchetto RTCP composito utilizzando tutti i pacchetti ricevuti e inviati;
questo algoritmo può essere utilizzato per sessioni in cui la trasmissione dei pacchetti è valida per tutti i partecipanti. In questo caso, il parametro della larghezza di banda della sessione è il prodotto della larghezza di banda del singolo mittente per il numero di partecipanti e la larghezza di banda RTP si basa sul protocollo sottostante per fornire un'indicazione della lunghezza. La lunghezza massima dei pacchetti RTP è limitata solo dai protocolli sottostanti.
Più pacchetti RTP possono essere trasportati in una singola unità dati di protocollo di livello inferiore, come un pacchetto UDP. Ciò riduce la ridondanza delle intestazioni e semplifica la sincronizzazione tra i diversi flussi.

Quando noi, parlando su un telefono IP, sentiamo la voce dell'interlocutore nel ricevitore, oppure, utilizzando un sistema di videoconferenza, comunichiamo con i nostri colleghi e parenti, scambiamo un flusso continuo di dati. Quando si trasferiscono dati in streaming come voce e video su una rete a pacchetto, è molto importante utilizzare meccanismi che risolvano i seguenti problemi:

Elimina l'effetto della perdita di pacchetti
Ristabilire l'ordine e controllare l'arrivo dei pacchi
Levigare l'effetto di ritardo (jitter)

Era per questi scopi che RTP(Real-time Transport Protocol) è il protocollo di trasporto in tempo reale che verrà discusso nell'articolo di oggi. Il protocollo è stato sviluppato presso l'IETF dall'Audio-Video Transport Working Group ed è descritto in RFC 3550.

In genere, RTP viene eseguito su User Datagram Protocol (UDP) perché è molto importante garantire che venga consegnato in tempo durante la trasmissione di dati multimediali.

RTP include la capacità di identificare il tipo di payload e assegnare un numero di pacchetto sequenziale in un flusso, nonché l'uso di timestamp.

Sul lato trasmittente, ogni pacchetto viene marcato con data e ora, il lato ricevente lo riceve e determina il ritardo totale, dopodiché viene calcolata la differenza nei ritardi totali e viene determinato il jitter. Pertanto, diventa possibile impostare un ritardo di consegna del pacchetto costante e quindi ridurre l'effetto del jitter.

Un'altra funzione RTP è associata alla possibile perdita di pacchetti durante il passaggio attraverso la rete IP, che si riflette nella comparsa di brevi pause nella conversazione. Il silenzio improvviso nel ricevitore telefonico, di regola, ha un effetto molto negativo sull'ascoltatore, quindi le capacità del protocollo RTP riempiono tali periodi di silenzio con il cosiddetto "rumore di comfort"

RTP funziona in combinazione con un altro protocollo IETF, ovvero RTCP (Real - time Transport Control Protocol), descritto in RFC 3550. RTCP è progettato per raccogliere informazioni statistiche, determinare la qualità del servizio (QoS) (Quality of Service), come nonché per la sincronizzazione tra i flussi multimediali di una sessione RTP.

La funzione principale di RTCP è quella di stabilire un feedback con l'applicazione per riferire sulla qualità delle informazioni ricevute. I partecipanti a una sessione RTCP si scambiano informazioni sul numero di pacchetti ricevuti e persi, il valore del jitter, la latenza, ecc. Sulla base dell'analisi di queste informazioni, viene presa la decisione di modificare i parametri di trasmissione, ad esempio per ridurre il rapporto di compressione delle informazioni al fine di migliorare la qualità della loro trasmissione.

Per eseguire queste funzioni, RTCP invia messaggi speciali di determinati tipi:

SR - Report mittente - report di origine con informazioni statistiche sulla sessione RTP
RR - Report del ricevitore: report del ricevitore con informazioni statistiche sulla sessione RTP
SDES - contiene una descrizione dei parametri di origine incluso cname (nome utente)
ADDIO – Avvia la fine dell'appartenenza al gruppo
APP - Descrizione delle funzioni dell'applicazione

RTP è un protocollo unidirezionale, quindi la comunicazione bidirezionale richiede due sessioni RTP, una su ciascun lato.

Una sessione RTP è determinata dagli indirizzi IP dei partecipanti, nonché da una coppia di porte UDP non riservate nell'intervallo 16384 - 32767. Inoltre, per organizzare il feedback con l'applicazione, è necessario stabilire anche una sessione RTCP a due vie . Per le sessioni RTCP, vengono occupate le porte con numero uno maggiore di RTP. Ad esempio, se viene selezionata la porta 19554 per RTP, la sessione RTCP occuperà la porta 19555. La formazione di una sessione RTP/RTCP è chiaramente mostrata nella figura sottostante.

Se un giorno dovrai frettolosamente capire cos'è il VoIP (voice over IP) e cosa significano tutte queste abbreviazioni selvagge, spero che questo tutorial possa essere d'aiuto. Prendo subito atto che i problemi di configurazione di ulteriori tipi di servizi di telefonia (come trasferimento di chiamata, posta vocale, chiamate in conferenza, ecc.) Non vengono qui considerati.

Quindi, di cosa ci occuperemo sotto il taglio:

Concetti base di telefonia: tipologie di dispositivi, schemi di collegamento
Pacchetto protocollo SIP/SDP/RTP: come funziona
Come vengono trasmesse le informazioni sui pulsanti premuti
Come vengono trasmessi voce e fax
Elaborazione del segnale digitale e garanzia della qualità del suono nella telefonia IP

1. Concetti base di telefonia

In generale, lo schema per collegare un abbonato locale a un provider telefonico tramite una normale linea telefonica è il seguente:

Sul lato provider (PBX) è installato un modulo telefonico con una porta FXS (Foreign eXchange Subscriber). A casa o in ufficio sono installati un telefono o un fax con una porta FXO (Foreign eXchange Office) e un modulo dialer.

Di aspetto esteriore le porte FXS e FXO non differiscono in alcun modo, si tratta di normali connettori RJ11 a 6 pin. Ma con l'aiuto di un voltmetro è molto facile distinguerli: ci sarà sempre un po' di tensione sulla porta FXS: 48/60 V quando il ricevitore è agganciato o 6-15 V durante una chiamata. Su FXO, se non connesso alla linea, la tensione è sempre 0.

Per trasferire i dati su una linea telefonica lato provider, è necessaria una logica aggiuntiva, che può essere implementata sul modulo SLIC (circuito interfaccia linea abbonato) e lato abbonato - utilizzando il modulo DAA (Direct Access Arrangement).

I telefoni wireless DECT (Digital European Cordless Telecommunications) sono molto popolari ora. Per progettazione, sono simili ai normali telefoni: hanno anche una porta FXO e un modulo dialer, ma aggiungono anche una stazione wireless e un modulo ricevitore a una frequenza di 1,9 GHz.

Gli abbonati sono collegati alla rete PSTN (rete telefonica pubblica commutata) - la rete telefonica uso comune, ovvero PSTN, PSTN. La rete PSTN può essere organizzata utilizzando diverse tecnologie: ISDN, ottica, POTS, Ethernet. Un caso speciale di PSTN, quando viene utilizzata una normale linea analogica / in rame - POTS (Plain Old Telephone Service) - un semplice vecchio sistema telefonico.

Con lo sviluppo di Internet comunicazioni telefoniche spostato su un nuovo livello. I telefoni fissi sono sempre meno utilizzati, principalmente per esigenze lavorative. I telefoni DECT sono un po' più convenienti, ma sono limitati dal perimetro della casa. I telefoni GSM sono ancora più convenienti, ma sono limitati all'interno del paese (il roaming è costoso). Ma per i telefoni IP sono anche softphone (SoftPhone), non ci sono restrizioni, tranne per l'accesso a Internet.

Skype è l'esempio più famoso di softphone. Può fare molte cose, ma ha due importanti inconvenienti: l'architettura chiusa e le intercettazioni sono conosciute da quali autorità. A causa del primo, non c'è modo di creare la propria microrete telefonica. E a causa del secondo, non è molto piacevole essere spiati, soprattutto nelle conversazioni personali e commerciali.

Fortunatamente esistono protocolli aperti per creare le proprie reti di comunicazione con i vantaggi di SIP e H.323. Esistono leggermente più softphone basati su SIP rispetto a H.323, il che può essere spiegato dalla relativa semplicità e flessibilità. Ma a volte questa flessibilità può inserire grossi bastoncini nelle ruote. Sia SIP che H.323 utilizzano il protocollo RTP per trasferire i media.

Consideriamo i principi di base del protocollo SIP per capire come sono collegati due abbonati.

2. Descrizione di un pacchetto di protocolli SIP/SDP/RTP

SIP (Session Initiation Protocol) è un protocollo per stabilire una sessione (non solo telefonica), è un protocollo testuale su UDP. È anche possibile utilizzare SIP su TCP, ma questi sono casi rari.

SDP (Session Description Protocol) è un protocollo per negoziare il tipo di dati trasmessi (per audio e video, questi sono i codec e i loro formati, per i fax - velocità di trasmissione e correzione degli errori) e i loro indirizzi di destinazione (IP e porta). È anche un protocollo basato su testo. I parametri SDP vengono trasmessi nel corpo dei pacchetti SIP.

RTP (Real-time Transport Protocol) è un protocollo di trasferimento dati audio/video. È un protocollo binario su UDP.

Struttura generale dei pacchetti SIP:

Start-Line: campo che indica il metodo SIP (comando) quando richiesto o il risultato dell'esecuzione di un metodo SIP quando si risponde.
Intestazioni: informazioni aggiuntive alla Start-Line, formattate come righe contenenti coppie ATTRIBUTE: VALUE.
Corpo: dati binari o di testo. Tipicamente utilizzato per trasferire parametri o messaggi SDP.

Ecco un esempio di due pacchetti SIP per una procedura comune - configurazione della chiamata:

A sinistra c'è il contenuto del pacchetto SIP INVITE, a destra - la risposta ad esso - SIP 200 OK.

I campi principali sono evidenziati con cornici:

Metodo/Richiesta-URI contiene il metodo SIP e l'URI. Nell'esempio, viene stabilita una sessione: il metodo INVITE, una chiamata all'abbonato [e-mail protetta]
Status-Code - codice di risposta al comando SIP precedente. In questo esempio, il comando è stato completato con successo - codice 200, ad es. l'abbonato 555 ha preso il telefono.
Via - l'indirizzo al quale l'abbonato 777 è in attesa di una risposta. Per un messaggio 200 OK, questo campo viene copiato dal messaggio INVITE.
Da / A - Il nome visualizzato e l'indirizzo del mittente e del destinatario del messaggio. Per un messaggio 200 OK, questo campo viene copiato dal messaggio INVITE.
Cseq contiene il numero di sequenza del comando e il nome del metodo a cui appartiene questo messaggio. Per un messaggio 200 OK, questo campo viene copiato dal messaggio INVITE.
Content-Type è il tipo di dati che vengono trasmessi nel blocco Body, in questo caso i dati SDP.
Informazioni sulla connessione - Indirizzo IP a cui il secondo abbonato deve inviare i pacchetti RTP (o pacchetti UDPTL in caso di trasmissione fax su T.38).
Descrizione supporto: la porta a cui il secondo abbonato deve trasmettere i dati specificati. In questo caso, questo è il suono (audio RTP / AVP) e un elenco di tipi di dati supportati: PCMU, PCMA, codec GSM e segnali DTMF.

Un messaggio SDP è costituito da righe contenenti coppie FIELD = VALUE. Tra i campi principali, si possono notare:

o- Origine, il nome dell'organizzatore della sessione e l'ID della sessione.
insieme a- Informazioni sulla connessione, il campo è descritto in precedenza.
m- Descrizione supporto, campo descritto in precedenza.
un- attributi media, specificare il formato dei dati trasmessi. Ad esempio, indicare la direzione del suono - ricezione o trasmissione (sendrecv), per i codec indicare la frequenza di campionamento e il numero di riferimento (rtpmap).

I pacchetti RTP contengono dati audio/video codificati in un formato specifico. Questo formato specificato nel campo PT (tipo di carico utile). La tabella di corrispondenza del valore di questo campo ad un formato specifico è riportata in https: // wikipedia org profilo audio video wiki RTP.

Anche nei pacchetti RTP è indicato un identificatore SSRC univoco (determina la sorgente del flusso RTP) e un timestamp (timestamp, utilizzato per la riproduzione uniforme di audio o video).

Un esempio di interazione tra due abbonati SIP tramite un server SIP (Asterisco):

Non appena il telefono SIP si avvia, prima di tutto si registra sul server remoto (SIP Registar), gli invia un messaggio SIP REGISTER.

Quando viene chiamato un abbonato, viene inviato un messaggio SIP INVITE, il cui corpo contiene un messaggio SDP, che specifica i parametri di trasmissione audio/video (quali codec sono supportati, a quale IP e porta inviare il suono, ecc.).

Quando l'utente remoto prende il telefono, riceviamo un messaggio SIP 200 OK anche con parametri SDP, solo l'utente remoto. Utilizzando i parametri SDP inviati e ricevuti è possibile stabilire una sessione audio/video RTP o una sessione fax T.38.

Se i parametri SDP ricevuti non ci soddisfano, o il server SIP intermedio decide di non far passare il traffico RTP attraverso se stesso, viene eseguita la procedura di rinegoziazione SDP, il cosiddetto REINVITE. A proposito, è proprio a causa di questa procedura che i server proxy SIP gratuiti hanno uno svantaggio: se entrambi gli abbonati si trovano nella stessa rete locale e il server proxy è dietro NAT, quindi dopo aver reindirizzato il traffico RTP, nessuno degli abbonati sentirà un altro.

Al termine della conversazione, l'abbonato che riaggancia invia un messaggio SIP BYE.

3. Trasferimento di informazioni sui pulsanti premuti

A volte, dopo aver stabilito una sessione, durante una conversazione, è necessario accedere a ulteriori tipi di servizi (ADO): chiamata in attesa, trasferimento, posta vocale, ecc. - che reagiscono a determinate combinazioni di pulsanti premuti.

Quindi, in una normale linea telefonica, ci sono due modi per comporre un numero:

Pulse - storicamente il primo, veniva utilizzato principalmente nei telefoni con combinatore rotativo. La selezione avviene per chiusura e apertura sequenziale della linea telefonica in base alla cifra selezionata.
Tono - composizione di un numero con codici DTMF (Dual-Tone Multi-Frequency) - ogni pulsante del telefono ha la propria combinazione di due segnali sinusoidali (toni). Eseguendo l'algoritmo di Goertzel, è abbastanza facile determinare il pulsante premuto.

Durante una chiamata, il metodo a impulsi è scomodo per la trasmissione del pulsante premuto. Quindi, ci vuole circa 1 secondo per trasmettere "0" (10 impulsi di 100 ms: 60 ms - interruzione di linea, 40 ms - chiusura di linea) più 200 ms per una pausa tra le cifre. Inoltre, durante la selezione a impulsi si sentono spesso dei clic caratteristici. Pertanto, nella telefonia convenzionale, viene utilizzata solo la modalità a toni di accesso al VAS.

Nella telefonia VoIP, le informazioni sui pulsanti premuti possono essere trasmesse in tre modi:

DTMF Inband - generando un tono audio e trasmettendolo all'interno dei dati audio (canale RTP corrente) - questa è una normale composizione a toni.
RFC2833: viene generato uno speciale evento telefonico a pacchetto RTP, che contiene informazioni sul tasto premuto, sul volume e sulla durata. Il numero del formato RTP in cui verranno trasmessi i pacchetti DTMF RFC2833 è specificato nel corpo del messaggio SDP. Ad esempio: a = rtpmap: 98 telefono-evento / 8000.
SIP INFO - viene formato un pacchetto SIP INFO con le informazioni sul tasto premuto, il volume e la durata.

La trasmissione DTMF all'interno dei dati audio (Inband) presenta diversi svantaggi: si tratta di risorse generali durante la generazione/incorporazione di toni e durante il loro rilevamento, limitazioni di alcuni codec che possono distorcere i codici DTMF e scarsa affidabilità durante la trasmissione (se alcuni dei pacchetti vengono persi, quindi il rilevamento può avvenire premendo due volte lo stesso tasto).

La principale differenza tra DTMF RFC2833 e SIP INFO: se il server proxy SIP abilita la trasmissione RTP direttamente tra gli abbonati bypassando il server stesso (ad esempio, canreinvite = yes in asterisco), il server non noterà i pacchetti RFC2833, per cui I servizi VAS non sono più disponibili... I pacchetti SIP vengono sempre trasmessi tramite server proxy SIP, quindi VAS funzionerà sempre.

4. Trasmissione vocale e fax

Come già accennato, il protocollo RTP viene utilizzato per trasferire i dati multimediali. I pacchetti RTP indicano sempre il formato dei dati trasmessi (codec).

Esistono molti codec differenti per la trasmissione vocale, con diversi rapporti bitrate/qualità/complessità, ce ne sono di aperti e chiusi. Qualsiasi softphone ha sicuramente il supporto per i codec G.711 alaw/ulaw, la loro implementazione è molto semplice, la qualità del suono non è male, ma richiedono una larghezza di banda di 64 kbps. Ad esempio, il codec G.729 richiede solo 8 kbps, ma richiede molta CPU e inoltre non è gratuito.

Per la trasmissione dei fax viene solitamente utilizzato il codec G.711 o il protocollo T.38. La trasmissione fax G.711 corrisponde alla trasmissione fax T.30, come se il fax fosse trasmesso su una normale linea telefonica, ma il segnale analogico proveniente dalla linea viene digitalizzato secondo la legge alaw/ulaw. Questa è anche chiamata trasmissione fax Inband T.30.

I fax T.30 negoziano i loro parametri: velocità di trasmissione, dimensione del datagramma, tipo di correzione degli errori. Il protocollo T.38 si basa sul protocollo T.30, ma a differenza della trasmissione Inband, vengono analizzati i comandi T.30 generati e ricevuti. In questo modo non vengono trasmessi dati grezzi, ma comandi di controllo fax riconosciuti.

Per trasmettere i comandi T.38 viene utilizzato il protocollo UDPTL, è un protocollo basato su UDP, viene utilizzato solo per T.38. Per trasferire i comandi T.38, puoi comunque utilizzare i protocolli TCP e RTP, ma vengono utilizzati molto meno spesso.

I principali vantaggi del T.38 sono il carico di rete ridotto e una maggiore affidabilità rispetto alla trasmissione fax Inband.

La procedura per inviare un fax in modalità T.38 è la seguente:

Viene stabilita una normale connessione vocale utilizzando qualsiasi codec.
Quando la carta viene caricata nel fax di invio, invia periodicamente un segnale T.30 CNG (Tono di chiamata) per indicare che è pronto per inviare il fax.
Sul lato ricevente, viene generato un segnale T.30 CED (Called Terminal Identification) - questa è la disponibilità a ricevere un fax. Questo segnale viene inviato dopo aver premuto il pulsante "Ricevi fax" oppure il fax lo fa automaticamente.
Sul lato mittente viene rilevato il segnale CED e avviene la procedura SIP REINVITE, e nel messaggio SDP viene indicato il tipo T.38: m = immagine 39164 udptl t38.

È auspicabile inviare fax su Internet in T.38. Se il fax deve essere trasmesso all'interno dell'ufficio o tra oggetti con una connessione stabile, è possibile utilizzare la trasmissione fax Inband T.30. In questo caso, prima di inviare un fax, è necessario disabilitare la procedura di cancellazione dell'eco per non introdurre ulteriori distorsioni.

Il libro Fax, modem e testo per la telefonia IP, di David Hanes e Gonzalo Salgueiro, è scritto in modo molto dettagliato sulla trasmissione di fax.

5. Elaborazione del segnale digitale (DSP). Garantire la qualità del suono nella telefonia IP, esempi di test

Abbiamo capito i protocolli per stabilire una sessione di conversazione (SIP / SDP) e il metodo di trasmissione dell'audio sul canale RTP. Resta un problema importante: la qualità del suono. Da un lato, la qualità del suono è determinata dal codec selezionato. Ma d'altra parte, sono ancora necessarie procedure DSP aggiuntive (DSP - elaborazione del segnale digitale). Queste procedure tengono conto delle peculiarità della telefonia VoIP: non sempre viene utilizzato un auricolare di alta qualità, ci sono cadute di pacchetti su Internet, a volte i pacchetti arrivano in modo non uniforme, anche la larghezza di banda della rete non è gomma.

Procedure di base per migliorare la qualità del suono:

VAD(Rilevatore di attività vocale) - una procedura per rilevare i frame che contengono voce (frame vocale attivo) o silenzio (frame vocale inattivo). Questa separazione può ridurre significativamente il carico della rete, poiché la trasmissione di informazioni sul silenzio richiede molti meno dati (basta trasmettere solo il livello di rumore o non trasmettere nulla).

Alcuni codec contengono già procedure VAD (GSM, G.729), mentre altri (G.711, G.722, G.726) devono essere implementati.

Se il VAD è configurato per trasmettere informazioni sul livello di rumore, i pacchetti SID speciali (Silence Insertion Descriptor) vengono trasmessi nel formato 13 m RTP CN (Comfort Noise).

Vale la pena notare che i pacchetti SID possono essere eliminati dai server proxy SIP, pertanto, per la verifica, è consigliabile configurare la trasmissione del traffico RTP oltre i server SIP.

metano(generazione di rumore di comfort) - una procedura per generare rumore di comfort basato su informazioni provenienti da pacchetti SID. Quindi, VAD e CNG funzionano insieme, ma la procedura CNG è molto meno richiesta, poiché non è sempre possibile notare il funzionamento del CNG, soprattutto a basso volume.

PLC(occultamento della perdita di pacchetti) - la procedura per recuperare un flusso audio in caso di perdita di pacchetti. Anche con una perdita di pacchetti del 50%, un buon algoritmo PLC raggiunge una qualità vocale accettabile. La distorsione, ovviamente, ci sarà, ma le parole si possono distinguere.

Il modo più semplice per emulare la perdita di pacchetti (su Linux) è usare l'utility tc dal pacchetto iproute con il modulo netem. Modella solo il traffico in uscita.

Un esempio di avvio dell'emulazione di rete con perdita di pacchetti del 50%:

Tc qdisc change dev eth1 root netem loss 50%

Disabilita l'emulazione:

Tc qdisc del dev eth1 root

Buffer di jitter- una procedura per eliminare l'effetto jitter, quando l'intervallo tra i pacchetti ricevuti varia notevolmente e che, nel peggiore dei casi, porta a un ordine errato dei pacchetti ricevuti. Inoltre, questo effetto porta a interruzioni nel discorso. Per eliminare l'effetto jitter è necessario implementare sul lato ricevente un buffer di pacchetti di dimensioni sufficienti a ripristinare l'ordine originario di invio dei pacchetti con un determinato intervallo.

Puoi anche emulare l'effetto jitter utilizzando l'utility tc (l'intervallo tra il momento previsto di arrivo del pacchetto e quello effettivo può raggiungere i 500 ms):

tc qdisc aggiungi dev eth1 root netem delay 500 ms riordina 99%

LEC(Line Echo Canceller) - Procedura di cancellazione dell'eco locale quando il sito lontano inizia a sentire la propria voce. La sua essenza è sottrarre il segnale ricevuto dal segnale trasmesso con un certo coefficiente.

Un'eco può verificarsi per diversi motivi:

eco acustica dovuta a percorso audio di scarsa qualità (il suono dall'altoparlante entra nel microfono);
eco elettrica dovuta alla mancata corrispondenza dell'impedenza tra il telefono e lo SLIC. Nella maggior parte dei casi, ciò si verifica in una linea telefonica da 4 a 2 fili.

Non è difficile scoprirne il motivo (eco acustico o elettrico): l'abbonato dalla cui parte si genera l'eco deve spegnere il microfono. Se l'eco si verifica comunque, allora è elettrico.

Per ulteriori informazioni sulle procedure VoIP e DSP, vedere il libro VoIP Voice and Fax Signal Processing. Un'anteprima è disponibile su Google Libri.

Questo conclude una panoramica teorica superficiale del VoIP. Se interessati, allora un esempio implementazione pratica mini-PBX su una piattaforma hardware reale può essere considerato nel prossimo articolo.

[!?] Domande e commenti sono ben accetti. A rispondere sarà l'autore dell'articolo Dmitry Valento, ingegnere del software presso il centro di progettazione elettronica Promwad.

tag:

per principianti
per i neofiti

Aggiungere etichette

Protocolli RTP e RSVP,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Le applicazioni moderne non possono permettersi di far arrivare i loro pacchetti in ritardo. Due protocolli (RTP e PSVP) consentono di garantire consegne puntuali assicurando la qualità del servizio.

La continua crescita di Internet e delle reti private pone nuove esigenze in termini di larghezza di banda. Le applicazioni client-server superano di gran lunga Telnet nella quantità di dati trasferiti. Il World Wide Web ha portato a un enorme aumento delle informazioni grafiche grafiche. Oggi, anche le applicazioni voce e video hanno i propri requisiti specifici per le reti già congestionate.

L'aumento della capacità di rete da solo non è sufficiente per soddisfare tutte queste esigenze. Ciò che è veramente necessario è una programmazione e un controllo della congestione intelligenti ed efficienti.

Storicamente, le reti basate su IP hanno fornito a tutte le applicazioni solo il servizio di consegna dei dati più semplice quando possibile. Tuttavia, le esigenze sono cambiate nel tempo. Le organizzazioni che hanno speso milioni di dollari per configurare una rete basata su IP per trasferire dati tra LAN ora trovano che queste configurazioni non sono in grado di supportare in modo efficiente nuove applicazioni multimediali multicast in tempo reale.

ATM è l'unica tecnologia di rete originariamente progettata per supportare il traffico TCP e UDP regolare insieme al traffico in tempo reale. Tuttavia, concentrarsi su ATM significa creare una nuova infrastruttura di rete per il traffico in tempo reale o sostituire una configurazione basata su IP esistente, entrambe molto costose.

Pertanto, la necessità di supportare più tipi di traffico con diversi requisiti di QoS all'interno dell'architettura TCP/IP è imperativa. Due strumenti chiave sono progettati per affrontare questa sfida: il protocollo di trasporto in tempo reale (RTP) e il protocollo di prenotazione delle risorse (RSVP).

RTP garantisce la consegna dei dati ad una o più destinazioni con un ritardo entro limiti specificati. Ciò significa che i dati possono essere riprodotti in tempo reale. RSVP consente ai sistemi finali di riservare le risorse di rete per ottenere la qualità del servizio richiesta, in particolare le risorse per il traffico RTP in tempo reale.

Il protocollo del livello di trasporto più utilizzato è il TCP. Sebbene TCP possa supportare un'ampia varietà di applicazioni distribuite, non è adatto per applicazioni in tempo reale.

Nelle applicazioni in tempo reale, il mittente genera un flusso di dati a una velocità costante e il/i destinatario/i deve fornire questi dati all'applicazione alla stessa velocità. Tali applicazioni includono conferenze audio e video, distribuzione video dal vivo (per la riproduzione immediata), spazi di lavoro condivisi, diagnostica medica remota, telefonia per computer, simulazione interattiva distribuita, giochi e monitoraggio in tempo reale.

L'utilizzo di TCP come protocollo di trasporto per queste applicazioni non è possibile per diversi motivi. Innanzitutto, questo protocollo consente solo una connessione tra due endpoint e quindi non è adatto per il multicasting. Prevede la ritrasmissione dei segmenti perduti che arrivano in un momento in cui l'applicazione real-time non li attende più. Inoltre, TCP non dispone di un meccanismo conveniente per associare le informazioni di temporizzazione ai segmenti, che è anche un requisito per le applicazioni in tempo reale.

Un altro protocollo di livello di trasporto ampiamente utilizzato: UDP non ha i primi due

restrizioni (punto a punto e trasmissione di segmenti persi), ma non fornisce nemmeno informazioni di temporizzazione critiche. Quindi UDP da solo non ha strumenti scopo generale per applicazioni in tempo reale.

Sebbene ogni applicazione in tempo reale possa avere i propri meccanismi per supportare la trasmissione in tempo reale, hanno molte somiglianze che rendono altamente desiderabile definire un singolo protocollo. Il protocollo standard di questo tipo è RTP, come definito nella RFC 1889.

In un tipico ambiente in tempo reale, il mittente genera pacchetti a una velocità costante. Vengono loro inviati a intervalli regolari, passano attraverso la rete e vengono ricevuti dal destinatario, che riproduce i dati in tempo reale al momento della ricezione.

Tuttavia, a causa della variazione della latenza durante la trasmissione dei pacchetti sulla rete, questi arrivano a intervalli irregolari. Per compensare questo effetto, i pacchetti in arrivo vengono memorizzati nel buffer, rispettati per un po' e quindi forniti a una velocità costante. Software generare output. Affinché ciò funzioni, ogni pacchetto è contrassegnato da un timestamp in modo che il destinatario possa riprodurre i dati in arrivo alla stessa velocità del mittente.

RTP supporta il trasferimento di dati in tempo reale tra più partecipanti alla sessione. (Una sessione è una connessione logica tra due o più utenti RTP, mantenuta per tutta la durata del trasferimento dei dati. Il processo di apertura di una sessione non rientra nell'ambito di RTP.)

Sebbene RTP possa essere utilizzato per la trasmissione unicast in tempo reale, la sua forza risiede nel supporto per la trasmissione multicast. Per fare ciò, ogni blocco di dati RTP contiene un identificatore del mittente che indica quale dei partecipanti sta generando i dati. I blocchi di dati RTP contengono anche un timestamp in modo che i dati possano essere riprodotti agli intervalli corretti dall'estremità ricevente.

Inoltre, RTP definisce il formato del payload dei dati trasmessi. Direttamente correlato a questo è il concetto di sincronizzazione, di cui il mixer è in parte responsabile: il motore di traduzione RTP. Ricevendo flussi di pacchetti RTP da una o più sorgenti, li combina e invia un nuovo flusso di pacchetti RTP a uno o più destinatari. Il mixer può semplicemente combinare i dati e cambiarne il formato.

Un'applicazione mixer di esempio sta combinando più sorgenti audio. Ad esempio, supponiamo che alcuni dei sistemi in una determinata sessione audio generino ciascuno il proprio flusso RTP. Il più delle volte è attiva una sola fonte, anche se a volte più fonti “parlano” contemporaneamente.

Se nuovo sistema vuole prendere parte alla sessione, ma il suo canale alla rete non ha una capacità precisa sufficiente per supportare tutti i flussi RTP, quindi il mixer riceve tutti questi flussi, li combina in uno e trasferisce l'ultimo al nuovo membro della sessione. Quando vengono ricevuti più flussi, il mixer aggiunge i valori PCM. L'intestazione RTP generata dal mixer include l'identificatore (i) del mittente (s) i cui dati sono presenti nel pacchetto.

Un dispositivo più semplice crea un pacchetto RTP in uscita per ogni pacchetto RTP in ingresso. Questo meccanismo, chiamato traduttore, può modificare il formato dei dati nel pacchetto o utilizzare un diverso insieme di protocolli di basso livello per trasferire dati da un dominio a un altro. Ad esempio, un potenziale destinatario potrebbe non essere in grado di elaborare video ad alta velocità utilizzati da altri partecipanti alla sessione. Quindi il traduttore converte il video in un formato di qualità inferiore, che richiede un bit rate inferiore.

Ogni pacchetto RTP ha un'intestazione principale e possibilmente campi aggiuntivi specifici per l'applicazione. Riso. 4 illustra la struttura dell'intestazione principale. I primi 12 ottetti sono costituiti dai seguenti campi:

campo versione (2 bit): versione corrente - seconda;
campo di riempimento (1 bit): questo campo segnala la presenza di ottetti di riempimento alla fine del payload. (Il riempimento viene utilizzato quando l'applicazione richiede che la dimensione del payload sia un multiplo, ad esempio, di 32 bit.) In questo caso, l'ultimo ottetto indica il numero di ottetti di riempimento;
campo di estensione dell'intestazione (1 bit): quando specificato, l'intestazione principale è seguita da un'intestazione aggiuntiva utilizzata nelle estensioni RTP sperimentali;
campo numero di mittenti (4 bit): questo campo contiene il numero di identificatori dei mittenti i cui dati sono nel pacchetto, con gli identificatori stessi che seguono l'intestazione principale;
campo marker (1 bit): Il significato del bit marker dipende dal tipo di payload. Il bit marker viene solitamente utilizzato per indicare i confini del flusso di dati. Nel caso del video, specifica la fine del fotogramma. Nel caso di una voce, specifica l'inizio del discorso dopo un periodo di silenzio;
Campo tipo di payload (7 bit): questo campo identifica il tipo di payload e il formato dei dati, inclusa la compressione e la crittografia. In uno stato stazionario, il mittente utilizza un solo tipo di payload per sessione, ma può modificarlo in risposta a condizioni mutevoli se segnalato dal protocollo di controllo del trasporto in tempo reale;
campo del numero di sequenza (16 bit): ogni sorgente inizia a numerare i pacchetti da un numero casuale, quindi incrementato di uno con ogni pacchetto di dati RTP inviato. Ciò consente di rilevare la perdita di pacchetti e determinare l'ordine dei pacchetti con lo stesso timestamp. Più pacchetti consecutivi possono avere lo stesso timestamp se generati logicamente nello stesso momento (ad esempio, pacchetti appartenenti allo stesso frame video);
campo timestamp (32 bit): registra il momento in cui è stato generato il primo ottetto dei dati del carico utile. Le unità di tempo utilizzate in questo campo dipendono dal tipo di carico utile. Il valore è determinato dall'orologio locale del mittente;
campo identificativo della sorgente di sincronizzazione: un numero generato casualmente che identifica in modo univoco la sorgente durante la sessione.

L'intestazione principale può essere seguita da uno o più campi di identificatori dei mittenti i cui dati sono presenti nel payload. Questi identificatori vengono inseriti dal mixer.

RTP viene utilizzato solo per trasmettere i dati dell'utente, in genere multicast, a tutti i partecipanti alla sessione. Un protocollo RTCP (Real-Time Transport Control Protocol) separato funziona con più destinazioni per fornire feedback ai mittenti dei dati RTP e agli altri partecipanti alla sessione.

RTCP utilizza lo stesso protocollo di trasporto sottostante di RTP (di solito UDP), ma un numero di porta diverso. Ogni partecipante alla sessione invia periodicamente un pacchetto RTCP a tutti gli altri partecipanti alla sessione. RFC 1889 descrive tre funzioni eseguite da RTCP.

La prima funzione è quella di fornire qualità del servizio e feedback in caso di congestione. Poiché i pacchetti RTCP sono pacchetti multicast, tutti i partecipanti alla sessione possono apprezzare quanto bene gli altri partecipanti stiano lavorando e ricevendo. I messaggi del mittente consentono ai destinatari di valutare la velocità dei dati e la qualità della trasmissione. I messaggi dei destinatari contengono informazioni sui problemi che devono affrontare, inclusa la perdita di pacchetti e il jitter eccessivo. Ad esempio, la velocità in bit per un'applicazione audio/video può essere ridotta se la linea non fornisce la qualità di servizio desiderata per una determinata velocità in bit.

Il feedback del destinatario è importante anche per diagnosticare gli errori di distribuzione.

Analizzando i messaggi di tutti i partecipanti alla sessione, l'amministratore di rete può determinare se il questo problema un partecipante o è di carattere generale.

La seconda funzione principale di RTCP è l'identificazione del mittente. I pacchetti RTCP contengono una descrizione testuale standard del mittente. Forniscono più informazioni sul mittente dei pacchetti di dati rispetto a un ID sorgente di sincronizzazione selezionato casualmente. Inoltre, aiutano l'utente a identificare i flussi di sessioni diverse. Pertanto, consentono all'utente di determinare che sessioni audio e video separate sono aperte contemporaneamente.

La terza funzione è stimare le dimensioni e il ridimensionamento della sessione. Per garantire la qualità del servizio e il feedback per gestire la congestione, nonché per identificare il mittente, tutti i partecipanti inviano periodicamente pacchetti RTCP. La frequenza di trasmissione di questi pacchetti diminuisce all'aumentare del numero dei partecipanti.

Se il numero di partecipanti è ridotto, viene inviato un pacchetto RTCP al massimo ogni cinque secondi. RFC 1889 descrive un algoritmo in base al quale i partecipanti limitano la frequenza dei pacchetti RTCP in base al numero totale di partecipanti. L'obiettivo è mantenere il traffico RTCP inferiore al 5% del traffico totale della sessione.

Lo scopo di qualsiasi rete è fornire dati al destinatario con una qualità del servizio garantita, inclusi larghezza di banda, latenza e margine di variazione della latenza. Man mano che il numero di utenti e applicazioni cresce, diventa più difficile garantire la qualità dei servizi.

La sola reazione al sovraccarico non è più sufficiente. Occorre uno strumento che consenta di evitare del tutto la congestione, ovvero che le applicazioni possano riservare le risorse di rete in base alla qualità del servizio richiesta.

Le misure preventive sono utili sia per le trasmissioni unicast che multicast. Nella trasmissione unicast, le due applicazioni negoziano una specifica QoS per una determinata sessione. Se la rete è pesantemente caricata, potrebbe non essere in grado di fornire il servizio della qualità richiesta. In questa situazione, le applicazioni dovranno rimandare la sessione a tempi migliori o cercare di abbassare i requisiti di qualità del servizio, se possibile.

La soluzione in questo caso consiste nel riservare risorse tramite applicazioni unicast per fornire il livello di servizio richiesto. Quindi i router lungo il percorso previsto allocano le risorse (ad esempio, spazio in coda e parte della capacità della linea in uscita). Se il router non è in grado di allocare le risorse a causa di un impegno precedente, invia una notifica all'applicazione. In questo caso, l'applicazione potrebbe tentare di avviare un'altra sessione con requisiti di qualità del servizio inferiori o riprogrammarla a una data successiva.

Il multicasting pone problemi di prenotazione delle risorse molto più complessi. Porta alla generazione di enormi volumi di traffico di rete - nel caso di applicazioni come il video, ad esempio, o in presenza di un gruppo ampio e disperso di destinatari. Tuttavia, il traffico da una sorgente multicast può in linea di principio essere notevolmente ridotto.

Ci sono due ragioni per questo. Innanzitutto, alcuni membri del team potrebbero non aver bisogno di fornire dati da fonte specifica in un certo periodo di tempo. Pertanto, i membri di un gruppo possono ricevere informazioni contemporaneamente attraverso due canali (da due fonti), ma il destinatario potrebbe essere interessato a ricevere un solo canale.

In secondo luogo, che alcuni membri del gruppo sono in grado di elaborare solo una parte delle informazioni trasmesse dal mittente. Ad esempio, un flusso video potrebbe avere due componenti: uno con una qualità dell'immagine bassa e l'altro con una qualità dell'immagine alta. Questo formato ha una serie di algoritmi di compressione video: generano un componente di base con un'immagine di bassa qualità e un componente aggiuntivo con una risoluzione maggiore.

Alcuni destinatari potrebbero non disporre di una potenza di elaborazione sufficiente per elaborare i componenti con alta risoluzione o essere connesso alla rete tramite una sottorete o un canale che non ha una capacità sufficiente per trasportare il segnale completo.

La prenotazione delle risorse consente ai router di determinare in anticipo se possono fornire traffico multicast a tutti i destinatari.

Nei precedenti tentativi di implementare la prenotazione delle risorse e negli approcci frame relay e ATM, le risorse necessarie sono richieste dalla sorgente del flusso di dati. Questo metodo è sufficiente nel caso della trasmissione unicast, poiché l'applicazione trasmittente trasmette i dati a una certa velocità e il livello di qualità del servizio richiesto è incorporato nello schema di trasmissione.

Tuttavia, questo approccio non può essere utilizzato per il multicasting. Diversi membri del team possono avere requisiti di risorse diversi. Se il flusso originale può essere suddiviso in flussi secondari, è possibile che alcuni membri del gruppo desiderino riceverne solo uno. In particolare, alcuni ricevitori saranno in grado di gestire solo la componente video a bassa risoluzione. Oppure, se più mittenti trasmettono a un gruppo, il destinatario può selezionare solo un mittente o un sottoinsieme di essi. Infine, i requisiti di qualità del servizio dei diversi destinatari possono variare a seconda dell'apparecchiatura di output, della potenza del processore e della velocità del canale.

Per questo motivo sembra preferibile la riservazione delle risorse da parte del destinatario. I mittenti possono fornire ai router caratteristiche generali di traffico (come velocità e variabilità dei dati), ma i destinatari devono determinare il livello di qualità del servizio richiesto. I router quindi aggregano le richieste di allocazione attraverso le parti condivise dell'albero di distribuzione.

RSVP si basa su tre concetti sui flussi di dati: sessione, specifica del flusso e specifica del filtro. Sessioneè un flusso di dati identificato da una destinazione. Si noti che questo concetto differisce dal concetto di sessione RTP, sebbene le sessioni RSVP e RTP possano essere una corrispondenza uno a uno. Dopo che il router ha riservato le risorse per una particolare destinazione, lo considera come l'inizio di una sessione e alloca le risorse per la durata di quella sessione.

Una richiesta di prenotazione dal sistema finale ricevente, denominata descrittore di flusso, è costituita da una specifica di flusso e da un filtro. Specifiche del flusso determina la qualità del servizio richiesta ed è utilizzato dal nodo per impostare i parametri dello schedulatore di pacchetti. Il router invia pacchetti con un determinato insieme di preferenze basate sulla specifica del flusso corrente.

Specifiche del filtro definisce un insieme di pacchetti per i quali sono richieste risorse. Insieme alla sessione definisce l'insieme dei pacchetti (o flusso) per i quali deve essere fornita la qualità di servizio richiesta. Tutti gli altri pacchetti diretti a questa destinazione vengono elaborati finché la rete è in grado di farlo.

RSVP non definisce il contenuto della specifica del flusso, trasmette semplicemente la richiesta. Una specifica di flusso di solito include una classe di servizio, Rspec (R sta per riserva) e Tspec (T sta per traffico). Gli altri due parametri sono un insieme di numeri. Il parametro Rspec definisce la qualità del servizio richiesta e il parametro Tspec descrive il flusso di dati. Il contenuto di Rspec e Tspec è trasparente a RSVP.

Fondamentalmente, una specifica di filtro descrive un sottoinsieme arbitrario di pacchetti da una sessione (cioè quei pacchetti la cui destinazione è determinata dalla data sessione). Ad esempio, una specifica di filtro può definire solo mittenti specifici o definire protocolli o pacchetti i cui campi di intestazione del protocollo corrispondono a quelli specificati.

Riso. 3 illustra la relazione tra sessione, specifica del flusso e specifica del filtro. Ogni pacchetto in entrata appartiene ad almeno una sessione ed è considerato secondo il flusso logico per quella sessione. Se il pacchetto non appartiene a nessuna sessione, viene consegnato nella misura in cui ci sono risorse libere.

La principale difficoltà di RSVP è legata al multicasting. Un esempio di configurazione multicast è mostrato in Fig. 6. Questa configurazione è composta da quattro router. Un collegamento tra due router qualsiasi, rappresentato da una linea, può essere un collegamento diretto o una sottorete. Tre host — Gl, G2 e G3 — sono nello stesso gruppo e ricevono datagrammi con il corrispondente indirizzo multicast. I dati a questo indirizzo vengono trasmessi da due host: S1 e S2. La linea rossa corrisponde all'albero di instradamento per S1 e questo gruppo e la linea blu è per S2 e questo gruppo. Le linee con le frecce indicano la direzione di trasmissione dei pacchetti da S1 (rosso) e da S2 (blu).

La figura mostra che tutti e quattro i router devono essere a conoscenza della prenotazione delle risorse di ciascun destinatario. Pertanto, le richieste di risorse vengono propagate nella direzione opposta attraverso l'albero di routing.

RSVP utilizza due tipi principali di messaggi: Resv e Path. I messaggi Resv vengono generati dai destinatari e propagati lungo l'albero, con ogni nodo lungo il percorso che raggruppa e assembla pacchetti da destinatari diversi quando possibile. Questi messaggi fanno entrare il router nello stato di prenotazione delle risorse per questa sessione (indirizzo multicast). Alla fine tutti i messaggi Resv concatenati raggiungono gli host del mittente. Sulla base delle informazioni ricevute, impostano i parametri di controllo del traffico appropriati per il primo salto.

Riso. 7 mostra il flusso dei messaggi Resv. Nota: i messaggi vengono uniti; pertanto, un solo messaggio viene inoltrato su qualsiasi ramo dell'albero di consegna combinato. Tuttavia, questi messaggi devono essere inviati di nuovo periodicamente per estendere il periodo di prenotazione delle risorse.

Il messaggio Path viene utilizzato per propagare le informazioni sulla rotta di ritorno. Tutti i moderni protocolli di routing multicast supportano solo un percorso diretto sotto forma di albero di propagazione (verso il basso dal mittente). Ma i messaggi Resv devono essere inviati all'indietro attraverso tutti i router intermedi a tutti gli host del mittente.

Poiché il protocollo di routing non fornisce informazioni sul percorso inverso, viene trasportato da RSVP nei messaggi Path. Qualsiasi host che desideri diventare un mittente invia un messaggio Path a tutti i membri del gruppo. Lungo la strada, ogni router e ogni host di destinazione passa allo stato del percorso, indicando che i pacchetti per questo mittente devono essere inoltrati all'hop da cui è stato ricevuto il pacchetto. Riso. 5 mostra che i pacchetti Path viaggiano lungo gli stessi percorsi dei pacchetti dati.

Diamo un'occhiata a come funziona RSVP. Dal punto di vista dell'host, il funzionamento del protocollo consiste nelle fasi seguenti (le prime due fasi di questa sequenza sono talvolta in ordine inverso).

Il destinatario si unisce a un gruppo multicast inviando un messaggio IGMP a un router vicino.
Il potenziale mittente invia il messaggio all'indirizzo del gruppo.
Il destinatario riceve un messaggio Path che identifica il mittente.
Ora che il destinatario ha informazioni sul percorso di ritorno, può inviare messaggi Resv con descrittori di flusso.
I messaggi Resv vengono inviati in rete al mittente.
Il mittente inizia a inviare i dati.
Il ricevitore inizia a ricevere i pacchetti di dati.

I metodi di ieri di lavorare con grandi volumi di grafici sono completamente inadatti ai sistemi moderni. È impossibile soddisfare le crescenti richieste di trasmissione dati a causa della crescita del volume dei dati, della proliferazione di applicazioni in tempo reale e multicast senza nuovi strumenti. RTP e RSVP forniscono una solida base per le reti prossima generazione LAN.

Un esempio di applicazione reale di questi protocolli è il modello VoIP (Voice over IP) - reti voice over IP, che è descritto nello standard H.232 e prevede il trasferimento di informazioni audio, video e dati su una rete IP. In questo caso, viene utilizzato il protocollo in tempo reale RTP per stabilire la connessione e il protocollo RSVP viene utilizzato per riservare le risorse di rete.