Quando noi, parlando su un telefono IP, sentiamo la voce dell'interlocutore nel ricevitore, o, utilizzando un sistema di videoconferenza, comunichiamo con i nostri colleghi e parenti, ci scambiamo un flusso continuo di dati. Quando si trasmettono dati in streaming come voce e video su una rete a pacchetto, è molto importante utilizzare meccanismi che risolvano i seguenti compiti:
Per questi scopi, è stato sviluppato RTP(Real-time Transport Protocol) è un protocollo di trasmissione in tempo reale, di cui parleremo nell'articolo di oggi. Il protocollo è stato sviluppato dall'IETF dall'Audio-Video Transport Working Group ed è descritto in RFC 3550.
Di norma, RTP funziona su UDP (User Datagram Protocol), poiché durante la trasmissione di dati multimediali è molto importante garantirne la consegna tempestiva.
RTP include la possibilità di determinare il tipo di payload e assegnare un numero di sequenza del pacchetto nel flusso, nonché l'uso di timestamp.
Sul lato trasmittente, ogni pacchetto è contrassegnato con un timestamp, 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 costante nella consegna dei pacchetti e quindi ridurre l'effetto del jitter.
Un'altra funzione di RTP è associata alla possibile perdita di pacchetti durante il passaggio attraverso la rete IP, che si esprime nella comparsa di brevi pause nella conversazione. Il silenzio improvviso nel telefono, di norma, ha un effetto molto negativo sull'ascoltatore, quindi, con le capacità del protocollo RTP, tali periodi di silenzio sono pieni del cosiddetto "rumore di comfort"
RTP funziona in combinazione con un altro protocollo IETF, vale a dire 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) e anche per sincronizzare tra i flussi multimediali della sessione RTP.
La funzione principale di RTCP è 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, valore di jitter, ritardo, 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 sua trasmissione.
Per eseguire queste funzioni, RTCP invia messaggi speciali di determinati tipi:
RTP è un protocollo unidirezionale, quindi la comunicazione bidirezionale richiede due sessioni RTP, una per lato.
Una sessione RTP è definita dagli indirizzi IP dei partecipanti, nonché da una coppia di porte UDP non riservate comprese nell'intervallo 16384 - 32767. Inoltre, per organizzare il feedback con l'applicazione, è anche necessario stabilire un doppio modo sessione RTCP. Per le sessioni RTCP, vengono occupate le porte con un numero uno maggiore di RTP. Quindi, ad esempio, se la porta 19554 è selezionata per RTP, la sessione RTCP prenderà la porta 19555. Visivamente, la formazione di una sessione RTP/RTCP è mostrata nella figura seguente.
Questa sezione discute alcuni aspetti del trasporto di pacchetti RTP mediante protocolli di rete e di trasporto. Se non diversamente specificato dalle specifiche di altri protocolli, per la trasmissione dei pacchetti si applicano le seguenti regole di base.
RTP si basa su protocolli di livello inferiore per fornire la separazione dei flussi di dati RTP e delle informazioni di controllo RTCP. Per UDP e protocolli simili, RTP utilizza un numero di porta pari e il flusso RTCP corrispondente utilizza un numero di porta maggiore di uno.
I pacchetti di informazioni RTP non contengono alcun campo di lunghezza, quindi RTP si basa sul protocollo sottostante per fornire anche un'indicazione di lunghezza. La lunghezza massima dei pacchetti RTP è limitata solo dai protocolli di livello inferiore.
Diversi pacchetti di protocollo RTP possono essere trasmessi in un'unità di dati di protocollo di livello inferiore, ad esempio in un pacchetto UDP. Ciò riduce la ridondanza dell'intestazione e può semplificare la sincronizzazione tra diversi flussi.
Questa sezione contiene un elenco di costanti definite nella specifica del protocollo RTP.
Le costanti del tipo di traffico RTP (PT - payload type) sono definite nei profili. Tuttavia, l'ottetto di intestazione RTP, che contiene i bit marker e il campo del tipo di traffico, non deve contenere i valori riservati 200 e 201 (decimali) per distinguere i pacchetti RTP dai pacchetti RTCP SR e RR. Per un formato standard con un bit di marcatore e un campo del tipo di traffico a sette bit, questa limitazione significa che i tipi di traffico 72 e 73 non devono essere utilizzati.
I valori dei tipi di pacchetto RTCP (vedi Tabella 1) sono scelti nell'intervallo da 200 a 204 per controllare meglio la correttezza dell'intestazione del pacchetto RTCP rispetto ai pacchetti RTP. Quando il campo del tipo di pacchetto RTCP viene confrontato con l'ottetto corrispondente dell'intestazione RTP, questo intervallo corrisponde a un bit marker di uno (cosa che normalmente non accade nei pacchetti di informazioni) e al bit più significativo del campo del tipo di traffico standard di uno (mentre i tipi di traffico definiti staticamente di solito hanno valori PT con uno zero nella cifra più significativa). Questo intervallo è stato scelto anche per essere più distante dai valori 0 e 255, poiché i campi costituiti interamente da zeri o uno sono per lo più caratteristici dei dati.
Altri tipi di pacchetti RTCP sono definiti dalla comunità IANA. Gli sviluppatori hanno la possibilità di registrare i valori richiesti per la ricerca sperimentale e quindi annullare la registrazione quando la necessità di tali valori non è più necessaria.
I tipi di articoli validi nel pacchetto SDES sono presentati nella tabella. 2. Altri tipi di elementi SDES sono assegnati dalla comunità IANA. Gli sviluppatori hanno la possibilità di registrare i valori di cui hanno bisogno durante l'esecuzione di studi sperimentali e quindi annullare la registrazione quando tali valori non sono più necessari.
Come notato sopra (vedi Sezione 2), per descrizione completa Il protocollo RTP per un'applicazione specifica richiede documenti aggiuntivi di due tipi: descrizione del profilo e formato del traffico.
RTP può essere utilizzato per molte classi di applicazioni con requisiti molto diversi. La flessibilità per adattarsi a questi requisiti è garantita dall'utilizzo di diversi profili (vedi ). In genere un'applicazione utilizza un solo profilo e nessuna indicazione esplicita di quale profilo si trovi questo momento in uso, n.
Un documento facoltativo del secondo tipo, la specifica del formato del traffico, definisce come un particolare tipo di traffico (ad es. video codificato H.261) dovrebbe essere trasmesso secondo RTP. Lo stesso formato di traffico può essere utilizzato per più profili e può quindi essere definito indipendentemente dal profilo. I documenti del profilo sono responsabili solo della corrispondenza di questo formato al valore PT .
La descrizione del profilo può definire i seguenti elementi, ma questo elenco non è esaustivo.
Intestazione del pacchetto di dati RTP. L'ottetto nell'intestazione del pacchetto dati RTP, che contiene il bit token e il campo del tipo di traffico, può essere ridefinito in base al profilo per soddisfare requisiti diversi, ad esempio per fornire più o meno bit token (Sezione 3.3).
tipi di traffico. Un profilo definisce in genere un insieme di formati di traffico (ad esempio, algoritmi di codifica multimediale) e una mappatura statica predefinita di questi formati e valori PT. Alcuni dei formati di traffico possono essere definiti facendo riferimento a singole descrizioni dei formati di traffico. Per ogni tipo di traffico definito, il profilo deve specificare la frequenza di clock del timestamp RTP da utilizzare (Sezione 3.1).
Aggiunte dell'intestazione del pacchetto di dati RTP. Se alcuni aggiuntivi funzionalità all'interno di una classe di applicazione del profilo che non dipende dal tipo di traffico, è possibile allegare campi aggiuntivi all'intestazione fissa del pacchetto di dati RTP .
Estensioni dell'intestazione del pacchetto di dati RTP. Il contenuto dei primi 16 bit della struttura RTP Data Packet Header Extension deve essere specificato se l'uso di questo meccanismo è consentito dal profilo. .
Tipi di pacchetti RTCP. È possibile definire (e registrare con IANA) nuovi tipi di pacchetti RTCP specifici per classe di applicazione.
Intervallo di segnalazione RTCP. Il profilo deve definire i valori utilizzati nel calcolo dell'intervallo di report RTCP: la frazione di larghezza di banda della sessione RTCP, l'intervallo di report minimo e la suddivisione della larghezza di banda tra mittenti e destinatari.
Estensione del pacchetto SR/RR. Se disponibile Informazioni aggiuntive su un mittente o destinatario che deve essere trasmesso regolarmente, è possibile definire una sezione di estensione per i pacchetti RTCP SR e RR.
Utilizzando SDES. Il profilo può definire priorità relative per gli elementi SDES RTCP da trasmettere o escludere (vedere la sezione 4.2.2); sintassi o semantica alternativa per una clausola CNAME (Sezione 4.4.1); formato elemento LOC (sezione 4.4.5); la semantica e l'uso della clausola NOTE (sezione 4.4.7) e le nuove clausole SDES da registrare con IANA.
Sicurezza. Un profilo può definire quali servizi di sicurezza e algoritmi le applicazioni devono utilizzare e può fornire il controllo sul loro utilizzo (clausola 7).
Corrispondenza password-chiave. Il profilo può determinare come la password immessa dall'utente viene convertita in una chiave di crittografia.
Il protocollo sottostante. La trasmissione di pacchetti RTP può richiedere l'uso di una particolare rete sottostante o di un protocollo di livello di trasporto.
Conformità al trasporto. Oltre alla mappatura standard di RTP e RTCP per trasportare gli indirizzi del livello specificati nella sezione 8, come le porte UDP, possono essere definiti.
Incapsulamento. La modellazione del pacchetto RTP può essere definita per consentire la trasmissione di più pacchetti di informazioni RTP in un'unica unità di dati del protocollo sottostante (sezione 8).
Ogni applicazione sviluppata non dovrebbe richiedere un nuovo profilo. È più opportuno espandere un profilo esistente all'interno della stessa classe di applicazioni, piuttosto che crearne uno nuovo. Ciò semplificherà l'interazione delle applicazioni, poiché ciascuna applicazione viene in genere eseguita con un solo profilo. È possibile eseguire semplici estensioni, come la definizione di valori PT aggiuntivi o tipi di pacchetto RTCP, registrandoli con IANA e pubblicando le loro descrizioni in una specifica del profilo o in una specifica del formato del traffico.
RFC 1890 descrive un profilo per l'utilizzo del protocollo di trasporto in tempo reale RTP versione 2 e del relativo protocollo di controllo RTCP all'interno di una conferenza audio o video di gruppo, il cosiddetto profilo RTP per conferenze audio e video (profilo RTP per conferenze audio e video) . con controllo minimo). Questo profilo definisce aspetti di RTP non specificati nella specifica versione 2 del protocollo RTP (RFC 1889). Controllo minimo significa che non è richiesto alcun supporto per la negoziazione dei parametri o il controllo dell'appartenenza (ad esempio, quando si utilizzano mappature del tipo di traffico statico e indicazioni sull'appartenenza fornite da RTCP). Considera le disposizioni principali questo profilo.
Questa sezione contiene una descrizione di una serie di elementi che possono essere definiti o modificati in un profilo.
L'intestazione del pacchetto di informazioni RTP. Viene utilizzato il formato standard dell'intestazione fissa dei pacchetti di informazioni RTP (un bit di marcatore).
tipi di traffico. I valori statici per i tipi di traffico sono definiti nelle sezioni 11.3 e 11.4.
Estensioni dell'intestazione del pacchetto di informazioni RTP. Nessun campo fisso aggiuntivo è allegato alle intestazioni del pacchetto di informazioni RTP.
Estensioni dell'intestazione del pacchetto di informazioni RTP. Non sono definite estensioni di intestazione del pacchetto di informazioni RTP, ma le applicazioni che utilizzano questo profilo POSSONO utilizzare tali estensioni. Cioè, le applicazioni non dovrebbero presumere che il bit X dell'intestazione RTP sia sempre zero. Le applicazioni devono essere preparate per ignorare l'espansione dell'intestazione. Se in futuro viene definita un'estensione dell'intestazione, è necessario specificare il contenuto dei primi 16 bit in modo da poter identificare molte estensioni diverse.
Tipi di pacchetti RTCP. Nessun tipo di pacchetto RTCP aggiuntivo è definito in questa specifica del profilo.
Intervallo di segnalazione RTCP. Quando si calcola l'intervallo di segnalazione RTCP, devono essere utilizzate le costanti proposte in RFC 1889.
Estensioni del pacchetto SR/RR. Le estensioni per i pacchetti RTCP SR e RR non sono definite.
Utilizzando SDES. Le applicazioni possono utilizzare una qualsiasi delle clausole SDES descritte. Mentre le informazioni sul nome canonico (CNAME) vengono inviate in ogni intervallo di rapporto, gli altri elementi devono essere inviati solo ogni quinto intervallo di rapporto.
Sicurezza. Anche i servizi di sicurezza RTP predefiniti sono definiti per impostazione predefinita con questo profilo.
Corrispondenza password-chiave. La password inserita dall'utente viene convertita utilizzando l'algoritmo MD5 in un digest a 16 ottetti. Una chiave di N bit viene ottenuta dal digest utilizzando i suoi primi N bit. La password deve includere solo lettere ASCII, numeri, trattini e spazi per ridurre la possibilità di danneggiamento durante la trasmissione delle password tramite telefono, fax, telex o e-mail. La password può essere preceduta da una specifica dell'algoritmo di crittografia. Tutti i caratteri fino alla prima barra (codice ASCII 0x2f) vengono presi come nome dell'algoritmo di crittografia. Se non è presente alcuna barra, l'algoritmo di crittografia predefinito è DES-CBC.
La password inserita dall'utente viene convertita nella sua forma canonica prima che venga applicato l'algoritmo di chiusura. A tal fine, la password viene convertita nel set di caratteri ISO 10646 utilizzando la codifica UTF-8 come definito nell'allegato P della norma ISO/IEC 10646-1:1993 (i caratteri ASCII non richiedono alcuna conversione); gli spazi vengono rimossi all'inizio e alla fine della password; due o più spazi vengono sostituiti con uno spazio (ASCII o UTF-8 0x20); tutte le lettere vengono convertite in lettere minuscole
il protocollo sottostante. Il profilo definisce l'uso di RTP su UDP in modalità bidirezionale e multicast.
Conformità al trasporto. Viene utilizzata la mappatura standard di RTP e RTCP per gli indirizzi del livello di trasporto.
Incapsulamento. L'incapsulamento dei pacchetti RTP non è definito.
Questo profilo definisce i tipi di codifica standard utilizzati con RTP. Altri tipi di codifica devono essere registrati con IANA prima dell'uso. Quando si registra un nuovo tipo di codifica, devono essere fornite le seguenti informazioni:
Per le applicazioni che non inviano pacchetti durante le pause, il primo burst di voce attiva (il primo pacchetto dopo la pausa) viene distinto impostando il bit indicatore nell'intestazione del pacchetto di informazioni RTP su uno. Le applicazioni senza soppressione del silenzio impostano questo bit a zero.
Il clock RTP utilizzato durante la generazione del timestamp RTP è indipendente dal numero di canali e dal tipo di codifica; è pari al numero di periodi di campionamento al secondo. Per la codifica a canale N (stereo, quad, ecc.), ogni periodo di campionamento (diciamo 1/8000 di secondo) genera N campioni. Il numero totale di campioni generati al secondo è uguale al prodotto della frequenza di campionamento per il numero di canali.
Quando si utilizzano più canali audio, vengono numerati da sinistra a destra, a partire dal primo. Nei pacchetti audio RTP, i dati dei canali con numero inferiore precedono i dati dei canali con numero più alto. Per più di due canali, viene utilizzata la seguente notazione:
| Numero di canali | Nome del sistema | Numeri di canale | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 2 | stereo | l | R | ||||
| 3 | l | R | C | ||||
| 4 | quadrilatero | fl | Fr | Rl | Rr | ||
| 4 | l | C | R | S | |||
| 5 | fl | Fr | Fc | SL | Sr | ||
| 6 | l | lc | C | R | rc | S | |
I campioni di tutti i canali appartenenti allo stesso momento di campionamento devono essere all'interno dello stesso pacchetto. L'interlacciamento di campioni da diversi canali dipende dal tipo di codifica.
La frequenza di campionamento deve essere selezionata dal set: 8000, 11025, 16000, 22050, 24000, 32000, 44100 e 48000 Hz (i computer Macintosh Apple hanno le proprie frequenze di campionamento 22254.54 e 11127.27, che possono essere trasformate in 22050 e 11025 s qualità accettabile saltando quattro o due campioni in un frame di 20 ms). Tuttavia, la maggior parte degli algoritmi di codifica audio sono definiti per un insieme più limitato di frequenze di campionamento. I ricevitori devono essere preparati per ricevere audio multicanale, ma possono anche selezionare mono.
Per la pacchettizzazione audio, l'intervallo di pacchettizzazione predefinito deve essere di 20 ms se non diversamente specificato nella descrizione della codifica. L'intervallo di pacchettizzazione definisce il ritardo minimo end-to-end. I pacchetti più lunghi hanno una porzione di byte relativamente più piccola per l'intestazione, ma causano un ritardo maggiore e rendono la perdita di pacchetti più significativa. Per le applicazioni non interattive come conferenze o canali con vincoli di larghezza di banda significativi, può essere accettabile un ritardo di pacchettizzazione più elevato. Il destinatario deve ricevere i pacchetti con un segnale acustico con un ritardo da 0 a 200 ms. Questo limite garantisce una dimensione del buffer accettabile per il ricevitore.
Nelle codifiche basate su campioni, ogni campione di segnale è rappresentato da un numero fisso di bit. All'interno di dati audio compressi, i singoli codici campione possono oltrepassare i limiti dell'ottetto. La durata del segnale trasmesso nel pacchetto audio è determinata dal numero di campioni nel pacchetto.
Per i tipi di codifica basati su campioni che producono uno o più ottetti per campione, i campioni di diversi canali campionati simultaneamente vengono impacchettati in ottetti adiacenti. Ad esempio, per la codifica stereo, la sequenza di ottetti è: canale sinistro, primo campione; canale destro, primo conteggio; canale sinistro, secondo conteggio; canale destro, secondo campione, ecc. Nella codifica multi-ottetto, l'ottetto più significativo viene trasmesso per primo. L'impacchettamento delle codifiche basate su campioni che producono meno di un ottetto per campione è determinato dall'algoritmo di codifica.
L'algoritmo di codifica basato su frame converte un blocco audio di lunghezza fissa in un altro blocco di dati compressi, solitamente anch'esso di lunghezza fissa. Per le codifiche basate su frame, il mittente può combinare diversi frame di questo tipo in un unico messaggio.
Per i codec basati su frame, l'ordine dei canali è definito per l'intero blocco. Cioè, per l'audio stereo, i campioni per i canali sinistro e destro sono codificati in modo indipendente; in cui il frame di codifica per il canale sinistro precede il frame per il canale destro.
Tutti i codec audio orientati ai frame devono essere in grado di codificare e decodificare più frame consecutivi trasmessi all'interno di un singolo pacchetto. Poiché la dimensione del frame per i codec orientati al frame è specificata, non è necessario utilizzare una notazione separata per la stessa codifica ma con un numero diverso di frame per pacchetto.
A tavola. 3 mostra i valori dei tipi di traffico (PT) definiti da questo profilo per i segnali audio, loro convegni e principale specifiche algoritmi di codifica.
A tavola. 4 mostra i valori dei tipi di codifica (PT), i simboli degli algoritmi di codifica e le caratteristiche tecniche degli algoritmi di codifica video definiti da questo profilo, nonché i valori PT non assegnati, riservati e assegnati dinamicamente.
I valori del tipo di traffico nell'intervallo da 96 a 127 possono essere determinati dinamicamente tramite il protocollo di controllo della conferenza, che non è trattato in questo articolo. Ad esempio, la directory di sessione può specificare che, per una data sessione, il tipo di traffico 96 denota la codifica PCMU, doppio canale a 8000 Hz. L'intervallo del tipo di traffico contrassegnato come "riservato" non viene utilizzato in modo che i pacchetti di protocollo RTCP e RTP possano essere distinti in modo affidabile .
Una sorgente RTP emette solo un tipo di traffico alla volta; non è consentito l'interleaving di diversi tipi di traffico in una sessione RTP. È possibile utilizzare più sessioni RTP in parallelo per trasportare diversi tipi di traffico. I tipi di traffico definiti in questo profilo si riferiscono all'audio o al video, ma non a entrambi. Tuttavia, è possibile definire tipi di traffico combinato che combinano, ad esempio, audio e video, con opportuna separazione nel formato del traffico.
Le applicazioni audio che utilizzano questo profilo devono, come minimo, essere in grado di inviare e ricevere tipi di traffico 0 (PCMU) e 5 (DVI4). Ciò consente l'interoperabilità senza negoziazione del formato.
Come definito nella descrizione del protocollo RTP, i dati RTP devono essere trasmessi su una porta UDP con numero pari e i pacchetti RTCP corrispondenti devono essere trasmessi su un numero di porta maggiore di uno (numero dispari).
Le applicazioni in esecuzione con questo profilo possono utilizzare qualsiasi coppia di porte UDP. Ad esempio, una coppia di porte può essere assegnata casualmente dal programma di gestione della sessione. Non è possibile fornire un'unica coppia fissa di numeri di porta perché in alcuni casi più applicazioni che utilizzano questo profilo devono essere eseguite correttamente sullo stesso host e alcuni sistemi operativi non consentono a più processi di utilizzare la stessa porta UDP con indirizzi multicast diversi.
Tuttavia, i numeri di porta predefiniti possono essere 5004 e 5005. Le applicazioni che utilizzano più profili possono scegliere questa coppia di porte come indicatore di quel profilo. Ma le applicazioni possono anche richiedere che la coppia di porte sia esplicitamente specificata.
Una delle tendenze più importanti nell'evoluzione delle telecomunicazioni moderne è lo sviluppo della telefonia IP, un insieme di nuove tecnologie che garantiscono la trasmissione di messaggi multimediali (voce, dati, video) attraverso reti informatiche e informatiche (ICN) costruite sulla base del protocollo IP (Internet Protocol), includendo reti informatiche locali, aziendali, globali e Internet. Il concetto di telefonia IP include la telefonia Internet, che consente di organizzare la comunicazione telefonica tra abbonati Internet, tra abbonati reti telefoniche uso generale (PSTN) su Internet, nonché comunicazioni telefoniche tra utenti PSTN e Internet.
La telefonia IP presenta una serie di innegabili vantaggi che ne garantiscono il rapido sviluppo e l'espansione del mercato della telefonia informatica. È vantaggioso per gli utenti finali a cui viene fornita la comunicazione telefonica con 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 più reti di comunicazione, ne viene utilizzata una. L'indubbio vantaggio della telefonia IP rispetto a un normale telefono è anche la capacità di fornire servizi aggiuntivi attraverso l'uso di un computer multimediale e varie applicazioni Internet. Pertanto, con la telefonia IP, aziende e privati possono espandere le proprie capacità di comunicazione incorporando funzionalità avanzate di videoconferenza, condivisione di applicazioni, strumenti tipo 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 si basa sul protocollo IP, che però non viene utilizzato solo per la telefonia: è stato originariamente sviluppato per la trasmissione di dati digitali a IVS a commutazione di pacchetto.
Nelle reti che non forniscono una qualità di servizio garantita (tra queste reti costruite sulla base del protocollo IP), i pacchetti possono andare perduti, l'ordine del loro arrivo può cambiare, i dati trasmessi nei pacchetti possono essere distorti. Varie procedure del livello di trasporto vengono utilizzate per garantire la consegna affidabile delle informazioni trasmesse in queste condizioni. Quando si trasmettono dati digitali, a tale scopo viene utilizzato il protocollo TCP (Transmission Control Protocol). Questo protocollo fornisce 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 audio e videoconferenza, i ritardi dei pacchetti hanno un effetto molto maggiore sulla qualità del segnale rispetto alle distorsioni dei singoli dati. Le differenze nei ritardi possono portare a lacune. Tali applicazioni richiedono un diverso protocollo del livello di trasporto che fornisca risequenziamento dei pacchetti, consegna con ritardo minimo, riproduzione in tempo reale in momenti specificati con precisione, riconoscimento del tipo di traffico, comunicazione multicast o bidirezionale. Tale protocollo è il protocollo di trasporto in tempo reale RTP (Real-Time Transport Protocol). Questo protocollo regola la trasmissione di dati multimediali in pacchetti attraverso l'IVS a livello di trasporto ed è integrato dal protocollo di controllo della trasmissione dei dati in tempo reale RTCP (Real-Time Control Protocol). Il protocollo RTCP, a sua volta, fornisce il controllo sulla consegna di dati multimediali, il controllo della qualità del servizio, il trasferimento di informazioni sui partecipanti alla sessione di comunicazione corrente, il controllo e l'identificazione ed è talvolta considerato parte del protocollo RTP.
Molte pubblicazioni sulla telefonia IP notano che la maggior parte delle apparecchiature di rete e speciali Software per questa tecnologia è sviluppata sulla base della Raccomandazione H.323 del Settore di standardizzazione delle telecomunicazioni dell'Unione internazionale delle telecomunicazioni (ITU-T) (inclusi TAPI 3.0, NetMeeting 2.0, ecc.). In che modo H.323 è correlato a RTP e RTCP? H.323 è un ampio quadro concettuale che include molti altri standard, ognuno dei quali si occupa di diversi aspetti del trasferimento di informazioni. La maggior parte di questi standard, come gli standard di codec audio e video, ha ampia applicazione non solo nella telefonia IP. Per quanto riguarda i protocolli RTP / RTCP, costituiscono la base dello standard H.323, si concentrano sulla fornitura della tecnologia esattamente IP e sono alla base dell'organizzazione della telefonia IP. Questo articolo è dedicato alla considerazione di questi protocolli.
Il protocollo di trasporto in tempo reale RTP fornisce la trasmissione in tempo reale end-to-end 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 un timestamp a ciascun pacchetto in uscita. Sul lato ricevente, i timestamp dei pacchetti indicano in quale sequenza e con quali ritardi devono essere riprodotti. Il supporto per RTP e RTCP consente all'host ricevente di organizzare i pacchetti ricevuti nell'ordine corretto, ridurre l'effetto del jitter del ritardo dei pacchetti sulla rete sulla qualità del segnale e ripristinare la sincronizzazione tra audio e video in modo che le informazioni in arrivo possano essere ascoltate e visualizzate correttamente dagli utenti.
Si noti che RTP stesso non dispone di alcun meccanismo per garantire la trasmissione tempestiva dei dati e la qualità del servizio, ma utilizza servizi sottostanti per garantire ciò. Non impedisce i pacchetti fuori ordine, ma non presuppone che la rete sottostante sia assolutamente affidabile e trasmetta i pacchetti nella sequenza corretta. I numeri di sequenza inclusi in RTP consentono al destinatario di risequenziare i pacchetti del mittente.
Protocollo RTP supporta sia la comunicazione bidirezionale che il trasferimento dati a un gruppo di destinazioni se il multicast è supportato dalla rete sottostante. RTP è progettato per fornire le informazioni richieste singole applicazioni, e nella maggior parte dei casi integrato nell'applicazione.
Sebbene RTP sia considerato un protocollo di livello di trasporto, di solito funziona sopra 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 dai livelli di trasporto e di rete sottostanti, quindi i protocolli RTP/RTCP possono essere utilizzati 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 informazioni o pacchetti di dati (pacchetti di dati), mentre i pacchetti generati secondo il protocollo RTCP e utilizzati per trasmettere informazioni di servizio necessarie per una teleconferenza affidabile sono chiamati pacchetti di controllo. o pacchetti di servizio (pacchetti di controllo). Un pacchetto RTP include un'intestazione fissa, un'estensione dell'intestazione di lunghezza variabile facoltativa e un campo dati. Un pacchetto RTCP inizia con una parte fissa (simile alla parte fissa dei pacchetti di informazioni RTP) seguita da blocchi costitutivi di lunghezza variabile.
Affinché il protocollo RTP sia più flessibile e applicabile a varie applicazioni, alcuni dei suoi parametri sono volutamente indefiniti, ma prevede il concetto di profilo. Il profilo (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 dell'intestazione del pacchetto, i tipi di traffico, le aggiunte e le estensioni dell'intestazione, i tipi di pacchetto, i servizi e gli algoritmi di sicurezza della comunicazione, le caratteristiche dell'uso del protocollo sottostante, ecc. Profilo RTP per conferenze audio e video con controllo minimo ). Ogni applicazione di solito funziona con un solo profilo e l'impostazione del tipo di profilo viene eseguita selezionando l'applicazione appropriata. Nessuna indicazione esplicita del tipo di profilo per numero di porta, identificatore di protocollo, ecc. non fornito.
Pertanto, una specifica RTP completa per una particolare applicazione deve includere documenti aggiuntivi, che includono una descrizione del profilo, nonché una descrizione del formato del traffico che definisce come un particolare tipo di traffico, come audio o video, verrà elaborato in RTP.
Le caratteristiche della trasmissione di dati multimediali durante le conferenze audio e video sono discusse nelle sezioni seguenti.
L'audioconferenza di gruppo richiede un indirizzo di gruppo 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 del protocollo RTCP. L'indirizzo del gruppo e le informazioni sulla porta vengono inviate ai partecipanti alla teleconferenza previsti. Se è richiesta la privacy, le informazioni ei pacchetti di controllo possono essere crittografati come definito nella Sezione 7.1, nel qual caso anche la chiave di crittografia deve essere generata e distribuita.
L'applicazione di audioconferenza utilizzata da ciascun partecipante alla conferenza invia i dati audio in piccole sequenze, ad esempio 20 ms. Ogni pezzo di dati audio è preceduto da un'intestazione RTP; l'intestazione ei dati RTP vengono a loro volta 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 arriva un nuovo partecipante che utilizza una connessione a bassa larghezza di banda o durante la congestione della rete.
In Internet, come in altre reti di dati a commutazione di pacchetto, i pacchetti a volte vengono persi e riordinati, oltre che ritardati per vari periodi. Per contrastare questi eventi, l'intestazione RTP contiene un timestamp e un numero di sequenza che consentono ai ricevitori di ripetere la temporizzazione in modo che, ad esempio, porzioni di un segnale audio vengano riprodotte continuamente dall'altoparlante ogni 20 ms. Questa ricostruzione temporale 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 entrare e uscire durante una teleconferenza, è utile sapere chi è attualmente nella conferenza e quanto bene i partecipanti alla conferenza stanno ricevendo i dati audio. A tale scopo, ogni istanza dell'applicazione audio durante la conferenza invia periodicamente sulla porta di controllo (porta RTCP) per le applicazioni di tutti gli altri partecipanti, messaggi di ricezione di pacchetti indicanti il loro nome utente. Il messaggio di ricezione indica la qualità dell'ascolto dell'oratore 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.
Se entrambi i segnali audio e video vengono utilizzati in una teleconferenza, 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 è definita 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 diretta a livello RTP tra le sessioni audio e video, tranne per il fatto che un 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 alcuni partecipanti alla conferenza devono poter ricevere un solo tipo di traffico, se lo desiderano. Nonostante la separazione, è possibile ottenere la riproduzione sincrona dei dati multimediali di origine (audio e video) utilizzando le informazioni di temporizzazione contenute nei pacchetti RTCP per entrambe le sessioni.
Non sempre tutti i siti hanno la possibilità di ricevere dati multimediali nello stesso formato. Si consideri il caso in cui i partecipanti della stessa località sono collegati tramite un collegamento a bassa velocità alla maggior parte degli altri partecipanti alla conferenza che hanno accesso alla rete a banda larga. Invece di costringere tutti a utilizzare una larghezza di banda più ristretta e una codifica audio di qualità inferiore, una struttura di comunicazione a livello RTP chiamata mixer può essere collocata in una regione con larghezza di banda ridotta. Questo mixer risincronizza i pacchetti audio in entrata per ripristinare gli intervalli originali di 20 ms, mescola questi flussi audio ripristinati in un singolo flusso, esegue la codifica audio a bassa larghezza di banda 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. Affinché gli endpoint riceventi forniscano una corretta indicazione della sorgente dei messaggi, l'intestazione RTP include mezzi per i mixer per identificare le sorgenti coinvolte nella formazione del pacchetto misto.
Alcuni dei partecipanti all'audioconferenza potrebbero essere collegati tramite linee di comunicazione a banda larga, ma potrebbero non essere raggiungibili tramite una conferenza di gruppo IP multicast (IPM). Ad esempio, potrebbero trovarsi dietro un firewall a livello di applicazione che non consentirà alcuna trasmissione di pacchetti IP. Per questi casi non sono necessari mixer, ma un diverso tipo di comunicazione a livello RTP, chiamato traduttore. Dei due traduttori, uno è installato all'esterno del firewall e inoltra esternamente tutti i pacchetti multicast ricevuti tramite una connessione protetta all'altro traduttore installato dietro il firewall. Il traduttore dietro il firewall li trasmette di nuovo come pacchetti multicast a un gruppo multiutente limitato a rete interna luogo.
Mixer e traduttori possono essere progettati per una serie di scopi. Esempio: un mixer video che ridimensiona le immagini video di individui in flussi video indipendenti e le compone in un singolo flusso video, simulando una scena di gruppo. Esempi di trasmissione: connessione di un gruppo di host solo IP/UDP a un gruppo di host solo ST-II o transcodifica pacchetto video per pacchetto da singole sorgenti senza ritiming o missaggio. I dettagli su come funzionano mixer e traduttori sono discussi nella Sezione 5.
Tutti i campi dei pacchetti RTP/RTCP vengono trasmessi sulla rete in 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 facoltativi hanno un valore pari a zero.
Il tempo assoluto (Wallclock time) in RTP è rappresentato utilizzando il formato timestamp NTP (Network Time Protocol), che è un conto alla rovescia in secondi relativo a zero ore il 1° gennaio 1900. Il formato timestamp NTP completo è un numero a virgola fissa senza segno a 64 bit con una parte intera nei primi 32 bit e una parte frazionaria negli ultimi 32 bit. In alcuni campi con una rappresentazione più compatta vengono utilizzati solo i 32 bit centrali: i 16 bit bassi della parte intera ei 16 bit alti della parte frazionaria.
Le prossime due sezioni di questo articolo (3 e 4) discutono i formati dei pacchetti e le caratteristiche del funzionamento dei protocolli RTP e RTCP, rispettivamente.
Come notato sopra, un pacchetto RTP include un'intestazione fissa, un'estensione dell'intestazione di lunghezza variabile facoltativa e un campo dati. L'intestazione fissa dei pacchetti del protocollo RTP ha il seguente formato: .
I primi dodici ottetti sono presenti in ogni pacchetto RTP, mentre il campo identificativo CSRC (contributing source) è presente solo quando inserito dal mixer. I campi hanno le seguenti finalità.
Versione (V): 2 bit. Questo campo identifica la versione RTP. Questo articolo si concentra sulla versione 2 del protocollo RTP (il valore 1 è stato utilizzato nella prima bozza di RTP).
Complemento (P): 1 bit. Se il bit di riempimento è impostato su uno, il pacchetto alla fine contiene uno o più ottetti di riempimento che non fanno parte del traffico. L'ultimo ottetto di riempimento contiene un'indicazione del numero di tali ottetti da ignorare successivamente. Il riempimento può essere richiesto da alcuni algoritmi di cifratura con dimensioni di blocco fisse o per trasportare più pacchetti RTP in un singolo payload del protocollo sottostante.
Estensione (X): 1 bit. Se il bit di estensione è impostato, l'intestazione fissa è seguita da un'estensione dell'intestazione con il formato definito 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.
Marcatore (M): 1 bit. L'interpretazione del marcatore è determinata dal profilo. Ha lo scopo di consentire di contrassegnare eventi significativi (ad esempio i confini dei fotogrammi 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 (PT): 7 bit. Questo campo identifica il formato del traffico RTP e determina come l'applicazione lo interpreterà. Un profilo definisce una mappatura statica predefinita dei valori PT e dei formati di traffico. Ulteriori codici del tipo di traffico possono essere definiti dinamicamente tramite strutture non RTP. Il mittente di un pacchetto RTP in un dato momento emette un singolo valore del tipo di traffico RTP; questo campo non è destinato al multiplexing di singoli flussi multimediali (vedere ).
Numero di sequenza: 16 bit. Il valore del numero di sequenza viene incrementato di uno con ogni pacchetto di informazioni RTP inviato e può essere utilizzato dal destinatario per rilevare i pacchetti persi e ripristinare la loro sequenza originale. Il valore iniziale del numero di sequenza viene scelto in modo casuale per rendere difficile il crack della chiave in base a valori noti di questo campo (anche se la fonte non utilizza la crittografia, poiché i pacchetti possono passare attraverso un relay che utilizza la crittografia). Timestamp: 32 bit. Il timestamp riflette il tempo di campionamento per il primo ottetto nel pacchetto di informazioni RTP. Il tempo di campionamento deve essere derivato da un timer che incrementa in modo monotono e lineare con il tempo per fornire la sincronizzazione e il rilevamento del jitter (vedere Sezione 4.3.1). La risoluzione del timer dovrebbe essere sufficiente per la precisione di temporizzazione desiderata e per la misurazione del jitter all'arrivo dei pacchetti (un rapporto del timer per frame video di solito non è sufficiente). La frequenza di temporizzazione dipende dal formato del traffico trasmesso ed è impostata staticamente nel profilo o nella specifica del formato del traffico, oppure può essere impostata dinamicamente per formati di traffico definiti tramite "strumenti non RTP". Se i pacchetti RTP vengono generati periodicamente, è necessario utilizzare 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 codificatore di timestamp venga incrementato di uno per ciascun periodo di campionamento. Se un'applicazione audio da un dispositivo di input legge blocchi contenenti 160 campioni, il timestamp deve essere incrementato di 160 per ciascuno di questi blocchi, indipendentemente dal fatto che il blocco sia stato trasmesso in un pacchetto o eliminato come pausa. Il valore iniziale del timestamp, come il valore iniziale del numero di sequenza, è una variabile casuale. Diversi pacchetti RTP consecutivi possono avere timestamp uguali se sono generati logicamente allo stesso tempo, ad esempio appartengono allo stesso fotogramma 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 comunque monotoni quando vengono trasmessi).
SSRC: 32 bit. Il campo SSRC (sorgente di sincronizzazione) identifica la sorgente di sincronizzazione (vedere l'elenco delle abbreviazioni e dei termini utilizzati). Questo ID viene scelto casualmente in modo che due sorgenti di clock all'interno della stessa sessione RTP non abbiano lo stesso ID SSRC. Sebbene la probabilità che più origini scelgano lo stesso identificatore è bassa, tutte le implementazioni RTP devono essere preparate per rilevare e risolvere tali collisioni. La sezione 6 discute la probabilità di collisioni insieme a un meccanismo per risolverle e rilevare loop di livello RTP basati sull'unicità dell'identificatore SSRC. Se una sorgente cambia il suo indirizzo di trasporto originale, deve anche scegliere un nuovo identificatore SSRC in modo che non venga interpretata come sorgente in loop.
Elenco CSRC: da 0 a 15 elementi, 32 bit ciascuno. L'elenco CSRC (Contributing Source) identifica le fonti di traffico contenute nel pacchetto da includere. Il numero di identificatori è dato dal campo CC. Se ci sono più di quindici fonti incluse, allora solo 15 di esse possono essere identificate. Gli ID CSRC vengono inseriti dai mixer quando si utilizzano gli ID SSRC per le sorgenti commutate. Ad esempio, per i pacchetti audio, gli identificatori SSRC di tutte le sorgenti che sono state mischiate quando il pacchetto è stato creato sono elencati nell'elenco CSRC, fornendo al destinatario una corretta indicazione delle sorgenti dei messaggi.
Come accennato in precedenza, secondo 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 audio e video codificati separatamente, ogni tipo di traffico deve essere inviato in una sessione RTP separata con il proprio indirizzo di trasporto di destinazione. Audio e video non dovrebbero essere trasportati nella stessa sessione RTP e separati in base al tipo di traffico o ai campi SSRC. Interlacciamento di pacchetti aventi Vari tipi traffico ma l'utilizzo dello stesso SSRC causerebbe alcuni problemi:
Utilizzando SSRC diversi per ogni tipo di traffico, ma inviandoli nella stessa sessione RTP, è possibile evitare i primi tre problemi, ma non gli ultimi due. Pertanto, la specifica del protocollo RTP richiede che ogni tipo di traffico utilizzi la propria sessione RTP.
L'intestazione del pacchetto di informazioni RTP esistente è completa per l'insieme di funzionalità richieste in generale per tutte le classi di applicazioni che potrebbero supportare RTP. Tuttavia, per un migliore adattamento a compiti specifici, l'intestazione può essere modificata mediante modifiche o aggiunte definite nella specifica del profilo.
Il bit indicatore e il campo del tipo di traffico contengono informazioni specifiche sul profilo, ma si trovano in un'intestazione fissa poiché si prevede che molte applicazioni ne avranno bisogno. L'ottetto contenente questi campi può essere ridefinito dal profilo per soddisfare requisiti diversi, ad esempio con più o meno bit di marcatore. Se sono presenti bit marker, dovrebbero essere inseriti nei bit di ordine superiore dell'ottetto, poiché i monitor indipendenti dal profilo possono essere in grado di osservare una correlazione tra il modello di perdita di pacchetti e il bit marker.
Le informazioni aggiuntive richieste per un particolare formato di traffico (ad esempio il tipo di codifica video) DEVONO essere riportate nel campo dati del pacchetto. Può essere posizionato in un determinato punto 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 tali applicazioni deve definire campi fissi aggiuntivi da inserire immediatamente dopo il campo SSRC dell'intestazione fissa esistente. Queste applicazioni saranno in grado di accedere rapidamente a campi aggiuntivi direttamente, mentre monitor o registratori indipendenti dal profilo saranno ancora in grado di elaborare i pacchetti RTP interpretando solo i primi dodici ottetti.
Se si ritiene che siano necessarie funzionalità aggiuntive in generale per tutti i profili, allora il file una nuova versione RTP per apportare modifiche permanenti al titolo fisso.
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 del pacchetto. Questo meccanismo è progettato in modo che l'estensione dell'intestazione possa essere ignorata da altre applicazioni cooperanti che non la richiedono.
Se il bit X nell'intestazione RTP è impostato su uno, un'estensione dell'intestazione di lunghezza variabile viene aggiunta all'intestazione RTP fissa (seguendo l'eventuale elenco CSRC). Si noti che questa estensione di intestazione è solo per 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 in esso contenute, esclusa l'intestazione dell'estensione a quattro ottetti (quindi la lunghezza può essere zero). È possibile aggiungere solo un'estensione all'intestazione di un pacchetto di informazioni RTP fisso. Per consentire a ciascuna di una pluralità di implementazioni cooperanti di sperimentare indipendentemente con 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 a distinguere identificatori o parametri. Il formato di questi 16 bit deve essere determinato dalla specifica del profilo con cui lavorano le applicazioni.
| 1999 | ||||||||||||
| 2000 |
Il requisito di supportare diversi tipi di traffico con diversi requisiti di qualità del servizio basati sullo stack del protocollo TCP/IP è ora molto rilevante. Questo problema viene risolto dal Real-Time Transport Protocol (RTP), che è uno standard IETF per la trasmissione in tempo reale di dati come voce o video su una rete che non garantisce la qualità del servizio.
Il protocollo RTP garantisce la consegna dei dati a uno o più destinatari con un ritardo non superiore al valore specificato. Per fare ciò, l'intestazione del protocollo contiene i timestamp necessari per il corretto ripristino delle informazioni audio e video, nonché i dati sul metodo di codifica delle informazioni.
Sebbene il protocollo TCP garantisca la consegna dei dati trasmessi nella sequenza corretta, il traffico non è uniforme, ovvero si verificano ritardi imprevedibili durante la consegna dei datagrammi. Poiché il protocollo RTP è a conoscenza del contenuto dei datagrammi e dispone di meccanismi di rilevamento della perdita di dati, può ridurre la latenza a un livello accettabile.
Schema dell'indirizzo del protocollo IP
Lo schema di indirizzamento internetwork utilizzato nel protocollo IP è descritto in RFC 990 e RFC 997. Si basa sulla separazione delle reti di indirizzamento dai dispositivi di indirizzamento in queste reti. Questo schema facilita l'instradamento. In questo caso, gli indirizzi devono essere assegnati in modo ordinato (consecutivo) per rendere più efficiente l'instradamento.
Quando si utilizza lo stack del protocollo TCP / IP sulla rete, i dispositivi finali ricevono indirizzi univoci. Tali dispositivi possono essere computer personale, media server, router, ecc. Tuttavia, alcuni dispositivi che hanno più porte fisiche, come i router, devono avere un indirizzo univoco su ciascuna delle porte. Sulla base dello schema di indirizzamento e del fatto che alcuni dispositivi sulla rete possono avere più indirizzi, possiamo concludere che questo schema l'indirizzamento non descrive il dispositivo stesso sulla rete, ma una connessione specifica di questo dispositivo alla rete. Questo schema porta a una serie di inconvenienti. Uno di questi è la necessità di modificare l'indirizzo del dispositivo quando lo si sposta su un'altra rete. Un altro inconveniente è che per lavorare con un dispositivo che ha più connessioni in una rete distribuita, è necessario conoscere tutti i suoi indirizzi che identificano queste connessioni.
Quindi, per ogni dispositivo nelle reti IP, possiamo parlare di indirizzi di tre livelli:
q L'indirizzo fisico del dispositivo (più precisamente, un'interfaccia specifica). Per i dispositivi su reti Ethernet, questo è l'indirizzo MAC scheda di rete o porta del router. Questi indirizzi vengono assegnati dai produttori di hardware. L'indirizzo fisico ha sei byte: i tre superiori sono l'identificativo del produttore, i tre inferiori sono assegnati dal produttore;
q Un indirizzo IP composto da quattro byte. Questo indirizzo viene utilizzato a livello di rete modello di riferimento OSI;
q Identificatore carattere - nome. Questo identificatore può essere assegnato arbitrariamente dall'amministratore.
Quando il protocollo IP è stato standardizzato nel settembre 1981, le sue specifiche richiedevano che ogni dispositivo connesso alla rete avesse un indirizzo univoco a 32 bit. Questo indirizzo è diviso in due parti. La prima parte dell'indirizzo identifica la rete in cui si trova il dispositivo. La seconda parte identifica univocamente il dispositivo stesso all'interno della rete. Questo schema porta a una gerarchia di indirizzi a due livelli (Figura 6.23).
Ora viene chiamato il campo del numero di rete nell'indirizzo prefisso di rete, perché identifica la rete. Tutte le workstation sulla rete condividono lo stesso prefisso di rete. Tuttavia, devono avere numeri di dispositivo univoci. Due postazioni di lavoro situate in reti diverse, devono avere prefissi di rete diversi, ma possono avere lo stesso numero di dispositivo.
Per la flessibilità nell'indirizzamento reti di computer I progettisti del protocollo hanno stabilito che lo spazio degli indirizzi IP dovrebbe essere diviso in tre diverse classi: A, B e C. Conoscendo la classe, sai dove si trova il confine tra il prefisso di rete e il numero del dispositivo in un indirizzo a 32 bit . Sulla fig. La Figura 6.24 mostra i formati degli indirizzi di queste classi di base.
Uno dei principali vantaggi dell'utilizzo delle classi è che è possibile determinare dalla classe dell'indirizzo dove si trova il confine tra il prefisso di rete e il numero del dispositivo. Ad esempio, se i due bit più significativi dell'indirizzo sono 10, il punto di divisione è tra i bit 15 e 16.
Lo svantaggio di questo metodo è la necessità di modificare l'indirizzo di rete quando si collegano dispositivi aggiuntivi. Ad esempio, se il numero totale di dispositivi in una rete di classe C supera 255, i relativi indirizzi dovranno essere sostituiti con indirizzi di classe B. La modifica degli indirizzi di rete richiederà ulteriori sforzi da parte dell'amministratore per eseguire il debug della rete. Gli amministratori di rete non possono effettuare una transizione graduale a una nuova classe di indirizzi perché le classi sono chiaramente separate. Devi proibire l'uso di un intero gruppo di indirizzi di rete, modificare contemporaneamente tutti gli indirizzi dei dispositivi in questo gruppo e solo successivamente consentirne nuovamente l'uso sulla rete. Inoltre, l'introduzione delle classi di indirizzi riduce notevolmente il numero teoricamente possibile di singoli indirizzi. IN Versione attuale Protocollo IP (versione 4) il numero totale di indirizzi potrebbe essere 2 32 (4 294 967 296), poiché il protocollo prevede l'utilizzo di 32 bit per specificare l'indirizzo. Naturalmente, l'utilizzo di alcuni bit per scopi di servizio riduce il numero disponibile di singoli indirizzi.
La classe A è per reti di grandi dimensioni. Ogni indirizzo di classe A ha un prefisso di rete a 8 bit con il bit più significativo impostato su 1 ei successivi sette bit utilizzati per il numero di rete. I restanti 24 bit vengono utilizzati per il numero del dispositivo. Al momento, tutti gli indirizzi di classe A sono già allocati. Le reti di classe A sono anche denominate "/8" perché gli indirizzi di classe A hanno un prefisso di rete a 8 bit.
Il numero massimo di reti di classe A è 126 (2 7 -2 - vengono sottratti due indirizzi, costituiti solo da zeri e uno). Ogni rete di questa classe supporta fino a 16.777.214 (2 24 -2) dispositivi. Poiché un blocco di indirizzi di classe A può contenere un massimo di 231 (2 147483648) indirizzi individuali e la versione IP 4 può supportare un massimo di 232 (4 294 967 296) indirizzi, la classe A occupa il 50% dello spazio totale degli indirizzi IP.
La classe B è destinata a reti di medie dimensioni. Ogni indirizzo di classe B ha un prefisso di rete a 16 bit in cui i due bit più significativi sono 10 ei successivi 14 bit vengono utilizzati per il numero di rete. 16 bit sono allocati per il numero di dispositivo. Le reti di classe B sono anche denominate "/16" perché gli indirizzi di classe B hanno un prefisso di rete a 16 bit.
Il numero massimo di reti di classe B è 16.382 (2 14 -2). Ogni rete di questa classe supporta fino a 65.534 (2 16 -2) dispositivi. Poiché un intero blocco di indirizzi di classe B può contenere fino a un massimo di 230 (1.073.741.824) indirizzi individuali, occupa il 25% dello spazio totale degli indirizzi IP.
Gli indirizzi di classe C vengono utilizzati nelle reti con un numero limitato di dispositivi. Ogni rete di classe C ha un prefisso di rete a 24 bit, in cui i tre bit più significativi sono 110 e i successivi 21 bit vengono utilizzati per il numero di rete. I restanti 8 bit sono allocati per i numeri di dispositivo. Le reti di classe C sono anche denominate "/24" perché gli indirizzi di classe C hanno un prefisso di rete a 24 bit.
Il numero massimo di reti di classe C è 2.097.152 (221). Ogni rete di questa classe supporta fino a 254 (2 8 -2) dispositivi. La classe C occupa il 12,5% dello spazio totale degli indirizzi IP.
A tavola. 6.9 riassume la nostra analisi delle classi di rete.
Tabella 6.9. Classi di rete
Oltre a queste tre classi di indirizzi, ne esistono altre due. Nella classe D, i quattro bit più significativi sono 1110. Questa classe è utilizzata per il multicasting. Nella classe E, i quattro bit superiori sono 1111. È riservato alla sperimentazione.
Per la leggibilità degli indirizzi nella letteratura tecnica, nei programmi applicativi, ecc., gli indirizzi IP sono rappresentati come quattro numeri decimali separati da punti. Ciascuno di questi numeri corrisponde a un ottetto (8 bit) dell'indirizzo IP. Questo formato è chiamato decimale puntato (Decimal-Point Notation) o notazione decimale puntata (Figura 6.25).
A tavola. 6.10 elenca gli intervalli di valori decimali per le tre classi di indirizzi. A tavola. 6.10 La voce XXX indica un campo arbitrario.
Tabella 6.10. Intervalli di valori dell'indirizzo
Alcuni indirizzi IP non possono essere assegnati ai dispositivi sulla rete (Tabella 6.11).
Come mostrato in questa tabella, negli indirizzi IP riservati, tutti i bit impostati a zero corrispondono a entrambi questo dispositivo, o questa rete, e gli indirizzi IP, i cui bit sono tutti impostati su 1, vengono utilizzati per trasmettere informazioni. Per fare riferimento all'intera rete IP nel suo complesso, viene utilizzato un indirizzo con un numero di dispositivo, con tutti i bit impostati su "0". L'indirizzo di rete di classe A 127.0.0.0 è riservato per il loopback e introdotto per testare la comunicazione tra processi sulla stessa macchina. Quando un'applicazione utilizza un indirizzo di loopback, lo stack del protocollo TCP/IP restituisce questi dati all'applicazione senza inviare nulla alla rete. Inoltre, questo indirizzo può essere utilizzato per l'interazione di processi separati all'interno della stessa macchina. Pertanto, nelle reti IP, è vietato assegnare indirizzi IP che iniziano con 127 ai dispositivi.
Oltre alla trasmissione diretta dei dati a una workstation specifica, viene utilizzata attivamente la trasmissione broadcast, in cui tutte le stazioni nella rete corrente o specificata ricevono informazioni. Esistono due tipi di trasmissioni nel protocollo IP: diretto e limitato.
Una trasmissione diretta consente a un dispositivo su una rete remota di inviare un datagramma a tutti i dispositivi sulla rete corrente. Un datagramma con un indirizzo di trasmissione inoltrato può passare attraverso i router, ma verrà consegnato solo a tutti i dispositivi sulla rete specificata, non a tutti i dispositivi. In una trasmissione diretta, l'indirizzo di destinazione è costituito da un numero di rete specifico e da un numero di dispositivo, i cui bit sono tutti 0 o 1. Ad esempio, gli indirizzi 185.100.255.255 e 185.100.0.0 verrebbero trattati come indirizzi di trasmissione diretta per la classe B rete 185.100.xxx.xxx Dal punto di vista dell'indirizzamento, il principale svantaggio della trasmissione direzionale è che è richiesta la conoscenza del numero di rete di destinazione.
La seconda forma di trasmissione, chiamata trasmissione limitata, trasmette all'interno della rete corrente (la rete in cui risiede il dispositivo di invio). Un datagramma con un indirizzo di trasmissione limitato non passerà mai attraverso un router. Nella trasmissione limitata, i bit del numero di rete e del numero del dispositivo sono tutti zero o uno. Pertanto, un datagramma con un indirizzo di destinazione di 255.255.255.255 o 0.0.0.0 verrà consegnato a tutti i dispositivi sulla rete. Sulla fig. La Figura 6.26 mostra le reti connesse tramite router. A tavola. La Figura 6.12 elenca i destinatari dei datagrammi broadcast inviati dalla workstation A.
Il protocollo IP supporta tre metodi di indirizzamento: singolo (unicast), broadcast (broadcast) e di gruppo (multicast).
Tabella 6.12. Ricevitori di datagrammi di trasmissione
Nell'indirizzamento singolo, i datagrammi vengono inviati a un singolo dispositivo specifico. L'implementazione di questo approccio non è difficile, ma se gruppo di lavoro contiene molte stazioni, il throughput potrebbe non essere sufficiente, poiché lo stesso datagramma verrà trasmesso molte volte.
Con l'indirizzamento broadcast, le applicazioni inviano un singolo datagramma, che viene consegnato a tutti i dispositivi sulla rete. Questo approccio è ancora più semplice da implementare, ma se in questo caso il traffico di trasmissione non è limitato alla rete locale (e, ad esempio, un'altra rete viene inoltrata utilizzando i router), allora rete globale deve avere significativo portata. Se le informazioni sono destinate solo a un piccolo gruppo di dispositivi, questo approccio sembra irrazionale.
In multicast, i datagrammi vengono consegnati a un gruppo specifico di dispositivi. Allo stesso tempo (cosa molto importante quando si lavora in reti distribuite), non viene generato traffico in eccesso. I datagrammi multicast e a indirizzo singolo differiscono nell'indirizzo. Nell'intestazione di un datagramma IP con multicast, invece degli indirizzi IP delle classi A, B, C, c'è un indirizzo di classe D, cioè un indirizzo di gruppo.
Un indirizzo di gruppo viene assegnato ad alcuni dispositivi destinatari o, in altre parole, a un gruppo. Il mittente scrive questo indirizzo multicast nell'intestazione del datagramma IP. Il datagramma sarà consegnato a tutti i membri del gruppo. I primi quattro bit dell'indirizzo di classe D sono 1110. Il resto dell'indirizzo (28 bit) è occupato dall'identificatore di gruppo (Figura 6.27).
Nel formato decimale puntato, gli indirizzi di gruppo vanno da 224.0.0.0 a 239.255.255.255. A tavola. La Figura 6.13 mostra lo schema di allocazione degli indirizzi di classe D.
Tabella 6.13. Assegnazione di indirizzi di classe D
Come si può vedere dalla Tav. 6.13, i primi 256 indirizzi sono riservati. In particolare, questo intervallo è riservato ai protocolli di instradamento e ad altri protocolli di basso livello. A tavola. 6.14 contiene alcuni indirizzi IP di classe D riservati.
Al di sopra di questo intervallo si trova un ampio gruppo di indirizzi dedicati alle applicazioni in esecuzione su Internet. L'intervallo di indirizzi più alto (circa 16 milioni di indirizzi) è per scopi amministrativi in reti locali. Gli indirizzi di gruppo di classe D sono gestiti centralmente e registrati da un'organizzazione speciale chiamata IANA.
Il multicast può essere implementato a due livelli del modello OSI: canale (livello di collegamento dati) e rete (livello di rete). I protocolli di trasmissione a livello di collegamento, come Ethernet e FDDI, possono supportare l'indirizzamento singolo, broadcast e multicast. Il multicast a livello di collegamento è particolarmente efficace se è supportato nell'hardware della scheda NIC.
Per supportare il multicasting IANA, è stato allocato un blocco di indirizzi Ethernet multicast, a partire da 01-00-5E (in notazione esadecimale). Un indirizzo IP multicast può essere tradotto in un indirizzo in questo blocco. Il principio della traduzione è abbastanza semplice: i 23 bit inferiori dell'identificatore di gruppo IP vengono copiati nei 23 bit inferiori dell'indirizzo Ethernet. Si noti che questo schema associa fino a 32 diversi gruppi IP con lo stesso indirizzo Ethernet, poiché i successivi 5 bit dell'identificatore del gruppo IP vengono ignorati.
Tabella 6.14. Indirizzi di classe D riservati
| Indirizzo | Scopo |
| 224.0.0.1 | Tutti i dispositivi sulla sottorete |
| 224.0.0.2 | Tutti i router sulla sottorete |
| 224.0.0.4 | Tutti i router DVMRP |
| 224.0.0.5 | Tutti i router MOSPF |
| 224.0.0.9 | IP RIP Versione II |
| 224.0.1.7 | notizie audio |
| 224.0.1.11 | Audio dell'IEFT |
| 224.0.1.12 | Video dell'IEFT |
Se il mittente e il destinatario appartengono allo stesso rete fisica, il processo di trasmissione e ricezione di frame multicast a livello di collegamento è abbastanza semplice. Il mittente specifica l'indirizzo IP del gruppo di destinatari e il NIC traduce questo indirizzo nell'indirizzo Ethernet del gruppo corrispondente e invia il frame.
Se il mittente e il destinatario si trovano su sottoreti diverse collegate da router, la consegna del datagramma è difficile. In questo caso, i router devono supportare uno dei protocolli di routing multicast (DVMRP, MOSPF, PIM - vedi sotto). Secondo questi protocolli, il router costruirà un albero di consegna e inoltrerà correttamente il traffico multicast. Inoltre, ciascun router deve supportare il protocollo IGMP (Group Management Protocol) per determinare la presenza dei membri del gruppo nelle sottoreti direttamente connesse (Figura 6.28).
Il principale protocollo di trasporto per le applicazioni multimediali è diventato il protocollo in tempo reale RTP (Real-Time Protocol), progettato per organizzare la trasmissione di pacchetti con segnali vocali codificati su una rete IP. La trasmissione dei pacchetti RTP viene effettuata tramite il protocollo UDP, che a sua volta funziona tramite IP (Fig. 1.5.).
Riso. 1.5.
Infatti, il livello a cui appartiene RTP non è definito in modo univoco come mostrato in Fig. 1.5 e come è solitamente descritto in letteratura. Da un lato, il protocollo funziona davvero su UDP, è implementato programmi applicativi e, a tutti gli effetti, è un protocollo applicativo. Ma allo stesso tempo, come affermato all'inizio di questo paragrafo, RTP fornisce servizi di trasporto indipendentemente dalle applicazioni multimediali ed è, da questo punto di vista, solo un protocollo di trasporto. Migliore definizione: RTP è un protocollo di trasporto implementato a livello di applicazione.
Per trasmettere il traffico vocale (multimediale), RTP utilizza i pacchetti, la cui struttura è mostrata in Fig. 1.6.
Un pacchetto RTP è composto da almeno 12 byte. I primi due bit dell'intestazione RTP (campo bit versione, V) indicano la versione del protocollo RTP (attualmente versione 2).
Chiaramente, con questa struttura di intestazione, è possibile al massimo solo un'altra versione RTP. Il campo che li segue contiene due bit: il bit P, che indica se i caratteri di riempimento sono stati aggiunti alla fine del campo del payload (di solito vengono aggiunti se il protocollo di trasporto o l'algoritmo di codifica richiedono l'uso di blocchi di dimensioni fisse), e il bit X, che indica se viene utilizzata un'intestazione estesa.
Riso. 1.6.
Se utilizzata, la prima parola dell'intestazione estesa contiene la lunghezza totale dell'estensione. Inoltre, i quattro bit CC determinano il numero di campi CSRC alla fine dell'intestazione RTP, cioè il numero di sorgenti che formano il flusso. Il marker bit M consente di contrassegnare ciò che lo standard definisce come eventi significativi, ad esempio l'inizio di un fotogramma video, l'inizio di una parola in un canale audio e così via. È seguito da un campo del tipo di dati PT (7 bit), che indica il codice del tipo di payload che determina il contenuto del campo del payload: dati dell'applicazione (dati dell'applicazione), ad esempio audio MP3 a 8 bit non compresso, ecc. Da questo codice, l'applicazione può imparare cosa fare per decodificare i dati. Il resto dell'intestazione a lunghezza fissa è costituito da un campo Sequence Number, un campo Time Stamp per registrare quando è stata creata la prima parola del pacchetto e un campo SSRC timing source che identifica questa sorgente. L'ultimo campo può essere un singolo dispositivo con un solo indirizzo di rete, più sorgenti che possono rappresentare diversi media (audio, video, ecc.) o diversi flussi dello stesso media. Dal momento che le fonti possono essere diversi dispositivi, l'identificatore SSRC viene scelto in modo casuale in modo che la possibilità di ricevere dati da due fonti contemporaneamente durante una sessione RTP sia minima. Tuttavia, viene definito anche un meccanismo per la risoluzione dei conflitti qualora si presentino. La parte fissa dell'intestazione RTP può essere seguita da un massimo di 15 campi CSRC a 32 bit separati che identificano le origini dati.
RTP è supportato dal protocollo RTCP (Real-Time Transport Control Protocol), che genera report aggiuntivi contenenti informazioni sulle sessioni RTP. Ricordiamo che né UDP né RTP sono impegnati a fornire QoS (Quality of Service). Il protocollo RTCP fornisce feedback con i mittenti e per i ricevitori di flusso fornisce alcuni miglioramenti QoS, informazioni sui pacchetti (perdita, ritardo, jitter) e utente (applicazione, flusso). Per il controllo del flusso, esistono due tipi di rapporti: generati dai mittenti e generati dai destinatari. Ad esempio, le informazioni sulla percentuale di pacchetti persi e sul numero assoluto di perdite consentono al mittente, quando riceve un report, di rilevare che la congestione del canale può impedire ai ricevitori di ricevere i flussi di pacchetti che si aspettavano. In questo caso, il mittente ha la possibilità di abbassare la velocità di codifica per ridurre la congestione e migliorare la ricezione. Il report del mittente contiene informazioni su quando è stato generato l'ultimo pacchetto RTP (include sia un timestamp interno che in tempo reale). Queste informazioni consentono al destinatario di coordinare e sincronizzare più flussi come video e audio. Se il flusso è diretto a più destinatari, vengono organizzati i flussi di pacchetti RTCP da ciascuno di essi. Ciò richiederà misure per limitare la larghezza di banda, inversamente proporzionale alla velocità con cui vengono generati i rapporti RTCP e al numero di destinatari.
Va notato che sebbene RTCP funzioni separatamente da RTP, la stessa catena RTP/UDP/IP porta a un sovraccarico significativo (sotto forma delle loro intestazioni). Il codec G.729 genera pacchetti di 10 byte (80 bit ogni 10 ms). Un'intestazione RTP, di 12 byte di dimensione, è più grande dell'intero pacchetto. Inoltre, è necessario aggiungere un'intestazione UDP a 8 byte e un'intestazione IP a 20 byte (in IPv4), che crea un'intestazione quattro volte più grande dei dati trasmessi.
