Questa sezione discute alcuni aspetti del trasporto di pacchetti RTP tramite rete e protocolli di trasporto. Se non diversamente specificato dalle specifiche di altri protocolli, durante la trasmissione dei pacchetti si applicano le seguenti regole generali.
RTP si basa sui protocolli sottostanti per fornire la separazione tra i flussi di dati RTP e le 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 superiore.
I pacchetti di informazioni RTP non contengono alcun campo di lunghezza, pertanto RTP si basa su un 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 può semplificare la sincronizzazione tra flussi diversi.
9. Elenco delle costanti di protocollo
Questa sezione contiene un elenco di costanti definite nella specifica del protocollo RTP.
Le costanti del tipo di traffico RTP (PT - tipo di payload) sono definite nei profili. Tuttavia, l'ottetto dell'intestazione RTP che contiene il bit/i 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 token 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 per i tipi di pacchetto RTCP (vedi Tabella 1) sono selezionati 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 il corrispondente ottetto dell'intestazione RTP, questo intervallo corrisponde a un bit di marker pari a uno (cosa che di solito non avviene nei pacchetti di dati) e al bit più significativo del campo del tipo di traffico standard pari a uno (mentre i tipi di traffico specificati staticamente di solito hanno valori di 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 zero o uno sono per lo più specifici dei dati.
Altri tipi di pacchetti RTCP sono definiti dalla Comunità IANA. Gli sviluppatori hanno la possibilità di registrare i valori di cui hanno bisogno per condurre ricerche sperimentali e quindi annullare la registrazione quando la necessità di tali valori scompare.
I tipi di articoli consentiti nel pacchetto SDES sono presentati nella tabella. 2. Altri tipi di clausole SDES sono designati dalla Comunità IANA. Gli sviluppatori hanno la possibilità di registrare i valori di cui hanno bisogno durante l'esecuzione di ricerche sperimentali e quindi annullare la registrazione quando tali valori non sono più necessari.
10. Descrizione del profilo di traffico e del formato
Come indicato in precedenza (cfr. Sezione 2), per una descrizione completa dell'RTP per una specifica applicazione sono necessari ulteriori documenti di due tipi: una descrizione del profilo e il formato del traffico.
RTP può essere utilizzato per molte classi di applicazioni con requisiti molto diversi. La flessibilità per adattarsi a questi requisiti è fornita dall'uso di profili diversi (vedi). In genere, un'applicazione utilizza un solo profilo e non vi è alcuna indicazione esplicita di quale profilo sia attualmente in uso.
Un ulteriore documento del secondo tipo - Traffic Format Specification - definisce come deve essere trasmesso un particolare tipo di traffico (ad esempio segnale video codificato secondo H.261) 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 conformità a questo formato e al valore PT .
I seguenti elementi possono essere definiti nella descrizione del profilo, ma questo elenco non è esaustivo.
Intestazione del pacchetto di dati RTP. L'ottetto nell'intestazione di un pacchetto di dati RTP, che contiene un bit di token e un campo del tipo di traffico, può essere ridefinito in base al profilo per soddisfare requisiti diversi, ad esempio per fornire più o meno bit di token (sezione 3.3).
Tipi di traffico. Un profilo in genere definisce una varietà di formati di traffico (ad esempio, algoritmi di codifica dei media) e una mappatura statica predefinita di questi formati e valori PT. Alcuni dei formati di traffico possono essere definiti facendo riferimento alle descrizioni dei singoli formati di traffico. Per ogni specifico tipo di traffico, il profilo deve specificare la velocità di clock del timestamp RTP da utilizzare (Sezione 3.1).
Aggiunte dell'intestazione del pacchetto di dati RTP. È possibile aggiungere ulteriori campi all'intestazione fissa del pacchetto di dati RTP se sono necessarie funzionalità aggiuntive all'interno della classe dell'applicazione del profilo, indipendentemente dal tipo di traffico. .
Estensioni dell'intestazione del pacchetto di dati RTP. Il contenuto dei primi 16 bit della struttura di estensione dell'intestazione del pacchetto di dati RTP deve essere specificato se l'uso di questo meccanismo è consentito dal profilo. .
Tipi di pacchetti RTCP. Possono essere definiti (e registrati dalla IANA) nuovi tipi di pacchetti RTCP specifici per la classe di applicazione.
Intervallo di segnalazione RTCP. Il profilo dovrebbe definire i valori da utilizzare nel calcolo dell'intervallo di segnalazione RTCP: la frazione della larghezza di banda della sessione RTCP, l'intervallo di segnalazione minimo e la condivisione della larghezza di banda tra mittenti e destinatari.
Estensione del pacchetto SR/RR. Se sono presenti informazioni aggiuntive sulla sorgente o sulla destinazione che devono essere trasmesse regolarmente, è possibile specificare una sezione di estensione per i pacchetti RTCP SR e RR.
Utilizzo di SDES. Il profilo può definire le priorità relative per gli elementi SDES RTCP da trasmettere o eliminare (vedere la sezione 4.2.2); sintassi o semantica alternativa per la clausola CNAME (sezione 4.4.1); formato dell'elemento LOC (sezione 4.4.5); semantica e uso della clausola NOTE (sezione 4.4.7) e nuove clausole SDES da registrare con IANA.
Sicurezza. Il profilo può definire quali servizi di sicurezza e algoritmi devono essere utilizzati dalle applicazioni e può controllarne l'uso (clausola 7).
Corrispondenza password-chiave. Il profilo può determinare come la password immessa dall'utente viene convertita in una chiave di crittografia.
Protocollo di livello inferiore. I pacchetti RTP possono richiedere l'uso di una rete sottostante specifica o di un protocollo di livello di trasporto.
Conformità ai trasporti. PU essere definito in modo diverso dalle corrispondenze RTP e RTCP standard specificate nella clausola 8 per gli indirizzi di livello di trasporto, come le porte UDP.
Incapsulamento. La configurazione dei pacchetti RTP può essere definita per consentire la trasmissione di più pacchetti di dati RTP in una singola unità di dati del protocollo di livello inferiore (clausola 8).
Ogni applicazione sviluppata non dovrebbe richiedere un nuovo profilo. È più opportuno espandere un profilo esistente all'interno di una classe di applicazioni, piuttosto che crearne uno nuovo. Ciò renderà più semplice l'interazione delle applicazioni, poiché ciascuna di solito viene eseguita con un solo profilo. Estensioni semplici, come la definizione di valori PT aggiuntivi o tipi di pacchetti RTCP, possono essere ottenute registrandole con IANA e pubblicando le loro descrizioni in una specifica del profilo o in una specifica del formato di traffico.
11. Profilo RTP per conferenze audio e video con controllo minimo
RFC 1890 descrive un profilo per l'utilizzo del protocollo di trasporto in tempo reale RTP versione 2 e il relativo protocollo di controllo RTCP in una conferenza audio o video di gruppo, il cosiddetto profilo RTP per conferenze audio e video con controllo minimo (Profilo RTP per audio e Videoconferenze con controllo minimo). Questo profilo definisce gli aspetti di RTP non specificati nella specifica del protocollo RTP versione 2 (RFC 1889). Il minimo di controllo significa che non è richiesto alcun supporto per la negoziazione dei parametri o il controllo della proprietà (ad esempio, quando si utilizzano mappature statiche dei tipi di traffico e indicazioni di proprietà fornite da RTCP). Consideriamo le principali disposizioni di questo profilo.
11.1. Formati dei pacchetti RTP e RTCP e parametri del protocollo
Questa sezione contiene una descrizione di una serie di elementi che possono essere definiti o modificati in un profilo.
Intestazione del pacchetto di informazioni RTP. Viene utilizzato il formato standard dell'intestazione fissa dei pacchetti di informazioni RTP (un bit di token).
Tipi di traffico. I valori statici per i tipi di traffico sono definiti nelle sezioni 11.3 e 11.4.
Aggiunte dell'intestazione del pacchetto di informazioni RTP. Nessun campo fisso aggiuntivo viene aggiunto 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è, nelle applicazioni non si dovrebbe presumere che il bit X dell'intestazione RTP sia sempre zero. Le applicazioni devono essere preparate per ignorare l'estensione dell'intestazione. Se in futuro viene specificata 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. Le costanti proposte nella RFC 1889 dovrebbero essere utilizzate nel calcolo dell'intervallo di segnalazione RTCP.
Estensioni del pacchetto SR / RR. Non ci sono estensioni per i pacchetti RTCP SR e RR.
Utilizzo di SDES. Le applicazioni possono utilizzare una qualsiasi delle clausole SDES descritte. Mentre le informazioni sul nome canonico (CNAME) vengono inviate in ogni intervallo di segnalazione, gli altri elementi devono essere inviati solo ogni cinque intervalli di segnalazione.
Sicurezza. Anche i servizi di sicurezza RTP predefiniti sono definiti per impostazione predefinita da questo profilo.
Corrispondenza password-chiave. La password inserita dall'utente viene convertita utilizzando l'algoritmo MD5 in un digest di 16 ottetti. Una chiave a N bit si ottiene da un digest utilizzando i suoi primi N bit. Si presume che la password possa includere solo lettere ASCII, numeri, trattini e spazi per ridurre la probabilità di distorsione 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 interpretati come nome dell'algoritmo di crittografia. Se non è presente alcuna barra, l'impostazione predefinita è la crittografia DES-CBC.
Prima dell'applicazione dell'algoritmo di chiusura, la password inserita dall'utente viene convertita in forma canonica. Per fare ciò, la password viene convertita nel set di caratteri ISO 10646 utilizzando la codifica UTF-8 come definito nell'Appendice P a ISO/IEC 10646-1: 1993 (i caratteri ASCII non richiedono alcuna conversione); gli spazi all'inizio e alla fine della password vengono rimossi; due o più spazi vengono sostituiti con uno spazio (ASCII o UTF-8 0x20); tutte le lettere vengono convertite in lettere minuscole
Protocollo sottostante. Il profilo definisce l'uso di RTP su UDP in modalità bidirezionale e multicast.
Conformità ai trasporti. Viene utilizzata una corrispondenza standard tra gli indirizzi del livello di trasporto RTP e RTCP.
Incapsulamento. L'incapsulamento del pacchetto RTP non è definito.
11.2. Registrazione dei tipi di traffico
Questo profilo definisce i tipi di codifica standard utilizzati con RTP. Altri tipi di codifica devono essere registrati presso la IANA prima dell'uso. Quando si registra un nuovo tipo di codifica, devono essere fornite le seguenti informazioni:
- il nome in codice del tipo di codifica e la frequenza di clock del timestamp RTP (il nome in codice dovrebbe essere lungo tre o quattro caratteri per fornire una rappresentazione compatta, se necessario);
- l'indicazione di chi ha il diritto di modificare il tipo di codifica (ad esempio, ISO, CCITT/ITU, altri organismi internazionali di normalizzazione, consorzio, specifica società o gruppo di società);
- eventuali parametri di funzionamento;
- collegamenti a descrizioni disponibili dell'algoritmo di codifica, come (in ordine di preferenza) RFC, articolo pubblicato, deposito di brevetto, relazione tecnica, fonte di codec o riferimento;
- per i tipi di codifica privata, informazioni di contatto (indirizzo postale e indirizzo e-mail);
- valore per indicare il tipo di traffico di questo profilo, se necessario (vedi sotto).
- Si noti che non tutti i tipi di codifica da utilizzare con RTP devono essere assegnati staticamente. I mezzi non RTP, che non sono trattati in questo articolo, possono essere utilizzati per mappare dinamicamente tra un valore di tipo di traffico (PT) nell'intervallo da 96 a 127 e un tipo di codifica.
- Lo spazio di valore disponibile per i tipi di traffico è piuttosto ridotto. I nuovi tipi di traffico vengono assegnati staticamente (in modo permanente) solo se sono soddisfatte le seguenti condizioni:
- la codifica è di grande interesse per la comunità di Internet;
- offre vantaggi paragonabili alle codifiche esistenti e/o è necessario per l'interoperabilità con i sistemi di conferenza o multimediali esistenti e ampiamente utilizzati;
- la descrizione è sufficiente per creare un decoder.
11.3. Codifica audio
Per le applicazioni che non inviano pacchetti durante le pause, il primo pacchetto vocale attivo (il primo pacchetto dopo la pausa) è contraddistinto da un bit di token impostato su uno nell'intestazione del pacchetto di dati RTP. Le applicazioni senza la soppressione del silenzio impostano questo bit su zero.
Il clock RTP utilizzato per generare il timestamp RTP è indipendente dal numero di canali e dal tipo di codifica; è uguale 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 alla frequenza di campionamento moltiplicata 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:
- l - sinistra;
- r - destra;
- c - centrale;
- S - periferico;
- F - frontale;
- R - indietro.
| Numero di canali | Nome del sistema | Numeri di canale | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 2 | stereo | io | R | ||||
| 3 | io | R | C | ||||
| 4 | quad | fl | FR | Rl | Rr | ||
| 4 | io | C | R | S | |||
| 5 | fl | FR | Fc | Sl | Sr | ||
| 6 | io | lc | C | R | rc | S | |
I campioni di tutti i canali appartenenti allo stesso tempo di campionamento devono trovarsi all'interno dello stesso pacchetto. L'interlacciamento di campioni da canali diversi dipende dal tipo di codifica.
La frequenza di campionamento deve essere selezionata tra una varietà di: 8000, 11025, 16000, 22050, 24000, 32000, 44100 e 48000 Hz (i computer Apple Macintosh hanno le proprie frequenze di campionamento di 22254,54 e 11127,27, che possono essere convertite 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 è definita per un insieme più limitato di frequenze di campionamento. I destinatari devono essere preparati a 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 la latenza end-to-end minima. I pacchetti più lunghi hanno relativamente meno byte per l'intestazione, ma causano un ritardo maggiore e rendono più significativa la perdita di pacchetti. Per le applicazioni non interattive, come le lezioni o i canali con vincoli di larghezza di banda significativi, può essere accettabile una latenza di pacchettizzazione più elevata. Il ricevitore dovrebbe ricevere pacchetti con segnale audio con un ritardo da 0 a 200 ms. Questa limitazione fornisce 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 dei dati audio compressi, i singoli codici campione possono attraversare i confini dell'ottetto. La durata del segnale trasmesso in un pacchetto sonoro è determinata dal numero di campioni nel pacchetto.
Per i tipi di codifica basati su campioni che producono uno o più ottetti per ciascun campione, i campioni provenienti da diversi canali campionati contemporaneamente vengono impacchettati in ottetti adiacenti. Ad esempio, per codificare un suono stereo, la sequenza di ottetti è: canale sinistro, primo campione; canale destro, primo conteggio; canale sinistro, secondo conteggio; canale destro, conteggio dei secondi, ecc. Nella codifica multi-ottetto, l'ottetto più significativo viene trasmesso per primo. L'impacchettamento di codifiche basate su campioni che producono meno di un ottetto per ciascun campione è determinato dall'algoritmo di codifica.
Un algoritmo di codifica basato su frame converte un blocco audio di lunghezza fissa in un altro blocco di dati compresso, solitamente anch'esso di lunghezza fissa. Per le codifiche basate su frame, il mittente può combinare più frame di questo tipo in un messaggio.
Per i codec basati su frame, l'ordine dei canali è specifico per l'intero blocco. Cioè, per il suono stereo, i campioni per i canali sinistro e destro sono codificati indipendentemente; in cui il frame di codifica per il canale sinistro precede il frame per il canale destro.
Tutti i codec audio frame-oriented devono essere in grado di codificare e decodificare più frame consecutivi trasmessi all'interno di un singolo pacchetto. Poiché è specificata la dimensione del frame per i codec orientati al frame, non è necessario utilizzare una notazione separata per la stessa codifica, ma con un numero diverso di frame nel pacchetto.
Tavolo 3 mostra i valori dei tipi di traffico (PT) definiti da questo profilo per i segnali audio, i loro simboli e le principali caratteristiche tecniche degli algoritmi di codifica.
11.4. Codifica video
Tavolo 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 impostati 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 della sessione può specificare che per una data sessione, il tipo di traffico 96 denota la codifica PCMU a doppio canale con una frequenza di campionamento di 8000 Hz. L'intervallo di valori del tipo di traffico contrassegnato come "riservato" non viene utilizzato in modo che i pacchetti RTCP e RTP possano essere distinti in modo affidabile .
Una sorgente RTP in un dato momento emette un solo tipo di traffico; non è consentito l'interlacciamento di traffico di tipo diverso nella stessa sessione RTP. Diverse sessioni RTP possono essere utilizzate 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, è consentito definire tipi di traffico combinato che combinano, ad esempio, audio e video, con un'adeguata separazione nel formato del traffico.
Le applicazioni audio che utilizzano questo profilo devono almeno essere in grado di inviare e ricevere i tipi di traffico 0 (PCMU) e 5 (DVI4). Ciò consente l'interoperabilità senza negoziazione del formato.
11.5. Assegnazione delle porte
Come definito nella descrizione del protocollo RTP, i dati RTP devono essere inviati tramite una porta UDP con numero pari e i corrispondenti pacchetti RTCP devono essere inviati tramite un numero di porta con numero dispari.
Le applicazioni che utilizzano questo profilo possono utilizzare qualsiasi coppia di porte UDP di questo tipo. Ad esempio, una coppia di porte può essere assegnata casualmente dal programma di gestione della sessione. Non è possibile specificare una singola 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 selezionare questa coppia di porte come indicatore di quel profilo. Ma le applicazioni possono anche richiedere la specifica esplicita di una coppia di porte.
12. Elenco dei termini e delle abbreviazioni utilizzati
- ASCII (American Standard Code for Information Interchange) è il codice standard americano per lo scambio di informazioni. Codice a sette bit per rappresentare informazioni testuali, utilizzato con alcune modifiche nella maggior parte dei sistemi informatici
- CBC (cipher block chaining) - catena di blocchi crittografata, modalità standard di crittografia dei dati DES
- CELP (previsione lineare eccitata dal codice) - un tipo di codifica audio che utilizza la previsione lineare eccitata dal codice
- CNAME (nome canonico) - nome canonico
- CSRC (fonte contribuente) - fonte inclusa. La sorgente del flusso di pacchetti RTP che ha contribuito al flusso combinato prodotto dal mixer RTP. Il mixer inserisce nell'intestazione del pacchetto RTP un elenco di identificatori SSRC di quelle sorgenti che hanno partecipato alla formazione di questo pacchetto. Questo elenco è chiamato elenco CSRC. Esempio: il mixer trasmette gli ID dei partecipanti alla teleconferenza attualmente parlando le cui voci sono state mixate e utilizzate per creare un pacchetto in uscita, puntando il destinatario alla sorgente del messaggio corrente, anche se tutti i pacchetti audio contengono lo stesso ID SSRC (come il mixer)
- DES (Data Encryption Standard) - standard di crittografia dei dati
- IANA (Internet Assigned Numbers Authority) - Comunità di numeri assegnati Internet
- IMA (Associazione Multimedia Interattiva) - Associazione Multimedia Interattiva
- IP (Protocollo Internet) - Protocollo Internet, protocollo di livello di rete, protocollo datagramma. Consente ai pacchetti di attraversare più reti lungo il percorso verso la loro destinazione
- IPM (IP Multicast) - multicast utilizzando il protocollo IP
- LD-CELP (previsione lineare eccitata da codice a basso ritardo) - un algoritmo di codifica vocale che utilizza la previsione lineare eccitata da codice con un ritardo ridotto
- LPC (codifica predittiva lineare) - codifica predittiva lineare
- NTP (Network Time Protocol) è un conto alla rovescia del tempo in secondi relativo a zero ore il 1 gennaio 1900. Il formato completo del timestamp NTP è 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 casi viene utilizzata una rappresentazione più compatta, in cui solo i 32 bit medi sono presi dal formato completo: i 16 bit inferiori della parte intera e i 16 bit superiori della parte frazionaria.
- RPE / LTP (eccitazione dell'impulso residuo / previsione a lungo termine) - un algoritmo di codifica vocale con eccitazione dell'impulso differenziale e previsione a lungo termine
- RTCP (Real-Time Control Protocol) - protocollo di controllo della trasmissione dei dati in tempo reale
- RTP (Real-Time Transport Protocol) - protocollo di trasporto in tempo reale
- SSRC (sorgente di sincronizzazione) - sorgente di sincronizzazione. La sorgente del flusso di pacchetti RTP, identificata dall'identificatore SSRC numerico a 32 bit trasportato nell'intestazione RTP, indipendentemente dall'indirizzo di rete. Tutti i pacchetti con la stessa sorgente di sincronizzazione utilizzano lo stesso spazio di temporizzazione e numero di sequenza, quindi il ricevitore raggruppa i pacchetti per la riproduzione con la sorgente di sincronizzazione. Un esempio di sorgente di sincronizzazione: il mittente di un flusso di pacchetti ricevuto da una sorgente di segnale come un microfono, una videocamera o un mixer RTP. La sorgente di sincronizzazione può modificare il formato dei dati nel tempo, ad esempio la codifica audio. L'identificatore SSRC è un valore selezionato casualmente che è considerato globalmente univoco all'interno di una particolare sessione RTP. Il partecipante alla teleconferenza non deve utilizzare lo stesso SSRC per tutte le sessioni RTP in una sessione di comunicazione multimediale; L'aggregazione delle identità SSRC viene fornita tramite RTCP. Se un partecipante genera più flussi in una sessione RTP, ad esempio da più videocamere, ogni flusso deve essere identificato da un SSRC separato
- TCP (Transmission Control Protocol) è un protocollo di livello di trasporto utilizzato insieme a IP
- UDP (User Datagram Protocol) è un protocollo di livello di trasporto senza connessione. UDP consente solo l'invio di un pacchetto a una o più stazioni della rete. La convalida e la garanzia dell'integrità (consegna garantita) della trasmissione dei dati viene effettuata a un livello superiore
- ADPCM - Modulazione del codice di impulso differenziale adattivo
- jitter - jitter, deviazioni di fase o frequenza del segnale; in relazione alla telefonia IP - irregolarità nel ritardo dei datagrammi nella rete
- ZPD - collegamento di trasmissione dati (secondo livello del modello di riferimento per l'interazione tra sistemi aperti)
- IVS - Reti informatiche e informatiche
- mixer - Un sistema intermedio che riceve pacchetti RTP da una o più sorgenti, eventualmente modifica il formato dei dati, concatena i pacchetti in un nuovo pacchetto RTP e quindi lo trasmette. Poiché molte sorgenti di segnale non sono generalmente sincronizzate, il mixer regola la temporizzazione dei flussi dei componenti e genera la propria temporizzazione per il flusso combinato. Pertanto, tutti i pacchetti di informazioni generati dal mixer sono identificati come aventi il mixer come sorgente di sincronizzazione.
- monitor (monitor) - un'applicazione che riceve pacchetti RTCP inviati dai partecipanti a una sessione RTP, in particolare, riceve report e valuta l'attuale qualità del servizio per controllare la distribuzione, rilevare errori e statistiche a lungo termine. Di solito le funzioni del monitor risiedono nelle applicazioni utilizzate nella sessione, ma il monitor può anche essere un'applicazione separata che non viene utilizzata in altro modo, non invia o riceve pacchetti di dati RTP. Tali applicazioni sono chiamate monitor di terze parti.
- ITU-T - Settore della standardizzazione delle telecomunicazioni dell'Unione internazionale delle telecomunicazioni
- sistema finale - un'applicazione che genera contenuto trasmesso in pacchetti RTP e/o che consuma il contenuto dei pacchetti RTP ricevuti. Il sistema finale può agire come una o più (ma di solito solo una) sorgenti di clock in ogni sessione RTP
- Pacchetto RTCP - Un pacchetto di controllo costituito da una porzione fissa dell'intestazione, simile ai pacchetti di informazioni RTP, seguita da elementi strutturali che variano a seconda del tipo di pacchetto RTCP. In genere, più pacchetti RTCP vengono inviati insieme come un pacchetto RTCP composito in un unico pacchetto di protocollo sottostante; questo è fornito dal campo lunghezza nell'intestazione fissa di ogni pacchetto RTCP
- Il pacchetto RTP è un'unità di dati del protocollo costituita da un'intestazione RTP fissa, possibilmente un elenco vuoto di origini, estensioni e traffico inclusi. Di solito un pacchetto di protocollo di livello inferiore contiene un pacchetto RTP, ma possono essercene diversi
- port è un'astrazione utilizzata dai protocolli a livello di trasporto per distinguere più destinazioni all'interno di un singolo computer host. La porta è identificata dal suo numero. Pertanto, il numero di porta è un numero che identifica l'applicazione specifica a cui sono destinati i dati inviati. Questo numero, insieme alle informazioni su quale protocollo (ad esempio, TCP o UDP) viene utilizzato al livello superiore, è contenuto tra le altre informazioni di servizio nei datagrammi inviati su Internet. I selettori di trasporto (TSEL) utilizzati dal livello di trasporto OSI sono equivalenti alle porte
- profilo (profilo) - un insieme di parametri per i protocolli RTP e RTCP per una classe di applicazioni, che determina le caratteristiche del loro funzionamento. Il profilo definisce l'uso di bit token e campi del tipo di traffico nell'intestazione del pacchetto di dati RTP, tipi di traffico, aggiunte dell'intestazione del pacchetto di dati RTP, primi 16 bit dell'estensione dell'intestazione del pacchetto di dati RTP, tipi di pacchetto RTCP, intervallo di segnalazione RTCP, pacchetto SR / RR estensione, utilizzo di pacchetti SDES, servizi e algoritmi per garantire la sicurezza delle comunicazioni e le caratteristiche dell'utilizzo del protocollo di livello inferiore
- Sessione RTP (sessione RTP) - comunicazione di molti partecipanti che interagiscono tramite il protocollo RTP. Per ogni partecipante, la sessione è determinata da una coppia specifica di indirizzi di trasporto di destinazione (un indirizzo di rete più una coppia di porte per RTP e RTCP). Una coppia di indirizzi di destinazione del trasporto può essere comune a tutti i partecipanti (come nel caso dell'IPM) oppure può essere diversa per ciascuno (singolo indirizzo di rete e una coppia comune di porte, come nella comunicazione bidirezionale). In una sessione multimediale, ogni tipo di traffico viene inviato in una sessione RTP separata con i propri pacchetti RTCP. Le sessioni RTP multicast si distinguono per diversi numeri di coppie di porte e/o diversi indirizzi multicast
- mezzi non RTP — Protocolli e meccanismi che potrebbero essere necessari in aggiunta a RTP per fornire un servizio accettabile. In particolare per le conferenze multimediali, l'applicazione di gestione delle conferenze può allocare indirizzi multicast e chiavi di crittografia, negoziare l'algoritmo di crittografia da utilizzare e determinare mappature dinamiche tra i valori del tipo di traffico RTP e i formati di traffico che rappresentano (formati che non hanno un valore predefinito valore, tipo di traffico). Per applicazioni semplici, è possibile utilizzare anche database di posta elettronica o conferenze
- traduttore: un sistema intermedio che inoltra i pacchetti RTP senza modificare l'ID della sorgente di sincronizzazione. Esempi di traduttori: dispositivi che eseguono la transcodifica senza miscelazione, replicatori multidirezionali o bidirezionali, applicazioni a livello di applicazione nei firewall
- indirizzo di trasporto: una combinazione di indirizzo di rete e numero di porta che identifica l'endpoint del livello di trasporto, ad esempio un indirizzo IP e un numero di porta UDP. I pacchetti vengono inoltrati dall'indirizzo di trasporto di origine all'indirizzo di trasporto di destinazione
- Traffico RTP: dati multimediali trasmessi in un pacchetto RTP, come campioni audio o dati video compressi
- PSTN - reti telefoniche pubbliche commutate
Buona giornata!
Totale: il sistema di monitoraggio è un complesso che è connesso in modalità non intrusiva all'n-esimo numero di collegamenti 10 Gigabit Ethernet, che “monitora” continuamente la trasmissione di tutti i flussi video RTP presenti nel traffico ed effettua misurazioni a un certo intervallo di tempo per salvarli successivamente sulla base. Secondo i dati del database, i rapporti vengono generati regolarmente per tutte le telecamere.
E cosa c'è di così difficile?
Nel processo di ricerca di una soluzione, sono stati immediatamente registrati diversi problemi:
- Connessione non invadente. Il sistema di monitoraggio si collega a canali già operativi, in cui la maggior parte delle connessioni (tramite RTSP) sono già state stabilite, server e client sanno già quali porte vengono scambiate, ma noi non lo sappiamo in anticipo. La porta ben nota è solo per RTSP, ma i flussi UDP possono andare su porte arbitrarie (inoltre, si è scoperto che spesso violano il requisito DOVREBBE di porte pari/dispari, vedere rfc3550). Come determinare che un particolare pacchetto da un determinato indirizzo IP appartiene a un flusso video? Ad esempio, il protocollo BitTorrent si comporta in modo simile: nella fase di stabilire una connessione, il client e il server concordano sulle porte e quindi tutto il traffico UDP sembra "solo un flusso di bit".
- I collegamenti collegati possono contenere più di flussi video. Ci possono essere HTTP, BitTorrent, SSH e qualsiasi altro protocollo che usiamo oggi. Pertanto, il sistema deve identificare correttamente i flussi video per separarli dal resto del traffico. Come farlo in tempo reale con 8 collegamenti da 10 Gb? Di solito, ovviamente, non sono pieni al 100%, quindi il traffico totale non sarà di 80 gigabit / s, ma di circa 50-60, ma non è così poco.
- Scalabilità. Laddove esistono già molti flussi video, potrebbero essercene anche di più, poiché la videosorveglianza si è dimostrata da tempo uno strumento efficace. Ciò suggerisce che dovrebbe esserci un margine di prestazione e un margine di collegamento.
Cerchiamo una soluzione adeguata...
Abbiamo naturalmente cercato di sfruttare al meglio la nostra esperienza. Quando è stata presa la decisione, avevamo già un'implementazione per l'elaborazione di pacchetti ethernet su un dispositivo Berkut-MX alimentato da FPGA (più facile - MX). Con l'aiuto di Bercut-MX, siamo stati in grado di ottenere i campi necessari per l'analisi dalle intestazioni dei pacchetti Ethernet. Sfortunatamente, non avevamo l'esperienza di elaborare un tale volume di traffico tramite server "ordinari", quindi hanno esaminato una soluzione del genere con una certa cautela ...
Sembrerebbe che rimanesse solo da applicare il metodo ai pacchetti RTP e la chiave d'oro sarebbe nelle nostre tasche, ma MX può solo elaborare il traffico, non include la possibilità di registrare e memorizzare le statistiche. Non c'è memoria sufficiente nell'FPGA per memorizzare le connessioni trovate (combinazioni IP-IP-porta-porta), perché un collegamento 2x10-Gigabit in ingresso può contenere circa 15mila flussi video, e per ognuno è necessario “ricordare ” il numero di pacchetti ricevuti, il numero di pacchetti persi, e così via... Inoltre, cercare a una tale velocità e con una tale quantità di dati, soggetti ad elaborazione lossless, diventa un compito non banale.
Per trovare una soluzione, abbiamo dovuto "scavare più a fondo" e capire quali algoritmi utilizzeremo per misurare la qualità e identificare i flussi video.
Cosa può essere misurato dai campi di un pacchetto RTP?
Dalla descrizione si evince che dal punto di vista delle misure di qualità nel pacchetto RTP, siamo interessati ai seguenti campi:
- numero di sequenza - contatore a 16 bit che aumenta con ogni pacchetto inviato;
- timestamp - timestamp, per h.264 la dimensione del campione è 1/90000 s (cioè corrisponde a una frequenza di 90 KHz);
- Bit di marcatore. In rfc3550 viene generalmente descritto che questo bit ha lo scopo di designare eventi "significativi", e infatti questo bit è più spesso utilizzato dalle telecamere per contrassegnare l'inizio di un frame video e pacchetti specializzati con informazioni SPS / PPS.
È abbastanza ovvio che il numero di sequenza consente di definire i seguenti parametri di flusso:
- perdita di pacchetti (perdita di frame);
- invio ripetuto del pacchetto (duplicato);
- riordino;
- riavviare la telecamera se c'è una grande interruzione nella sequenza.
Misure di marca temporale:
- variazione del ritardo (detta anche jitter). Allo stesso tempo, un contatore a 90 KHz dovrebbe funzionare sul lato ricevente;
- in linea di principio, il ritardo nel passaggio del pacchetto. Ma per questo è necessario sincronizzare l'ora della telecamera con il timestamp, e questo è possibile se la telecamera trasmette i rapporti del mittente (RTCP SR), che generalmente non è corretto, poiché nella vita reale, molte fotocamere ignorano l'invio RTCP SR (circa la metà delle fotocamere con cui abbiamo lavorato).
Bene, M-bit ti permette di misurare il frame rate. Tuttavia, i frame SPS / PPS del protocollo h.264 introducono un errore, poiché i fotogrammi video non lo sono. Ma può essere livellato utilizzando le informazioni dall'intestazione dell'unità NAL, che segue sempre l'intestazione RTP.
Algoritmi dettagliati per la misurazione dei parametri esulano dallo scopo dell'articolo, non approfondirò. Se sei interessato, l'rfc3550 contiene un esempio di codice di calcolo delle perdite e una formula per il calcolo del jitter. La conclusione principale è che solo pochi campi dei pacchetti RTP e delle unità NAL sono sufficienti per misurare le caratteristiche di base di un flusso di trasporto. E il resto delle informazioni non partecipa alle misurazioni e può e deve essere scartato!
Come identificare i flussi RTP?
Per mantenere le statistiche, le informazioni ricevute dall'intestazione RTP devono essere "legate" a un identificatore di telecamera (stream video). La telecamera può essere identificata in modo univoco dai seguenti parametri:
- Indirizzi IP di origine e destinazione
- Porte di origine e di destinazione
- SSRC. È di particolare importanza quando vengono trasmessi più flussi da un IP, ad es. nel caso di un encoder multiporta.
È interessante notare che all'inizio abbiamo identificato le telecamere solo tramite IP sorgente e SSRC, basandoci sul fatto che SSRC dovrebbe essere casuale, ma in pratica si è scoperto che molte telecamere impostano SSRC su un valore fisso (diciamo 256). Apparentemente, ciò è dovuto al risparmio di risorse. Di conseguenza, abbiamo dovuto aggiungere porte all'ID della fotocamera. Questo ha risolto completamente il problema dell'unicità.
Come separare i pacchetti RTP dal resto del traffico?
La domanda rimane: come farà Berkut-MX, dopo aver accettato il pacchetto, a capire che si tratta di RTP? L'intestazione RTP non ha un'identificazione così esplicita come IP, non ha un checksum, può essere trasmessa su UDP con numeri di porta che vengono selezionati dinamicamente quando si stabilisce una connessione. E nel nostro caso, la maggior parte delle connessioni è già stata stabilita da molto tempo e puoi aspettare una reinstallazione per molto tempo.
Per risolvere questo problema, rfc3550 (Appendice A.1) consiglia di controllare i bit della versione RTP - questi sono due bit e il campo Payload Type (PT) - sette bit, che nel caso di un tipo dinamico richiede un intervallo ridotto. In pratica, abbiamo scoperto che per il set di fotocamere con cui lavoriamo, PT rientra nel range da 96 a 100.
C'è un altro fattore: la parità del porto, ma come ha dimostrato la pratica, non è sempre rispettato, quindi ha dovuto essere abbandonato.
Pertanto, il comportamento di Berkut-MX è il seguente:
- riceviamo il pacco, lo smontiamo nei campi;
- se la versione è 2 e il tipo di payload rientra nei limiti specificati, inviamo le intestazioni al server.
Ovviamente, con questo approccio, ci sono falsi positivi, dal momento che non solo i pacchetti RTP possono rientrare in criteri così semplici. Ma è importante per noi che non lasceremo assolutamente passare il pacchetto RTP e il server filtrerà i pacchetti "sbagliati".
Per filtrare i casi falsi, il server utilizza un meccanismo che registra la sorgente del traffico video per diversi pacchetti ricevuti consecutivamente (il pacchetto contiene un numero di sequenza!). Se sono arrivati più pacchetti con numeri sequenziali, non si tratta di una coincidenza accidentale e iniziamo a lavorare con questo flusso. Questo algoritmo si è dimostrato molto affidabile.
Andare avanti ...
Rendendosi conto che tutte le informazioni in arrivo nei pacchetti non sono necessarie per misurare la qualità e identificare i flussi, abbiamo deciso di caricare tutto il lavoro highload e time-critical sulla ricezione e l'isolamento dei campi dei pacchetti RTP su Berkut-MX, ovvero su FPGA. "Trova" il flusso video, analizza il pacchetto, lascia solo i campi richiesti e lo invia a un server normale in un tunnel UDP. Il server effettua misurazioni per ciascuna telecamera e salva i risultati nel database.
Di conseguenza, il server non funziona con 50-60 Gigabit/s, ma con un massimo del 5% (questa è la proporzione dei dati inviati rispetto alla dimensione media del pacchetto). Cioè, all'ingresso dell'intero sistema, 55 Gigabit / s, mentre il server riceve solo non più di 3 Gigabit / s!
Di conseguenza, abbiamo ottenuto la seguente architettura:
E abbiamo ottenuto il primo risultato in questa configurazione due settimane dopo l'assegnazione dell'incarico tecnico iniziale!
Cosa fa il server alla fine?
Quindi cosa fa il server nella nostra architettura? I suoi compiti:
- ascoltare un socket UDP e leggere i campi di intestazione compressi da esso;
- analizzare i pacchetti in entrata e ottenere i campi di intestazione RTP da lì insieme agli identificatori della telecamera;
- correlare i campi ricevuti con quelli ricevuti in precedenza, e capire se i pacchetti sono stati persi, se i pacchetti sono stati reinviati, se l'ordine di arrivo è stato modificato, qual è stata la variazione del ritardo di transito dei pacchetti (jitter), ecc.;
- fissare il misurato nella base con riferimento al tempo;
- analizzare il database e generare report, inviare trap su eventi critici (elevata perdita di pacchetti, perdita di pacchetti da una telecamera, ecc.).
Dato che il traffico totale all'ingresso del server è di circa 3 Gigabit/s, il server può gestirlo anche se non utilizziamo alcun DPDK, ma semplicemente lavorare tramite un socket linux (avendo precedentemente aumentato la dimensione del buffer per il socket, ovviamente ). Inoltre, sarà possibile collegare nuovi collegamenti e MX", perché il margine di prestazione rimane.
Ecco come appare la parte superiore del server (questa è la parte superiore di un solo contenitore lxc, i report vengono generati in un altro):
Da esso si può vedere che l'intero carico sul calcolo dei parametri di qualità e sulla presa in considerazione delle statistiche è distribuito uniformemente sui quattro processi. Siamo riusciti a ottenere una tale distribuzione grazie all'uso dell'hashing in FPGA: la funzione hash viene calcolata dall'IP e i bit meno significativi dell'hash ricevuto determinano il numero di porta UDP a cui andranno le statistiche. Di conseguenza, ogni processo in ascolto sulla propria porta riceve approssimativamente la stessa quantità di traffico.
Pro e contro
Ora è il momento di vantarsi e ammettere le carenze della soluzione.
Inizierò con i pro:
- nessuna perdita alla giunzione con collegamenti 10G. Poiché l'FPGA prende tutto il "colpo", possiamo essere sicuri che ogni pacchetto verrà analizzato;
- per monitorare 55.000 telecamere (e oltre), è necessario un solo server con una scheda 10G. Utilizziamo ancora server basati su Xeon 2x con 4 core, 2400 MHz ciascuno. Basta con un margine: parallelamente alla raccolta delle informazioni, vengono generati i report;
- il monitoraggio di 8 "decine" (collegamenti 10G) sta in sole 2-3 unità: non sempre c'è molto spazio e potenza nel rack per il sistema di monitoraggio;
- quando si collegano i collegamenti da MX'ov tramite lo switch, è possibile aggiungere nuovi collegamenti senza interrompere il monitoraggio, perché non è necessario inserire schede nel server e non è necessario spegnerlo per questo;
- il server non è sovraccarico di dati, riceve solo ciò che gli serve;
- le intestazioni di MX vengono fornite in un pacchetto Ethernet jumbo, il che significa che il processore non sarà soffocato dagli interrupt (inoltre, non dimentichiamo la coalescenza degli interrupt).
In tutta onestà, prenderò in considerazione anche gli svantaggi:
- a causa della rigorosa ottimizzazione per un'attività specifica, l'aggiunta del supporto per nuovi campi o protocolli richiede modifiche al codice FPGA. Questo porta a più tempo sprecato che se stessimo facendo lo stesso sul processore. Sia in fase di sviluppo e test, sia durante la distribuzione;
- le informazioni video non vengono affatto analizzate. La fotocamera può catturare il ghiacciolo appeso di fronte o essere girata nella direzione sbagliata. Questo fatto passerà inosservato. Ovviamente abbiamo fornito la possibilità di registrare video dalla telecamera selezionata, ma l'operatore non passa attraverso tutte le 55.000 telecamere!
- server e dispositivi alimentati da FPGA sono più costosi di uno o due server;)
Riepilogo
Alla fine, abbiamo ottenuto un complesso hardware e software in cui possiamo controllare sia la parte che analizza i pacchetti sulle interfacce sia quella che mantiene le statistiche. Il pieno controllo su tutti i nodi del sistema ci ha letteralmente salvato quando le telecamere hanno iniziato a passare alla modalità interleaved RTSP/TCP. Perché in questo caso l'intestazione RTP non si trova più nel pacchetto ad un offset fisso: può essere ovunque, anche sul confine di due pacchetti (la prima metà è in uno, la seconda nell'altro). Di conseguenza, l'algoritmo per ottenere l'intestazione RTP e i suoi campi ha subito notevoli cambiamenti. Abbiamo dovuto riassemblare il TCP sul server per tutte le 50.000 connessioni, da qui il carico piuttosto elevato nella parte superiore.
Non abbiamo mai lavorato nel campo delle applicazioni ad alto carico prima, ma siamo riusciti a risolvere il problema utilizzando le nostre competenze FPGA e il risultato è stato abbastanza buono. C'è anche un margine rimasto: ad esempio, altri 20-30 mila stream possono essere collegati a un sistema con 55.000 telecamere.
Ottimizzazione dei sottosistemi linux (distribuzione delle code tramite interrupt, aumento dei buffer di ricezione, allocazione delle direttive dei core a processi specifici, ecc.) sono uscito dall'ambito dell'articolo, perché questo argomento è già molto ben trattato.
Non ho descritto tutto, sono stati raccolti molti rastrelli, quindi non esitare a fare domande :)
Molte grazie a tutti coloro che hanno letto fino alla fine!
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 (Internet Protocol) comprese le 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 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 telefono convenzionale è anche la capacità di fornire servizi aggiuntivi attraverso l'uso di un computer multimediale e 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à di 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 la consegna affidabile delle informazioni trasmesse in queste condizioni, vengono utilizzate varie 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. Queste applicazioni richiedono un protocollo di livello di trasporto diverso in grado di recuperare la sequenza di pacchetti originale, consegnarli con un ritardo minimo, riprodurre in tempo reale a orari precisi, riconoscere il tipo di traffico, comunicazione di gruppo o 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). RTCP, a sua volta, fornisce il controllo sulla consegna dei dati multimediali, il controllo della qualità del servizio, la trasmissione di informazioni sui partecipanti alla sessione di comunicazione corrente, 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. Sul lato ricevente, 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 il fuori servizio 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. pacchetti (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 di 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 appare un nuovo partecipante che utilizza una linea di comunicazione con larghezza di banda ridotta, o 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 (cfr. 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, 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. 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 una serie di 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 (vedi 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 deve essere ricavato da un timer che ne incrementi i valori in modo monotono e lineare nel tempo per garantire la sincronizzazione e il rilevamento del jitter (vedi. 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 (vedi. 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 state mescolate al momento della creazione del pacchetto sono elencati nell'elenco CSRC, fornendo al destinatario un'indicazione corretta dell'origine dei messaggi.
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 è identificata 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 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. L'interlacciamento di pacchetti con diversi tipi di traffico ma utilizzando lo stesso SSRC causerebbe alcuni problemi:
- Se uno dei tipi di traffico cambia durante la 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 temporizzazione e lo spazio del numero di sequenza. L'interlacciamento di più tipi di traffico richiederebbe intervalli di sincronizzazione diversi se le frequenze di clock di flussi diversi sono diverse e spazi di numeri di sequenza diversi per indicare il tipo di traffico a cui si riferisce la perdita di pacchetti.
- Messaggi RTCP mittente e destinatario (vedi sezione 4.3) descrivono solo un valore dell'intervallo di tempo e uno 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'utilizzo di percorsi di rete diversi o l'allocazione delle 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 l'utilizzo di una sessione RTP diversa per ogni tipo di traffico.
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 marker. Se ci sono dei marker bit, 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 marker bit.
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 richiede 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 che siano necessarie funzionalità aggiuntive in comune a tutti i profili, è necessario definire una nuova versione RTP per apportare modifiche permanenti all'intestazione fissa.
3.4. Estensione dell'intestazione RTP
Per consentire alle singole implementazioni di sperimentare nuove funzioni 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 |
RTP - Protocollo di trasporto in tempo reale RTCP - Protocollo di controllo in tempo reale Include inoltre informazioni su: Perdita di pacchetti Buffer del jitter Ritardi Livello del segnale Metrica della qualità del segnale (Call Quality Metrics) Echo Return Loss ecc. RTCP XR - Report estesi del protocollo di controllo in tempo reale Tutti i campi descritti per RTCP plus: Fattore R - Parametro di qualità del segnale MOS - Parametro di qualità del segnale e altri
I pacchetti contenenti la voce in uscita vengono inviati utilizzando RTP/RTCP per il protocollo utilizzato per le chiamate VOIP. RTP può trasportare supporti identificati da parametri registrati dall'"autorità per i numeri assegnati a Internet" - IANA. Sono utilizzati anche per i campi nel protocollo utilizzato nei messaggi.
Alcuni valori del campo payload:
| PT | nome codec | audio/video (A/V) | frequenza di clock (Hz) | numero di canali | Documento | 0 | PCMU | UN | 8000 | 1 | RFC3551 | 3 | GSM | UN | 8000 | 1 | RFC3551 | 4 | G723 | UN | 8000 | 1 | Kumar | 5 | DVI4 | UN | 8000 | 1 | RFC3551 | 6 | DVI4 | UN | 16000 | 1 | RFC3551 | 7 | LPC | UN | 8000 | 1 | RFC3551 | 8 | PCMA | UN | 8000 | 1 | RFC3551 | 9 | G722 | UN | 8000 | 1 | RFC3551 | 10 | L16 | UN | 44100 | 2 | RFC3551 | 11 | L16 | UN | 44100 | 1 | RFC3551 | 12 | QCELP | UN | 8000 | 1 | - | 13 | CN | UN | 8000 | 1 | RFC3389 | 14 | MPA | UN | 90000 | RFC3551, RFC2250 | 15 | G728 | UN | 8000 | 1 | RFC3551 | 16 | DVI4 | UN | 11025 | 1 | DiPol | 17 | DVI4 | UN | 22050 | 1 | DiPol | 18 | G729 | UN | 8000 | 1 | 19 | riservato | UN | 20 | non assegnato | UN | 21 | non assegnato | UN | 22 | non assegnato | UN | 23 | non assegnato | UN | 24 | non assegnato | V | 25 | CelB | V | 90000 | RFC2029 | 26 | JPEG | V | 90000 | RFC2435 | 27 | non assegnato | V | 28 | nv | V | 90000 | RFC3551 | 29 | non assegnato | V | 30 | non assegnato | V | 31 | H261 | V | 90000 | RFC2032 | 32 | monovolume | V | 90000 | RFC2250 | 33 | MP2T | AV | 90000 | RFC2250 | 34 | H263 | V | 90000 | Zhu | 35--71 | non assegnato | 72--76 | riservato a RTCP per evitare conflitti | RFC3550 | 77--95 | non assegnato | 77--95 | dinamico | RFC3551 |
IANA: Parametri RTP registrati: http://www.iana.org/assignments/rtp-parameters
