Buon pomeriggio
Riassumendo: il sistema di monitoraggio è un complesso che è connesso in modalità non intrusiva all'ennesimo numero di collegamenti 10 gigabit Ethernet, che “monitora” continuamente la trasmissione di tutti i flussi video RTP presenti nel traffico ed effettua misurazioni ad un certo intervallo di tempo per salvarle successivamente nel database. Secondo i dati del database, i report vengono regolarmente creati per tutte le telecamere.
Nel processo di ricerca di una soluzione, sono stati immediatamente risolti diversi problemi:
Naturalmente, abbiamo cercato di sfruttare al massimo la nostra esperienza. Quando è stata presa la decisione, avevamo già un'implementazione dell'elaborazione dei pacchetti Ethernet sul dispositivo Bercut-MX alimentato da FPGA (più semplicemente - 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 esperienza nell'elaborazione di un tale volume di traffico utilizzando server "normali", quindi hanno guardato a tale soluzione con una certa apprensione ...
Sembrerebbe che restasse solo da applicare il metodo ai pacchetti RTP e avremmo la chiave d'oro in tasca, ma MX può solo elaborare il traffico, non include la possibilità di registrare e archiviare statistiche. Non c'è memoria sufficiente nell'FPGA per memorizzare le connessioni trovate (combinazioni IP-IP-porta-porta), perché in un collegamento 2x10 gigabit che entra in ingresso possono esserci 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 una tale quantità di dati a condizione di un'elaborazione senza perdita diventa un'attività 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.
Dalla descrizione si può vedere che dal punto di vista delle misure di qualità nel pacchetto RTP, siamo interessati ai seguenti campi:
È abbastanza ovvio che il numero di sequenza consente di definire i seguenti parametri di flusso:
Timestamp ti permette di misurare:
Bene, M-bit ti consente di misurare il frame rate. È vero, i frame SPS / PPS del protocollo h.264 introducono un errore, perché non sono fotogrammi video. 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 interessati, rfc3550 ha un esempio di codice di calcolo della perdita 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 è coinvolto nelle misurazioni e può e deve essere scartato!
Per mantenere le statistiche, le informazioni ottenute dall'intestazione RTP devono essere "allegate" a un determinato identificatore di telecamera (stream video). La telecamera può essere univocamente identificata dai seguenti parametri:
È interessante notare che all'inizio abbiamo effettuato l'identificazione della telecamera solo tramite IP di origine e SSRC, basandoci sul fatto che SSRC dovrebbe essere casuale, ma in pratica si è scoperto che molte telecamere impostano SSRC su un valore fisso (ad esempio, 256). Apparentemente, ciò è dovuto al risparmio di risorse. Di conseguenza, abbiamo dovuto aggiungere porte all'ID della videocamera. Ciò ha risolto completamente il problema dell'unicità.
La domanda rimane: come farà Berkut-MX, avendo 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 viene stabilita la connessione. E nel nostro caso, la maggior parte delle connessioni è stata stabilita da tempo e puoi aspettare molto tempo per la reinstallazione.
Per risolvere questo problema, si consiglia in rfc3550 (Appendice A.1) di controllare i bit della versione RTP - si tratta di due bit e il campo Payload Type (PT) - sette bit, che nel caso di un tipo dinamico richiede un intervallo ridotto. Abbiamo scoperto in pratica che per il set di telecamere con cui lavoriamo, PT rientra nell'intervallo da 96 a 100.
C'è un altro fattore: la parità del porto, ma come ha dimostrato la pratica, non è sempre osservata, quindi ha dovuto essere abbandonata.
Pertanto, il comportamento di Berkut-MX è il seguente:
Ovviamente, con questo approccio, ci sono falsi positivi, perché. non solo i pacchetti RTP possono rientrare in criteri così semplici. Ma per noi è importante che sicuramente non perderemo il pacchetto RTP e il server filtrerà i pacchetti "sbagliati".
Per filtrare i casi falsi, il server utilizza un meccanismo che registra l'origine del traffico video per diversi pacchetti ricevuti in sequenza (c'è un numero di sequenza nel pacchetto!). Se sono arrivati diversi pacchetti con numeri consecutivi, non è una coincidenza e iniziamo a lavorare con questo flusso. Questo algoritmo si è rivelato molto affidabile.
Rendendoci conto che tutte le informazioni che arrivano nei pacchetti non sono necessarie per misurare la qualità e identificare i flussi, abbiamo deciso di trasferire 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 normale server nel tunnel UDP. Il server effettua le 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 è esattamente la proporzione di dati inviati alla dimensione media del pacchetto). Cioè, all'ingresso dell'intero sistema 55 Gigabit / s, e solo non più di 3 Gigabit / s arrivano al server!
Di conseguenza, abbiamo ottenuto la seguente architettura:
E abbiamo ottenuto il primo risultato in questa configurazione due settimane dopo aver impostato il TOR iniziale!
Quindi cosa fa il server nella nostra architettura? I suoi compiti:
Nonostante il traffico totale all'ingresso del server sia di circa 3 Gigabit / s, il server se la cava anche se non utilizziamo DPDK, ma lavoriamo semplicemente tramite un socket Linux (dopo aver aumentato la dimensione del buffer per il socket, ovviamente). Inoltre, sarà possibile collegare nuovi collegamenti e MX ", perché il margine di prestazioni 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 per il calcolo dei parametri di qualità e la contabilizzazione delle statistiche è distribuito uniformemente su quattro processi. Siamo riusciti a ottenere una tale distribuzione utilizzando l'hashing nell'FPGA: la funzione hash viene calcolata dall'IP ei bit bassi dell'hash ricevuto determinano il numero della porta UDP a cui andranno le statistiche. Di conseguenza, ogni processo in ascolto sulla sua porta riceve approssimativamente la stessa quantità di traffico.
È tempo di vantarsi e ammettere i difetti della soluzione.
Inizierò con i pro:
In tutta onestà, considererò gli svantaggi:
Alla fine, abbiamo ottenuto un complesso software e hardware in cui possiamo controllare sia la parte che analizza i pacchetti sulle interfacce sia la parte che conserva 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 al 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 modifiche fondamentali. Abbiamo dovuto eseguire il riassemblaggio 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 grazie alle nostre competenze in FPGA e si è rivelato abbastanza buono. C'era anche un margine: ad esempio, altri 20-30mila stream possono essere collegati a un sistema con 55.000 telecamere.
Ottimizzazione dei sottosistemi Linux (distribuzione delle code tramite interruzioni, aumento dei buffer di ricezione, allocazione diretta dei core a processi specifici, ecc.) Ho lasciato fuori dallo scopo dell'articolo, perché. questo argomento è già molto ben trattato.
Ho descritto lontano da tutto, sono stati raccolti molti rastrelli, quindi sentiti libero di fare domande :)
Molte grazie a tutti coloro che hanno letto fino alla fine!
Il problema più urgente è sempre più la mancanza di spazio degli indirizzi, che richiede la modifica del formato dell'indirizzo.
Un altro problema è l'insufficiente scalabilità della procedura di routing, la base delle reti IP. La rapida crescita della rete provoca un sovraccarico dei router, che oggi sono costretti a mantenere tabelle di instradamento con decine e centinaia di migliaia di voci, oltre a risolvere i problemi di frammentazione dei pacchetti. Il lavoro dei router può essere facilitato, in particolare, aggiornando il protocollo IP.
Insieme all'introduzione di nuove funzioni direttamente nel protocollo IP, è consigliabile garantire una sua più stretta interazione con i nuovi protocolli introducendo nuovi campi nell'intestazione del pacchetto.
Di conseguenza, si è deciso di sottoporre a modernizzazione il protocollo IP, perseguendo i seguenti obiettivi principali:
Espansione dello spazio degli indirizzi. Il protocollo IP risolve il potenziale problema della carenza di indirizzi espandendo la lunghezza dell'indirizzo a 128. Tuttavia, un aumento così significativo della lunghezza dell'indirizzo è stato fatto in gran parte non per eliminare il problema della carenza di indirizzi, ma per aumentare l'efficienza delle reti basate su questo protocollo. L'obiettivo principale era un cambiamento strutturale nel sistema di indirizzamento, ampliandone le funzionalità.
Invece dei due livelli esistenti della gerarchia degli indirizzi (numero di rete e numero di host), IPv6 propone di utilizzare quattro livelli, il che implica un'identificazione di rete a tre livelli e un livello per l'identificazione del nodo.
Ora l'indirizzo è scritto in esadecimale, con ogni quattro cifre separate l'una dall'altra da due punti, ad esempio:
FEDC:0A96:0:0:0:0:7733:567A.
Per le reti che supportano entrambe le versioni del protocollo IPv4 e IPv6, è possibile utilizzare la tradizionale notazione decimale per i 4 byte inferiori, ed esadecimale per quelli superiori:
0:0:0:0:FFFF 194.135.75.104.
All'interno del sistema di indirizzamento IPv6, esiste anche uno spazio di indirizzi dedicato per uso locale, ovvero per le reti esterne a Internet. Ci sono due varietà indirizzi locali: per reti "piatte" senza subnet (Link-Local) e per reti con subnet (Site-Local), che differiscono per il valore del prefisso.
Modifica del formato delle intestazioni dei pacchetti. Ciò può essere implementato da un nuovo schema organizzativo di "intestazioni nidificate", che assicuri la divisione dell'intestazione in quella principale, che contiene le informazioni minime necessarie, e in quelle aggiuntive, che possono mancare. Questo approccio apre ricche possibilità per estendere il protocollo definendo nuove intestazioni opzionali, rendendo il protocollo aperto.
L'intestazione del datagramma IPv6 principale è lunga 40 byte e ha il seguente formato (Figura 2.4).
Campo Classe di traffico equivalente nello scopo al campo Tipo di servizio, e il campo Limite di luppolo- campo Tempo di vivere Protocollo IPv4.
Campo Etichetta di flusso consente di isolare ed elaborare i singoli flussi di dati in modo speciale senza la necessità di analizzare il contenuto dei pacchetti. Questo è molto importante in termini di riduzione del carico sui router.
Campo Intestazione successivaè un analogo del campo Protocol (Protocol) IPv4 e determina il tipo di intestazione che segue quella principale. Ciascuna intestazione aggiuntiva successiva contiene anche un campo Intestazione successiva.
Protocollo di controllo Il Transmission Control Protocol (TCP) è stato sviluppato per supportare la comunicazione interattiva tra computer. Il protocollo TCP garantisce l'affidabilità e la validità dello scambio di dati tra processi su computer che fanno parte di una rete comune.
Sfortunatamente, il protocollo TCP non è adatto alla trasmissione di informazioni multimediali. Il motivo principale è la disponibilità del controllo della consegna. Il monitoraggio richiede troppo tempo per trasmettere informazioni più sensibili al ritardo. Inoltre, TCP fornisce meccanismi di controllo della velocità per evitare la congestione della rete. I dati audio e video richiedono, tuttavia, velocità in bit strettamente definite, che non possono essere modificate arbitrariamente.
Da un lato, il protocollo TCP interagisce con il protocollo applicativo dell'applicazione utente e, dall'altro, con il protocollo che fornisce le funzioni di "basso livello" di instradamento e indirizzamento dei pacchetti, che, di norma, vengono eseguite da IP.
La struttura logica del software di rete che implementa i protocolli della famiglia TCP/IP in ciascun nodo di Internet è mostrata in fig. 2.5.
I rettangoli rappresentano i moduli che elaborano i dati e le linee che collegano i rettangoli rappresentano i percorsi di trasferimento dei dati. Linea orizzontale nella parte inferiore della figura è indicata una rete Ethernet, utilizzata come esempio di supporto fisico.
Riso. 2.5.
Per stabilire una connessione tra due processi su computer diversi rete, è necessario conoscere non solo gli indirizzi Internet dei computer, ma anche i numeri di quelle porte TCP (socket) utilizzate dai processi su questi computer. Qualsiasi connessione TCP su Internet è identificata in modo univoco da due indirizzi IP e due numeri di porta TCP.
Il protocollo TCP può gestire pacchetti danneggiati, persi, duplicati o fuori ordine. Ciò si ottiene attraverso un meccanismo per assegnare un numero di sequenza a ciascun pacchetto trasmesso e un meccanismo per controllare la ricezione dei pacchetti.
Quando TCP trasmette un segmento di dati, una copia di quei dati viene inserita nella coda di ritrasmissione e viene avviato un timer di riconoscimento.
Il protocollo UDP (User Datagram Protocol) è destinato allo scambio di datagrammi tra processi di computer situati in un sistema integrato di reti di computer.
Il protocollo UDP si basa sul protocollo IP e fornisce ai processi applicativi servizi di trasporto leggermente diversi da quelli del protocollo IP. Il protocollo UDP prevede la consegna dei dati non garantita, ovvero non richiede la conferma della loro ricezione; inoltre, questo protocollo non richiede l'istituzione di una connessione tra la fonte e il destinatario delle informazioni, cioè tra i moduli UDP.
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 sequenza dei pacchetti, il timestamp e il 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 disporre 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 qualità del servizio, ma utilizza i 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.
Blocchi di dati di protocollo RTP/RTCP sono chiamati 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 ) e pacchetti generati secondo il protocollo RTCP e utilizzati per trasmettere informazioni di servizio necessarie per un funzionamento affidabile teleconferenze 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 informativi RTP) seguita da elementi strutturali di lunghezza variabile.
Affinché il protocollo RTP sia più flessibile e applicabile a varie applicazioni, alcuni dei suoi parametri sono volutamente indefiniti, ma include 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 estensioni dell'intestazione e le estensioni dell'intestazione, i tipi di pacchetto, i servizi e gli algoritmi di sicurezza della comunicazione, le specifiche dell'utilizzo del protocollo sottostante, ecc. Ogni applicazione di solito funziona con un solo profilo e l'impostazione del tipo di profilo viene effettuata selezionando l'applicazione appropriata. Non vi è alcuna indicazione esplicita del tipo di profilo tramite numero di porta, identificatore di protocollo, ecc.
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.
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 trasmesse ai potenziali membri teleconferenze. Se è richiesta la segretezza, le informazioni ei pacchetti di controllo possono essere crittografati, nel qual caso a chiave distribuita crittografia.
L'applicazione di audioconferenza utilizzata da ciascun partecipante a una 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.
Su Internet, come in altre reti di dati a commutazione di pacchetto, i pacchetti vengono talvolta persi e riordinati e ritardati per periodi di tempo variabili. 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 in teleconferenze. Il numero di sequenza può essere utilizzato anche dal ricevitore per stimare il numero di pacchetti persi.
Dato che i partecipanti teleconferenze può entrare e uscire durante esso, è utile sapere chi vi partecipa questo momento e quanto bene i partecipanti alla conferenza ricevono i dati audio. A tale scopo, ogni istanza dell'applicazione audio durante la conferenza emette 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 dentro teleconferenze vengono utilizzati entrambi i segnali audio e video, vengono trasmessi separatamente. Per la trasmissione di ogni tipo di traffico, indipendentemente dall'altro, la specifica del protocollo introduce il concetto di sessione di comunicazione 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). 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 affinché le sessioni possano essere associate.
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 codifica audio con una qualità ridotta, una struttura di comunicazione a livello RTP chiamata mixer può essere collocata in un'area 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. Essere in grado di fornire l'indicazione corretta agli endpoint riceventi fonte del messaggio, 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 collegamenti a banda larga, ma potrebbero non essere raggiungibili tramite una chiamata in 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.
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 contrassegnati come facoltativi hanno un valore pari a zero.
Protocollo di controllo RTCP (RTCP - Real-Time Control Protocol) si basa sulla trasmissione periodica di pacchetti gestione a tutti i partecipanti a una sessione di comunicazione utilizzando lo stesso meccanismo di distribuzione del protocollo RTP. Il protocollo sottostante deve fornire il multiplexing di informazioni e pacchetti di controllo, ad esempio utilizzando diversi numeri di porta UDP. Il protocollo RTCP svolge quattro funzioni principali.
Le funzioni da uno a tre sono obbligatorie quando RTP viene utilizzato in multicast IP e consigliate in tutti gli altri casi. Gli sviluppatori di applicazioni RTP sono incoraggiati a evitare meccanismi che sono solo bidirezionali e non scalabili per aumentare il numero di utenti.
Il protocollo RTP consente a un'applicazione di ridimensionare automaticamente la rappresentatività di una sessione di comunicazione da pochi partecipanti a diverse migliaia. Ad esempio, in un'audioconferenza, il traffico dati è essenzialmente autolimitante perché solo una o due persone possono parlare alla volta e, con la distribuzione multicast, la velocità dei dati su un dato collegamento rimane relativamente costante indipendentemente dal numero di partecipanti. Tuttavia, il traffico di controllo non è autolimitante. Se i rapporti di ricezione da ciascun partecipante vengono inviati a una velocità costante, il traffico di controllo aumenterà linearmente all'aumentare del numero di partecipanti. Pertanto, deve essere previsto un meccanismo speciale per ridurre la frequenza di trasmissione dei pacchetti di controllo.
Per ciascuna sessione, si presume che il traffico dati soddisfi un limite aggregato, denominato larghezza di banda della sessione, condiviso da tutti i partecipanti. Questa larghezza di banda può essere riservata e il suo limite è impostato dalla rete. La larghezza di banda della sessione è indipendente dal tipo di codifica multimediale, ma la scelta del tipo di codifica può essere limitata dalla larghezza di banda della sessione. L'impostazione della larghezza di banda della sessione dovrebbe essere fornita dall'applicazione di gestione della sessione quando richiama l'applicazione multimediale, ma le applicazioni multimediali possono anche impostare un valore predefinito basato sulla larghezza di banda dei dati del singolo mittente per il tipo di codifica selezionato per una determinata sessione.
I calcoli della larghezza di banda per il controllo e il traffico dati vengono eseguiti considerando i sottostanti protocolli di trasporto e livello di rete (ad esempio, UDP e IP). Le intestazioni del livello di collegamento dati (DLH) non vengono prese in considerazione nei calcoli perché un pacchetto può essere incapsulato con diverse intestazioni DLL durante la trasmissione.
Il traffico di controllo dovrebbe essere limitato a una porzione piccola e nota della larghezza di banda della sessione: abbastanza piccola da non influire sulla funzione principale del protocollo di trasporto, la trasmissione dei dati; noto in modo che il traffico di controllo possa essere incluso nella specifica della larghezza di banda data al protocollo prenotazione delle risorse, e in modo che ogni partecipante possa autonomamente calcolare la propria quota. Si presuppone che la parte della larghezza di banda della sessione assegnata a RTCP debba essere impostata al 5%. Tutti i partecipanti alla sessione devono utilizzare la stessa quantità di larghezza di banda RTCP, in modo che i valori dell'intervallo di trasmissione del pacchetto di controllo calcolato siano gli stessi. Pertanto, queste costanti devono essere impostate per ciascun profilo.
L'algoritmo di calcolo dell'intervallo tra gli invii di multipack RTCP per la condivisione tra i partecipanti della banda allocata per il traffico di controllo ha le seguenti principali caratteristiche:
Più pacchetti di protocollo RTP possono essere trasportati in un'unica unità di dati di protocollo sottostante, come un pacchetto UDP. Ciò riduce la ridondanza dell'intestazione e semplifica la sincronizzazione tra diversi flussi.
Se un giorno dovessi capire rapidamente cos'è il VoIP (voice over IP) e cosa significano tutte queste abbreviazioni selvagge, spero che questo manuale possa aiutarti. Noterò immediatamente che i problemi di configurazione di tipi aggiuntivi di servizi di telefonia (come il trasferimento di chiamata, segreteria telefonica, teleconferenze, ecc.) non sono qui considerati.
Quindi, di cosa ci occuperemo sotto il taglio:
In generale, lo schema per collegare un abbonato locale a un operatore telefonico tramite una normale linea telefonica è il seguente:
Sul lato del provider (PBX), è installato un modulo telefonico con una porta FXS (Foreign eXchange Subscriber). Un telefono o un fax con una porta FXO (Foreign eXchange Office) e un modulo dialer è installato a casa o in ufficio.
In apparenza, le porte FXS e FXO non differiscono in alcun modo, si tratta di normali connettori RJ11 a 6 pin. Ma con l'aiuto di un voltmetro, è molto facile distinguerli: ci sarà sempre una certa tensione sulla porta FXS: 48/60 V quando il ricevitore è agganciato o 6-15 V durante una chiamata. Sul FXO, se non è collegato alla linea, la tensione è sempre 0.
Per trasferire i dati su una linea telefonica, è necessaria una logica aggiuntiva da parte del provider, che può essere implementata sul modulo SLIC (subscriber line interface circuit) e da parte dell'abbonato, utilizzando il modulo DAA (Direct Access Arrangement).
I telefoni wireless DECT (Digital European Cordless Telecommunications) sono piuttosto popolari ora. Come dispositivo sono simili ai normali telefoni: hanno anche una porta FXO e un modulo combinatore, ma hanno anche un modulo comunicazone wireless stazioni e portatili a una frequenza di 1,9 GHz.
Gli abbonati si connettono alla rete PSTN (Public Switched Telephone Network) - rete telefonica uso generale, è PSTN, PSTN. La rete PSTN può essere organizzata utilizzando diverse tecnologie: ISDN, ottica, POTS, Ethernet. Un caso speciale di PSTN, quando viene utilizzata una normale linea analogica/in rame - POTS (Plain Old Telephone Service) - un semplice vecchio sistema telefonico.
Con lo sviluppo di Internet comunicazioni telefoniche passato a nuovo livello. I telefoni fissi vengono utilizzati sempre meno, principalmente per esigenze ufficiali. I telefoni DECT sono un po' più comodi, ma limitati al perimetro della casa. I telefoni GSM sono ancora più convenienti, ma sono limitati dai confini del paese (il roaming è costoso). Ma per i telefoni IP sono anche softphone (SoftPhone), non ci sono restrizioni, ad eccezione dell'accesso a Internet.
Skype è l'esempio più famoso di softphone. Può fare molte cose, ma ha due svantaggi importanti: un'architettura chiusa e le intercettazioni si conoscono da quali autorità. A causa del primo non è possibile creare una propria microrete telefonica. E a causa del secondo, non è molto piacevole essere spiati, specialmente nelle conversazioni personali e commerciali.
Fortunatamente, esistono protocolli aperti per creare le proprie reti di comunicazione con chicche: SIP e H.323. Ci sono alcuni softphone in più sul protocollo SIP che su H.323, il che può essere spiegato dalla sua relativa semplicità e flessibilità. Ma a volte questa flessibilità può mettere un grosso bastone nella ruota. Entrambi i protocolli SIP e H.323 utilizzano il protocollo RTP per trasferire i dati multimediali.
Considera i principi di base del protocollo SIP per capire come si connettono due abbonati.
SIP (Session Initiation Protocol) - un protocollo per stabilire una sessione (non solo telefonica) è un protocollo di testo su UDP. È anche possibile utilizzare SIP su TCP, ma si tratta di casi rari.
SDP (Session Description Protocol) è un protocollo per la negoziazione del tipo di dati trasmessi (per audio e video si tratta di codec e relativi formati, per fax - velocità di trasmissione e correzione degli errori) e dei loro indirizzi di destinazione (IP e porta). È anche un protocollo di testo. I parametri SDP vengono inviati nel corpo dei pacchetti SIP.
RTP (Real-time Transport Protocol) è un protocollo di trasferimento dati audio/video. È un protocollo binario su UDP.
Struttura generale dei pacchetti SIP:
Ecco un esempio di due pacchetti SIP per una comune procedura di configurazione delle chiamate:
A sinistra c'è il contenuto del pacchetto SIP INVITE, a destra c'è la risposta ad esso - SIP 200 OK.
I campi principali sono incorniciati:
Un messaggio SDP è costituito da righe contenenti coppie FIELD=VALUE. I campi principali includono:
I pacchetti RTP contengono dati audio/video codificati in un formato specifico. Questo formato specificato nel campo PT (tipo di payload). Tabella di ricerca dei valori dato campo Vedere il profilo audio video https://wikipedia org wiki RTP per il formato specifico.
I pacchetti RTP contengono anche un identificatore SSRC univoco (determina l'origine del flusso RTP) e un timestamp (timestamp, utilizzato per riprodurre audio o video in modo uniforme).
Un esempio di interazione tra due abbonati SIP tramite un server SIP (asterisco):
Non appena un telefono SIP viene avviato, la prima cosa che fa è registrarsi su un server remoto (SIP Registar), inviargli un messaggio SIP REGISTER.
Quando si chiama un utente viene inviato un messaggio SIP INVITE il cui corpo contiene un messaggio SDP contenente i parametri di trasmissione audio/video (quali codec sono supportati, a quale IP e porta inviare l'audio, ecc.).
Quando l'utente remoto solleva il telefono, riceviamo un messaggio SIP 200 OK anche con parametri SDP, solo l'utente remoto. Utilizzando i parametri SDP inviati e ricevuti, è possibile impostare una sessione audio/video RTP o una sessione fax T.38.
Se i parametri SDP ricevuti non sono adatti a noi o il server SIP intermedio ha deciso di non far passare il traffico RTP attraverso se stesso, viene eseguita la procedura di rinegoziazione SDP, il cosiddetto REINVITE. A proposito, è proprio a causa di questa procedura che i server proxy SIP gratuiti hanno uno svantaggio: se entrambi gli abbonati si trovano sulla stessa rete locale e il server proxy è dietro NAT, dopo che il traffico RTP è stato reindirizzato, nessuno degli abbonati sentirà l'altro.
Dopo la fine della conversazione, l'abbonato che ha riattaccato invia un messaggio SIP BYE.
A volte, dopo che la sessione è stata stabilita, durante una chiamata, è richiesto l'accesso a servizi aggiuntivi (VAS): chiamata in attesa, trasferimento, segreteria telefonica, ecc. - che reagiscono a determinate combinazioni di pulsanti premuti.
Quindi, in una normale linea telefonica, ci sono due modi per comporre un numero:
Durante una conversazione, il metodo a impulsi è scomodo per trasmettere il pulsante premuto. Quindi, ci vuole circa 1 secondo per trasmettere "0" (10 impulsi di 100 ms ciascuno: 60 ms - interruzione di riga, 40 ms - chiusura di riga) più 200 ms per una pausa tra le cifre. Inoltre, durante la composizione a impulsi si sentiranno spesso clic caratteristici. Pertanto, nella telefonia convenzionale, viene utilizzata solo la modalità a toni di accesso a VAS.
Nella telefonia VoIP, le informazioni sui pulsanti premuti possono essere trasmesse in tre modi:
La trasmissione di DTMF all'interno di dati audio (Inband) presenta diversi svantaggi: si tratta di risorse di sovraccarico durante la generazione / incorporamento di toni e durante il rilevamento, limitazioni di alcuni codec che possono distorcere i codici DTMF e scarsa affidabilità di trasmissione (se alcuni dei pacchetti vengono persi, è possibile che venga rilevata la doppia pressione dello stesso tasto).
La differenza principale tra DTMF RFC2833 e SIP INFO: se la possibilità di trasferire RTP direttamente tra abbonati bypassando il server stesso è abilitata sul server proxy SIP (ad esempio, canreinvite=yes in asterisco), il server non noterà i pacchetti RFC2833, a seguito dei quali i servizi VAS non saranno più disponibili. I pacchetti SIP vengono sempre trasmessi tramite server proxy SIP, quindi VAS funzionerà sempre.
Come già accennato, il protocollo RTP viene utilizzato per trasferire i dati multimediali. I pacchetti RTP specificano sempre il formato dei dati trasmessi (codec).
Esistono molti codec diversi per la trasmissione vocale, con diversi rapporti di bitrate / qualità / complessità, ce ne sono di aperti e chiusi. Qualsiasi softphone deve avere il supporto per i codec G.711 alaw/ulaw, la loro implementazione è molto semplice, la qualità del suono non è male, ma richiedono una larghezza di banda di 64 kbps. Ad esempio, il codec G.729 richiede solo 8 kbps, ma consuma molto CPU e non è gratuito.
Per la trasmissione di fax, di solito viene utilizzato il codec G.711 o il protocollo T.38. L'invio di fax utilizzando il codec G.711 corrisponde all'invio di un fax utilizzando il protocollo T.30, come se il fax fosse inviato su una normale linea telefonica, ma allo stesso tempo segnale analogico dalla linea è digitalizzato secondo la legge alaw/ulaw. Questo è anche chiamato fax Inband T.30.
I fax che utilizzano il protocollo T.30 negoziano i propri parametri: velocità di trasmissione, dimensione del datagramma, tipo di correzione degli errori. Il protocollo T.38 è basato sul protocollo T.30, ma a differenza della trasmissione Inband, vengono analizzati i comandi T.30 generati e ricevuti. Pertanto, non vengono trasmessi dati grezzi, ma comandi di controllo fax riconosciuti.
Il comando T.38 viene trasmesso utilizzando il protocollo UDPTL, che è un protocollo basato su UDP e viene utilizzato solo per T.38. Anche i protocolli TCP e RTP possono essere utilizzati per trasmettere i comandi T.38, ma vengono utilizzati molto meno frequentemente.
I principali vantaggi di T.38 sono il carico di rete ridotto e una maggiore affidabilità rispetto alla trasmissione fax in banda.
La procedura per l'invio di un fax in modalità T.38 è la seguente:
Invio di fax via Internet preferibilmente in T.38. Se il fax deve essere trasmesso all'interno dell'ufficio o tra oggetti che dispongono di una connessione stabile, è possibile utilizzare la trasmissione fax Inband T.30. In questo caso, prima di inviare un fax, la procedura di cancellazione dell'eco deve essere disattivata per non introdurre ulteriori distorsioni.
Informazioni molto dettagliate sull'invio di fax sono contenute nel libro "Fax, Modem, and Text for IP Telephony" di David Hanes e Gonzalo Salgueiro.
Ci siamo occupati dei protocolli per stabilire una sessione di conversazione (SIP/SDP) e del metodo di trasmissione dell'audio su un canale RTP. C'era una domanda importante: la qualità del suono. Da un lato, la qualità del suono è determinata dal codec selezionato. Ma d'altra parte, sono ancora necessarie procedure DSP aggiuntive (DSP - elaborazione del segnale digitale). Queste procedure tengono conto delle peculiarità della telefonia VoIP: non sempre vengono utilizzate cuffie di alta qualità, ci sono cadute di pacchetti su Internet, a volte i pacchetti arrivano in modo non uniforme e anche la larghezza di banda della rete non è gommata.
Procedure di base che migliorano la qualità del suono:
VAD(Rilevatore di attività vocale) - una procedura per determinare i frame che contengono voce (frame vocale attivo) o silenzio (frame vocale inattivo). Questa separazione può ridurre notevolmente il carico di rete, poiché la trasmissione di informazioni sul silenzio richiede molti meno dati (è sufficiente trasmettere il livello di rumore o niente).
Alcuni codec contengono già procedure VAD (GSM, G.729), mentre altri (G.711, G.722, G.726) devono implementarle.
Se il VAD è configurato per trasmettere informazioni sul livello di rumore, vengono trasmessi speciali pacchetti SID (Silence Insertion Descriptor) nel formato 13th CN (Comfort Noise) RTP.
Vale la pena notare che i pacchetti SID possono essere eliminati dai server proxy SIP, quindi per la verifica è consigliabile configurare la trasmissione del traffico RTP oltre i server SIP.
Metano(generazione del rumore di comfort) - una procedura per generare rumore di comfort sulla base delle informazioni dai pacchetti SID. Pertanto, VAD e CNG lavorano insieme, ma la procedura CNG è molto meno richiesta, poiché non è sempre possibile notare il lavoro del CNG, soprattutto a basso volume.
PLC(packet loss concealment) - la procedura per ripristinare il flusso audio in caso di perdita di pacchetti. Anche con una perdita di pacchetti del 50%, un buon algoritmo PLC può ottenere una qualità vocale accettabile. Le distorsioni, ovviamente, saranno, ma puoi distinguere le parole.
Il modo più semplice per emulare la perdita di pacchetti (su Linux) è utilizzare l'utilità tc dal pacchetto iproute con il modulo netem. Esegue solo la modellazione del traffico in uscita.
Un esempio di esecuzione dell'emulazione di rete con una perdita di pacchetti del 50%:
Tc qdisc cambia dev eth1 radice netem perdita 50%
Disabilita l'emulazione:
Tc qdisc del dev eth1 root
buffer di jitter- una procedura per eliminare l'effetto jitter, quando l'intervallo tra i pacchetti ricevuti cambia molto e che, nel peggiore dei casi, porta a un ordine errato dei pacchetti ricevuti. Inoltre, questo effetto porta a interruzioni del discorso. Per eliminare l'effetto jitter, è necessario implementare un buffer di pacchetti sul lato ricevente con una dimensione sufficiente a ripristinare l'ordine originale di invio dei pacchetti a un dato intervallo.
Puoi anche emulare l'effetto jitter usando l'utilità tc (l'intervallo tra il momento previsto dell'arrivo del pacchetto e il momento effettivo può essere fino a 500 ms):
LEC(Line Echo Canceller) - una procedura per eliminare l'eco locale quando l'abbonato remoto inizia a sentire la propria voce. La sua essenza è sottrarre il segnale ricevuto dal segnale trasmesso con un certo coefficiente.
Gli echi possono verificarsi per diversi motivi:
Scoprire il motivo (eco acustico o elettrico) non è difficile: l'abbonato dal cui lato si crea l'eco deve spegnere il microfono. Se l'eco si verifica ancora, allora è elettrico.
Per ulteriori informazioni sulle procedure VoIP e DSP, vedere Elaborazione del segnale vocale e fax VoIP. Un'anteprima è disponibile su Google Libri.
Questo completa una panoramica teorica superficiale del VoIP. Se sei interessato, nel prossimo articolo puoi considerare un esempio dell'implementazione pratica di un mini-PBX su una piattaforma hardware reale.
[!?] Domande e commenti sono ben accetti. A loro risponderà l'autore dell'articolo Dmitry Valento, un ingegnere del software presso il centro di progettazione elettronica Promwad.
Tag:
Le applicazioni moderne non possono tollerare che i loro pacchetti arrivino in ritardo. Due protocolli (RTP e PSVP) garantiscono consegne puntuali con qualità del servizio.
La continua crescita di Internet e delle reti private pone nuove esigenze in termini di larghezza di banda. Le applicazioni client-server sono di gran lunga superiori a Telnet in termini di quantità di dati trasferiti. Mondo ampia rete ha portato a un gigantesco aumento del grafico informazioni grafiche. Oggi, inoltre, le applicazioni voce e video avanzano i propri requisiti specifici per reti già sovraccariche.
Per soddisfare tutte queste esigenze, un aumento della capacità della rete non è sufficiente. Ciò di cui c'è veramente bisogno sono metodi intelligenti ed efficienti di gestione della pianificazione e controllo del carico di lavoro.
Storicamente, le reti basate su IP hanno fornito a tutte le applicazioni solo il servizio di consegna dei dati più semplice possibile. Tuttavia, le esigenze sono cambiate nel tempo. Organizzazioni che hanno speso milioni di dollari per installare una rete basata su IP per il trasferimento dei dati reti locali, si trovano ora di fronte al fatto che tali configurazioni non sono in grado di supportare in modo efficiente nuove applicazioni multimediali multicast in tempo reale.
Il bancomat è l'unico tecnologia di rete, originariamente progettato per supportare il normale traffico TCP e UDP insieme al traffico in tempo reale. Tuttavia, passare ad ATM significa creare una nuova infrastruttura di rete per il traffico in tempo reale o sostituire una configurazione basata su IP esistente, entrambe operazioni molto costose.
Pertanto, la necessità di supportare più tipi di traffico con diversi requisiti di qualità del servizio all'interno dell'architettura TCP/IP è molto urgente. Due strumenti chiave sono progettati per risolvere questo problema: il Real-Time Transport Protocol (RTP) e il Resource Reservation Protocol (RSVP).
RTP garantisce la consegna dei dati a una o più destinazioni con un ritardo entro limiti specificati. Ciò significa che i dati possono essere riprodotti in tempo reale. RSVP consente ai sistemi finali di essere ridondanti risorse di rete per ottenere la qualità del servizio richiesta, in particolare le risorse per il traffico in tempo reale sul protocollo RTP.
Il protocollo del livello di trasporto più utilizzato è il TCP. Sebbene TCP possa supportare un'ampia varietà di applicazioni distribuite, non è adatto per applicazioni in tempo reale.
Nelle applicazioni in tempo reale, il mittente genera un flusso di dati a una velocità costante ei destinatari devono fornire tali dati all'applicazione alla stessa velocità. Tali applicazioni includono conferenze audio e video, distribuzione di video in diretta (per la riproduzione immediata), spazi di lavoro condivisi, diagnostica medica remota, telefonia al computer, simulazione interattiva distribuita, giochi e monitoraggio in tempo reale.
L'utilizzo di TCP come protocollo di trasporto per queste applicazioni non è possibile per diversi motivi. Innanzitutto, questo protocollo consente solo la connessione tra due endpoint e quindi non è adatto per il multicast. Prevede la ritrasmissione dei segmenti persi che arrivano in un momento in cui l'applicazione in tempo reale non li attende più. Inoltre, TCP non dispone di un comodo meccanismo per associare le informazioni di temporizzazione ai segmenti, che è anche un requisito per le applicazioni in tempo reale.
Un altro protocollo di livello di trasporto ampiamente utilizzato, UDP non ha i primi due
restrizioni (connessione point-to-point e trasmissione di segmenti persi), ma non fornisce informazioni critiche sulla sincronizzazione. Quindi UDP stesso non ha strumenti scopo generale per applicazioni in tempo reale.
Sebbene ogni applicazione in tempo reale possa avere i propri meccanismi per supportare la trasmissione in tempo reale, condividono molte caratteristiche comuni che rendono altamente auspicabile la definizione di un singolo protocollo. Il protocollo standard di questo tipo è RTP, definito in RFC 1889.
In un tipico ambiente in tempo reale, il mittente genera pacchetti a una velocità costante. Vengono loro inviati a intervalli regolari, viaggiano attraverso la rete e vengono ricevuti dal ricevitore, che riproduce i dati in tempo reale man mano che vengono ricevuti.
Tuttavia, a causa della variazione della latenza man mano che i pacchetti viaggiano attraverso la rete, arrivano a intervalli irregolari. Per compensare questo effetto, i pacchetti in arrivo vengono memorizzati nel buffer, trattenuti per un po' e quindi forniti a una velocità costante. Software Il che genera l'output. Per far funzionare questo schema, ogni pacchetto ha un timestamp in modo che il destinatario possa riprodurre i dati in arrivo alla stessa velocità del mittente.
RTP supporta il trasferimento di dati in tempo reale tra più partecipanti in una sessione. (Una sessione è una relazione logica tra due o più utenti RTP che viene mantenuta per tutta la durata del trasferimento dei dati. Il processo di apertura di una sessione non rientra nell'ambito di RTP.)
Sebbene RTP possa essere utilizzato anche per l'unicast in tempo reale, la sua forza risiede nel supporto multicast. Per fare ciò, ogni blocco di dati RTP contiene un identificatore del mittente che indica quale partecipante sta generando i dati. I blocchi di dati RTP contengono anche un timestamp in modo che i dati possano essere riprodotti agli intervalli corretti dall'estremità ricevente.
Inoltre, RTP definisce il formato del payload dei dati trasmessi. Direttamente correlato a questo è il concetto di sincronizzazione, che è in parte responsabilità del mixer, il meccanismo di traduzione RTP. Dopo aver ricevuto flussi di pacchetti RTP da una o più fonti, li combina e invia un nuovo flusso di pacchetti RTP a uno o più destinatari. Il mixer può semplicemente combinare i dati e anche cambiarne il formato.
Esempio di applicazione mixer: combinazione di più sorgenti audio. Ad esempio, supponiamo che alcuni dei sistemi in una determinata sessione audio generino ciascuno il proprio flusso RTP. Il più delle volte è attiva solo una fonte, anche se a volte più fonti "parlano" contemporaneamente.
Se nuovo sistema vuole partecipare a una sessione, ma il suo collegamento alla rete non ha una capacità sufficientemente precisa per supportare tutti i flussi RTP, quindi il mixer riceve tutti questi flussi, li unisce in uno solo e passa l'ultimo al nuovo membro della sessione. Quando vengono ricevuti più flussi, il mixer aggiunge i valori PCM. L'intestazione RTP generata dal mixer include l'identificatore(i) del(i) mittente(i) i cui dati sono presenti nel pacchetto.
Un dispositivo più semplice crea un pacchetto RTP in uscita per ogni pacchetto RTP in entrata. Questo meccanismo, chiamato traduttore, può modificare il formato dei dati nel pacchetto o utilizzare un insieme diverso di protocolli di basso livello per trasferire i dati da un dominio all'altro. Ad esempio, un potenziale destinatario potrebbe non essere in grado di elaborare il segnale video ad alta velocità utilizzato da altri partecipanti alla sessione. Il traduttore quindi converte il video in un formato di qualità inferiore che richiede un bit rate inferiore.
Ogni pacchetto RTP ha un'intestazione di base e possibilmente campi aggiuntivi specifici dell'applicazione. Riso. 4 illustra la struttura dell'intestazione principale. I primi 12 ottetti sono costituiti dai seguenti campi:
L'intestazione principale può essere seguita da uno o più campi identificativi del mittente i cui dati sono presenti nel payload. Questi identificatori vengono inseriti dal mixer.
Il protocollo RTP viene utilizzato solo per trasferire i dati dell'utente, solitamente multicast, a tutti i partecipanti alla sessione. Un protocollo RTCP (Real-Time Transport Control Protocol) separato funziona con più destinazioni per fornire feedback ai mittenti di dati RTP e ad altri partecipanti alla sessione.
RTCP utilizza lo stesso protocollo di trasporto di base di RTP (solitamente UDP), ma un numero di porta diverso. Ogni partecipante alla sessione invia periodicamente un pacchetto RTCP a tutti gli altri partecipanti alla sessione. RFC 1889 descrive tre funzioni svolte da RTCP.
La prima funzione è fornire qualità del servizio e feedback in caso di congestione. Poiché i pacchetti RTCP sono multicast, tutti i partecipanti alla sessione possono valutare quanto bene lavorano e ricevono gli altri partecipanti. I messaggi del mittente consentono ai destinatari di valutare la velocità dei dati e la qualità della trasmissione. I messaggi dei destinatari contengono informazioni sui problemi che stanno riscontrando, inclusa la perdita di pacchetti e l'eccessivo ripple. Ad esempio, il bit rate per un'applicazione audio/video può essere ridotto se il collegamento non fornisce la qualità di servizio desiderata a un dato bit rate.
Il feedback del destinatario è importante anche per la diagnosi degli errori di propagazione.
Analizzando i messaggi di tutti i partecipanti a una sessione, un amministratore di rete può determinare se un determinato problema riguarda un partecipante o è di natura generale.
La seconda funzione principale di RTCP è l'identificazione del mittente. I pacchetti RTCP contengono una descrizione testuale standard del mittente. Forniscono più informazioni sul mittente dei pacchetti di dati rispetto a un ID sorgente di sincronizzazione selezionato in modo casuale. Inoltre, aiutano l'utente a identificare i thread relativi a diverse sessioni. Ad esempio, consentono all'utente di determinare se sessioni audio e video separate sono aperte contemporaneamente.
La terza funzione è il dimensionamento e il ridimensionamento della sessione. Per garantire la qualità del servizio e il feedback per controllare la congestione, nonché per identificare il mittente, tutti i partecipanti inviano periodicamente pacchetti RTCP. La frequenza di trasmissione di questi pacchetti diminuisce all'aumentare del numero di partecipanti.
Con un numero ridotto di partecipanti, viene inviato al massimo un pacchetto RTCP ogni cinque secondi. RFC 1889 descrive un algoritmo in cui i partecipanti limitano la velocità dei pacchetti RTCP in base al numero totale di partecipanti. L'obiettivo è mantenere il traffico RTCP al di sotto del 5% del traffico totale della sessione.
Lo scopo di qualsiasi rete è fornire dati al destinatario con una qualità del servizio garantita, incluso portata, ritardo e il limite di variazione del ritardo consentito. Con l'aumentare del numero di utenti e applicazioni, diventa sempre più difficile garantire la qualità dei servizi.
La semplice risposta al sovraccarico non è più sufficiente. È necessario uno strumento per evitare del tutto la congestione, ovvero per consentire alle applicazioni di riservare risorse di rete in conformità con la qualità del servizio richiesta.
Le misure preventive sono utili sia per unicast che per multicast. In unicast, due applicazioni concordano su uno specifico livello di qualità del servizio per una data sessione. Se la rete è molto carica, potrebbe non essere in grado di fornire la qualità del servizio richiesta. In questa situazione, le applicazioni dovranno posticipare la sessione fino a tempi migliori o cercare di ridurre i requisiti di qualità del servizio, se possibile.
La soluzione in questo caso è che le applicazioni unicast riservino le risorse per fornire il livello di servizio richiesto. Quindi i router sul percorso previsto allocano le risorse (ad esempio, un posto in coda e parte della capacità della linea in uscita). Se il router non è in grado di allocare risorse a causa di impegni precedenti, ne informa l'applicazione. In questo caso, l'applicazione potrebbe tentare di avviare un'altra sessione con requisiti di qualità del servizio inferiori o riprogrammarla a una data successiva.
Il multicasting pone problemi di prenotazione delle risorse molto più complessi. Porta alla generazione di enormi quantità di traffico di rete, ad esempio nel caso di applicazioni come video o quando è presente un gruppo ampio e disperso di destinatari. Tuttavia, il traffico proveniente da una sorgente multicast può in linea di principio essere notevolmente ridotto.
Ci sono due ragioni per questo. In primo luogo, alcuni membri di un gruppo potrebbero non aver bisogno di fornire dati da una particolare fonte in un determinato periodo di tempo. Pertanto, i membri di un gruppo possono ricevere informazioni simultaneamente tramite due canali (da due fonti), ma il destinatario potrebbe essere interessato a ricevere solo un canale.
In secondo luogo, che alcuni membri del gruppo sono in grado di elaborare solo una parte delle informazioni trasmesse dal mittente. Ad esempio, un flusso video può essere costituito da due componenti: uno con bassa qualità dell'immagine e l'altro con alta qualità dell'immagine. Questo formato ha una serie di algoritmi di compressione video: generano un componente base con un'immagine di bassa qualità e un componente aggiuntivo con una risoluzione maggiore.
Alcuni destinatari potrebbero non disporre di una potenza di elaborazione sufficiente per elaborare i componenti alta risoluzione oppure essere connesso alla rete tramite una sottorete o un collegamento che non ha una capacità sufficiente per trasportare l'intero segnale.
La prenotazione delle risorse consente ai router di determinare in anticipo se possono fornire traffico multicast a tutti i destinatari.
Nei precedenti tentativi di implementare le prenotazioni di risorse e negli approcci adottati in frame relay e ATM, le risorse necessarie sono richieste dalla sorgente del flusso di dati. Questo metodo è sufficiente nel caso di trasmissione unicast, perché l'applicazione trasmittente trasmette i dati a una certa velocità e il livello richiesto di qualità del servizio è insito nello schema di trasmissione.
Tuttavia, questo approccio non può essere utilizzato per il multicasting. Diversi membri del gruppo possono avere diversi requisiti di risorse. Se il flusso originale può essere suddiviso in flussi secondari, allora alcuni membri del gruppo potrebbero volerne ricevere solo uno. In particolare, alcuni ricevitori saranno in grado di elaborare solo la componente video a bassa risoluzione. Oppure, se più mittenti trasmettono allo stesso gruppo, il destinatario può scegliere solo un mittente o un sottoinsieme di essi. Infine, i requisiti di qualità del servizio dei diversi destinatari possono variare a seconda dell'apparecchiatura di output, della potenza del processore e della velocità del canale.
Per questo motivo, le prenotazioni delle risorse da parte del destinatario sono considerate preferibili. I mittenti possono fornire ai router Caratteristiche generali traffico (ad es. velocità e variabilità dei dati), ma spetta ai destinatari determinare il livello di qualità del servizio richiesto. I router quindi aggregano le richieste di allocazione delle risorse nelle parti comuni dell'albero di distribuzione.
RSVP si basa su tre concetti relativi ai flussi di dati: sessione, specifica del flusso e specifica del filtro. Sessioneè un flusso di dati identificato dalla sua destinazione. Si noti che questo concetto è diverso da quello di una sessione RTP, sebbene le sessioni RSVP e RTP possano avere una corrispondenza uno a uno. Dopo che un router ha riservato le risorse per una particolare destinazione, lo tratta come l'inizio di una sessione e alloca le risorse per la durata di tale sessione.
Una richiesta di prenotazione dal sistema finale di destinazione, chiamata descrittore di flusso, è costituita da una specifica di flusso e da un filtro. Specifica del flusso definisce la qualità del servizio richiesta e viene utilizzato dal nodo per impostare i parametri dello scheduler dei pacchetti. Il router trasmette i pacchetti con un determinato set di preferenze in base alla specifica del flusso corrente.
Specifica del filtro definisce un insieme di pacchetti in cui sono richieste le risorse. Insieme alla sessione, definisce un insieme di pacchetti (o flusso) per i quali deve essere fornita la qualità di servizio richiesta. Tutti gli altri pacchetti destinati a quella destinazione vengono elaborati nella misura in cui la rete è in grado di farlo.
RSVP non definisce il contenuto della specifica del flusso, passa semplicemente la richiesta. Una specifica di flusso include in genere una classe di servizio, Rspec (R sta per riserva) e Tspec (T sta per traffico). Gli altri due parametri sono un insieme di numeri. Il parametro Rspec definisce la qualità del servizio richiesta e il parametro Tspec descrive il flusso di dati. I contenuti di Rspec e Tspec sono trasparenti a RSVP.
In linea di principio, una specifica di filtro descrive un sottoinsieme arbitrario di pacchetti da una singola sessione (ovvero quei pacchetti la cui destinazione è determinata da quella sessione). Ad esempio, una specifica di filtro potrebbe definire solo mittenti specifici o definire protocolli o pacchetti i cui campi di intestazione del protocollo corrispondono a quelli specificati.
Riso. 3 illustra la relazione tra sessione, specifica del flusso e specifica del filtro. Ogni pacchetto in arrivo appartiene ad almeno una sessione ed è considerato secondo il flusso logico per quella sessione. Se il pacchetto non appartiene a nessuna sessione, viene consegnato nella misura in cui vi sono risorse libere.
La principale difficoltà con RSVP è legata al multicasting. Un esempio di configurazione multicast è mostrato in fig. 6. Questa configurazione è composta da quattro router. Il collegamento tra due router qualsiasi, rappresentato da una linea, può essere un collegamento diretto o una sottorete. Tre host - Gl, G2 e G3 - sono nello stesso gruppo e ricevono datagrammi con il corrispondente indirizzo multicast. I dati a questo indirizzo vengono trasmessi da due host: S1 e S2. La linea rossa corrisponde all'albero di instradamento per S1 e questo gruppo, e la linea blu per S2 e questo gruppo. Le linee freccia indicano la direzione dei pacchetti da S1 (rosso) e da S2 (blu).
La figura mostra che tutti e quattro i router devono essere a conoscenza della prenotazione delle risorse di ciascun destinatario. Pertanto, le richieste di allocazione delle risorse si propagano all'indietro attraverso l'albero di instradamento.
RSVP utilizza due tipi di messaggio principali: Resv e Path. I messaggi Resv vengono generati dai destinatari e si propagano lungo l'albero, con ogni nodo lungo il percorso che concatena e riassembla i pacchetti da diversi destinatari quando possibile. Questi messaggi fanno sì che il router entri in uno stato di prenotazione delle risorse per quella sessione (indirizzo multicast). Alla fine tutti i messaggi Resv combinati raggiungono gli host di invio. Sulla base delle informazioni ricevute, impostano i parametri di controllo della pianificazione appropriati per il primo salto.
Riso. 7 mostra il flusso di messaggi Resv. Nota bene: i messaggi sono concatenati; pertanto, viene inviato un solo messaggio su qualsiasi ramo dell'albero di recapito combinato. Tuttavia, questi messaggi devono essere inviati di nuovo periodicamente per estendere il periodo di prenotazione delle risorse.
Il messaggio Path viene utilizzato per propagare informazioni sul percorso inverso. Tutti i moderni protocolli di routing multicast supportano solo il percorso diretto sotto forma di un albero di propagazione (a partire dal mittente). Ma i messaggi Resv devono essere rispediti attraverso tutti i router intermedi a tutti gli host di invio.
Poiché il protocollo di instradamento non fornisce informazioni sul percorso inverso, viene trasportato da RSVP nei messaggi Path. Qualsiasi host che vuole essere il mittente invia un messaggio Path a tutti i membri del gruppo. Lungo il percorso, ciascun router e ciascun host di destinazione entra nello stato del percorso, indicando che i pacchetti per questo mittente devono essere inoltrati all'hop da cui è stato ricevuto il pacchetto. Riso. 5 mostra che i pacchetti Path vengono inviati sugli stessi percorsi dei pacchetti di dati.
Considera il funzionamento del protocollo RSVP. Dal punto di vista dell'host, il funzionamento del protocollo consiste nei seguenti passaggi (i primi due passaggi di questa sequenza sono talvolta invertiti).
I metodi di lavoro di ieri con grandi volumi di grafica sono del tutto inadatti ai sistemi moderni. Senza nuovi strumenti, è impossibile soddisfare le crescenti esigenze di trasmissione dei dati a causa della crescita del loro volume, della diffusione delle applicazioni in tempo reale e della distribuzione multicast. RTP e RSVP forniscono una solida base per le LAN di nuova generazione.
Un esempio della reale applicazione di questi protocolli è il modello VoIP (Voice over IP) - trasmissione della voce su reti IP, che è descritto nello standard H.232 e prevede la trasmissione di informazioni audio, video e dati su una rete IP. In questo caso, il protocollo in tempo reale RTP viene utilizzato per stabilire una connessione e il protocollo RSVP viene utilizzato per riservare le risorse di rete.
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. I pacchetti RTP vengono trasmessi Protocollo UDP, lavorando, a sua volta, su 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: un 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 richiede l'uso di blocchi di dimensioni fisse) e un 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 ai mittenti e ai ricevitori di streaming 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.
