Protokół RTP. Rozwój struktury sieci z komutacją pakietów na przykładzie OAO „Moskiewska Państwowa Sieć Telefoniczna”

Jednym z najważniejszych trendów w ewolucji nowoczesnej telekomunikacji jest rozwój telefonii IP - zestawu nowych technologii, które zapewniają transmisję wiadomości multimedialnych (głos, dane, wideo) przez sieci informacyjne i komputerowe (ICN) zbudowane na w oparciu o protokół IP (Internet Protocol), w tym lokalny, korporacyjny, globalny sieć komputerowa i Internet. Pojęcie telefonii IP obejmuje telefonię internetową, która umożliwia organizowanie komunikacji telefonicznej między abonentami Internetu, między abonentami publicznych sieci telefonicznych (PSTN) za pośrednictwem Internetu, a także wzajemną komunikację telefoniczną między abonentami PSTN i Internetu.

Telefonia IP ma szereg niezaprzeczalnych 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ę komunikację 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. Niewątpliwą przewagą telefonii IP nad zwykłym telefonem jest również możliwość świadczenia dodatkowe usługi poprzez wykorzystanie komputera multimedialnego i różnych aplikacji internetowych. Dzięki telefonii IP firmy i osoby prywatne mogą rozszerzyć swoje możliwości komunikacyjne, wprowadzając zaawansowane wideokonferencje, udostępnianie aplikacji, narzędzia typu tablica i tak dalej.

Jakie międzynarodowe standardy i protokoły regulują główne parametry i algorytmy działania 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 używany nie tylko w telefonii: został pierwotnie opracowany do przesyłania danych cyfrowych do IVS z komutacją 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, kolejność ich nadejścia może ulec zmianie, dane przesyłane w pakietach mogą być zniekształcone. Aby zapewnić niezawodną dostawę przesyłane informacje w tych warunkach stosowane są różne procedury warstwy transportowej. Podczas transmisji danych cyfrowych służy do tego protokół TCP (Transmission Control Protocol). Protokół ten zapewnia niezawodne dostarczanie danych i przywraca pierwotną kolejność pakietów. W przypadku wykrycia błędu w pakiecie lub utraty pakietu 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ż zniekształcenia poszczególnych danych. Różnice w opóźnieniach mogą prowadzić do luk. Do takich zastosowań potrzebny jest inny protokół warstwy transportowej, który zapewnia przywrócenie oryginalnej sekwencji pakietów, ich dostarczenie z minimalnym opóźnieniem, odtwarzanie w czasie rzeczywistym w ściśle określonych momentach, rozpoznawanie typu ruchu, multicast lub dwukierunkowa komunikacja. Takim protokołem jest protokół transportu czasu rzeczywistego RTP (Real-Time Transport Protocol). Protokół ten reguluje transmisję danych multimedialnych w pakietach przez IVS na poziomie transportu i jest uzupełniony protokołem kontroli transmisji danych w czasie rzeczywistym RTCP (Real-Time Control Protocol). Protokół RTCP z kolei zapewnia kontrolę nad dostarczaniem danych multimedialnych, kontrolę jakości usług, przekazywanie informacji o uczestnikach bieżącej sesji komunikacyjnej, kontrolę i identyfikację, a czasami jest uważany za część Protokół RTP.

W wielu publikacjach dotyczących telefonii IP zwraca się uwagę, że większość urządzeń sieciowych i specjalnego oprogramowania dla tej technologii jest opracowywana w oparciu o Rekomendację Sektora Normalizacji Telekomunikacji Międzynarodowego Związku Telekomunikacyjnego (ITU-T) H.323 (m.in. TAPI 3.0, NetMeeting 2.0, itp.). Jak H.323 odnosi się do RTP i RTCP? H.323 to szerokie ramy koncepcyjne, które obejmują wiele innych standardów, z których każdy dotyczy różnych aspektów przesyłania informacji. Większość z tych standardów, takich jak standardy kodeków audio i wideo, jest szeroko stosowana nie tylko w telefonii IP. Jeśli chodzi o protokoły RTP/RTCP, to stanowią one podstawę standardu H.323, koncentrują się na zapewnieniu dokładnie technologii IP i są podstawą organizacji telefonii IP. Ten artykuł jest poświęcony rozważeniu tych protokołów.

2. Podstawowe pojęcia

Protokół transportowy RTP w czasie rzeczywistym zapewnia transmisję w czasie rzeczywistym danych multimedialnych typu end-to-end, takich jak interaktywne audio i wideo. Protokół ten implementuje rozpoznawanie typu ruchu, numerację sekwencji pakietów, pracę z znaczniki czasu i kontrola transmisji.

Działanie protokołu RTP sprowadza się do przypisania każdemu wychodzącemu pakietowi znacznika czasu. Po stronie odbiorczej znaczniki czasu pakietów wskazują, w jakiej kolejności iz jakim opóźnieniem należy je odtworzyć. Obsługa protokołów RTP i RTCP umożliwia hostowi odbierającemu uporządkowanie odebranych pakietów we właściwej kolejności, zmniejszenie wpływu tętnienia opóźnienia pakietów w sieci na jakość sygnału oraz przywrócenie synchronizacji między dźwiękiem i wideo, dzięki czemu przychodzące informacje mogą być prawidłowo słyszane 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 podstawowych usług, aby to zapewnić. Nie zapobiega pakietom poza kolejnością, ale nie zakłada, że sieć bazowa jest absolutnie niezawodna i przesyła pakiety we właściwej kolejności. Numery sekwencyjne zawarte w RTP pozwalają odbiorcy na ponowne sekwencjonowanie pakietów nadawcy.

Protokół 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 protokoły 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 wykorzystywane do przesyłania danych multimedialnych nazywane są pakietami informacyjnymi lub pakietami danych (pakietami danych), a pakiety generowane zgodnie z protokołem RTCP i wykorzystywane do przesyłania informacji o usługach wymaganych do niezawodnej telekonferencji nazywane są pakietami. lub pakiety usługowe (pakiety kontrolne). Pakiet RTP zawiera stały nagłówek, opcjonalne rozszerzenie nagłówka o zmiennej długości oraz 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 nadawał się do różnych aplikacji, niektóre jego parametry są celowo niezdefiniowane, ale uwzględnia koncepcję profilu. Profil (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, cechy użycia podstawowego protokołu itp. Profil RTP dla konferencji audio i wideo przy minimalnej kontroli ). Każda aplikacja zwykle działa tylko z jednym profilem, a ustawienie typu profilu odbywa się poprzez wybranie odpowiedniej aplikacji. Brak wyraźnego wskazania typu profilu według numeru portu, identyfikatora protokołu itp. nie podano.

Dlatego pełna specyfikacja RTP dla konkretnej aplikacji musi zawierać dodatkowe dokumenty, w tym opis profilu, a także opis formatu ruchu, który określa, w jaki sposób określony rodzaj ruchu, taki jak audio lub wideo, będzie przetwarzany w RTP.

W kolejnych rozdziałach omówiono funkcje transmisji danych multimedialnych podczas audio i wideokonferencji.

2.1. Grupowe konferencje audio

Grupowe konferencje audio wymagają adresu grupowego dla wielu użytkowników i dwóch portów. W takim przypadku jeden port jest wymagany do wymiany danych audio, a drugi służy do pakietów kontrolnych protokołu RTCP. Adres grupy i informacje o porcie są wysyłane do zamierzonych uczestników telekonferencji. Jeśli wymagana jest prywatność, pakiety informacyjne i 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 seriach, na przykład 20 ms. Każdy fragment danych audio jest poprzedzony nagłówkiem RTP; nagłówek RTP i dane są z kolei formowane (kapsułkowane) w pakiet UDP. Nagłówek RTP wskazuje, jaki typ kodowania dźwięku (np. PCM, ADPCM lub LPC) został użyty do utworzenia danych w pakiecie. Umożliwia to zmianę rodzaju kodowania podczas konferencji, na przykład w przypadku pojawienia się nowego uczestnika korzystającego z połączenia o niskiej przepustowości lub w przypadku przeciążenia sieci.

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 sekwencyjny, które umożliwiają odbiornikom zmianę taktowania, tak aby na przykład fragmenty sygnału audio były odtwarzane w sposób ciągły przez głośnik co 20 ms. Ta rekonstrukcja taktowania jest wykonywana oddzielnie i niezależnie dla każdego źródła pakietów RTP w telekonferencji. Numer sekwencyjny może być również używany przez odbiornik do oszacowania liczby utraconych pakietów.

Ponieważ uczestnicy telekonferencji mogą dołączać do telekonferencji i opuszczać ją w trakcie jej trwania, warto wiedzieć, kto aktualnie uczestniczy w konferencji i jak dobrze uczestnicy konferencji odbierają dane audio. W tym celu każda instancja aplikacji audio podczas konferencji okresowo wysyła na port kontrolny (port RTCP) dla aplikacji wszystkich innych uczestników wiadomości odbioru pakietów wskazujące ich nazwę 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 można również uwzględnić inne informacje identyfikacyjne służące do kontroli przepustowości. Opuszczając konferencję, strona wysyła pakiet RTCP BYE.

2.2. Wideokonferencje

Jeżeli w telekonferencji wykorzystywane są 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 lista użytych skrótów i terminów). Sesja jest zdefiniowana 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 warstwy RTP między sesjami 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 tej separacji jest to, że niektórzy uczestnicy konferencji muszą mieć możliwość odbierania tylko jednego rodzaju ruchu, jeśli chcą. Pomimo separacji, synchroniczne odtwarzanie źródłowych danych medialnych (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. Koncepcja mikserów i translatorów

Nie zawsze wszystkie witryny mają możliwość odbioru danych multimedialnych w tym samym formacie. Rozważmy przypadek, w którym uczestnicy z tej samej miejscowości są połączeni przez łącze o niskiej prędkości z większością innych uczestników konferencji, którzy mają dostęp do sieci szerokopasmowej. Zamiast zmuszać wszystkich do korzystania z węższej przepustowości i kodowania dźwięku o niższej jakości, w obszarze o niskiej przepustowości można umieścić narzędzie komunikacji w warstwie RTP zwane mikserem. Ten mikser ponownie synchronizuje przychodzące pakiety audio, aby przywrócić oryginalne interwały 20 ms, miksuje te przywrócone strumienie audio w jeden strumień, koduje sygnał dźwiękowy 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 odbierać punkty końcowe, aby zapewnić prawidłowe wskazanie źródła wiadomości, nagłówek RTP zawiera środki dla mikserów do identyfikowania źródeł biorących udział w tworzeniu mieszanego pakietu.

Niektórzy uczestnicy konferencji audio mogą być połączeni łączami szerokopasmowymi, ale mogą nie być osiągalni przez konferencję grupową 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 inny rodzaj komunikacji w warstwie RTP, zwany translatorami. Z dwóch translatorów jeden jest zainstalowany poza zaporą i przekazuje wszystkie pakiety multiemisji odebrane przez bezpieczne połączenie z zewnątrz do drugiego translatora zainstalowanego za zaporą. Przekaźnik znajdujący się za zaporą ponownie rozsyła je jako pakiety multiemisji 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 w niezależnych strumieniach wideo i łączy je w pojedynczy strumień wideo, symulując scenę grupową. Przykłady transmisji: Łączenie grupy hostów obsługujących tylko IP/UDP z grupą hostów obsługujących tylko ST-II lub transkodowanie pakietów wideo po pakiecie z poszczególnych źródeł bez retimingu lub miksowania. 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 znacznika czasu NTP (Network Time Protocol), który jest odliczaniem 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. 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ą formaty pakietów i cechy funkcjonowania odpowiednio protokołów RTP i RTCP.

3. Protokół przesyłania danych RTP

3.1. Naprawiono pola nagłówka RTP

Jak wspomniano powyżej, pakiet RTP zawiera stały nagłówek, opcjonalne rozszerzenie nagłówka o zmiennej długości oraz pole danych. Stały nagłówek pakietów protokołu 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. Ten artykuł koncentruje się na wersji 2 protokołu RTP (wartość 1 została użyta w pierwszej wersji roboczej protokołu RTP).

Uzupełnienie (P): 1 bit. Jeśli bit dopełnienia jest ustawiony na jeden, pakiet na końcu zawiera jeden lub więcej oktetów dopełniających, które nie są częścią ruchu. Ostatni oktet dopełniający zawiera wskazanie liczby takich oktetów, które mają być następnie ignorowane. Dopełnienie może być wymagane przez niektóre algorytmy szyfrowania ze stałymi rozmiarami bloków lub do przenoszenia wielu pakietów RTP w jednym podstawowym ładunku protokołu.

Rozszerzenie (X): 1 bit. Jeśli bit rozszerzenia jest ustawiony, po stałym nagłówku następuje rozszerzenie nagłówka o formacie zdefiniowanym w .

Licznik CSRC (CC): 4 bity. Licznik CSRC zawiera liczbę identyfikatorów źródła CSRC do uwzględnienia (patrz lista 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 wprowadzać dodatkowe bity znacznika lub określać, ż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, jak aplikacja go zinterpretuje. Profil definiuje domyślne statyczne mapowanie wartości PT i formatów ruchu. Dodatkowe kody typu ruchu mogą być definiowane dynamicznie za pośrednictwem urządzeń innych niż RTP. Nadawca pakietu RTP w dowolnym momencie emituje pojedynczą wartość typu ruchu RTP; to pole 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 informacji RTP i może być używana przez odbiornik do wykrywania utraconych pakietów i przywracania ich oryginalnej sekwencji. Początkowa wartość numeru sekwencyjnego jest wybierana losowo, aby utrudnić złamanie klucza na podstawie znanych wartości tego pola (nawet jeśli źródło nie korzysta z szyfrowania, ponieważ pakiety mogą przechodzić przez przekaźnik, który wykorzystuje szyfrowanie). Znacznik czasu: 32 bity. Znacznik czasu odzwierciedla czas próbkowania dla pierwszego oktetu w pakiecie informacyjnym RTP. Czas próbkowania musi pochodzić z timera, który zwiększa się monotonicznie i liniowo w czasie, aby zapewnić synchronizację i wykrywanie jittera (patrz rozdział 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ą „narzędzi innych niż RTP”. Jeżeli pakiety RTP są generowane okresowo, należy stosować nominalne czasy próbkowania określone 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 audio z urządzenia wejściowego odczytuje bloki zawierające 160 próbek, to znacznik czasu musi być zwiększany o 160 dla każdego takiego bloku, niezależnie od tego, czy blok został przesłany w pakiecie, czy odrzucony jako pauza. Wartość początkowa znacznika czasu, podobnie jak początkowa wartość numeru sekwencyjnego, jest wartością losową. Kilka kolejnych pakietów RTP może mieć takie same znaczniki czasu, jeśli są one logicznie generowane w tym samym czasie, np. 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 lista użytych skrótów i terminów). Ten identyfikator jest wybierany losowo, aby żadne dwa źródła zegara w tej samej sesji RTP nie miały tego samego identyfikatora SSRC. Chociaż prawdopodobieństwo, że wiele źródeł wybierze ten sam identyfikator, jest niskie, 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 pierwotny 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 źródeł przyczyniających się (CSRC) identyfikuje źródła ruchu zawartego w pakiecie do uwzględnienia. Liczbę identyfikatorów podaje 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, gdy używane są identyfikatory SSRC dla przełączanych źródeł. Na przykład w przypadku pakietów dźwiękowych identyfikatory 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 zdefiniowana przez określoną parę docelowych adresów transportowych (jeden adres sieciowy plus para portów dla RTP i RTCP). Na przykład w telekonferencji składającej się z oddzielnie zakodowanego dźwięku i obrazu każdy rodzaj ruchu musi być wysłany w oddzielnej sesji RTP z własnym docelowym adresem transportowym. Audio i wideo nie powinny być przenoszone w tej samej sesji RTP i rozdzielone na podstawie typu ruchu lub pól SSRC. Przeplatanie pakietów posiadających Różne rodzaje ruch, ale użycie tego samego SSRC spowodował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 różnią się, oraz różnych przestrzeni numerów sekwencyjnych, aby wskazać typ ruchu, z którym związana jest utrata pakietów.
Komunikaty nadawcze i odbiorcze RTCP (patrz rozdział 4.3) opisują tylko jedną wartość przedziału czasowego i przestrzeń numeru sekwencyjnego dla SSRC i nie zawierają pola typu ruchu.
Mikser RTP nie jest w stanie łączyć przeplatanych strumieni różnych typów ruchu w jeden strumień.
Następujące czynniki uniemożliwiają transmisję wielu rodzajów ruchu w jednej sesji RTP: Korzystanie z różnych ścieżki sieciowe lub przydział zasobów sieciowych; odbieranie podzbioru danych multimedialnych, gdy jest to wymagane, takich jak dźwięk tylko wtedy, gdy sygnał wideo przekroczył dostępną przepustowość; implementacje sink, które wykorzystują oddzielne procesy dla różnych typów ruchu, podczas gdy użycie oddzielnych sesji RTP pozwala na implementacje jedno- i wieloprocesowe.

Używając różnych SSRC dla każdego typu ruchu, ale wysył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 wymaga, aby każdy rodzaj ruchu korzystał z własnej sesji RTP.

3.3. Zmiany nagłówka RTP zdefiniowane w profilu

Istniejący nagłówek pakietu informacyjnego RTP jest kompletny dla zestawu funkcji wymaganych ogólnie dla wszystkich klas aplikacji, które mogą obsługiwać RTP. Jednak w celu lepszego dostosowania do określonych zadań 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 są umieszczone w stałym nagłówku, ponieważ oczekuje się, że wiele aplikacji będzie ich potrzebowało. Oktet zawierający te pola może być przedefiniowany przez profil w celu dostosowania do różnych wymagań, np. z większą lub mniejszą liczbą bitów znacznikowych. Jeśli obecne są jakiekolwiek bity znacznika, należy je umieścić w bitach wyższego rzędu oktetu, ponieważ monitory niezależne od profilu mogą być w stanie zaobserwować korelację między wzorcem utraty pakietów a bitem znacznika.

Dodatkowe informacje wymagane dla konkretnego formatu ruchu (np. typ kodowania wideo) MUSZĄ być umieszczone w polu danych pakietu. Może być umieszczony w określonym miejscu na początku lub wewnątrz tablicy danych.

Jeśli określona klasa aplikacji wymaga dodatkowej funkcjonalności niezależnej od formatu ruchu, profil, z którym te aplikacje działają, musi definiować dodatkowe stałe pola, które będą umieszczane 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 będą nadal mogły przetwarzać pakiety RTP, interpretując tylko pierwsze dwanaście oktetów.

Jeśli uważa się, że ogólnie dla wszystkich profili potrzebna jest dodatkowa funkcjonalność, wówczas nowa wersja RTP, aby na stałe zmienić tytuł.

3.4. Rozszerzenie nagłówka RTP

Aby umożliwić poszczególnym implementacjom eksperymentowanie z nowymi funkcjami niezależnymi od formatu ruchu, które wymagają przeniesienia dodatkowych informacji w nagłówku pakietu danych, protokół RTP zapewnia mechanizm rozszerzania nagłówka pakietu. Mechanizm ten został zaprojektowany tak, aby rozszerzenie nagłówka mogło zostać zignorowane przez inne współpracujące aplikacje, które go nie wymagają.

Jeśli bit X w nagłówku RTP jest ustawiony na jeden, 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 współpracujących 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 nieokreślone, pozostawione do rozróżnienia identyfikatory lub parametry. Format tych 16 bitów musi być określony przez specyfikację profilu, z którą pracują aplikacje.

1999
2000

Najbardziej palącym problemem jest coraz bardziej brak przestrzeni adresowej, co wymaga zmiany formatu adresu.

Kolejnym problemem jest niewystarczająca skalowalność procedury routingu - podstawy sieci IP. Szybki rozwój sieci powoduje przeciążenie routerów, które w dzisiejszych czasach zmuszone są do utrzymywania tablic routingu zawierających dziesiątki i setki tysięcy wpisów, a także radzenia sobie z problemami z fragmentacją pakietów. Pracę routerów można ułatwić w szczególności poprzez aktualizację protokołu IP.

Wraz z wprowadzaniem nowych funkcji bezpośrednio do protokołu IP, wskazane jest zapewnienie jego ściślejszego współdziałania z nowymi protokołami poprzez wprowadzenie nowych pól do nagłówka pakietu.

W rezultacie postanowiono poddać protokół IP modernizacji, realizując następujące główne cele:

stworzenie nowego rozszerzonego schematu adresowania;
poprawa skalowalności sieci poprzez ograniczenie funkcji routerów szkieletowych;
zapewnienie ochrony danych.

Rozszerzenie przestrzeni adresowej. Protokół IP rozwiązuje potencjalny problem braków adresowych poprzez rozszerzenie długości adresu do 128. Jednak tak znaczny wzrost długości adresu został dokonany w dużej mierze nie po to, by wyeliminować problem braków adresowych, ale by zwiększyć wydajność sieci opartych na tym protokole. Głównym celem była zmiana strukturalna systemu adresowania, rozszerzająca jego funkcjonalność.

Zamiast istniejących dwóch poziomów hierarchii adresów (numer sieci i numer hosta), IPv6 proponuje użycie czterech poziomów, co oznacza trzypoziomową identyfikację sieci i jeden poziom identyfikacji węzła.

Teraz adres jest zapisany w systemie szesnastkowym, a każde cztery cyfry są oddzielone od siebie dwukropkiem, na przykład:

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

W przypadku sieci obsługujących obie wersje protokołu IPv4 i IPv6 możliwe jest użycie tradycyjnej notacji dziesiętnej dla niższych 4 bajtów i szesnastkowej dla wyższych:

0:0:0:0:FFFF 194.135.75.104.

W ramach systemu adresowania IPv6 istnieje również wydzielona przestrzeń adresowa do użytku lokalnego, czyli dla sieci poza Internetem. Istnieją dwie odmiany adresy lokalne: dla niepodsieci „płaskich” (Link-Local) i dla podsieci (Site-Local), które różnią się wartością prefiksu.

Zmiana formatu nagłówków pakietów. Można to zrealizować za pomocą nowego schematu organizacji „nagłówków zagnieżdżonych”, który zapewnia podział nagłówka na główny, który zawiera niezbędne minimum informacji, oraz dodatkowe, których może brakować. Takie podejście otwiera bogate możliwości rozszerzania protokołu poprzez definiowanie nowych opcjonalnych nagłówków, dzięki czemu protokół jest otwarty.

Główny nagłówek datagramu IPv6 ma długość 40 bajtów i następujący format (rysunek 2.4).

Pole Klasa ruchu równoważny celowo z polem Typ usługi, a pole Limit przeskoku- pole Czas żyć Protokół IPv4.

Pole Etykieta przepływu pozwala w szczególny sposób izolować i przetwarzać poszczególne strumienie danych bez konieczności analizowania zawartości pakietów. Jest to bardzo ważne z punktu widzenia zmniejszenia obciążenia routerów.

Pole Następny nagłówek jest odpowiednikiem pola Protokół (Protokół) IPv4 i określa typ nagłówka następującego po głównym. Każdy kolejny dodatkowy nagłówek zawiera również pole Następny nagłówek.

2.3.3. Protokół TCP

Protokół kontrolny Protokół kontroli transmisji (TCP) został opracowany w celu obsługi interaktywnej komunikacji między komputerami. Protokół TCP zapewnia niezawodność i poprawność wymiany danych między procesami na komputerach będących częścią wspólnej sieci.

Niestety protokół TCP nie nadaje się do przesyłania informacji multimedialnych. Głównym powodem jest dostępność kontroli dostaw. Monitorowanie trwa zbyt długo, aby przesłać więcej informacji wrażliwych na opóźnienia. Ponadto protokół TCP zapewnia mechanizmy kontroli szybkości, aby uniknąć przeciążenia sieci. Dane audio i wideo wymagają jednak ściśle określonych przepływności, których nie można dowolnie zmieniać.

Z jednej strony protokół TCP współdziała z protokołem aplikacji niestandardowa aplikacja, a z drugiej strony protokół zapewniający „niskopoziomowe” funkcje routingu i adresowania pakietów, które z reguły są realizowane przez IP.

Logiczną strukturę oprogramowania sieciowego implementującego protokoły z rodziny TCP/IP w każdym węźle Internetu przedstawiono na ryc. 2.5.

Prostokąty reprezentują moduły przetwarzające dane, a linie łączące prostokąty reprezentują ścieżki przesyłania danych. Pozioma linia na dole rysunku wskazuje Sieć Ethernet, który jest używany jako przykład środowiska fizycznego.

Ryż. 2.5.

Aby nawiązać połączenie między dwoma procesami na różnych komputerach w sieci, konieczna jest znajomość nie tylko adresów internetowych komputerów, ale także liczby tych portów TCP (gniazd), których procesy używają na tych komputerach. Każde połączenie TCP w Internecie jest jednoznacznie identyfikowane przez dwa adresy IP i dwa numery portów TCP.

Protokół TCP może obsługiwać pakiety uszkodzone, utracone, zduplikowane lub niesprawne. Osiąga się to dzięki mechanizmowi przypisywania numeru sekwencyjnego każdemu przesyłanemu pakietowi oraz mechanizmowi sprawdzania odbioru pakietów.

Kiedy TCP przesyła segment danych, kopia tych danych jest umieszczana w kolejce retransmisji i uruchamiany jest licznik czasu potwierdzenia.

2.3.4. Protokół UDP

Protokół User Datagram Protocol (UDP) jest przeznaczony do wymiany datagramów pomiędzy procesami komputerów znajdujących się w zintegrowanym systemie sieci komputerowych.

Protokół UDP jest oparty na protokole IP i zapewnia procesom aplikacji usługi transportowe, które różnią się nieco od usług protokołu IP. Protokół UDP zapewnia niegwarantowane dostarczenie danych, tj. nie wymaga potwierdzenia ich otrzymania; dodatkowo protokół ten nie wymaga ustanowienia połączenia między źródłem a odbiorcą informacji, czyli między modułami UDP.

2.3.5. Protokoły RTP i RTCP

Podstawowe koncepcje

Protokół transportowy RTP w czasie rzeczywistym zapewnia transmisję w czasie rzeczywistym danych multimedialnych typu end-to-end, takich jak interaktywne audio i wideo. Protokół ten implementuje rozpoznawanie typu ruchu, sekwencjonowanie pakietów, znakowanie czasem i kontrolę transmisji.

Należy pamiętać, że sam RTP nie ma żadnego mechanizmu gwarantującego terminową transmisję danych i jakość usługi, ale korzysta z usług podstawowych, aby to zapewnić. Nie zapobiega pakietom poza kolejnością, ale nie zakłada, że sieć bazowa jest absolutnie niezawodna i przesyła pakiety we właściwej kolejności. Numery sekwencyjne zawarte w RTP pozwalają odbiorcy na ponowne sekwencjonowanie pakietów nadawcy.

Bloki danych protokołu RTP/RTCP nazywane są pakietami. Pakiety generowane zgodnie z protokołem RTP i służące do przesyłania danych multimedialnych nazywane są pakietami informacyjnymi lub pakietami danych (pakietami danych), a pakietami generowanymi zgodnie z protokołem RTCP i służącymi do przesyłania informacji serwisowych niezbędnych do niezawodnego działania telekonferencje nazywane są pakietami kontrolnymi lub pakietami usługowymi ( pakietami kontrolnymi ). Pakiet RTP zawiera stały nagłówek, opcjonalne rozszerzenie nagłówka o zmiennej długości oraz pole danych. Pakiet RTCP zaczyna się od części nieruchomej (podobnej do części nieruchomej) pakiety informacyjne RTP ), a następnie elementy konstrukcyjne, które mają zmienną długość.

Aby protokół RTP był bardziej elastyczny i służył do różne zastosowania, niektóre jego parametry są celowo niejasne, ale uwzględnia koncepcję profilu. Profil (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, dopełnienie nagłówka i rozszerzenia nagłówka, typy pakietów, usługi i algorytmy bezpieczeństwa komunikacji, względy dotyczące wykorzystania protokołu itp. Każda aplikacja zazwyczaj działa tylko z jednym profilem, a typ profilu ustawia się wybierając odpowiednią aplikację. Brak wyraźnego wskazania typu profilu przez numer portu, identyfikator protokołu itp.

W związku z tym pełna specyfikacja RTP dla konkretnej aplikacji musi zawierać dodatkowe dokumenty, w tym opis profilu, a także opis formatu ruchu, który definiuje, w jaki sposób określony rodzaj ruchu, taki jak audio lub wideo, będzie przetwarzany w RTP.

Grupowe konferencje audio

Grupowe konferencje audio wymagają adresu grupowego dla wielu użytkowników i dwóch portów. W takim przypadku jeden port jest wymagany do wymiany danych audio, a drugi służy do pakietów kontrolnych protokołu RTCP. Adres grupy i informacje o porcie są przekazywane potencjalnym członkom telekonferencje. Jeśli wymagana jest poufność, informacje i pakiety kontrolne mogą być szyfrowane, w takim przypadku a klucz rozproszony szyfrowanie.

W Internecie, podobnie jak w innych sieciach transmisji danych z komutacją pakietów, pakiety są czasami gubione i zmieniane w kolejności oraz opóźniane o różne okresy czasu. Aby przeciwdziałać tym zdarzeniom, nagłówek RTP zawiera znacznik czasu i numer sekwencyjny, które umożliwiają odbiornikom zmianę taktowania, tak aby na przykład fragmenty sygnału audio były odtwarzane w sposób ciągły przez głośnik co 20 ms. Ta rekonstrukcja taktowania jest wykonywana oddzielnie i niezależnie dla każdego źródła pakietów RTP w telekonferencje. Numer sekwencyjny może być również używany przez odbiornik do oszacowania liczby utraconych pakietów.

Ponieważ uczestnicy telekonferencje może dołączać i opuszczać konferencję podczas konferencji, warto wiedzieć, kto aktualnie uczestniczy w konferencji i jak dobrze uczestnicy konferencji odbierają dane audio. W tym celu każda instancja aplikacji audio podczas konferencji okresowo wysyła na port kontrolny (port RTCP) dla aplikacji wszystkich pozostałych uczestników wiadomości o odebraniu pakietów wskazujących ich nazwę 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 można również uwzględnić inne informacje identyfikacyjne służące do kontroli przepustowości. Opuszczając konferencję, strona wysyła pakiet RTCP BYE.

Wideokonferencje

Jeśli w telekonferencje wykorzystywane są zarówno sygnały audio, jak i wideo, przesyłane są oddzielnie. Dla transmisji każdego typu ruchu, niezależnie od drugiego, specyfikacja protokołu wprowadza pojęcie sesji komunikacyjnej RTP. Sesja jest zdefiniowana 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 warstwy RTP między sesjami 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 sesje były skojarzone.

Koncepcja mikserów i translatorów

Nie zawsze wszystkie witryny mają możliwość odbioru danych multimedialnych w tym samym formacie. Rozważmy przypadek, w którym uczestnicy z tej samej miejscowości są połączeni przez łącze o niskiej prędkości z większością innych uczestników konferencji, którzy mają dostęp do sieci szerokopasmowej. Zamiast zmuszać wszystkich do korzystania z węższej przepustowości i kodowania dźwięku o niższej jakości, w obszarze o niskiej przepustowości można umieścić narzędzie komunikacji w warstwie RTP zwane mikserem. Ten mikser ponownie synchronizuje przychodzące pakiety audio, aby przywrócić oryginalne interwały 20 ms, miesza te przywrócone strumienie audio w jeden strumień, wykonuje kodowanie audio o niskiej przepustowości 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 móc zapewnić prawidłowe wskazanie w odbieranych punktach końcowych źródło wiadomości, nagłówek RTP zawiera środki dla mikserów do identyfikowania źródeł zaangażowanych w tworzenie mieszanego pakietu.

Niektórzy uczestnicy konferencji audio mogą być połączeni łączami szerokopasmowymi, ale mogą nie być osiągalni za pośrednictwem grupowego połączenia konferencyjnego 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 inny rodzaj komunikacji w warstwie RTP, zwany translatorami. Z dwóch translatorów jeden jest zainstalowany poza zaporą i przekazuje wszystkie pakiety multiemisji odebrane przez bezpieczne połączenie z zewnątrz do drugiego translatora zainstalowanego za zaporą. Przekaźnik znajdujący się za zaporą ponownie rozsyła je jako pakiety multiemisji do grupy wielu użytkowników ograniczonej do sieci wewnętrznej witryny.

Protokół kontroli RTCP

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.

Protokół kontrolny RTCP (RTCP - Real-Time Control Protocol) opiera się na okresowej transmisji pakietów kierownictwo wszystkim uczestnikom sesji komunikacyjnej przy użyciu tego samego mechanizmu dystrybucji, co protokół RTP. Podstawowy protokół musi zapewniać multipleksowanie pakietów informacji i kontroli, na przykład przy użyciu różnych numerów portów UDP. Protokół RTCP spełnia cztery główne funkcje.

Główną funkcją jest zapewnienie informacja zwrotna ocena jakości dystrybucji danych. Jest to nieodłączna funkcja protokołu RTCP jako protokołu transportowego i jest związana z funkcjami kontroli przepływu i przeciążeniami innych protokołów transportowych. Informacje zwrotne mogą być bezpośrednio przydatne do zarządzania kodowaniem adaptacyjnym, ale eksperymenty z multiemisją IP wykazały, że informacje zwrotne od odbiorców są również ważne dla diagnozowania defektów dystrybucji informacji. Przesyłanie wszystkim uczestnikom raportów z informacją zwrotną na temat odbioru danych pozwala, obserwując problemy, ocenić, czy mają one charakter lokalny, czy globalny. Dzięki mechanizmowi dystrybucji IPM dla podmiotów takich jak dostawcy usług sieciowych, można również otrzymywać informacje zwrotne i działać jako zewnętrzny monitor podczas diagnozowania problemów z siecią. Ta funkcja sprzężenia zwrotnego jest zapewniana przez raporty RTCP nadawcy i odbiorcy.
Protokół RTCP utrzymuje silny identyfikator źródła danych RTP w warstwie transportowej, zwany „nazwą kanoniczną” (CNAME). Ponieważ identyfikator SSRC może się zmienić w przypadku wykrycia konfliktu lub ponownego uruchomienia programu, adresaci potrzebują kanonicznego rekordu CNAME, aby śledzić każdego członka. Odbiorcy również wymagają rekordu CNAME dla ustaw mapowanie przepływ informacji od danego uczestnika do wielu powiązanych sesji RTP, na przykład podczas synchronizacji audio i wideo.
Pierwsze dwie funkcje wymagają od wszystkich uczestników wysyłania pakietów RTCP, dlatego RTP musi regulować częstotliwość takich pakietów, aby umożliwić skalowanie liczby uczestników. Po wysłaniu przez każdego uczestnika telekonferencje pakiety kontrolne do wszystkich pozostałych uczestników, każdy może samodzielnie ocenić łączną liczbę uczestników.
Czwartą, opcjonalną cechą RTCP jest dostarczanie informacji kontroli sesji (np. identyfikacji uczestnika) do odzwierciedlenia w interfejsie użytkownika. Jest to najprawdopodobniej przydatne w sesjach „luźno zarządzanych”, w których uczestnicy dołączają do grupy i opuszczają ją bez kontroli członkostwa lub negocjacji parametrów.

Funkcje od pierwszego do trzeciego są obowiązkowe, gdy RTP jest używany w multiemisji IP, i zalecane we wszystkich innych przypadkach. Zachęcamy twórców aplikacji RTP do unikania mechanizmów, które są tylko dwukierunkowe i nie skalują się w celu zwiększenia liczby użytkowników.

Szybkość pakietów RTCP

Protokół RTP pozwala aplikacji na automatyczne skalowanie reprezentatywności sesji komunikacyjnej od kilku uczestników do kilku tysięcy. Na przykład w konferencji audio ruch danych jest zasadniczo samoograniczający się, ponieważ tylko jedna lub dwie osoby mogą jednocześnie rozmawiać, aw dystrybucji multiemisji szybkość transmisji danych na dowolnym łączu pozostaje względnie stała, niezależnie od liczby uczestników. Jednak ruch kontrolny nie ogranicza się samoczynnie. Jeżeli raporty odbiorcze od każdego uczestnika będą wysyłane ze stałą szybkością, to ruch kontrolny będzie wzrastał liniowo wraz ze wzrostem liczby uczestników. Dlatego należy zapewnić specjalny mechanizm zmniejszający częstotliwość przesyłania pakietów kontrolnych.

Zakłada się, że dla każdej sesji ruch danych spełnia zagregowany limit, zwany przepustowością sesji, który jest współdzielony przez wszystkich uczestników. Ta przepustowość może być zarezerwowana, a jej limit jest ustalany przez sieć. Przepustowość sesji jest niezależna od typu kodowania mediów, ale wybór typu kodowania może być ograniczony przez przepustowość sesji. Oczekuje się, że ustawienie przepustowości sesji będzie dostarczane przez aplikację do zarządzania sesją, gdy wywołuje ona aplikację multimedialną, ale aplikacje multimedialne mogą również ustawiać wartość domyślną w oparciu o przepustowość danych pojedynczego nadawcy dla typu kodowania wybranego dla danej sesji.

Obliczenia przepustowości dla kontroli i ruchu danych są wykonywane z uwzględnieniem podstawowych protokołów warstwy transportowej i sieci (np. UDP i IP). Nagłówki warstwy łącza danych (DLH) nie są uwzględniane w obliczeniach, ponieważ pakiet może być obudowany różnymi nagłówkami DLL podczas transmisji.

Ruch kontrolny powinien być ograniczony do małej i znanej części przepustowości sesji: na tyle małej, aby nie wpływała na główną funkcję protokołu transportowego - transmisję danych; wiadomo, że ruch kontrolny może być uwzględniony w specyfikacji przepustowości podanej protokołowi rezerwacja zasobów i tak, aby każdy uczestnik mógł samodzielnie obliczyć swój udział. Zakłada się, że część przepustowości sesji przydzielona do RTCP powinna być ustawiona na 5%. Wszyscy uczestnicy sesji muszą korzystać z tej samej przepustowości RTCP, aby obliczone wartości interwału transmisji pakietu kontrolnego były takie same. Dlatego te stałe muszą być ustawione dla każdego profilu.

Algorytm obliczania odstępu czasu pomiędzy wysyłaniem pakietów wieloczęściowych RTCP do podziału między uczestników pasma przydzielonego dla ruchu kontrolnego ma następujące główne cechy:

nadawcy wspólnie wykorzystują co najmniej 1/4 przepustowości ruchu kontrolnego, tak jak w sesjach z dużą liczbą odbiorców, ale z niewielką liczbą nadawców; natychmiast po nawiązaniu połączenia uczestnicy otrzymują w krótkim czasie CNAME witryn nadających;
szacowany odstęp między pakietami RTCP musi wynosić co najmniej 5 sekund, aby uniknąć serii pakietów RTCP przekraczających dozwoloną przepustowość, gdy liczba uczestników jest mała, a ruch nie jest wygładzany zgodnie z prawem dużych liczb;
odstęp między pakietami RTCP zmienia się losowo od połowy do półtora obliczonych odstępów, aby uniknąć niezamierzonej synchronizacji wszystkich uczestników. Pierwszy pakiet RTCP wysłany po wejściu w sesję jest również losowo opóźniany (do połowy minimalnego interwału RTCP) w przypadku uruchomienia aplikacji w wielu lokalizacjach w tym samym czasie, na przykład podczas ogłaszania rozpoczęcia sesji;
aby automatycznie dostosować się do zmian w ilości przesyłanych informacji sterujących, dynamiczne oszacowanie średniego rozmiaru złożonego pakietu RTCP jest obliczane przy użyciu wszystkich odebranych i wysłanych pakietów;
ten algorytm może być używany do sesji, w których transmisja pakietowa jest dozwolona dla wszystkich uczestników. W takim przypadku parametr przepustowości sesji jest iloczynem przepustowości indywidualnego nadawcy pomnożonej przez liczbę uczestników, a przepustowość RTP opiera się na protokole bazowym i zapewnia wskazanie długości. Maksymalna długość pakietów RTP jest ograniczona tylko protokołami niższych warstw.
Wiele pakietów protokołu RTP może być wysyłanych w jednej podstawowej jednostce danych protokołu, takiej jak pakiet UDP. Zmniejsza to nadmiarowość nagłówków i upraszcza synchronizację między różnymi strumieniami.

Kiedy rozmawiając przez telefon IP słyszymy głos rozmówcy w odbiorniku lub za pomocą systemu wideokonferencyjnego komunikujemy się z kolegami i bliskimi, wymieniamy ciągły strumień danych. Podczas przesyłania danych strumieniowych, takich jak głos i obraz przez sieć pakietową, bardzo ważne jest zastosowanie mechanizmów, które rozwiążą następujące zadania:

Wyeliminuj efekt utraty pakietów
Przywracanie zamówień i kontrola pakietów
Opóźnienie wygładzania (jitter)

W tym celu został opracowany RTP(Real-time Transport Protocol) to protokół transmisji w czasie rzeczywistym, który zostanie omówiony w dzisiejszym artykule. Protokół został opracowany przez IETF przez Grupę Roboczą ds. Transportu Audio-Video i jest opisany w RFC 3550.

Z reguły RTP działa na szczycie protokołu UDP (User Datagram Protocol), ponieważ podczas przesyłania danych multimedialnych bardzo ważne jest zapewnienie ich terminowej dostawy.

RTP obejmuje możliwość określenia typu ładunku i przypisania numeru sekwencyjnego pakietu w strumieniu, a także wykorzystanie znaczników czasu.

Po stronie nadawczej każdy pakiet jest oznaczony znacznikiem czasu, strona odbierająca go odbiera i określa całkowite opóźnienie, po czym obliczana jest różnica w całkowitych opóźnieniach i określany jest jitter. W ten sposób staje się możliwe ustawienie stałego opóźnienia w dostarczaniu pakietów, a tym samym zmniejszenie efektu fluktuacji.

Kolejna funkcja RTP związana jest z możliwą utratą pakietów podczas przechodzenia przez sieć IP, co wyraża się pojawieniem się krótkich przerw w rozmowie. Nagła cisza w słuchawce z reguły bardzo negatywnie oddziałuje na słuchacza, dlatego przy możliwościach protokołu RTP takie okresy ciszy wypełniane są tzw.

RTP działa w połączeniu z innym protokołem IETF, mianowicie RTCP (Real-time Transport Control Protocol), który jest opisany w RFC 3550. RTCP jest przeznaczony do zbierania informacji statystycznych, określania jakości usług QoS (Quality of Service), a także do synchronizować strumienie multimediów sesji RTP.

Główną funkcją RTCP jest uzyskiwanie informacji zwrotnej z aplikacją w celu raportowania jakości otrzymanych informacji. Uczestnicy sesji RTCP wymieniają informacje o liczbie odebranych i utraconych pakietów, wartości jittera, opóźnieniu itp. Na podstawie analizy tych informacji podejmowana jest decyzja o zmianie parametrów transmisji, np. o zmniejszeniu stopnia kompresji informacji w celu poprawy jakości jej transmisji.

Aby wykonać te funkcje, RTCP wysyła specjalne wiadomości określonego typu:

SR - Sender Report - raport źródłowy z informacjami statystycznymi o sesji RTP
RR - Receiver Report - raport odbiorcy z informacjami statystycznymi o sesji RTP
SDES - zawiera opis opcji źródła, w tym cname (nazwa użytkownika)
ŻEGNAJ – Inicjuje koniec członkostwa w grupie
APLIKACJA - Opis funkcji aplikacji

RTP jest protokołem jednokierunkowym, więc komunikacja dwukierunkowa wymaga dwóch sesji RTP, po jednej z każdej strony.

Sesję RTP określają adresy IP uczestników, a także para niezarezerwowanych portów UDP z zakresu 16384 – 32767. Dodatkowo w celu uporządkowania informacji zwrotnej z aplikacją konieczne jest również ustanowienie dwu- sposób sesji RTCP. W przypadku sesji RTCP zajęte są porty o numerze jeden większym niż RTP. Na przykład, jeśli port 19554 jest wybrany dla RTP, sesja RTCP przyjmie port 19555. Wizualnie tworzenie sesji RTP/RTCP pokazano na poniższym rysunku.

Jeśli pewnego dnia będziesz musiał pochopnie dowiedz się, czym jest VoIP (voice over IP) i co oznaczają te wszystkie dzikie skróty, mam nadzieję, że ta instrukcja pomoże. Od razu zauważę, że kwestie konfiguracji dodatkowych rodzajów usług telefonicznych (takich jak przekazywanie połączeń, poczta głosowa, połączenia konferencyjne itp.) nie są tutaj brane pod uwagę.

Czyli czym zajmiemy się pod cięciem:

Podstawowe pojęcia telefonii: rodzaje urządzeń, schematy połączeń
Pakiet protokołów SIP/SDP/RTP: jak to działa
W jaki sposób przekazywane są informacje o wciśniętych przyciskach
Jak działa transmisja głosu i faksu?
Cyfrowe przetwarzanie sygnału i zapewnienie jakości dźwięku w telefonii IP

1. Podstawowe pojęcia telefonii

Ogólnie schemat łączenia abonenta lokalnego z operatorem telefonicznym za pośrednictwem zwykłej linii telefonicznej jest następujący:

Po stronie dostawcy (PBX) zainstalowany jest moduł telefoniczny z portem FXS (Foreign eXchange Subscriber). W domu lub biurze zainstalowany jest telefon lub faks z portem FXO (Foreign eXchange Office) i modułem dialera.

Za pomocą wygląd zewnętrzny Porty FXS i FXO nie różnią się od siebie, są to zwykłe 6-pinowe złącza RJ11. Ale używając woltomierza bardzo łatwo je rozróżnić - na porcie FXS zawsze będzie jakieś napięcie: 48/60 V, gdy słuchawka jest odłożona, lub 6-15 V podczas rozmowy. W FXO, jeśli nie jest podłączony do linii, napięcie zawsze wynosi 0.

Do przesyłania danych przez linię telefoniczną potrzebna jest dodatkowa logika po stronie dostawcy, którą można zaimplementować w module SLIC (subscriber line interface circuit), a po stronie abonenta – za pomocą modułu DAA (Direct Access Arrangement).

Bezprzewodowe telefony DECT (Digital European Cordless Telecommunications) są teraz dość popularne. Pod względem urządzenia są podobne do konwencjonalnych telefonów: mają również port FXO i moduł dialera, ale dodano również stację bezprzewodową i moduł słuchawki na częstotliwości 1,9 GHz.

Abonenci są podłączani do sieci PSTN (Public Switched Telephone Network) – sieci telefonicznej powszechne zastosowanie, ona jest PSTN, PSTN. Sieć PSTN może być zorganizowana przy użyciu różnych technologii: ISDN, optyka, POTS, Ethernet. Szczególny przypadek PSTN, gdy używana jest zwykła linia analogowa/miedziana - POTS (Plain Old Telephone Service) - prosty stary system telefoniczny.

Wraz z rozwojem Internetu komunikacja telefoniczna przeniósł się na nowy poziom. Telefony stacjonarne są coraz rzadziej używane, głównie na potrzeby urzędowe. Telefony DECT są nieco wygodniejsze, ale ograniczają się do obwodu domu. Telefony GSM są jeszcze wygodniejsze, ale ograniczają je granice kraju (roaming jest drogi). Ale dla telefonów IP są to również softphone (SoftPhone), nie ma żadnych ograniczeń, poza dostępem do Internetu.

Skype jest najbardziej znanym przykładem telefonu programowego. Potrafi wiele rzeczy, ale ma dwie ważne wady: zamkniętą architekturę i podsłuchy są znane przez władze. Z powodu pierwszego nie ma możliwości stworzenia własnej mikrosieci telefonicznej. A z drugiej strony - szpiegowanie nie jest przyjemne, zwłaszcza w rozmowach osobistych i handlowych.

Na szczęście istnieją otwarte protokoły do tworzenia własnych sieci komunikacyjnych z bajerami - są to SIP i H.323. W protokole SIP jest o kilka więcej softfonów niż w H.323, co można wytłumaczyć jego względną prostotą i elastycznością. Ale czasami ta elastyczność może wbić duży kij w koło. Zarówno protokoły SIP, jak i H.323 używają protokołu RTP do przesyłania danych multimedialnych.

Rozważ podstawowe zasady protokołu SIP, aby zrozumieć, w jaki sposób łączy się dwóch abonentów.

2. Opis pakietu protokołów SIP/SDP/RTP

SIP (Session Initiation Protocol) - protokół do nawiązywania sesji (nie tylko telefonicznej) to protokół tekstowy przez UDP. Możliwe jest również użycie SIP przez TCP, ale są to rzadkie przypadki.

SDP (Session Description Protocol) to protokół do negocjacji rodzaju przesyłanych danych (dla dźwięku i obrazu są to kodeki i ich formaty, dla faksów prędkość transmisji i korekcja błędów) oraz ich adresy docelowe (IP i port). Jest to również protokół tekstowy. Parametry SDP są wysyłane w treści pakietów SIP.

RTP (Real-time Transport Protocol) to protokół przesyłania danych audio/wideo. Jest to protokół binarny przez UDP.

Ogólna struktura pakietów SIP:

Start-Line: Pole wskazujące metodę SIP (polecenie) na żądanie lub wynik wykonania metody SIP podczas odpowiadania.
Nagłówki: dodatkowe informacje do wiersza startowego, sformatowane jako ciągi zawierające pary ATRYBUT: WARTOŚĆ.
Treść: dane binarne lub tekstowe. Zwykle używany do wysyłania parametrów lub komunikatów SDP.

Oto przykład dwóch pakietów SIP dla jednej wspólnej procedury konfiguracji połączenia:

Po lewej stronie znajduje się zawartość pakietu SIP INVITE, po prawej odpowiedź na nią - SIP 200 OK.

Główne pola są oprawione:

Method/Request-URI zawiera metodę SIP i URI. W przykładzie nawiązywana jest sesja - metoda INVITE, abonent jest wywoływany [e-mail chroniony]
Status-Code - kod odpowiedzi na poprzednią komendę SIP. W tym przykładzie polecenie zostało zakończone pomyślnie - kod 200, czyli Abonent 555 odebrał telefon.
Via - adres, pod którym abonent 777 czeka na odpowiedź. Dla wiadomości 200 OK to pole jest kopiowane z wiadomości INVITE.
Od/Do — wyświetlana nazwa i adres nadawcy i odbiorcy wiadomości. Dla wiadomości 200 OK to pole jest kopiowane z wiadomości INVITE.
Cseq zawiera numer sekwencji polecenia oraz nazwę metody, do której odnosi się dana wiadomość. Dla wiadomości 200 OK to pole jest kopiowane z wiadomości INVITE.
Content-Type - typ danych przesyłanych w bloku treści, w tym przypadku dane SDP.
Connection Information - adres IP, na który drugi abonent musi wysłać pakiety RTP (lub pakiety UDPTL w przypadku transmisji faksu przez T.38).
Opis mediów - port, na który drugi abonent musi przesłać określone dane. W tym przypadku są to audio (audio RTP/AVP) oraz lista obsługiwanych typów danych - PCMU, PCMA, kodeki GSM i sygnały DTMF.

Wiadomość SDP składa się z linii zawierających pary FIELD=VALUE. Główne pola to:

o- Pochodzenie, nazwa organizatora sesji i identyfikator sesji.
z- Informacje o połączeniu, pole zostało opisane wcześniej.
m- Opis nośnika, pole opisane wcześniej.
a- atrybuty mediów, określają format przesyłanych danych. Na przykład wskazują kierunek dźwięku - odbiór lub nadawanie (sendrecv), dla kodeków wskazują częstotliwość próbkowania i numer powiązania (rtpmap).

Pakiety RTP zawierają dane audio/wideo zakodowane w określonym formacie. Ten format określony w polu PT (typ ładunku). Tabela przedstawiająca, w jaki sposób wartość tego pola odpowiada określonemu formatowi, znajduje się w https://wikipedia org wiki profil audio-wideo RTP .

Pakiety RTP zawierają również unikalny identyfikator SSRC (określa źródło strumienia RTP) oraz znacznik czasu (znacznik czasu, używany do równomiernego odtwarzania dźwięku lub obrazu).

Przykład interakcji między dwoma abonentami SIP za pośrednictwem serwera SIP (Asterisk):

Jak tylko telefon SIP zostanie uruchomiony, pierwszą rzeczą, jaką robi, jest rejestracja na zdalnym serwerze (SIP Registar), wysłanie mu wiadomości SIP REGISTER.

Podczas dzwonienia do abonenta wysyłana jest wiadomość SIP INVITE, której treść zawiera wiadomość SDP zawierającą parametry transmisji audio/wideo (jakie kodeki są obsługiwane, na jaki adres IP i port wysłać audio itp.).

Gdy zdalny abonent odbierze telefon, otrzymujemy wiadomość SIP 200 OK również z parametrami SDP, tylko zdalny abonent. Korzystając z wysłanych i odebranych parametrów SDP, można skonfigurować sesję audio/wideo RTP lub sesję faksu T.38.

Jeśli otrzymane parametry SDP nam nie odpowiadały lub pośredni serwer SIP zdecydował się nie przepuszczać przez siebie ruchu RTP, to wykonywana jest procedura renegocjacji SDP, tzw. REINVITE. Nawiasem mówiąc, właśnie z powodu tej procedury bezpłatne serwery proxy SIP mają jedną wadę - jeśli obaj subskrybenci znajdują się w tej samej sieci lokalnej, a serwer proxy znajduje się za NAT, to po przekierowaniu ruchu RTP żaden z subskrybentów nie usłyszy jeszcze jeden.

Po zakończeniu rozmowy abonent, który się rozłączył, wysyła wiadomość SIP BYE.

3. Przekazywanie informacji o wciśniętych przyciskach

Niekiedy po nawiązaniu sesji w trakcie połączenia wymagany jest dostęp do usług dodatkowych (VAS) – wstrzymanie połączenia, transfer, poczta głosowa itp. - które reagują na określone kombinacje wciskanych przycisków.

Tak więc na zwykłej linii telefonicznej są dwa sposoby wybierania numeru:

Pulse - historycznie pierwszy, stosowany był głównie w telefonach z dialerem obrotowym. Wybieranie następuje w wyniku sekwencyjnego zamykania i otwierania linii telefonicznej zgodnie z wybraną cyfrą.
Tonowe - wybieranie za pomocą kodów DTMF (Dual-Tone Multi-Frequency) - każdy przycisk telefonu ma swoją kombinację dwóch sygnałów sinusoidalnych (tonów). Wykonując algorytm Goertzela, dość łatwo jest określić wciśnięty przycisk.

Podczas rozmowy metoda impulsowa jest niewygodna w przekazywaniu wciśniętego przycisku. Tak więc przesłanie „0” zajmuje około 1 sekundy (10 impulsów po 100 ms każdy: 60 ms – przerwanie linii, 40 ms – zamknięcie linii) plus 200 ms na przerwę między cyframi. Ponadto podczas wybierania impulsowego często słychać charakterystyczne kliknięcia. Dlatego w telefonii konwencjonalnej używany jest tylko tonowy tryb dostępu do VAS.

W telefonii VoIP informacje o naciśniętych przyciskach można przekazać na trzy sposoby:

DTMF Inband - generowanie tonu audio i przesyłanie go wewnątrz danych audio (bieżący kanał RTP) to normalne wybieranie tonowe.
RFC2833 - generowany jest specjalny pakiet RTP zdarzenia telefonicznego, który zawiera informacje o naciśniętym klawiszu, głośności i czasie trwania. Numer formatu RTP, w którym pakiety RFC2833 DTMF będą transmitowane, jest określony w treści wiadomości SDP. Na przykład: a=rtpmap:98 telefon-zdarzenie/8000.
SIP INFO - tworzony jest pakiet SIP INFO z informacjami o naciśniętym klawiszu, głośności i czasie trwania.

Transmisja DTMF wewnątrz danych audio (Inband) ma kilka wad - są to zasoby narzutowe podczas generowania/osadzania tonów i ich wykrywania, ograniczenia niektórych kodeków, które mogą zniekształcać kody DTMF oraz słaba niezawodność transmisji (jeśli część pakietów zostanie utracona, to może nastąpić dwukrotne naciśnięcie tego samego klawisza).

Główna różnica między DTMF RFC2833 a SIP INFO: jeśli serwer proxy SIP ma możliwość bezpośredniego przesyłania RTP między abonentami z pominięciem samego serwera (np. canreinvite=yes w gwiazdki), to serwer nie zauważy pakietów RFC2833, jako w wyniku czego usługi VAS stają się niedostępne. Pakiety SIP są zawsze przesyłane przez serwery proxy SIP, więc VAS zawsze będzie działać.

4. Transmisja głosu i faksu

Jak już wspomniano, do przesyłania danych multimedialnych wykorzystywany jest protokół RTP. Pakiety RTP zawsze określają format przesyłanych danych (kodek).

Istnieje wiele różnych kodeków do transmisji głosu, z różnymi współczynnikami bitrate/jakość/złożoność, są otwarte i zamknięte. Każdy softphone musi obsługiwać kodeki G.711 alaw/ulaw, ich implementacja jest bardzo prosta, jakość dźwięku nie jest zła, ale wymagają przepustowości 64 kbps. Na przykład kodek G.729 wymaga tylko 8 kb/s, ale bardzo obciąża procesor i nie jest darmowy.

Do transmisji faksów zwykle używany jest kodek G.711 lub protokół T.38. Transmisja faksu przy użyciu kodeka G.711 odpowiada transmisji faksu przy użyciu protokołu T.30, tak jakby faks był przesyłany zwykłą linią telefoniczną, ale sygnał analogowy z linii jest digitalizowany zgodnie z prawem alaw/ulaw. Jest to również nazywane faksowaniem Inband T.30.

Faksy korzystające z protokołu T.30 negocjują swoje parametry: prędkość transmisji, rozmiar datagramu, rodzaj korekcji błędów. Protokół T.38 bazuje na protokole T.30, ale w przeciwieństwie do transmisji Inband, generowane i odbierane polecenia T.30 są analizowane. W ten sposób przesyłane są nie surowe dane, ale rozpoznane polecenia sterujące faksem.

Polecenie T.38 jest przesyłane przy użyciu protokołu UDPTL, który jest protokołem opartym na UDP i jest używany tylko dla T.38. Protokoły TCP i RTP mogą być również używane do przesyłania poleceń T.38, ale są one używane znacznie rzadziej.

Główne zalety T.38 to mniejsze obciążenie sieci i większa niezawodność w porównaniu z transmisją faksów przychodzących.

Procedura wysyłania faksu w trybie T.38 wygląda następująco:

Normalne połączenie głosowe jest nawiązywane przy użyciu dowolnego kodeka.
Gdy papier jest załadowany do faksu wysyłającego, co jakiś czas wysyła sygnał T.30 CNG (sygnał wywołania), aby wskazać, że jest gotowy do wysłania faksu.
Po stronie odbiorczej generowany jest sygnał T.30 CED (identyfikacja wywoływanego terminala) - jest to gotowość do odbioru faksu. Sygnał ten jest wysyłany albo po naciśnięciu przycisku „Odbierz faks” albo faks robi to automatycznie.
Sygnał CED jest wykrywany po stronie nadawczej i następuje procedura SIP REINVITE, a typ T.38 jest wskazywany w komunikacie SDP: m=image 39164 udptl t38.

Wysyłanie faksów przez Internet najlepiej w T.38. Jeśli faks musi być przesłany w biurze lub między obiektami, które mają stabilne połączenie, można zastosować transmisję faksu Inband T.30. W takim przypadku przed wysłaniem faksu należy wyłączyć procedurę usuwania echa, aby nie wprowadzać dodatkowych zniekształceń.

Bardzo szczegółowe informacje na temat faksowania znajdują się w książce „Fax, Modem and Text for IP Telephony” Davida Hanesa i Gonzalo Salgueiro.

5. Cyfrowe przetwarzanie sygnału (DSP). Zapewnienie jakości dźwięku w telefonii IP, przykłady testowe

Zajmowaliśmy się protokołami nawiązywania sesji konwersacyjnej (SIP/SDP) oraz sposobem przesyłania dźwięku kanałem RTP. Było jedno ważne pytanie – jakość dźwięku. Z jednej strony o jakości dźwięku decyduje wybrany kodek. Ale z drugiej strony nadal potrzebne są dodatkowe procedury DSP (DSP - cyfrowe przetwarzanie sygnału). Procedury te uwzględniają specyfikę telefonii VoIP: nie zawsze używany jest wysokiej jakości zestaw słuchawkowy, w Internecie występują zrzuty pakietów, czasami pakiety docierają nierównomiernie, przepustowość sieci również nie jest gumowa.

Podstawowe procedury poprawiające jakość dźwięku:

VAD(Wykrywacz aktywności głosu) – procedura wyznaczania ramek zawierających głos (aktywna ramka głosu) lub ciszę (nieaktywna ramka głosu). Ta separacja może znacznie zmniejszyć obciążenie sieci, ponieważ transmisja informacji o ciszy wymaga znacznie mniej danych (wystarczy przesłać poziom szumu lub w ogóle nic).

Niektóre kodeki zawierają już procedury VAD (GSM, G.729), podczas gdy inne (G.711, G.722, G.726) wymagają ich implementacji.

Jeśli VAD jest skonfigurowany do przesyłania informacji o poziomie szumu, wtedy specjalne pakiety SID (Silence Insertion Descriptor) są przesyłane w 13. formacie RTP CN (Comfort Noise).

Warto zauważyć, że pakiety SID mogą być odrzucane przez serwery proxy SIP, dlatego do weryfikacji wskazane jest skonfigurowanie transmisji ruchu RTP przez serwery SIP.

CNG(generowanie szumu komfortu) – procedura generowania szumu komfortu na podstawie informacji z pakietów SID. Tak więc VAD i CNG współpracują ze sobą, ale procedura CNG jest znacznie mniej pożądana, ponieważ nie zawsze można zauważyć pracę CNG, szczególnie przy niskich wolumenach.

PLC(ukrywanie utraty pakietów) - procedura przywracania strumienia audio w przypadku utraty pakietów. Nawet przy 50% utracie pakietów dobry algorytm PLC może osiągnąć akceptowalną jakość mowy. Oczywiście będą zniekształcenia, ale możesz rozróżnić słowa.

Najłatwiejszym sposobem emulowania utraty pakietów (w systemie Linux) jest użycie narzędzia tc z pakietu iproute z modułem netem. Realizuje jedynie kształtowanie ruchu wychodzącego.

Przykład uruchomienia emulacji sieci z 50% utratą pakietów:

Tc qdisc change dev eth1 utrata root netem 50%

Wyłącz emulację:

Tc qdisc del dev eth1 root

bufor jittera- procedura pozbycia się efektu jittera, kiedy odstępy pomiędzy odbieranymi pakietami bardzo się zmieniają, co w najgorszym przypadku prowadzi do nieprawidłowej kolejności odbieranych pakietów. Efekt ten prowadzi również do przerw w mowie. Aby wyeliminować efekt jittera, konieczne jest zaimplementowanie po stronie odbiorczej bufora pakietów o rozmiarze wystarczającym do przywrócenia pierwotnej kolejności wysyłania pakietów w zadanym interwale.

Możesz również emulować efekt jittera za pomocą narzędzia tc (odstęp między oczekiwanym momentem przybycia pakietu a rzeczywistym momentem może wynosić do 500 ms):

tc qdisc add dev eth1 root netem opóźnienie 500 ms zmiana kolejności 99%

LE C(Line Echo Canceller) – procedura eliminowania lokalnego echa, gdy zdalny abonent zaczyna słyszeć własny głos. Jego istotą jest odjęcie odbieranego sygnału od nadawanego sygnału o określonym współczynniku.

Echa mogą wystąpić z kilku powodów:

echo akustyczne z powodu słabej jakości ścieżki audio (dźwięk z głośnika wchodzi do mikrofonu);
echo elektryczne spowodowane niedopasowaniem impedancji między telefonem a modułem SLIC. W większości przypadków ma to miejsce w obwodach, które przekształcają 4-przewodową linię telefoniczną w 2-przewodową.

Ustalenie przyczyny (echo akustyczne lub elektryczne) nie jest trudne: abonent, po którego stronie powstaje echo, musi wyłączyć mikrofon. Jeśli echo nadal występuje, oznacza to, że jest elektryczne.

Aby uzyskać więcej informacji na temat procedur VoIP i DSP, zobacz Przetwarzanie sygnału VoIP i faksu. Podgląd jest dostępny w Książkach Google.

To kończy powierzchowny teoretyczny przegląd VoIP. Jeśli jesteś zainteresowany, to przykład praktyczne wdrożenie PBX na prawdziwej platformie sprzętowej można omówić w następnym artykule.

[!?] Pytania i komentarze mile widziane. Odpowie im autor artykułu Dmitry Valento, inżynier oprogramowania w centrum projektowania elektroniki Promwad.

Tagi:

dla początkujących
dla początkujących

Dodaj tagi

protokoły RTP i RSVP,

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

Nowoczesne aplikacje nie tolerują opóźnień przychodzących ich pakietów. Dwa protokoły (RTP i PSVP) zapewniają terminową dostawę z jakością usług.

Ciągły rozwój Internetu i sieci prywatnych stawia nowe wymagania dotyczące przepustowości. Aplikacje klient-serwer znacznie przewyższają Telnet pod względem ilości przesyłanych danych. Sieć WWW doprowadziła do gigantycznego wzrostu graficznego wykresu informacyjnego. Ponadto, obecnie aplikacje głosowe i wideo stawiają własne specyficzne wymagania dla i tak już przeciążonych sieci.

Aby spełnić wszystkie te wymagania, jeden wzrost przepustowości sieci nie wystarczy. To, co jest naprawdę potrzebne, to inteligentne, wydajne metody zarządzania harmonogramem i kontroli obciążenia pracą.

W przeszłości sieci oparte na protokole IP zapewniały wszystkim aplikacjom tylko najprostszą możliwą usługę dostarczania danych. Jednak z biegiem czasu potrzeby się zmieniły. Organizacje, które wydały miliony dolarów na instalację sieci danych opartej na protokole IP między sieciami lokalnymi, przekonują się obecnie, że takie konfiguracje nie są w stanie efektywnie obsługiwać nowych aplikacji multimedialnych działających w czasie rzeczywistym w trybie multiemisji.

ATM jest jedyną technologią sieciową, która została pierwotnie zaprojektowana do obsługi normalnego ruchu TCP i UDP wraz z ruchem w czasie rzeczywistym. Jednak przejście na ATM oznacza albo stworzenie nowej infrastruktury sieciowej dla ruchu w czasie rzeczywistym, albo zastąpienie istniejącej konfiguracji opartej na IP, które są bardzo kosztowne.

Dlatego bardzo pilna jest potrzeba obsługi wielu typów ruchu o różnych wymaganiach dotyczących jakości usług w ramach architektury TCP/IP. Aby rozwiązać ten problem, zaprojektowano dwa kluczowe narzędzia: protokół transportu w czasie rzeczywistym (RTP) i protokół rezerwacji zasobów (RSVP).

RTP gwarantuje dostarczenie danych do jednego lub więcej miejsc docelowych z opóźnieniem w określonych granicach. Oznacza to, że dane mogą być odtwarzane w czasie rzeczywistym. RSVP umożliwia systemom końcowym rezerwowanie zasobów sieciowych w celu uzyskania wymaganej jakości usług, zwłaszcza zasobów dla ruchu w czasie rzeczywistym za pośrednictwem protokołu RTP.

Najczęściej używanym protokołem warstwy transportowej jest TCP. Chociaż protokół TCP może obsługiwać szeroką gamę aplikacji rozproszonych, nie nadaje się do aplikacji czasu rzeczywistego.

W aplikacjach czasu rzeczywistego nadawca generuje strumień danych ze stałą szybkością, a odbiorca (odbiorcy) musi dostarczać te dane do aplikacji z tą samą szybkością. Takie aplikacje obejmują konferencje audio i wideo, dystrybucję wideo na żywo (do natychmiastowego odtwarzania), współdzielone obszary robocze, zdalną diagnostykę medyczną, telefonię komputerową, rozproszoną symulację interaktywną, gry i monitorowanie w czasie rzeczywistym.

Używanie TCP jako protokołu transportowego dla tych aplikacji nie jest możliwe z kilku powodów. Po pierwsze, ten protokół umożliwia połączenie tylko między dwoma punktami końcowymi i dlatego nie nadaje się do multiemisji. Zapewnia retransmisję utraconych segmentów w momencie, gdy aplikacja czasu rzeczywistego już na nie nie czeka. Ponadto TCP nie ma wygodnego mechanizmu kojarzenia informacji o taktowaniu z segmentami, co jest również wymagane w przypadku aplikacji czasu rzeczywistego.

Kolejny szeroko stosowany protokół warstwy transportowej, UDP, nie ma dwóch pierwszych

ograniczenia (połączenie punkt-punkt i transmisja utraconych segmentów), ale nie zapewnia krytycznych informacji o synchronizacji. Więc sam UDP nie ma żadnych narzędzi ogólny cel do zastosowań w czasie rzeczywistym.

Chociaż każda aplikacja działająca w czasie rzeczywistym może mieć własne mechanizmy obsługi transmisji w czasie rzeczywistym, mają one wiele wspólnych cech, które sprawiają, że zdefiniowanie jednego protokołu jest bardzo pożądane. Standardowym protokołem tego rodzaju jest RTP, zdefiniowany w RFC 1889.

W typowym środowisku czasu rzeczywistego nadawca generuje pakiety ze stałą szybkością. Są one do nich wysyłane w regularnych odstępach czasu, podróżują przez sieć i są odbierane przez odbiorcę, który odtwarza dane w czasie rzeczywistym, tak jak są odbierane.

Jednak ze względu na różnice w opóźnieniach, gdy pakiety przemieszczają się w sieci, docierają one w nieregularnych odstępach czasu. Aby zrekompensować ten efekt, przychodzące pakiety są buforowane, przetrzymywane przez chwilę, a następnie dostarczane ze stałą szybkością. oprogramowanie Ten, który generuje dane wyjściowe. Aby ten schemat działał, każdy pakiet jest oznaczony znacznikiem czasu, dzięki czemu odbiorca może odtworzyć przychodzące dane z taką samą prędkością, jak nadawca.

RTP obsługuje przesyłanie danych w czasie rzeczywistym między wieloma uczestnikami sesji. (Sesja to logiczna relacja między dwoma lub większą liczbą użytkowników RTP, która jest utrzymywana przez czas przesyłania danych. Proces otwierania sesji wykracza poza zakres RTP.)

Chociaż RTP może być również używany do emisji pojedynczej w czasie rzeczywistym, jego siła tkwi w obsłudze multiemisji. W tym celu każdy blok danych RTP zawiera identyfikator nadawcy wskazujący, który uczestnik generuje dane. Bloki danych RTP zawierają również znacznik czasu, dzięki czemu dane mogą być odtwarzane w odpowiednich odstępach czasu przez odbiorcę.

Ponadto RTP definiuje format ładunku przesyłanych danych. Bezpośrednio z tym związana jest koncepcja synchronizacji, za którą częściowo odpowiada mikser – mechanizm translacji RTP. Po otrzymaniu strumieni pakietów RTP z jednego lub więcej źródeł łączy je i wysyła nowy strumień pakietów RTP do jednego lub więcej odbiorców. Mikser może po prostu łączyć dane, a także zmieniać ich format.

Przykład aplikacji miksera — łączenie wielu źródeł dźwięku. Załóżmy na przykład, że niektóre systemy w danej sesji audio generują swój własny strumień RTP. Przez większość czasu aktywne jest tylko jedno źródło, chociaż czasami „rozmawia” kilka źródeł jednocześnie.

Jeśli nowy system chce uczestniczyć w sesji, ale jego łącze do sieci nie ma wystarczającej przepustowości, aby obsłużyć wszystkie strumienie RTP, wówczas mikser odbiera wszystkie te strumienie, łączy je w jeden i przekazuje ostatni nowemu członkowi sesji. Gdy odbieranych jest wiele strumieni, mikser dodaje wartości PCM. Nagłówek RTP generowany przez mikser zawiera identyfikator(y) nadawcy(ów), którego dane są obecne w pakiecie.

Prostsze urządzenie tworzy jeden wychodzący pakiet RTP dla każdego przychodzącego pakietu RTP. Mechanizm ten, zwany translatorem, może zmieniać format danych w pakiecie lub wykorzystywać inny zestaw protokołów niskiego poziomu do przesyłania danych z jednej domeny do drugiej. Na przykład potencjalny odbiorca może nie być w stanie przetworzyć szybkiego sygnału wideo używanego przez innych uczestników sesji. Tłumacz następnie konwertuje wideo do formatu o niższej jakości, który wymaga niższej przepływności.

Każdy pakiet RTP ma podstawowy nagłówek i ewentualnie dodatkowe pola specyficzne dla aplikacji. Ryż. 4 ilustruje strukturę głównego nagłówka. Pierwsze 12 oktetów składa się z następujących pól:

pole wersji (2 bity): aktualna wersja - drugie;
pole dopełniające (1 bit): To pole sygnalizuje obecność oktetów dopełniających na końcu ładunku. (Dopełnienie jest stosowane, gdy aplikacja wymaga, aby rozmiar ładunku był wielokrotnością, na przykład 32 bitów). W tym przypadku ostatni oktet wskazuje liczbę oktetów dopełniających;
pole rozszerzenia nagłówka (1 bit): gdy to pole jest ustawione, to po głównym nagłówku występuje dodatkowy, używany w eksperymentalnych rozszerzeniach RTP;
pole licznika nadawcy (4 bity): to pole zawiera liczbę identyfikatorów nadawców, których dane znajdują się w pakiecie, same identyfikatory następują po głównym nagłówku;
pole znacznika (1 bit): znaczenie bitu znacznika zależy od typu ładunku. Bit znacznika jest zwykle używany do wskazania granic strumienia danych. W przypadku wideo ustawia koniec klatki. W przypadku głosu określa początek mowy po okresie ciszy;
Pole typu ładunku (7 bitów): To pole identyfikuje typ ładunku i format danych, w tym kompresję i szyfrowanie. W stanie stacjonarnym nadawca używa tylko jednego typu ładunku na sesję, ale może go zmienić w odpowiedzi na zmieniające się warunki, jeśli jest sygnalizowany przez protokół kontroli transportu w czasie rzeczywistym;
pole numeru sekwencyjnego (16 bitów): każde źródło zaczyna numerować pakiety od dowolnej liczby, a następnie zwiększa się o jeden z każdym wysłanym pakietem danych RTP. Pozwala to wykryć utratę pakietów i określić kolejność pakietów z tym samym znacznikiem czasu. Kilka kolejnych pakietów może mieć ten sam znacznik czasu, jeśli są one generowane logicznie w tej samej chwili (np. pakiety należące do tej samej ramki wideo);
pole znacznika czasu (32 bity): rejestruje moment, w którym został wygenerowany pierwszy oktet danych ładunku. Jednostki, w jakich podany jest czas w tym polu, zależą od rodzaju ładunku. Wartość jest określana przez lokalny zegar nadawcy;
Pole Identyfikator źródła synchronizacji: losowo generowana liczba, która jednoznacznie identyfikuje źródło podczas sesji.

Po głównym nagłówku może następować jedno lub więcej pól identyfikatora nadawcy, których dane znajdują się w ładunku. Te identyfikatory są wstawiane przez mikser.

Protokół RTP jest używany tylko do przesyłania danych użytkownika - zwykle multicast - do wszystkich uczestników sesji. Oddzielny protokół kontroli transportu w czasie rzeczywistym (RTCP) współpracuje z wieloma miejscami docelowymi, zapewniając informacje zwrotne nadawcom danych RTP i innym uczestnikom sesji.

RTCP używa tego samego podstawowego protokołu transportowego co RTP (zwykle UDP), ale inny numer portu. Każdy uczestnik sesji okresowo wysyła pakiet RTCP do wszystkich pozostałych uczestników sesji. RFC 1889 opisuje trzy funkcje realizowane przez RTCP.

Pierwszą funkcją jest zapewnienie jakości usług i informacji zwrotnej w przypadku przeciążenia. Ponieważ pakiety RTCP są rozsyłane grupowo, wszyscy uczestnicy sesji mogą ocenić, jak dobrze pracują i odbierają inni uczestnicy. Wiadomości nadawcy pozwalają odbiorcom ocenić szybkość transmisji i jakość transmisji. Wiadomości adresatów zawierają informacje o problemach, które napotykają, w tym o utracie pakietów i nadmiernym tętnieniu. Na przykład, przepływność dla aplikacji audio/wideo może zostać zmniejszona, jeśli łącze nie zapewnia pożądanej jakości usługi przy danej przepływności.

Informacja zwrotna od odbiorcy jest również ważna przy diagnozowaniu błędów propagacji.

Analizując wiadomości wszystkich uczestników sesji, administrator sieci może określić, czy ten problem jednego uczestnika lub ma charakter ogólny.

Drugą główną funkcją RTCP jest identyfikacja nadawcy. Pakiety RTCP zawierają standardowy opis tekstowy nadawcy. Dostarczają więcej informacji o nadawcy pakietów danych niż losowo wybrany identyfikator źródła synchronizacji. Ponadto pomagają użytkownikowi zidentyfikować wątki związane z różnymi sesjami. Na przykład pozwalają użytkownikowi określić, czy oddzielne sesje audio i wideo są otwarte w tym samym czasie.

Trzecią funkcją jest określanie rozmiaru i skalowanie sesji. Aby zapewnić jakość usług i informacje zwrotne w celu kontrolowania przeciążenia, a także identyfikacji nadawcy, wszyscy uczestnicy okresowo wysyłają pakiety RTCP. Częstotliwość transmisji tych pakietów maleje wraz ze wzrostem liczby uczestników.

Przy małej liczbie uczestników jeden pakiet RTCP jest wysyłany co najwyżej co pięć sekund. RFC 1889 opisuje algorytm, w którym uczestnicy ograniczają szybkość pakietów RTCP na podstawie całkowitej liczby uczestników. Celem jest utrzymanie ruchu RTCP poniżej 5% całkowitego ruchu sesji.

Celem każdej sieci jest dostarczanie do odbiorcy danych z gwarantowaną jakością usług, w tym przepustowością, opóźnieniem i tolerancją na zmiany opóźnień. Wraz ze wzrostem liczby użytkowników i aplikacji coraz trudniej jest zapewnić jakość usług.

Samo reagowanie na przeciążenie już nie wystarcza. Potrzebne jest narzędzie, aby całkowicie uniknąć przeciążenia, czyli umożliwić aplikacjom rezerwowanie zasobów sieciowych zgodnie z wymaganą jakością usług.

Środki zapobiegawcze są przydatne zarówno w przypadku emisji pojedynczej, jak i multiemisji. W trybie unicast dwie aplikacje uzgadniają określony poziom jakości usług dla danej sesji. Jeśli sieć jest mocno obciążona, może nie być w stanie zapewnić wymaganej jakości usług. W takiej sytuacji aplikacje będą musiały przełożyć sesję na lepsze czasy lub spróbować obniżyć wymagania dotyczące jakości usług, jeśli to możliwe.

Rozwiązaniem w tym przypadku jest rezerwowanie zasobów przez aplikacje emisji pojedynczej w celu zapewnienia wymaganego poziomu usług. Następnie routery na zamierzonej ścieżce przydzielają zasoby (na przykład miejsce w kolejce i część przepustowości linii wychodzącej). Jeśli router nie może przydzielić zasobów z powodu wcześniejszych zobowiązań, powiadamia aplikację. W takim przypadku aplikacja może próbować zainicjować kolejną sesję z niższymi wymaganiami jakościowymi usługi lub przełożyć ją na późniejszy termin.

Multiemisja stwarza znacznie bardziej złożone problemy z rezerwacją zasobów. Prowadzi to do generowania ogromnych ilości ruchu sieciowego – w przypadku aplikacji takich jak np. wideo lub gdy istnieje duża i rozproszona grupa odbiorców. Jednak ruch ze źródła multiemisji można w zasadzie znacznie zmniejszyć.

Są ku temu dwa powody. Po pierwsze, niektórzy członkowie grupy mogą nie musieć dostarczać danych z konkretne źródło w określonym czasie. W ten sposób członkowie jednej grupy mogą otrzymywać informacje jednocześnie dwoma kanałami (z dwóch źródeł), ale odbiorca może być zainteresowany otrzymaniem tylko jednego kanału.

Po drugie, że niektórzy członkowie grupy są w stanie przetwarzać tylko część informacji przekazanych przez nadawcę. Na przykład strumień wideo może składać się z dwóch elementów: jednego o niskiej jakości obrazu i drugiego o wysokiej jakości obrazu. Ten format posiada szereg algorytmów kompresji wideo: generują one podstawowy komponent z obrazem o niskiej jakości oraz dodatkowy komponent o wyższej rozdzielczości.

Niektórzy odbiorcy mogą nie mieć wystarczającej mocy obliczeniowej do przetwarzania komponentów za pomocą wysoka rozdzielczość lub być podłączony do sieci za pośrednictwem podsieci lub łącza, które nie mają wystarczającej pojemności do przenoszenia pełnego sygnału.

Rezerwacja zasobów pozwala routerom z wyprzedzeniem określić, czy mogą dostarczać ruch multiemisji do wszystkich odbiorców.

W poprzednich próbach implementacji rezerwacji zasobów oraz w podejściach przyjętych w frame relay i ATM, niezbędne zasoby są wymagane przez źródło przepływu danych. Ta metoda jest wystarczająca w przypadku transmisji unicast, ponieważ aplikacja transmitująca przesyła dane z określoną szybkością, a wymagany poziom jakości usługi jest nieodłączny od schematu transmisji.

Takiego podejścia nie można jednak stosować do multiemisji. Różni członkowie grupy mogą mieć różne wymagania dotyczące zasobów. Jeśli oryginalny strumień można podzielić na podstrumienie, niektórzy członkowie grupy mogą chcieć otrzymywać tylko jeden z nich. W szczególności, niektóre odbiorniki będą w stanie przetwarzać tylko komponent wideo o niskiej rozdzielczości. Lub jeśli kilku nadawców nadaje do tej samej grupy, odbiorca może wybrać tylko jednego nadawcę lub ich podzbiór. Wreszcie wymagania dotyczące jakości usług różnych odbiorców mogą się różnić w zależności od sprzętu wyjściowego, mocy procesora i szybkości kanału.

Z tego powodu preferowane są rezerwacje zasobów przez odbiorcę. Nadawcy mogą dostarczać routerom ogólnych charakterystyk ruchu (takich jak szybkość transmisji danych i zmienność), ale odbiorcy muszą określić wymagany poziom jakości usługi. Routery agregują następnie żądania alokacji zasobów we wspólnych częściach drzewa propagacji.

RSVP opiera się na trzech koncepcjach dotyczących przepływów danych: sesji, specyfikacji przepływu i specyfikacji filtra. Sesja to strumień danych identyfikowany przez miejsce docelowe. Zauważ, że ta koncepcja różni się od sesji RTP, chociaż sesje RSVP i RTP mogą mieć korespondencję jeden do jednego. Gdy router zarezerwuje zasoby dla określonego miejsca docelowego, traktuje to jako początek sesji i przydziela zasoby na czas trwania tej sesji.

Żądanie rezerwacji z docelowego systemu końcowego, zwane deskryptorem przepływu, składa się ze specyfikacji przepływu i filtra. Specyfikacja przepływu definiuje wymaganą jakość usług i jest używany przez węzeł do ustawiania parametrów harmonogramu pakietów. Router przesyła pakiety z zadanym zestawem preferencji na podstawie aktualnej specyfikacji przepływu.

Specyfikacja filtra definiuje zestaw pakietów, w ramach których żądane są zasoby. Wraz z sesją określa zbiór pakietów (lub przepływ), dla których ma być zapewniona wymagana jakość usługi. Wszelkie inne pakiety przeznaczone dla tego miejsca docelowego są przetwarzane, o ile sieć jest w stanie to zrobić.

RSVP nie definiuje zawartości specyfikacji przepływu, po prostu przekazuje żądanie. Specyfikacja przepływu zazwyczaj obejmuje klasę usług, Rspec (R oznacza rezerwę) i Tspec (T oznacza ruch). Pozostałe dwa parametry to zestaw liczb. Parametr Rspec definiuje wymaganą jakość usługi, a parametr Tspec opisuje przepływ danych. Zawartość Rspec i Tspec jest przezroczysta dla RSVP.

Zasadniczo specyfikacja filtra opisuje dowolny podzbiór pakietów z pojedynczej sesji (tj. pakiety, których miejsce docelowe jest określane przez tę sesję). Na przykład specyfikacja filtru może definiować tylko określonych nadawców lub określać protokoły lub pakiety, których pola nagłówka protokołu są zgodne z określonymi.

Ryż. 3 ilustruje związek między sesją, specyfikacją przepływu i specyfikacją filtra. Każdy przychodzący pakiet należy do co najmniej jednej sesji i jest rozpatrywany zgodnie z logicznym przepływem tej sesji. Jeśli pakiet nie należy do żadnej sesji, jest dostarczany, o ile dostępne są wolne zasoby.

Główna trudność z RSVP związana jest z multicastingiem. Przykład konfiguracji multicast pokazano na ryc. 6. Ta konfiguracja składa się z czterech routerów. Łącze między dowolnymi dwoma routerami, reprezentowane przez linię, może być łączem bezpośrednim lub podsiecią. Trzy hosty — Gl, G2 i G3 — znajdują się w tej samej grupie i odbierają datagramy z odpowiednim adresem multicast. Dane pod tym adresem są przesyłane przez dwa hosty - S1 i S2. Czerwona linia odpowiada drzewu routingu dla S1 i tej grupy, a niebieska linia dla S2 i tej grupy. Linie strzałek wskazują kierunek pakietów od S1 (czerwony) i od S2 (niebieski).

Rysunek pokazuje, że wszystkie cztery routery muszą być świadome rezerwacji zasobów każdego odbiorcy. W ten sposób żądania alokacji zasobów rozchodzą się wstecz przez drzewo routingu.

RSVP używa dwóch głównych typów wiadomości: Resv i Path. Wiadomości resv są generowane przez odbiorców i propagują w górę drzewa, przy czym każdy węzeł po drodze łączy i ponownie składa pakiety od różnych odbiorców, jeśli to możliwe. Komunikaty te powodują, że router wchodzi w stan rezerwacji zasobów dla tej sesji (adres multiemisji). Ostatecznie wszystkie połączone wiadomości Resv docierają do hostów wysyłających. Na podstawie otrzymanych informacji ustawiają odpowiednie parametry sterowania harmonogramem dla pierwszego przeskoku.

Ryż. 7 przedstawia strumień wiadomości Resv. Uwaga: wiadomości są łączone; dlatego tylko jedna wiadomość jest wysyłana do dowolnej gałęzi połączonego drzewa dostarczania. Jednak te wiadomości muszą być okresowo ponownie wysyłane, aby przedłużyć okres rezerwacji zasobów.

Komunikat o ścieżce jest używany do propagowania informacji o trasie zwrotnej. Wszystkie nowoczesne protokoły routingu multicast obsługują tylko trasę bezpośrednią w postaci drzewa propagacji (w dół od nadawcy). Jednak wiadomości Resv muszą być odsyłane przez wszystkie routery pośrednie do wszystkich hostów wysyłających.

Ponieważ protokół routingu nie dostarcza informacji o trasie zwrotnej, jest on przenoszony przez RSVP w wiadomościach Path. Każdy host, który chce być nadawcą, wysyła wiadomość Path do wszystkich członków grupy. Po drodze każdy router i każdy host docelowy wchodzi w stan ścieżki, wskazując, że pakiety dla tego nadawcy powinny być przekazywane do przeskoku, z którego pakiet został odebrany. Ryż. 5 pokazuje, że pakiety Path są wysyłane tymi samymi ścieżkami, co pakiety danych.

Rozważ działanie protokołu RSVP. Z punktu widzenia hosta działanie protokołu składa się z następujących kroków (pierwsze dwa kroki w tej kolejności są czasami odwrócone).

Odbiorca dołącza do grupy multiemisji, wysyłając komunikat IGMP do sąsiedniego routera.
Potencjalny nadawca wysyła wiadomość na adres grupy.
Odbiorca otrzymuje wiadomość Path identyfikującą nadawcę.
Teraz, gdy odbiorca ma informacje o ścieżce zwrotnej, może wysyłać wiadomości Resv z deskryptorami strumieni.
Wiadomości resv są wysyłane przez sieć do nadawcy.
Nadawca rozpoczyna transmisję danych.
Odbiornik zaczyna odbierać pakiety danych.

Wczorajsze metody pracy z dużymi ilościami grafiki są całkowicie nieodpowiednie dla nowoczesnych systemów. Bez nowych narzędzi nie da się sprostać rosnącym zapotrzebowaniu na transmisję danych ze względu na wzrost ich wolumenu, rozprzestrzenianie się aplikacji czasu rzeczywistego oraz multicast. RTP i RSVP zapewniają solidną podstawę dla sieci następne pokolenie lan.

Przykładem rzeczywistego zastosowania tych protokołów jest model VoIP (Voice over IP) - transmisja głosu przez sieci IP, który jest opisany w standardzie H.232 i przewiduje transmisję informacji audio, wideo i danych przez sieć IP . W tym przypadku do nawiązania połączenia używany jest protokół czasu rzeczywistego RTP, a do rezerwowania zasobów sieciowych używany jest protokół RSVP.