W tej sekcji omówiono niektóre aspekty transportu pakietów RTP przez sieć i protokoły transportowe. O ile nie określono inaczej w specyfikacjach innych protokołów, podczas przesyłania pakietów obowiązują następujące zasady ogólne.
Protokół RTP opiera się na podstawowych protokołach, aby zapewnić separację między strumieniami danych RTP i informacjami sterującymi RTCP. W przypadku protokołów UDP i podobnych RTP używa parzystego numeru portu, a odpowiedni strumień RTCP używa portu o jeden wyższy.
Pakiety informacyjne RTP nie zawierają żadnego pola długości, dlatego RTP opiera się na protokole bazowym, aby zapewnić wskazanie długości. Maksymalna długość pakietów RTP jest ograniczona tylko przez podstawowe protokoły.
Wiele pakietów RTP może być przenoszonych w pojedynczej jednostce danych protokołu niższej warstwy, takiej jak pakiet UDP. Zmniejsza to nadmiarowość nagłówków i może uprościć synchronizację między różnymi strumieniami.
9. Lista stałych protokołu
Ta sekcja zawiera listę stałych zdefiniowanych w specyfikacji protokołu RTP.
Stałe typu ruchu RTP (PT - payload type) są zdefiniowane w profilach. Jednak oktet nagłówka RTP, który zawiera bit(y) znacznika i pole typu ruchu, NIE MOŻE zawierać zarezerwowanych wartości 200 i 201 (dziesiętnie), aby odróżnić pakiety RTP od pakietów RTCP SR i RR. Dla standardowego formatu z jednym bitem tokena i siedmiobitowym polem typu ruchu, to ograniczenie oznacza, że typy ruchu 72 i 73 nie powinny być używane.
Wartości dla typów pakietów RTCP (patrz Tabela 1) są wybierane w zakresie od 200 do 204, aby lepiej kontrolować poprawność nagłówka pakietu RTCP w porównaniu z pakietami RTP. Gdy pole typu pakietu RTCP jest porównywane z odpowiednim oktetem nagłówka RTP, zakres ten odpowiada bitowi znacznika równemu jeden (co zwykle nie ma miejsca w pakietach danych) i najbardziej znaczącemu bitowi pola standardowego typu ruchu równemu jeden (podczas gdy statycznie określone typy ruchu zwykle mają wartości PT z zerem w najbardziej znaczącej cyfrze). Ten zakres został również wybrany jako bardziej odległy od wartości 0 i 255, ponieważ pola składające się wyłącznie z zer lub jedynek są w większości specyficzne dla danych.
Inne typy pakietów RTCP są definiowane przez społeczność IANA. Deweloperzy mają możliwość zarejestrowania wartości, których potrzebują do prowadzenia badań eksperymentalnych, a następnie anulowania rejestracji, gdy zapotrzebowanie na te wartości zniknie.
Dozwolone rodzaje pozycji w pakiecie SDES przedstawiono w tabeli. 2. Inne rodzaje klauzul SDES są wyznaczane przez społeczność IANA. Deweloperzy mają możliwość zarejestrowania wartości, których potrzebują podczas przeprowadzania badań eksperymentalnych, a następnie wyrejestrowania się, gdy te wartości nie są już potrzebne.
10. Opis profilu i formatu ruchu
Jak wspomniano powyżej (patrz sekcja 2), aby uzyskać pełny opis RTP dla konkretnej aplikacji, wymagane są dodatkowe dokumenty dwojakiego rodzaju: opis profilu i format ruchu.
RTP może być używany w wielu klasach aplikacji o bardzo różnych wymaganiach. Elastyczność w dostosowywaniu się do tych wymagań zapewnia zastosowanie różnych profili (patrz). Zazwyczaj aplikacja używa tylko jednego profilu i nie ma wyraźnego wskazania, który profil jest aktualnie używany.
Dodatkowy dokument drugiego typu, specyfikacja formatu ruchu, określa, w jaki sposób określony rodzaj ruchu (na przykład sygnał wideo zakodowany zgodnie z H.261) powinien być transmitowany zgodnie z RTP. Ten sam format ruchu może być używany dla wielu profili i dlatego można go zdefiniować niezależnie od profilu. Dokumenty profilu są odpowiedzialne tylko za zgodność z tym formatem i wartością PT .
W opisie profilu można zdefiniować następujące pozycje, ale ta lista nie jest wyczerpująca.
Nagłówek pakietu danych RTP. Oktet w nagłówku pakietu danych RTP, który zawiera bit tokena i pole typu ruchu, może być przedefiniowany zgodnie z profilem, aby spełnić różne wymagania, na przykład, aby zapewnić więcej lub mniej bitów tokenu (sekcja 3.3).
Rodzaje ruchu. Profil zazwyczaj definiuje różne formaty ruchu (np. algorytmy kodowania mediów) oraz domyślne mapowanie statyczne tych formatów i wartości PT. Niektóre formaty ruchu można zdefiniować, odnosząc się do poszczególnych opisów formatu ruchu. Dla każdego konkretnego typu ruchu profil musi określać wymaganą częstotliwość zegara znacznika czasu RTP, która ma być używana (sekcja 3.1).
Dodatki nagłówka pakietu danych RTP. Dodatkowe pola można dołączyć do stałego nagłówka pakietu danych RTP, jeśli wymagana jest jakaś dodatkowa funkcjonalność w klasie aplikacji profilu, niezależnie od rodzaju ruchu. .
Rozszerzenia nagłówka pakietów danych RTP. Zawartość pierwszych 16 bitów struktury rozszerzenia nagłówka pakietu danych RTP powinna być określona, jeśli profil zezwala na użycie tego mechanizmu. .
Typy pakietów RTCP. Można zdefiniować (i zarejestrować przez IANA) nowe typy pakietów RTCP specyficzne dla klasy aplikacji.
Interwał raportowania RTCP. Profil powinien określać wartości do wykorzystania przy obliczaniu interwału raportowania RTCP: ułamek przepustowości sesji RTCP, minimalny interwał raportowania oraz podział przepustowości między nadawców i odbiorców.
Rozszerzenie pakietu SR/RR. Jeśli istnieją dodatkowe informacje o źródle lub miejscu docelowym, które muszą być regularnie przesyłane, wówczas można określić sekcję rozszerzenia dla pakietów RTCP SR i RR.
Korzystanie z SDES. Profil może definiować względne priorytety dla elementów RTCP SDES, które mają być przekazywane lub usuwane (patrz sekcja 4.2.2); alternatywna składnia lub semantyka klauzuli CNAME (sekcja 4.4.1); Format pozycji LOC (rozdział 4.4.5); semantyka i użycie klauzuli NOTE (sekcja 4.4.7) oraz nowe klauzule SDES do zarejestrowania w IANA.
Bezpieczeństwo. Profil może określać, których usług bezpieczeństwa i algorytmów mają używać aplikacje, oraz może kontrolować ich użycie (punkt 7).
Dopasowywanie hasła do klucza. Profil może określić, w jaki sposób hasło wprowadzone przez użytkownika jest konwertowane na klucz szyfrowania.
Protokół niższej warstwy. Pakiety RTP mogą wymagać użycia określonej podstawowej sieci lub protokołu warstwy transportowej.
Zgodność transportowa. MOGĄ być zdefiniowane inne niż standardowe powiązania RTP i RTCP określone w klauzuli 8 do adresów warstwy transportowej, takich jak porty UDP.
Kapsułkowanie. Kształtowanie pakietów RTP można zdefiniować, aby umożliwić przesyłanie wielu pakietów danych RTP w pojedynczej jednostce danych protokołu niższej warstwy (klauzula 8).
Każda aplikacja, którą tworzysz, nie powinna wymagać nowego profilu. Bardziej celowe jest rozszerzenie istniejącego profilu w ramach jednej klasy aplikacji niż tworzenie nowego. Ułatwi to interakcję aplikacji, ponieważ każdy z nich zwykle działa tylko w jednym profilu. Proste rozszerzenia, takie jak definiowanie dodatkowych wartości PT lub typów pakietów RTCP, można zrealizować rejestrując je w IANA i publikując ich opisy w specyfikacji profilu lub specyfikacji formatu ruchu.
11. Profil RTP do konferencji audio i wideo przy minimalnej kontroli
RFC 1890 opisuje profil do używania protokołu transportu w czasie rzeczywistym RTP w wersji 2 i skojarzonego z nim protokołu sterowania RTCP w grupowej konferencji audio lub wideo, tak zwany profil RTP dla konferencji audio i wideo z minimalną kontrolą (profil RTP dla audio i wideo). Konferencje wideo z minimalną kontrolą). Ten profil definiuje aspekty protokołu RTP, które nie zostały określone w specyfikacji protokołu RTP w wersji 2 (RFC 1889). Minimalna kontrola oznacza, że nie jest wymagana obsługa negocjacji parametrów lub kontroli własności (na przykład podczas korzystania z mapowań statycznych typów ruchu i wskazań własności dostarczanych przez RTCP). Rozważmy główne postanowienia tego profilu.
11.1. Formaty pakietów RTP i RTCP oraz parametry protokołów
Ta sekcja zawiera opis wielu elementów, które można zdefiniować lub zmienić w profilu.
Nagłówek pakietu informacyjnego RTP. Używany jest standardowy format stałego nagłówka pakietu informacyjnego RTP (jeden bit tokena).
Rodzaje ruchu. Statyczne wartości rodzajów ruchu są określone w punktach 11.3 i 11.4.
Dodatki nagłówka pakietu informacyjnego RTP. Do nagłówków pakietów informacyjnych RTP nie są dołączane żadne dodatkowe stałe pola.
Rozszerzenia nagłówka pakietu informacji RTP. Nie są zdefiniowane żadne rozszerzenia nagłówka pakietu informacji RTP, ale aplikacje korzystające z tego profilu MOGĄ używać takich rozszerzeń. Oznacza to, że w aplikacjach nie należy zakładać, że bit X nagłówka RTP jest zawsze równy zero. Aplikacje powinny być przygotowane do ignorowania rozszerzenia nagłówka. Jeśli w przyszłości zostanie określone rozszerzenie nagłówka, należy określić zawartość pierwszych 16 bitów, aby można było zidentyfikować wiele różnych rozszerzeń.
Typy pakietów RTCP. W tej specyfikacji profilu nie zdefiniowano żadnych dodatkowych typów pakietów RTCP.
Interwał raportowania RTCP. Przy obliczaniu interwału raportowania RTCP należy używać stałych proponowanych w RFC 1889.
Rozszerzenia pakietów SR / RR. Nie ma rozszerzeń dla pakietów RTCP SR i RR.
Korzystanie z SDES. Aplikacje mogą używać dowolnej z opisanych klauzul SDES. Podczas gdy informacje o nazwie kanonicznej (CNAME) są wysyłane w każdym interwale raportowania, inne elementy powinny być wysyłane tylko co piąty interwał raportowania.
Bezpieczeństwo. Domyślne usługi bezpieczeństwa RTP są również domyślnie definiowane przez ten profil.
Dopasowywanie hasła do klucza. Hasło wprowadzone przez użytkownika jest konwertowane za pomocą algorytmu MD5 na 16-oktetowy skrót. N-bitowy klucz jest uzyskiwany ze skrótu przy użyciu jego pierwszych N bitów. Zakłada się, że hasło może zawierać tylko litery ASCII, cyfry, łączniki i spacje, aby zmniejszyć prawdopodobieństwo zniekształcenia podczas przesyłania hasła przez telefon, faks, teleks lub e-mail. Hasło może być poprzedzone określeniem algorytmu szyfrowania. Wszelkie znaki do pierwszego ukośnika (kod ASCII 0x2f) są interpretowane jako nazwa algorytmu szyfrowania. Jeśli nie ma ukośnika, wartością domyślną jest szyfrowanie DES-CBC.
Przed zastosowaniem algorytmu zamykającego hasło wprowadzone przez użytkownika jest konwertowane do postaci kanonicznej. W tym celu hasło jest konwertowane na zestaw znaków ISO 10646 przy użyciu kodowania UTF-8, zgodnie z definicją w Załączniku P do ISO / IEC 10646-1: 1993 (znaki ASCII nie wymagają żadnej konwersji); spacje na początku i na końcu hasła są usuwane; co najmniej dwie spacje są zastępowane jedną spacją (ASCII lub UTF-8 0x20); wszystkie litery są konwertowane na małe litery
Podstawowy protokół. Profil definiuje użycie RTP przez UDP w trybie dwukierunkowym i multiemisji.
Zgodność transportowa. Używana jest standardowa korespondencja między adresami warstwy transportowej RTP i RTCP.
Kapsułkowanie. Enkapsulacja pakietów RTP jest niezdefiniowana.
11.2. Rejestracja rodzajów ruchu
Ten profil definiuje standardowe typy kodowania używane z RTP. Inne rodzaje kodowania muszą być zarejestrowane w IANA przed użyciem. Rejestrując nowy typ kodowania, należy podać następujące informacje:
- nazwa kodowa typu kodowania i częstotliwość zegara znacznika czasu RTP (nazwa kodowa powinna mieć długość trzech lub czterech znaków, aby zapewnić zwartą reprezentację, jeśli to konieczne);
- wskazanie, kto ma prawo zmienić rodzaj kodowania (np. ISO, CCITT/ITU, inne międzynarodowe organy normalizacyjne, konsorcjum, konkretna firma lub grupa firm);
- wszelkie parametry operacyjne;
- linki do dostępnych opisów algorytmu kodowania, takich jak (w kolejności preferencji) RFC, opublikowany artykuł, zgłoszenie patentowe, raport techniczny, źródło kodeka lub odniesienie;
- w przypadku prywatnych typów kodowania, dane kontaktowe (adres pocztowy i adres e-mail);
- wartość, aby w razie potrzeby wskazać rodzaj ruchu tego profilu (patrz poniżej).
- Zauważ, że nie wszystkie typy kodowania używane z RTP muszą być przypisane statycznie. Środki inne niż RTP, które nie zostały omówione w tym artykule, mogą służyć do dynamicznego dopasowywania wartości typu ruchu (PT) z zakresu od 96 do 127 i typu kodowania.
- Dostępna przestrzeń wartości dla typów ruchu jest dość mała. Nowe typy ruchu są przypisywane statycznie (na stałe) tylko wtedy, gdy spełnione są następujące warunki:
- kodowanie jest bardzo interesujące dla społeczności internetowej;
- oferuje korzyści porównywalne z istniejącymi kodowaniami i/lub jest wymagana do współdziałania z istniejącymi, szeroko stosowanymi systemami konferencyjnymi lub multimedialnymi;
- opis wystarczy do stworzenia dekodera.
11.3. Kodowanie dźwięku
W przypadku aplikacji, które nie wysyłają pakietów podczas przerw, pierwszy pakiet aktywnej mowy (pierwszy pakiet po przerwie) jest rozróżniany przez bit tokena ustawiony na jeden w nagłówku pakietu danych RTP. Aplikacje bez tłumienia ciszy ustawiają ten bit na zero.
Zegar RTP używany do generowania znacznika czasu RTP jest niezależny od liczby kanałów i rodzaju kodowania; jest równa liczbie okresów próbkowania na sekundę. W przypadku kodowania N-kanałowego (stereo, quad, itp.) każdy okres próbkowania (powiedzmy 1/8000 sekundy) generuje N próbek. Całkowita liczba próbek generowanych na sekundę jest równa częstotliwości próbkowania pomnożonej przez liczbę kanałów.
W przypadku korzystania z wielu kanałów audio są one numerowane od lewej do prawej, zaczynając od pierwszego. W pakietach audio RTP dane z kanałów o niższych numerach poprzedzają dane z kanałów o wyższych numerach. Dla więcej niż dwóch kanałów stosuje się następującą notację:
- l - lewy;
- r - prawy;
- c - centralny;
- S - peryferyjny;
- F - czołowy;
- R - tył.
| Liczba kanałów | Nazwa systemu | Numery kanałów | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 2 | stereofoniczny | ja | r | ||||
| 3 | ja | r | C | ||||
| 4 | kwadrat | Fl | Fr | Rl | Rr | ||
| 4 | ja | C | r | S | |||
| 5 | Fl | Fr | Fc | Sl | Sr | ||
| 6 | ja | lc | C | r | rc | S | |
Próbki wszystkich kanałów należących do tego samego czasu próbkowania muszą znajdować się w tym samym pakiecie. Przeplatanie próbek z różnych kanałów zależy od rodzaju kodowania.
Częstotliwość próbkowania musi być wybrana z zakresu: 8000, 11025, 16000, 22050, 24000, 32000, 44100 i 48000 Hz (komputery Apple Macintosh mają własne częstotliwości próbkowania 22254,54 i 11127,27, które można przekonwertować na 22050 i 11025 s akceptowalna jakość poprzez pominięcie czterech lub dwóch próbek w ramce 20 ms). Jednak większość algorytmów kodowania audio jest zdefiniowana dla bardziej ograniczonego zestawu częstotliwości próbkowania. Odbiorcy muszą być przygotowani na odbiór dźwięku wielokanałowego, ale mogą również wybrać mono.
W przypadku pakietowania dźwięku domyślny interwał pakietowania powinien wynosić 20 ms, o ile nie określono inaczej w opisie kodowania. Interwał pakietyzacji określa minimalne opóźnienie między końcami. Dłuższe pakiety mają stosunkowo mniej bajtów na nagłówek, ale powodują większe opóźnienia i sprawiają, że utrata pakietów jest bardziej znacząca. W przypadku aplikacji nieinteraktywnych, takich jak wykłady lub kanały ze znacznymi ograniczeniami przepustowości, dopuszczalne może być większe opóźnienie pakietowania. Odbiornik powinien odbierać pakiety z sygnałem audio z opóźnieniem od 0 do 200 ms. To ograniczenie zapewnia akceptowalny rozmiar bufora dla odbiornika.
W kodowaniu opartym na próbce każda próbka sygnału jest reprezentowana przez stałą liczbę bitów. W skompresowanych danych audio poszczególne kody próbek mogą przekraczać granice oktetów. Czas trwania sygnału transmitowanego w pakiecie audio jest określony przez liczbę próbek w pakiecie.
W przypadku typów kodowania opartego na próbce, które wytwarzają jeden lub więcej oktetów dla każdej próbki, próbki z różnych kanałów próbkowanych jednocześnie są pakowane w sąsiednie oktety. Na przykład, aby zakodować dźwięk stereo, sekwencja oktetów to: lewy kanał, pierwsza próbka; prawy kanał, pierwsze liczenie; lewy kanał, drugi licznik; prawy kanał, drugi licznik itp. W kodowaniu wielooktetowym najważniejszy oktet jest przesyłany jako pierwszy. Pakowanie kodowań opartych na próbkach, które dają mniej niż jeden oktet dla każdej próbki, jest określane przez algorytm kodowania.
Algorytm kodowania oparty na ramkach przekształca blok audio o stałej długości w inny skompresowany blok danych, zwykle również o stałej długości. W przypadku kodowania opartego na ramkach nadawca może połączyć wiele takich ramek w jedną wiadomość.
W przypadku kodeków opartych na ramkach kolejność kanałów jest specyficzna dla całego bloku. Oznacza to, że w przypadku dźwięku stereo próbki dla lewego i prawego kanału są kodowane niezależnie; przy czym ramka kodowania dla lewego kanału poprzedza ramkę dla prawego kanału.
Wszystkie kodeki audio zorientowane na ramki muszą być zdolne do kodowania i dekodowania wielu kolejnych ramek przesyłanych w ramach jednego pakietu. Ponieważ rozmiar ramki dla kodeków zorientowanych ramkowo jest określony, nie ma potrzeby używania oddzielnej notacji dla tego samego kodowania, ale z różną liczbą ramek w pakiecie.
Tabela 3 przedstawia wartości typów ruchu (PT) zdefiniowane przez ten profil dla sygnałów audio, ich symboli oraz główne parametry techniczne algorytmów kodowania.
11.4. Kodowanie wideo
Tabela 4 przedstawia wartości typów kodowania (PT), symbole algorytmów kodowania i charakterystyki techniczne algorytmów kodowania wideo zdefiniowane przez ten profil, a także nieprzypisane, zarezerwowane i dynamicznie ustawiane wartości PT.
Wartości typu ruchu w zakresie od 96 do 127 mogą być dynamicznie określane za pomocą protokołu sterowania konferencją, czego nie omówiono w tym artykule. Na przykład katalog sesji może określać, że dla danej sesji typ ruchu 96 oznacza dwukanałowe kodowanie PCMU z częstotliwością próbkowania 8000 Hz. Zakres wartości typu ruchu oznaczony jako „zarezerwowany” nie jest używany, aby można było niezawodnie rozróżnić pakiety RTCP i RTP .
Źródło RTP w dowolnym momencie generuje tylko jeden rodzaj ruchu; przeplatanie ruchu różnych typów w tej samej sesji RTP jest niedozwolone. Kilka sesji RTP może być używanych równolegle do przenoszenia różnych typów ruchu. Typy ruchu zdefiniowane w tym profilu odnoszą się do audio lub wideo, ale nie do obu. Dozwolone jest jednak zdefiniowanie typów ruchu kombinowanego, które łączą np. audio i wideo, z odpowiednią separacją w formacie ruchu.
Aplikacje audio korzystające z tego profilu muszą przynajmniej mieć możliwość wysyłania i odbierania ruchu typu 0 (PCMU) i 5 (DVI4). Umożliwia to współdziałanie bez negocjacji formatu.
11.5. Przypisanie portu
Zgodnie z definicją w opisie protokołu RTP, dane RTP muszą być wysyłane przez port UDP o numerze parzystym, a odpowiednie pakiety RTCP muszą być wysyłane przez port o numerze nieparzystym.
Aplikacje korzystające z tego profilu mogą używać dowolnej takiej pary portów UDP. Na przykład, program do zarządzania sesją może losowo przypisać parę portów. Nie można określić pojedynczej pary numerów portów, ponieważ w niektórych przypadkach kilka aplikacji korzystających z tego profilu musi działać poprawnie na tym samym hoście, a niektóre systemy operacyjne nie pozwalają wielu procesom na używanie tego samego portu UDP z różnymi adresami multiemisji.
Jednak domyślnymi numerami portów mogą być 5004 i 5005. Aplikacje korzystające z wielu profili mogą wybrać tę parę portów jako wskaźnik tego profilu. Ale aplikacje mogą również wymagać jawnego określenia pary portów.
12. Wykaz użytych terminów i skrótów
- ASCII (American Standard Code for Information Interchange) to amerykański standardowy kod wymiany informacji. Siedmiobitowy kod do reprezentacji informacji tekstowych, używany z pewnymi modyfikacjami w większości systemów obliczeniowych
- CBC (cipher block chaining) - szyfrowany łańcuch bloków, standardowy tryb szyfrowania danych DES
- CELP (code-excited linear prediction) - rodzaj kodowania audio wykorzystujący predykcję liniową wzbudzoną kodem
- CNAME (nazwa kanoniczna) - nazwa kanoniczna
- CSRC (źródło wspierające) - włączone źródło. Źródło strumienia pakietów RTP, które przyczyniło się do połączonego strumienia wytwarzanego przez mikser RTP. Mikser wstawia do nagłówka pakietu RTP listę identyfikatorów SSRC tych źródeł, które brały udział w tworzeniu tego pakietu. Lista ta nazywana jest listą CSRC. Przykład: Mikser przesyła identyfikatory aktualnie przemawiających uczestników telekonferencji, których głosy zostały zmiksowane i użyte do utworzenia pakietu wychodzącego, wskazując odbiorcę na bieżące źródło wiadomości, nawet jeśli wszystkie pakiety audio zawierają ten sam identyfikator SSRC (jak mikser)
- DES (Data Encryption Standard) - standard szyfrowania danych
- IANA (Internet Assigned Numbers Authority) - społeczność internetowa ds. numerów przydzielonych
- IMA (Interaktywne Stowarzyszenie Multimedialne) – Stowarzyszenie Interaktywnych Multimedialnych
- IP (Internet Protocol) - protokół internetowy, protokół warstwy sieciowej, protokół datagramowy. Umożliwia pakietom przechodzenie przez wiele sieci w drodze do miejsca przeznaczenia
- IPM (IP Multicast) - multiemisja przy użyciu protokołu IP
- LD-CELP (ang. low-delay code extracted linear prediction) – algorytm kodowania mowy wykorzystujący predykcję liniową wzbudzaną kodem z małym opóźnieniem
- LPC (liniowe kodowanie predykcyjne) - liniowe kodowanie predykcyjne
- NTP (Network Time Protocol) to odliczanie czasu w sekundach w stosunku do zerowej godziny 1 stycznia 1900 roku. Pełny format znacznika czasu NTP to 64-bitowa liczba stałoprzecinkowa bez znaku z częścią całkowitą w pierwszych 32 bitach i częścią ułamkową w ostatnich 32 bitach. W niektórych przypadkach używana jest bardziej zwarta reprezentacja, w której tylko środkowe 32 bity są pobierane z pełnego formatu: dolne 16 bitów części całkowitej i górne 16 bitów części ułamkowej.
- RPE/LTP (wzbudzenie impulsu szczątkowego / przewidywanie długoterminowe) - algorytm kodowania mowy z różnicowym wzbudzeniem impulsowym i przewidywaniem długoterminowym
- RTCP (Real-Time Control Protocol) - protokół kontroli transmisji danych w czasie rzeczywistym
- RTP (Real-Time Transport Protocol) - protokół transportu w czasie rzeczywistym
- SSRC (źródło synchronizacji) - źródło synchronizacji. Źródło strumienia pakietów RTP, identyfikowane przez 32-bitowy numeryczny identyfikator SSRC, który jest przenoszony w nagłówku RTP, niezależnie od adresu sieciowego. Wszystkie pakiety z tym samym źródłem synchronizacji używają tego samego czasu i przestrzeni numerów sekwencyjnych, więc odbiornik grupuje pakiety do odtwarzania ze źródłem synchronizacji. Przykład źródła synchronizacji: nadawca strumienia pakietów odebranego ze źródła sygnału, takiego jak mikrofon, kamera wideo lub mikser RTP. Źródło synchronizacji może z czasem zmieniać format danych, na przykład kodowanie audio. Identyfikator SSRC to losowo wybrana wartość, która jest uważana za globalnie unikalną w ramach określonej sesji RTP. Uczestnik telekonferencji nie musi używać tego samego SSRC dla wszystkich sesji RTP w sesji komunikacji multimedialnej; Agregacja tożsamości SSRC jest zapewniana za pośrednictwem protokołu RTCP. Jeśli uczestnik generuje wiele strumieni w jednej sesji RTP, na przykład z wielu kamer wideo, każdy strumień musi być identyfikowany przez oddzielny SSRC
- TCP (Transmission Control Protocol) to protokół warstwy transportowej używany w połączeniu z IP
- UDP (User Datagram Protocol) to bezpołączeniowy protokół warstwy transportowej. UDP pozwala tylko na wysłanie pakietu do jednej lub więcej stacji w sieci. Walidacja i zapewnienie integralności (gwarantowane dostarczenie) transmisji danych odbywa się na wyższym poziomie
- ADPCM – adaptacyjna modulacja różnicowego kodu impulsowego
- jitter - jitter, odchylenia fazy lub częstotliwości sygnału; w odniesieniu do telefonii IP - nieprawidłowości w opóźnieniu datagramów w sieci
- ZPD - łącze transmisji danych (drugi poziom Modelu Referencyjnego Interakcji Systemów Otwartych)
- IVS - sieci informacyjne i komputerowe
- mixer - system pośredni, który odbiera pakiety RTP z jednego lub więcej źródeł, ewentualnie zmienia format danych, łączy pakiety w nowy pakiet RTP, a następnie przesyła go. Ponieważ wiele źródeł sygnału na ogół nie jest zsynchronizowanych, mikser dostosowuje taktowanie strumieni składowych i generuje własne taktowanie dla połączonego strumienia. W ten sposób wszystkie pakiety informacji generowane przez mikser są identyfikowane jako mające mikser jako źródło synchronizacji.
- monitor (monitor) – aplikacja, która odbiera pakiety RTCP wysyłane przez uczestników sesji RTP, w szczególności raporty z odbioru, oraz ocenia bieżącą jakość usługi w celu monitorowania dystrybucji, wykrywania błędów i długoterminowych statystyk. Zwykle funkcje monitora leżą w aplikacjach używanych w sesji, ale monitor może być również oddzielną aplikacją, która nie jest używana w inny sposób, nie wysyła ani nie odbiera pakietów danych RTP. Takie aplikacje nazywane są monitorami innych firm.
- ITU-T - Sektor Normalizacji Telekomunikacji Międzynarodowego Związku Telekomunikacyjnego
- system końcowy - aplikacja generująca treści przesyłane w pakietach RTP i/lub zużywająca zawartość odebranych pakietów RTP. System końcowy może działać jako jedno lub więcej (ale zwykle tylko jedno) źródło zegara w każdej sesji RTP
- Pakiet RTCP — pakiet kontrolny składający się ze stałej części nagłówka, podobnego do pakietów informacyjnych RTP, po którym następują elementy strukturalne, które różnią się w zależności od typu pakietu RTCP. Zazwyczaj wiele pakietów RTCP jest wysyłanych razem jako złożony pakiet RTCP w pojedynczym podstawowym pakiecie protokołu; zapewnia to pole długości w stałym nagłówku każdego pakietu RTCP
- Pakiet RTP to jednostka danych protokołu składająca się ze stałego nagłówka RTP, ewentualnie pustej listy dołączonych źródeł, rozszerzeń i ruchu. Zwykle jeden pakiet protokołu niższej warstwy zawiera jeden pakiet RTP, ale może być ich kilka
- port to abstrakcja używana przez protokoły warstwy transportowej do rozróżniania wielu miejsc docelowych w ramach jednego komputera hosta. Port jest identyfikowany przez swój numer. W związku z tym numer portu jest numerem, który identyfikuje konkretną aplikację, dla której przeznaczone są wysyłane dane. Liczba ta, wraz z informacją o tym, który protokół (np. TCP lub UDP) jest używany w wyższej warstwie, jest zawarta między innymi informacjami o usługach w datagramach przesyłanych przez Internet. Selektory transportu (TSEL) używane przez warstwę transportową OSI są równoważne portom
- profil (profil) - zestaw parametrów dla protokołów RTP i RTCP dla klasy aplikacji, który określa cechy ich funkcjonowania. Profil definiuje użycie pól bitu tokena i typu ruchu w nagłówku pakietu danych RTP, typy ruchu, dodawanie nagłówka pakietu danych RTP, pierwsze 16 bitów rozszerzenia nagłówka pakietu danych RTP, typy pakietów RTCP, interwał raportowania RTCP, pakiet SR / RR rozszerzenie, wykorzystanie pakietów SDES, usług i algorytmów zapewniających bezpieczeństwo komunikacji oraz funkcje korzystania z protokołu niższej warstwy
- Sesja RTP (sesja RTP) - komunikacja wielu uczestników wchodzących w interakcję za pośrednictwem protokołu RTP. Dla każdego uczestnika sesja jest określana przez określoną parę docelowych adresów transportowych (jeden adres sieciowy plus para portów dla RTP i RTCP). Para adresów docelowych transportu może być wspólna dla wszystkich uczestników (jak w przypadku IPM) lub może być różna dla każdego (indywidualny adres sieciowy i wspólna para portów, jak w komunikacji dwukierunkowej). W sesji multimedialnej każdy rodzaj ruchu jest wysyłany w oddzielnej sesji RTP z własnymi pakietami RTCP. Sesje Multicast RTP są rozróżniane przez różne numery par portów i/lub różne adresy multicast
- Non-RTP oznacza — Protokoły i mechanizmy, które mogą być potrzebne jako dodatek do RTP, aby zapewnić akceptowalną usługę. Szczególnie w przypadku konferencji multimedialnych aplikacja do zarządzania konferencjami może przydzielać adresy multiemisji i klucze szyfrowania, negocjować stosowany algorytm szyfrowania oraz określać dynamiczne mapowania między wartościami typu ruchu RTP a reprezentowanymi przez nie formatami ruchu (formaty, które nie mają predefiniowana wartość, rodzaj ruchu). W przypadku prostych aplikacji można również wykorzystać bazy danych e-mail lub konferencji
- translator - system pośredni, który przekazuje pakiety RTP bez zmiany identyfikatora źródła synchronizacji. Przykłady translatorów: urządzenia wykonujące transkodowanie bez mieszania, replikatory wielokierunkowe lub dwukierunkowe, aplikacje warstwy aplikacji w zaporach sieciowych
- adres transportowy — kombinacja adresu sieciowego i numeru portu, która identyfikuje punkt końcowy warstwy transportowej, na przykład adres IP i numer portu UDP. Pakiety są przekazywane ze źródłowego adresu transportowego do docelowego adresu transportowego
- Ruch RTP - dane multimedialne przesyłane w pakiecie RTP, na przykład próbki audio lub skompresowane dane wideo
- PSTN - publiczne komutowane sieci telefoniczne
Dobry dzień!
Razem: system monitoringu to kompleks, który jest podłączony w trybie nieinwazyjnym do n-tej liczby 10-gigabitowych łączy Ethernet, które w sposób ciągły „monitoruje” transmisję wszystkich strumieni wideo RTP obecnych w ruchu i dokonuje pomiarów co określony przedział czasowy w celu późniejszego zapisania ich w bazie. Zgodnie z danymi z bazy regularnie generowane są raporty dla wszystkich kamer.
A co jest w tym tak trudnego?
W trakcie poszukiwania rozwiązania natychmiast naprawiono kilka problemów:
- Nieinwazyjne połączenie. System monitoringu łączy się z już działającymi kanałami, w których większość połączeń (przez RTSP) została już nawiązana, serwer i klient już wiedzą, które porty są wymieniane, ale nie wiemy tego z góry. Dobrze znany port jest tylko dla RTSP, ale strumienie UDP mogą przechodzić na dowolne porty (poza tym okazało się, że często naruszają wymóg portów parzystych / nieparzystych, patrz rfc3550). Jak ustalić, że określony pakiet z określonego adresu IP należy do strumienia wideo? Przykładowo protokół BitTorrent zachowuje się w podobny sposób – na etapie nawiązywania połączenia klient i serwer uzgadniają porty, a wtedy cały ruch UDP wygląda jak „tylko strumień bitów”.
- Połączone linki mogą zawierać więcej niż strumienie wideo. Mogą istnieć protokoły HTTP, BitTorrent, SSH i dowolne inne, których używamy dzisiaj. Dlatego system musi poprawnie identyfikować strumienie wideo, aby oddzielić je od reszty ruchu. Jak to zrobić w czasie rzeczywistym za pomocą 8 łączy 10Gb? Oczywiście zwykle nie są one w 100% zapełnione, więc łączny ruch nie będzie wynosił 80 gigabitów/s, ale około 50-60, ale to nie tak mało.
- Skalowalność. Tam, gdzie jest już wiele strumieni wideo, może być ich jeszcze więcej, ponieważ nadzór wideo od dawna sprawdza się jako skuteczne narzędzie. Sugeruje to, że powinien istnieć margines wydajności i margines łącza.
Szukamy odpowiedniego rozwiązania...
Naturalnie staraliśmy się jak najlepiej wykorzystać nasze własne doświadczenie. Zanim zapadła decyzja, mieliśmy już implementację przetwarzania pakietów ethernetowych na urządzeniu Bercut-MX z układem FPGA (łatwiejszym - MX). Z pomocą Bercut-MX udało nam się uzyskać niezbędne pola do analizy z nagłówków pakietów Ethernet. Niestety nie mieliśmy doświadczenia w przetwarzaniu takiego wolumenu ruchu za pomocą „zwykłych” serwerów, więc z pewną ostrożnością przyjrzeliśmy się takiemu rozwiązaniu…
Wydawałoby się, że pozostało tylko zastosować metodę do pakietów RTP i złoty klucz byłby w naszej kieszeni, ale MX może tylko przetwarzać ruch, nie obejmuje możliwości rejestrowania i przechowywania statystyk. W FPGA nie ma wystarczającej ilości pamięci do przechowywania znalezionych połączeń (kombinacje IP-IP-port-port), ponieważ łącze 2x10-Gigabit wchodzące na wejście może zawierać około 15 tysięcy strumieni wideo, a dla każdego z nich trzeba „pamiętać ” liczba pakietów odebranych, liczba pakietów utraconych itd. Co więcej, wyszukiwanie z taką szybkością iz taką ilością danych, podlegających bezstratnemu przetwarzaniu, staje się zadaniem nietrywialnym.
Aby znaleźć rozwiązanie, musieliśmy „sięgnąć głębiej” i dowiedzieć się, jakich algorytmów użyjemy do pomiaru jakości i identyfikacji strumieni wideo.
Co można zmierzyć za pomocą pól pakietu RTP?
Z opisu widać, że z punktu widzenia pomiarów jakości w pakiecie RTP interesują nas następujące pola:
- numer sekwencyjny - 16-bitowy licznik, który zwiększa się z każdym wysłanym pakietem;
- timestamp - znacznik czasu, dla h.264 wielkość próbki to 1/90000 s (czyli odpowiada częstotliwości 90 KHz);
- Bit znacznika. W rfc3550 ogólnie opisano, że ten bit jest przeznaczony do oznaczania „istotnych” zdarzeń i w rzeczywistości ten bit jest najczęściej używany przez kamery do oznaczania początku klatki wideo i wyspecjalizowanych pakietów z informacjami SPS/PPS.
Jest oczywiste, że numer sekwencyjny pozwala zdefiniować następujące parametry przepływu:
- utrata pakietów (utrata ramek);
- wielokrotne wysyłanie pakietu (duplikat);
- zmiana kolejności;
- zrestartuj kamerę, jeśli wystąpi duża przerwa w sekwencji.
Miary sygnatury czasowej:
- zmienność opóźnienia (zwana także jitterem). Jednocześnie po stronie odbiorczej powinien działać licznik 90 KHz;
- w zasadzie opóźnienie w przejściu pakietu. Ale w tym celu musisz zsynchronizować czas kamery ze znacznikiem czasu, a jest to możliwe, jeśli kamera przesyła raporty nadawcy (RTCP SR), co jest ogólnie niepoprawne, ponieważ w rzeczywistości wiele kamer ignoruje wysyłanie RTCP SR (około połowa kamer, z którymi pracowaliśmy).
Cóż, M-bit pozwala mierzyć liczbę klatek na sekundę. Jednak ramki SPS/PPS protokołu h.264 wprowadzają błąd, ponieważ ramki wideo nie są. Można go jednak wyrównać, używając informacji z nagłówka jednostki NAL, który zawsze następuje po nagłówku RTP.
Szczegółowe algorytmy pomiaru parametrów wykraczają poza zakres artykułu, nie będę się zagłębiał. Jeśli jesteś zainteresowany, rfc3550 zawiera przykładowy kod obliczania strat i wzór na obliczanie jittera. Główny wniosek jest taki, że tylko kilka pól z pakietów RTP i jednostek NAL wystarczy do zmierzenia podstawowych charakterystyk strumienia transportowego. A reszta informacji nie bierze udziału w pomiarach i może i powinna zostać odrzucona!
Jak zidentyfikować strumienie RTP?
Aby utrzymać statystyki, informacje otrzymane z nagłówka RTP muszą być „powiązane” z jakimś identyfikatorem kamery (strumienia wideo). Kamerę można jednoznacznie zidentyfikować za pomocą następujących parametrów:
- Źródłowe i docelowe adresy IP
- Porty źródłowe i docelowe
- SSRC. Ma to szczególne znaczenie, gdy z jednego IP nadawanych jest kilka strumieni, tj. w przypadku enkodera wieloportowego.
Co ciekawe, początkowo identyfikowaliśmy kamery tylko według źródła IP i SSRC, opierając się na tym, że SSRC powinno być losowe, ale w praktyce okazało się, że wiele kamer ustawia SSRC na stałą wartość (powiedzmy 256). Najwyraźniej wynika to z oszczędności zasobów. W rezultacie musieliśmy dodać porty do identyfikatora kamery. To całkowicie rozwiązało problem wyjątkowości.
Jak oddzielić pakiety RTP od reszty ruchu?
Pozostaje pytanie: w jaki sposób Berkut-MX po przyjęciu pakietu zrozumie, że jest to RTP? Nagłówek RTP nie posiada tak wyraźnej identyfikacji jak IP, nie posiada sumy kontrolnej, może być transmitowany przez UDP z numerami portów wybieranymi dynamicznie podczas nawiązywania połączenia. A w naszym przypadku większość połączeń jest już nawiązanych od dłuższego czasu i na ponowną instalację można czekać bardzo długo.
Aby rozwiązać ten problem, rfc3550 (Załącznik A.1) zaleca sprawdzenie bitów wersji RTP – są to dwa bity, oraz pole Payload Type (PT) – siedem bitów, co w przypadku typu dynamicznego zajmuje niewielki zakres. W praktyce dowiedzieliśmy się, że dla zestawu kamer, z którymi pracujemy, PT mieści się w przedziale od 96 do 100.
Jest jeszcze jeden czynnik – parytet portu, ale jak pokazuje praktyka, nie zawsze jest on respektowany, więc trzeba było z niego zrezygnować.
Tak więc zachowanie Berkut-MX wygląda następująco:
- odbieramy paczkę, rozkładamy ją na pola;
- jeśli wersja to 2, a typ ładunku mieści się w określonych granicach, to wysyłamy nagłówki do serwera.
Oczywiście przy takim podejściu pojawiają się fałszywe alarmy, ponieważ nie tylko pakiety RTP mogą podlegać tak prostym kryteriom. Ale dla nas ważne jest, że na pewno nie przepuścimy pakietu RTP, a serwer odfiltruje „niewłaściwe” pakiety.
Do filtrowania fałszywych przypadków serwer wykorzystuje mechanizm, który rejestruje źródło ruchu wideo dla kilku kolejno odbieranych pakietów (pakiet zawiera numer sekwencyjny!). Jeśli przyszło kilka pakietów z kolejnymi numerami, to nie jest to przypadkowy zbieg okoliczności i zaczynamy pracę z tym strumieniem. Algorytm ten okazał się bardzo niezawodny.
Iść dalej ...
Zdając sobie sprawę, że wszystkie informacje przychodzące w pakietach nie są potrzebne do mierzenia jakości i identyfikowania przepływów, zdecydowaliśmy się załadować całą pracę związaną z wysokim obciążeniem i krytyczną czasem pracy dotyczącą odbierania i izolowania pól pakietów RTP na Berkut-MX, czyli na FPGA. „Znajduje” strumień wideo, analizuje pakiet, pozostawia tylko wymagane pola i wysyła go do zwykłego serwera w tunelu UDP. Serwer wykonuje pomiary dla każdej kamery i zapisuje wyniki do bazy danych.
W efekcie serwer nie pracuje z prędkością 50-60 Gigabit/s, ale maksymalnie 5% (jest to stosunek przesyłanych danych do średniej wielkości pakietu). Czyli na wejściu całego systemu 55 Gigabitów/s, podczas gdy serwer odbiera tylko nie więcej niż 3 Gigabity/s!
W rezultacie otrzymaliśmy następującą architekturę:
A pierwszy wynik w tej konfiguracji otrzymaliśmy dwa tygodnie po ustaleniu wstępnego zadania technicznego!
Co w końcu robi serwer?
Co zatem robi serwer w naszej architekturze? Jego zadania:
- nasłuchiwanie gniazda UDP i odczytywanie z niego spakowanych pól nagłówka;
- analizować przychodzące pakiety i pobierać stamtąd pola nagłówka RTP wraz z identyfikatorami kamer;
- skorelować odebrane pola z tymi, które zostały odebrane wcześniej i zrozumieć, czy pakiety zostały utracone, czy pakiety zostały ponownie wysłane, czy zmieniono kolejność nadejścia, jaka była zmiana opóźnienia tranzytu pakietów (jitter) itp .;
- ustalić zmierzone w podstawie w odniesieniu do czasu;
- analizować bazę danych i generować raporty, wysyłać pułapki o zdarzeniach krytycznych (duża utrata pakietów, utrata pakietów z kamery itp.).
Biorąc pod uwagę, że łączny ruch na wejściu serwera to około 3 Gigabity/s, serwer poradzi sobie z tym nawet jeśli nie korzystamy z żadnego DPDK, ale po prostu pracujemy przez gniazdo linuxowe (po wcześniejszym zwiększeniu rozmiaru bufora dla gniazda oczywiście ). Co więcej, będzie można podłączyć nowe łącza i MX-y, ponieważ margines wydajności pozostaje.
Tak wygląda wierzchołek serwera (to jest wierzchołek tylko jednego kontenera lxc, raporty generowane są w innym):
Widać z niego, że całe obciążenie na obliczanie parametrów jakościowych i uwzględnianie statystyk rozkłada się równomiernie na cztery procesy. Taki rozkład udało nam się osiągnąć dzięki zastosowaniu hashowania w FPGA: funkcja haszująca jest obliczana przez IP, a najmniej znaczące bity otrzymanego hasha określają numer portu UDP, do którego trafią statystyki. W związku z tym każdy proces nasłuchujący na własnym porcie odbiera w przybliżeniu taką samą ilość ruchu.
Wady i zalety
Teraz nadszedł czas, aby się pochwalić i przyznać się do niedociągnięć rozwiązania.
Zacznę od profesjonalistów:
- brak strat na skrzyżowaniu z łączami 10G. Ponieważ FPGA przyjmuje całe „uderzenie”, możemy być pewni, że każdy pakiet zostanie przeanalizowany;
- do monitorowania 55 000 kamer (i więcej) wymagany jest tylko jeden serwer z jedną kartą 10G. Obecnie używamy serwerów opartych na 2x Xeon z 4 rdzeniami po 2400 MHz każdy. Dość z marginesem: równolegle z gromadzeniem informacji generowane są raporty;
- monitoring 8 „dziesiątek” (10G linków) mieści się tylko w 2-3 jednostkach: nie zawsze w szafie jest dużo miejsca i zasilania dla systemu monitoringu;
- przy łączeniu łączy z MX'ov przez switch można dodawać nowe łącza bez zatrzymywania monitorowania, ponieważ do serwera nie trzeba wkładać tablic i nie trzeba go w tym celu wyłączać;
- serwer nie jest przeładowany danymi, otrzymuje tylko to, co jest potrzebne;
- nagłówki z MX przychodzą w dużym pakiecie Ethernet, co oznacza, że procesor nie będzie dławiony przerwaniami (poza tym nie zapominamy o łączeniu się przerwań).
W uczciwości rozważę również wady:
- ze względu na ścisłą optymalizację pod konkretne zadanie dodanie obsługi nowych pól lub protokołów wymaga zmian w kodzie FPGA. Prowadzi to do większej straty czasu, niż gdybyśmy robili to samo na procesorze. Zarówno w fazie rozwoju i testowania, jak i podczas wdrażania;
- informacje wideo nie są w ogóle analizowane. Kamera może uchwycić wiszący przed nią sopel lodu lub obrócić się w złym kierunku. Ten fakt pozostanie niezauważony. My oczywiście zapewniliśmy możliwość nagrywania wideo z wybranej kamery, ale operator nie przechodzi przez wszystkie 55 000 kamer!
- urządzenia serwerowe i zasilane z FPGA są droższe niż tylko jeden lub dwa serwery ;)
Streszczenie
W końcu otrzymaliśmy kompleks sprzętowo-programowy, w którym możemy kontrolować zarówno część, która analizuje pakiety na interfejsach, jak i tę, która prowadzi statystyki. Pełna kontrola nad wszystkimi węzłami systemu dosłownie uratowała nas, gdy kamery zaczęły przechodzić w tryb z przeplotem RTSP/TCP. Ponieważ w tym przypadku nagłówek RTP nie znajduje się już w pakiecie ze stałym przesunięciem: może być w dowolnym miejscu, nawet na granicy dwóch pakietów (pierwsza połowa jest w jednym, druga w drugiej). W związku z tym algorytm uzyskiwania nagłówka RTP i jego pól przeszedł dramatyczne zmiany. Musieliśmy wykonać reasembler TCP na serwerze dla wszystkich 50 000 połączeń - stąd dość duże obciążenie na górze.
Nigdy wcześniej nie pracowaliśmy w dziedzinie aplikacji o dużym obciążeniu, ale udało nam się rozwiązać problem wykorzystując nasze umiejętności FPGA i wyszło całkiem nieźle. Pozostaje nawet margines – np. kolejne 20-30 tys. strumieni można podłączyć do systemu z 55 tys. kamer.
Strojenie podsystemów linuxowych (rozkład kolejek przez przerwania, zwiększenie buforów odbiorczych, dyrektywne przydzielanie rdzeni do konkretnych procesów itp.) Wyszedłem poza zakres artykułu, ponieważ ten temat jest już bardzo dobrze omówiony.
Nie opisałem wszystkiego, zebrano dużo prowizji, więc nie wahaj się zadawać pytań :)
Wielkie dzięki wszystkim, którzy przeczytali do końca!
Jednym z najważniejszych trendów w ewolucji nowoczesnej telekomunikacji jest rozwój telefonii IP - różnorodnych nowych technologii, które zapewniają transmisję wiadomości multimedialnych (głos, dane, wideo) poprzez zbudowane na bazie sieci informacyjne i komputerowe (ICN) IP (Internet Protocol), w tym lokalne, korporacyjne, globalne sieci komputerowe oraz Internet. Pojęcie telefonii IP obejmuje telefonię internetową, która umożliwia organizowanie komunikacji telefonicznej pomiędzy abonentami Internetu, pomiędzy abonentami publicznych komutowanych sieci telefonicznych (PSTN) za pośrednictwem Internetu, a także wzajemną komunikację telefoniczną abonentów PSTN i Internetu.
Telefonia IP posiada szereg niewątpliwych zalet, które zapewniają jej szybki rozwój i ekspansję rynku telefonii komputerowej. Jest to korzystne dla użytkowników końcowych, którym zapewnia się łączność telefoniczną przy dość niskiej stawce za minutę. W przypadku firm posiadających odległe oddziały technologia IP umożliwia organizowanie komunikacji głosowej z wykorzystaniem istniejących korporacyjnych sieci IP. Zamiast kilku sieci komunikacyjnych używana jest jedna. Bezwarunkową przewagą telefonii IP nad telefonem konwencjonalnym jest również możliwość świadczenia usług dodatkowych poprzez wykorzystanie komputera multimedialnego i różnych aplikacji internetowych. Dzięki telefonii IP firmy i osoby prywatne mogą rozszerzyć możliwości komunikacji, włączając nowoczesne wideokonferencje, udostępnianie aplikacji, narzędzia takie jak tablica i wiele innych.
Jakie międzynarodowe standardy i protokoły regulują główne parametry i algorytmy funkcjonowania komunikacji sprzętowej i programowej stosowanej w telefonii IP? Oczywiście, jak sama nazwa wskazuje, technologia ta jest zbudowana w oparciu o protokół IP, który jednak jest wykorzystywany nie tylko w telefonii: pierwotnie został opracowany do przesyłania danych cyfrowych w IVS z przełączaniem pakietów.
W sieciach, które nie zapewniają gwarantowanej jakości usług (m.in. sieci zbudowane w oparciu o protokół IP), pakiety mogą zostać utracone, może ulec zmianie kolejność ich nadejścia, dane przesyłane w pakietach mogą ulec zniekształceniu. Aby zapewnić niezawodne dostarczanie przesyłanych informacji w tych warunkach, stosowane są różne procedury warstwy transportowej. Podczas transmisji danych cyfrowych wykorzystywany jest w tym celu protokół TCP (Transmission Control Protocol). Protokół ten zapewnia niezawodne dostarczanie danych i przywraca pierwotną kolejność pakietów. Jeśli w pakiecie zostanie znaleziony błąd lub pakiet zostanie utracony, procedury TCP wysyłają żądanie retransmisji.
W przypadku konferencji audio i wideo opóźnienia pakietów mają znacznie większy wpływ na jakość sygnału niż pojedyncze artefakty danych. Różnice w opóźnieniach mogą prowadzić do przerw. Dla tych aplikacji potrzebny jest inny protokół warstwy transportowej, który może przywrócić oryginalną sekwencję pakietów, dostarczyć je z minimalnym opóźnieniem, odtwarzać w czasie rzeczywistym w ściśle określonych godzinach, rozpoznawać rodzaj ruchu, komunikację grupową lub dwukierunkową. Ten protokół to RTP (Real-Time Transport Protocol). Protokół ten reguluje przesyłanie danych multimedialnych w pakietach przez ICS na poziomie transportu i jest uzupełniany przez protokół kontroli przesyłania danych RTCP (Real-Time Control Protocol). RTCP z kolei zapewnia kontrolę nad dostarczaniem danych multimedialnych, kontrolę jakości usługi, przesyłanie informacji o uczestnikach bieżącej sesji komunikacyjnej, kontrolę i identyfikację, a czasami jest uważany za część protokołu RTP.
W wielu publikacjach poświęconych telefonii IP zauważa się, że większość urządzeń sieciowych i specjalnego oprogramowania dla tej technologii jest opracowywana w oparciu o Zalecenie Sektora Normalizacji Telekomunikacji Międzynarodowego Związku Telekomunikacyjnego (ITU-T) H.323 (w tym TAPI 3.0, NetMeeting 2.0 itd.). Jak H.323 wypada w porównaniu z RTP i RTCP? H.323 to szerokie ramy koncepcyjne, które obejmują wiele innych standardów, z których każdy odpowiada za różne aspekty przekazywania informacji. Większość z tych standardów, na przykład standardy kodeków audio i wideo, są szeroko stosowane nie tylko w telefonii IP. Jeśli chodzi o protokoły RTP / RTCP, stanowią one podstawę standardu H.323, koncentrują się na zapewnieniu dokładnie technologii IP i leżą u podstaw organizacji telefonii IP. Ten artykuł jest poświęcony rozważeniu tych protokołów.
2. Podstawowe pojęcia
Protokół transportowy w czasie rzeczywistym RTP zapewnia transmisję w czasie rzeczywistym danych multimedialnych typu end-to-end, takich jak interaktywne audio i wideo. Protokół ten realizuje rozpoznawanie typu ruchu, numerację sekwencji pakietów, pracę z znaczniki czasu i kontrola transmisji.
Działanie protokołu RTP sprowadza się do przypisywania znaczników czasu każdemu wychodzącemu pakietowi. Po stronie odbiorczej znaczniki czasowe pakietów wskazują, w jakiej kolejności iz jakim opóźnieniem mają być odtwarzane. Obsługa protokołów RTP i RTCP umożliwia węzłowi odbiorczemu uporządkowanie odebranych pakietów we właściwej kolejności, zmniejszenie wpływu zakłóceń opóźnienia pakietów na jakość sygnału oraz przywrócenie synchronizacji między dźwiękiem i obrazem, dzięki czemu przychodzące informacje mogą być prawidłowo odsłuchiwane i przeglądane przez użytkowników.
Należy pamiętać, że sam RTP nie ma żadnego mechanizmu gwarantującego terminową transmisję danych i jakość usług, ale korzysta z usług niższej warstwy, aby to zapewnić. Nie zapobiega to nieprawidłowej kolejności pakietów ani nie sugeruje, że szkielet jest całkowicie niezawodny i przekazuje pakiety we właściwej kolejności. Numery sekwencyjne zawarte w RTP pozwalają odbiorcy na zrekonstruowanie sekwencji pakietów nadawcy.
RTP obsługuje zarówno komunikację dwukierunkową, jak i transfer danych do grupy miejsc docelowych, jeśli multiemisja jest obsługiwana przez sieć bazową. RTP ma na celu dostarczanie informacji wymaganych przez poszczególne aplikacje iw większości przypadków jest zintegrowany z działaniem aplikacji.
Chociaż RTP jest uważany za protokół warstwy transportowej, zwykle działa na szczycie innego protokołu warstwy transportowej, UDP (protokół datagramów użytkownika). Oba protokoły przyczyniają się do funkcjonalności warstwy transportowej. Należy zauważyć, że RTP i RTCP są niezależne od podstawowych warstw transportowych i sieciowych, więc RTP / RTCP mogą być używane z innymi odpowiednimi protokołami transportowymi.
Jednostki danych protokołu RTP / RTCP nazywane są pakietami. Pakiety generowane zgodnie z protokołem RTP i służące do transmisji danych multimedialnych nazywane są pakietami danych, a pakiety generowane zgodnie z protokołem RTCP i służące do przesyłania informacji o usługach wymaganych do niezawodnego działania telekonferencji nazywane są pakietami zarządzania pakietami lub pakietami usług (pakiety kontrolne). Pakiet RTP zawiera stały nagłówek, opcjonalne zmienne rozszerzenie nagłówka i pole danych. Pakiet RTCP zaczyna się od stałej części (podobnej do stałej części pakietów informacji RTP), po której następują bloki konstrukcyjne o zmiennej długości.
Aby protokół RTP był bardziej elastyczny i mógł być używany do różnych aplikacji, niektóre jego parametry są celowo niezdefiniowane, ale uwzględnia koncepcję profilu. Profil to zestaw parametrów protokołów RTP i RTCP dla określonej klasy aplikacji, który określa cechy ich funkcjonowania. Profil definiuje użycie poszczególnych pól nagłówka pakietu, typy ruchu, dodawanie nagłówka i rozszerzenia nagłówka, typy pakietów, usługi i algorytmy bezpieczeństwa komunikacji, specyfikę używania bazowego protokołu itp. Profil RTP dla konferencji audio i wideo przy minimalnej kontroli). Każda aplikacja zwykle działa tylko z jednym profilem, a typ profilu ustawia się wybierając odpowiednią aplikację. Brak wyraźnego wskazania typu profilu według numeru portu, identyfikatora protokołu itp. nie podano.
W związku z tym pełna specyfikacja RTP dla konkretnej aplikacji powinna zawierać dodatkowe dokumenty zawierające opis profilu oraz opis formatu ruchu, który określa sposób obsługi ruchu określonego typu, takiego jak audio lub wideo, w RTP.
W kolejnych rozdziałach omówiono cechy transmisji danych multimedialnych podczas konferencji audio i wideo.
2.1. Grupowe konferencje audio
W przypadku konferencji multiemisji audio wymagany jest adres multiemisji dla wielu użytkowników i dwa porty. W takim przypadku jeden port jest wymagany do wymiany danych audio, a drugi jest używany do pakietów kontrolnych RTCP. Adres multiemisji i informacje o porcie są przekazywane do zamierzonych uczestników telekonferencji. Jeśli wymagana jest prywatność, informacje i pakiety kontrolne mogą być szyfrowane zgodnie z definicją w sekcji 7.1, w którym to przypadku należy również wygenerować i rozpowszechnić klucz szyfrowania.
Aplikacja do obsługi konferencji audio używana przez każdego uczestnika konferencji wysyła dane audio w małych porcjach, na przykład 20 ms. Każdy fragment danych audio jest poprzedzony nagłówkiem RTP; nagłówek RTP i dane są naprzemiennie formowane (kapsułkowane) w pakiet UDP. Nagłówek RTP wskazuje, jaki typ kodowania audio (na przykład PCM, ADPCM lub LPC) został użyty do utworzenia danych w pakiecie. Umożliwia to zmianę rodzaju kodowania w trakcie konferencji, np. w przypadku pojawienia się nowego uczestnika, który korzysta z linii komunikacyjnej o niskiej przepustowości lub gdy sieć jest przeciążona.
W Internecie, podobnie jak w innych sieciach danych z komutacją pakietów, pakiety są czasami gubione i zmieniane w kolejność, a także opóźniane o różne czasy. Aby przeciwdziałać tym zdarzeniom, nagłówek RTP zawiera znacznik czasu i numer sekwencji, które umożliwiają odbiorcom ponowną synchronizację do ich pierwotnego stanu, dzięki czemu na przykład fragmenty sygnału audio są odtwarzane przez głośnik w sposób ciągły co 20 ms. Ta rekonstrukcja synchronizacji jest wykonywana oddzielnie i niezależnie dla każdego źródła pakietów RTP w telekonferencji. Numer sekwencyjny może być również wykorzystany przez odbiornik do oszacowania liczby utraconych pakietów.
Ponieważ uczestnicy telekonferencji mogą dołączać do konferencji i opuszczać ją w trakcie jej trwania, warto wiedzieć, kto aktualnie uczestniczy w konferencji i jak dobrze uczestnicy konferencji odbierają dźwięk. W tym celu każda instancja aplikacji audio podczas konferencji okresowo wysyła komunikaty na porcie kontrolnym (port RTCP) dla aplikacji wszystkich innych uczestników o odbiorze pakietów ze wskazaniem ich nazwy użytkownika. Komunikat odbioru wskazuje, jak dobrze jest słyszany bieżący mówca i może być używany do sterowania koderami adaptacyjnymi. Oprócz nazwy użytkownika mogą być również zawarte inne informacje identyfikacyjne służące do kontroli przepustowości. Opuszczając konferencję, strona wysyła pakiet RTCP BYE.
2.2. Wideokonferencje
Jeśli telekonferencja wykorzystuje zarówno sygnały audio, jak i wideo, są one transmitowane oddzielnie. Dla transmisji każdego typu ruchu, niezależnie od drugiego, specyfikacja protokołu wprowadza pojęcie sesji RTP (patrz. wykaz użytych skrótów i terminów). Sesja jest identyfikowana przez określoną parę docelowych adresów transportowych (jeden adres sieciowy plus para portów dla RTP i RTCP). Pakiety dla każdego typu ruchu są przesyłane przy użyciu dwóch różnych par portów UDP i/lub adresów multicast. Nie ma bezpośredniego połączenia RTP między sesjami komunikacji audio i wideo, z wyjątkiem tego, że użytkownik uczestniczący w obu sesjach musi używać tej samej nazwy kanonicznej w pakietach RTCP dla obu sesji, aby można było połączyć sesje.
Jednym z powodów takiego oddzielenia jest to, że niektórzy uczestnicy konferencji powinni mieć możliwość odbierania tylko jednego rodzaju ruchu, jeśli sobie tego życzą. Pomimo separacji, synchroniczne odtwarzanie mediów źródłowych (audio i wideo) można osiągnąć przy użyciu informacji o taktowaniu, które są przenoszone w pakietach RTCP dla obu sesji.
2.3. Zrozumienie mikserów i tłumaczy
Nie wszystkie witryny mogą zawsze odbierać dane multimedialne w tym samym formacie. Rozważmy przypadek, w którym uczestnicy z tej samej lokalizacji są połączeni linią o niskiej prędkości z większością pozostałych uczestników konferencji, którzy mają szerokopasmowy dostęp do sieci. Zamiast zmuszać wszystkich do używania węższej przepustowości i kodowania dźwięku o niższej jakości, w obszarze o wąskim paśmie można umieścić funkcję komunikacji w warstwie RTP, zwaną mikserem. Ten mikser ponownie synchronizuje przychodzące pakiety audio, aby przywrócić oryginalne odstępy 20 ms, miesza te zrekonstruowane strumienie audio w jeden strumień, koduje sygnał audio dla wąskiego pasma i przesyła strumień pakietów przez łącze o niskiej prędkości. W takim przypadku pakiety mogą być adresowane do jednego odbiorcy lub grupy odbiorców o różnych adresach. Aby zapewnić prawidłowe wskazanie źródła wiadomości w punktach końcowych odbioru, nagłówek RTP zawiera środki dla mikserów do identyfikowania źródeł biorących udział w mieszanym pakiecie.
Niektórzy uczestnicy konferencji audio mogą być połączeni liniami szerokopasmowymi, ale mogą nie być osiągalni przez konferencje IP multicast (IPM). Na przykład mogą znajdować się za zaporą warstwy aplikacji, która nie pozwoli na transmisję pakietów IP. W takich przypadkach nie są potrzebne miksery, ale inne rodzaje komunikacji na poziomie RTP, zwane translatorami. Spośród dwóch translatorów jeden jest zainstalowany poza zaporą ogniową, az zewnątrz przekazuje wszystkie pakiety multiemisji odebrane przez bezpieczne połączenie do drugiego translatora znajdującego się za zaporą. Tłumacz znajdujący się za zaporą przesyła je ponownie jako pakiety multicastowe do grupy wielu użytkowników ograniczonej do sieci wewnętrznej witryny.
Miksery i translatory mogą być zaprojektowane do wielu celów. Przykład: Mikser wideo, który skaluje obrazy wideo poszczególnych osób do niezależnych strumieni wideo i łączy je w pojedynczy strumień wideo, symulując scenę grupową. Przykłady transmisji: łączenie grupy hostów przy użyciu wyłącznie protokołów IP/UDP z grupą hostów akceptujących tylko ST-II lub transkodowanie pakietu sygnału wideo po pakiecie z poszczególnych źródeł bez ponownej synchronizacji lub mieszania. Szczegóły działania mikserów i translatorów omówiono w rozdziale 5.
2.4. Kolejność bajtów, wyrównanie i format znacznika czasu
Wszystkie pola pakietów RTP / RTCP są przesyłane przez sieć w bajtach (oktetach); najbardziej znaczący bajt jest przesyłany jako pierwszy. Wszystkie dane pola nagłówka są wyrównane zgodnie z ich długością . Oktety oznaczone jako opcjonalne mają wartość zero.
Czas bezwzględny (czas na zegarze ściennym) w RTP jest reprezentowany przy użyciu formatu sygnatury czasowej protokołu NTP (Network Time Protocol), który jest liczbą czasu w sekundach w stosunku do zera godzin w dniu 1 stycznia 1900 roku. Pełny format znacznika czasu NTP to 64-bitowa liczba stałoprzecinkowa bez znaku z częścią całkowitą w pierwszych 32 bitach i częścią ułamkową w ostatnich 32 bitach. Niektóre pola z bardziej zwartą reprezentacją używają tylko środkowych 32 bitów — dolnych 16 bitów części całkowitej i górnych 16 bitów części ułamkowej.
Kolejne dwie sekcje tego artykułu (3 i 4) omawiają odpowiednio formaty pakietów i funkcje protokołów RTP i RTCP.
3. Protokół przesyłania danych RTP
3.1. Stałe pola nagłówka RTP
Jak wspomniano powyżej, pakiet RTP zawiera stały nagłówek, opcjonalne zmienne rozszerzenie nagłówka i pole danych. Stały nagłówek pakietów RTP ma następujący format:.
Pierwszych dwanaście oktetów jest obecnych w każdym pakiecie RTP, podczas gdy pole identyfikatora CSRC (źródło wnoszące wkład) jest obecne tylko po wstawieniu przez mikser. Pola mają następujące cele.
Wersja (V): 2 bity. To pole identyfikuje wersję RTP. W tym artykule omówiono wersję 2 protokołu RTP (wartość 1 została użyta w pierwszym projekcie RTP).
Dopełnienie (P): 1 bit. Jeśli bit dopełnienia jest ustawiony na jeden, pakiet zawiera na końcu jeden lub więcej oktetów dopełniających, które nie są częścią ruchu. Ostatni oktet dopełnienia zawiera wskazanie liczby takich oktetów, które mają być następnie zignorowane. Dopełnienie może być wymagane przez niektóre algorytmy szyfrowania o stałym rozmiarze bloku lub do przenoszenia wielu pakietów RTP w pojedynczej jednostce danych protokołu niższej warstwy.
Rozszerzenie (X): 1 bit. Jeśli bit rozszerzenia jest ustawiony, po stałym nagłówku następuje rozszerzenie nagłówka o formacie określonym w.
Licznik CSRC (CC): 4 bity. Licznik CSRC zawiera liczbę identyfikatorów źródła CSRC, które należy uwzględnić (patrz wykaz użytych skrótów i terminów), które następują po stałym nagłówku.
Znacznik (M): 1 bit. Interpretacja markera zależy od profilu. Ma to na celu umożliwienie zaznaczania znaczących zdarzeń (np. granic ramek wideo) w strumieniu pakietów. Profil może wprowadzić dodatkowe bity znacznika lub określić, że nie ma bitu znacznika, zmieniając liczbę bitów w polu typu ruchu (patrz).
Typ ruchu (PT): 7 bitów. To pole identyfikuje format ruchu RTP i określa jego interpretację przez aplikację. Profil definiuje domyślne mapowanie statyczne między wartościami PT a formatami ruchu. Dodatkowe kody typu ruchu mogą być dynamicznie określane za pomocą środków innych niż RTP. Nadawca pakietu RTP w dowolnym momencie dostarcza pojedynczą wartość dla typu ruchu RTP; pole to nie jest przeznaczone do multipleksowania poszczególnych strumieni mediów (patrz).
Numer sekwencyjny: 16 bitów. Wartość numeru sekwencji jest zwiększana o jeden z każdym wysłanym pakietem danych RTP i może być używana przez odbiornik do wykrywania utraty pakietów i rekonstrukcji ich do oryginalnej sekwencji. Początkowa wartość numeru sekwencyjnego jest wybierana losowo, aby skomplikować próby złamania klucza na podstawie znanych wartości tego pola (nawet jeśli szyfrowanie nie jest używane przez źródło, ponieważ pakiety mogą przechodzić przez tłumacza, który używa szyfrowania) . Znacznik czasu: 32 bity. Znacznik czasu odzwierciedla punkt próbkowania dla pierwszego oktetu w pakiecie informacyjnym RTP. Czas próbkowania musi być uzyskany z timera, który inkrementuje swoje wartości monotonicznie i liniowo w czasie, aby zapewnić synchronizację i wykrywanie jittera (patrz. sekcja 4.3.1). Rozdzielczość timera powinna być wystarczająca dla pożądanej dokładności taktowania i pomiaru fluktuacji przychodzących pakietów (jeden raport timera na klatkę wideo zwykle nie wystarcza). Częstotliwość taktowania zależy od formatu przesyłanego ruchu i jest ustawiana statycznie w profilu lub specyfikacji formatu ruchu, lub może być ustawiana dynamicznie dla formatów ruchu zdefiniowanych za pomocą środków innych niż RTP. Jeżeli pakiety RTP są generowane okresowo, należy użyć nominalnych czasów próbkowania określonych przez zegar próbkowania, a nie wartości zegara systemowego. Na przykład, dla sygnału audio o stałej szybkości, pożądane jest, aby czujnik znacznika czasu był zwiększany o jeden dla każdego okresu próbkowania. Jeśli aplikacja dźwiękowa odczytuje z urządzenia wejściowego bloki zawierające 160 próbek, to znacznik czasu powinien wzrosnąć o 160 dla każdego takiego bloku, niezależnie od tego, czy blok jest przesyłany w pakiecie, czy odrzucany jako pauza. Początkowa wartość znacznika czasu, jak również początkowa wartość numeru sekwencyjnego, jest zmienną losową. Kilka kolejnych pakietów RTP może mieć takie same znaczniki czasu, jeśli są one logicznie generowane w tym samym czasie, na przykład, należą do tej samej ramki wideo. Kolejne pakiety RTP mogą zawierać niemonotoniczne znaczniki czasu, jeśli dane nie są przesyłane w kolejności próbkowania, jak ma to miejsce w przypadku interpolowanych ramek wideo MPEG (jednak numery sekwencyjne pakietów nadal będą monotoniczne podczas transmisji).
SSRC: 32 bity. Pole SSRC (źródło synchronizacji) identyfikuje źródło synchronizacji (patrz. wykaz użytych skrótów i terminów). Ten identyfikator jest wybierany losowo, aby żadne dwa źródła synchronizacji w tej samej sesji RTP nie miały takich samych identyfikatorów SSRC. Chociaż jest mało prawdopodobne, że wiele źródeł wybierze ten sam identyfikator, wszystkie implementacje RTP muszą być przygotowane do wykrywania i rozwiązywania takich kolizji. Rozdział 6 omawia prawdopodobieństwo kolizji wraz z mechanizmem ich rozwiązywania i wykrywania pętli warstwy RTP w oparciu o unikalność identyfikatora SSRC. Jeśli źródło zmieni swój oryginalny adres transportowy, musi również wybrać nowy identyfikator SSRC, aby nie było interpretowane jako źródło zapętlone.
Lista CSRC: od 0 do 15 pozycji po 32 bity. Lista CSRC (contributing source) identyfikuje uwzględnione źródła ruchu zawartego w pakiecie. Liczbę identyfikatorów określa pole CC. Jeśli jest więcej niż piętnaście uwzględnionych źródeł, to tylko 15 z nich można zidentyfikować. Identyfikatory CSRC są wstawiane przez miksery podczas używania identyfikatorów SSRC dla źródeł dołączania. Na przykład, w przypadku pakietów dźwiękowych, SSRC wszystkich źródeł, które zostały zmieszane podczas tworzenia pakietu, są wymienione na liście CSRC, zapewniając odbiorcy prawidłowe wskazanie źródeł wiadomości.
3.2. Sesje RTP
Jak wspomniano powyżej, zgodnie z protokołem RTP, różne rodzaje ruchu muszą być przesyłane oddzielnie, w różnych sesjach RTP. Sesja jest identyfikowana przez określoną parę docelowych adresów transportowych (jeden adres sieciowy plus para portów dla RTP i RTCP). Na przykład w telekonferencji, która składa się z dźwięku i obrazu zakodowanych oddzielnie, każdy rodzaj ruchu musi być wysłany w oddzielnej sesji RTP z własnym docelowym adresem transportowym. Audio i wideo nie powinny być przesyłane w tej samej sesji RTP i rozdzielone na podstawie typu ruchu lub pól SSRC. Przeplatanie pakietów o różnych typach ruchu, ale przy użyciu tego samego SSRC, powodowałoby pewne problemy:
- Jeśli jeden z typów ruchu zmieni się w trakcie sesji, nie będzie ogólnych możliwości określenia, która ze starych wartości została zastąpiona nową.
- SSRC identyfikuje pojedynczą wartość przedziału czasowego i przestrzeń numerów sekwencyjnych. Przeplatanie wielu typów ruchu wymagałoby różnych interwałów synchronizacji, jeśli częstotliwości taktowania różnych strumieni są różne, oraz różnych przestrzeni numerów sekwencyjnych, aby wskazać typ ruchu, do którego odnosi się utrata pakietów.
- Wiadomości nadawcy i odbiorcy RTCP (patrz sekcja 4.3) opisują tylko jedną wartość przedziału czasu i przestrzeń numeru sekwencyjnego dla SSRC i nie zawierają pola typu ruchu.
- Mikser RTP nie jest w stanie łączyć przeplecionych strumieni różnych typów ruchu w jeden strumień.
- Następujące czynniki utrudniają transmisję wielu rodzajów ruchu w pojedynczej sesji RTP: wykorzystanie różnych ścieżek sieciowych lub alokacja zasobów sieciowych; odbieranie podzbioru danych multimedialnych, gdy jest to wymagane, na przykład tylko dźwięku, jeśli sygnał wideo przekroczył dostępną przepustowość; implementacje odbiornika, które używają oddzielnych procesów dla różnych rodzajów ruchu, podczas gdy użycie oddzielnych sesji RTP pozwala na implementację jednego lub wielu procesów.
Używając różnych SSRC dla każdego typu ruchu, ale przesyłając je w tej samej sesji RTP, można uniknąć pierwszych trzech problemów, ale dwóch ostatnich nie da się uniknąć. Dlatego specyfikacja protokołu RTP narzuca inną sesję RTP dla każdego typu ruchu.
3.3. Zmiany nagłówka RTP specyficzne dla profilu
Istniejący nagłówek pakietu informacji RTP jest kompletny dla zestawu funkcji wymaganych ogólnie dla wszystkich klas aplikacji, które mogą obsługiwać RTP. Jednak, aby lepiej odpowiadać konkretnym potrzebom, nagłówek można modyfikować poprzez modyfikacje lub dodatki zdefiniowane w specyfikacji profilu.
Bit znacznika i pole typu ruchu przenoszą informacje specyficzne dla profilu, ale znajdują się w stałym nagłówku, ponieważ oczekuje się, że wiele aplikacji będzie ich potrzebowało. Oktet zawierający te pola może zostać zastąpiony przez profil, aby spełnić różne wymagania, na przykład z większą lub mniejszą liczbą bitów znacznika. Jeśli istnieją bity znacznikowe, MUSZĄ one być umieszczone w najbardziej znaczących bitach oktetu, ponieważ monitory niezależne od profilu mogą być w stanie obserwować korelację między wzorcami utraty pakietów a bitem znacznika.
Dodatkowe informacje wymagane dla określonego formatu ruchu (na przykład rodzaj kodowania wideo) powinny być przenoszone w polu danych pakietu. Może być umieszczony w określonym miejscu na początku lub w tablicy danych.
Jeżeli dana klasa aplikacji wymaga dodatkowej funkcjonalności niezależnej od formatu ruchu, to profil, z którym te aplikacje działają, powinien definiować dodatkowe stałe pola bezpośrednio po polu SSRC istniejącego stałego nagłówka. Aplikacje te będą w stanie szybko uzyskać bezpośredni dostęp do dodatkowych pól, podczas gdy monitory lub rejestratory niezależne od profilu nadal będą mogły przetwarzać pakiety RTP, interpretując tylko pierwsze dwanaście oktetów.
Jeśli uważa się, że potrzebne są dodatkowe funkcje wspólne dla wszystkich profili, należy zdefiniować nową wersję RTP, aby na stałe zmienić stały nagłówek.
3.4. Rozszerzenie nagłówka RTP
Aby umożliwić poszczególnym implementacjom eksperymentowanie z nowymi funkcjami niezależnymi od formatu ruchu, które wymagają przenoszenia dodatkowych informacji w nagłówku pakietu informacji, protokół RTP zapewnia mechanizm rozszerzenia nagłówka. Mechanizm ten został zaprojektowany tak, aby rozszerzenie nagłówka mogło zostać zignorowane przez inne komunikujące się aplikacje, które go nie wymagają.
Jeśli bit X w nagłówku RTP jest ustawiony na jeden, to rozszerzenie nagłówka o zmiennej długości jest dołączane do stałego nagłówka RTP (zgodnie z listą CSRC, jeśli istnieje). Pamiętaj, że to rozszerzenie nagłówka jest przeznaczone tylko do ograniczonego użytku. Rozszerzenie nagłówka pakietu RTP ma następujący format:
Rozszerzenie zawiera 16-bitowe pole długości, które wskazuje liczbę 32-bitowych słów, z wyłączeniem czterooktetowego nagłówka rozszerzenia (stąd długość może wynosić zero). Do stałego nagłówka pakietu informacyjnego RTP można dodać tylko jedno rozszerzenie. Aby umożliwić każdej z wielu interoperacyjnych implementacji niezależne eksperymentowanie z różnymi rozszerzeniami nagłówka lub aby umożliwić konkretnej implementacji eksperymentowanie z więcej niż jednym typem rozszerzenia nagłówka, użycie pierwszych 16 bitów rozszerzenia jest niezdefiniowane, pozostawiając rozróżnienie identyfikatorów lub parametry. Format tych 16 bitów musi być określony przez specyfikację profilu, z którym działają aplikacje.
| 1999 | ||||||||||||
| 2000 |
RTP - Real-time Transport Protocol RTCP - Real-time Control Protocol Dodatkowo zawiera informacje o: utracie pakietów, buforowaniu jittera, opóźnieniach, poziomie sygnału, metryce jakości sygnału (wskaźniki jakości połączenia), utracie echa, itp. RTCP XR - Rozszerzone raporty protokołu sterowania w czasie rzeczywistym Wszystkie pola opisane dla RTCP plus: R Factor - parametr jakości sygnału MOS - parametr jakości sygnału i inne
Pakiety zawierające głos wychodzący są wysyłane przy użyciu protokołu RTP/RTCP dla protokołu używanego do połączeń VOIP. RTP może przenosić nośniki identyfikowane za pomocą parametrów, które są rejestrowane przez "Internet przydzielony urząd numerów" - IANA. Są one również używane do pól w protokole używanym w wiadomościach.
Niektóre wartości pola payload:
| PT | nazwa kodeka | audio/wideo (A/V) | częstotliwość zegara (Hz) | Liczba kanałów | Dokument | 0 | PCMU | A | 8000 | 1 | RFC3551 | 3 | GSM | A | 8000 | 1 | RFC3551 | 4 | G723 | A | 8000 | 1 | Kumar | 5 | DVI4 | A | 8000 | 1 | RFC3551 | 6 | DVI4 | A | 16000 | 1 | RFC3551 | 7 | LPC | A | 8000 | 1 | RFC3551 | 8 | PCMA | A | 8000 | 1 | RFC3551 | 9 | G722 | A | 8000 | 1 | RFC3551 | 10 | L16 | A | 44100 | 2 | RFC3551 | 11 | L16 | A | 44100 | 1 | RFC3551 | 12 | QCELP | A | 8000 | 1 | - | 13 | CN | A | 8000 | 1 | RFC3389 | 14 | MPA | A | 90000 | RFC3551, RFC2250 | 15 | G728 | A | 8000 | 1 | RFC3551 | 16 | DVI4 | A | 11025 | 1 | Dipol | 17 | DVI4 | A | 22050 | 1 | Dipol | 18 | G729 | A | 8000 | 1 | 19 | skryty | A | 20 | nie przypisano | A | 21 | nie przypisano | A | 22 | nie przypisano | A | 23 | nie przypisano | A | 24 | nie przypisano | V | 25 | CelB | V | 90000 | RFC2029 | 26 | JPEG | V | 90000 | RFC2435 | 27 | nie przypisano | V | 28 | nv | V | 90000 | RFC3551 | 29 | nie przypisano | V | 30 | nie przypisano | V | 31 | H261 | V | 90000 | RFC2032 | 32 | MPV | V | 90000 | RFC2250 | 33 | MP2T | AV | 90000 | RFC2250 | 34 | H263 | V | 90000 | Zhu | 35--71 | nie przypisano | 72--76 | zarezerwowane dla RTCP, aby uniknąć konfliktów | RFC3550 | 77--95 | nie przypisano | 77--95 | dynamiczny | RFC3551 |
IANA: Zarejestrowane parametry RTP: http://www.iana.org/assignments/rtp-parameters
