W artykule zaprezentowano rozszerzenia do protokołu RSVP, umożliwiające przesyłanie informacji sygnalizacyjnych o chwilowym zapotrzebowaniu na zasoby sieciowe. Przeprowadzone testy wykazały, że wprowadzone zmiany nie wpłynęły znacząco na jakość testowych obrazów wideo (w stosunku do RSVP bez rozszerzeń), poprawiły natomiast wykorzystanie łącza stanowiącego "wąskie gardło". Utrzymano zatem wysoką jakość usługi sieciowej QoS, przy zwiększeniu wykorzystania łącza. 1. WSTĘP Wiele nowoczesnych usług dostępnych w sieci Internet (np VoIP, IPTV) to usługi multimedialne, wymagające transmisji informacji w czasie rzeczywistym. Dla prawidłowego funkcjonowania usługi te wymagają odpowiednich gwarancji QoS (Quality of Service) jakości transmisji [1][2], co w praktyce oznacza konieczność zapewnienia niezbędnych zasobów sieciowych dla transmisji objętej gwarancją jakości. Aplikacje wymagające QoS informacje o zapotrzebowaniu na zasoby sieciowe często przekazują korzystając z sygnalizacji realizowanej przez protokół RSVP (Resource ReSerVation Protocol) [1][3]. W niniejszym artykule zaprezentowano rozszerzenia do protokołu RSVP, zaproponowane przez Autorów [4]. Rozszerzenia zwiększają funkcjonalność standardowego protokołu RSVP, który wysyła informacje o całkowitym zapotrzebowaniu na zasoby sieciowe, szacowanym dla całej sesji. Wersja rozszerzona RSVP może dodatkowo, w trakcie trwania sesji, przesyłać informacje sygnalizacyjne o chwilowym zapotrzebowaniu na zasoby sieciowe. Mogą być one wysyłane na bieżąco, w sposób ciągły. Ewentualnie mogą być wysyłane w miarę potrzeby, jeśli zapotrzebowanie na zasoby sieciowe zmieni się w sposób istotny. Informacja taka może być następnie wykorzystana do dynamicznej zmiany ustawień rezerwacyjnych. Zaproponowane przez Autorów rozszerzenia do protokołu RSVP umożliwiają zaimplementowanie w architekturze IntServ dynamicznej alokacji zasobów sieciowych. Jak wykazały badania, tak zrealizowana dynamiczna a[...]

  DOI: 10.15199/59.2015.8-9.11 PRZEGLĄD TELEKOMUNIKACYJNY - ROCZNIK LXXXVIII - WIADOMOŚCI TELEKOMUNIKACYJNE - ROCZNIK LXXxIV - nr 8-9/2015 747 Jednym z takich rozwiązań, stosowanych obecnie w wielu systemach operacyjnych pracujących w urządzeniach końcowych, jest - wykorzystywany wcześniej w urządzeniach pośredniczących (ruterach) - mechanizm równoważenia obciążenia (Load Balancing). Mechanizm ten pozwala na przesyłanie różnych strumieni danych przez różne interfejsy, dostępne w systemie końcowym. Dzięki zastosowaniu mechanizmu równoważenia obciążenia możliwe stało się rozdzielanie połączeń pomiędzy interfejsy sieciowe urządzenia końcowego. W rozwiązaniu tym, jedno połączenie sieciowe zawsze wykorzystuje jeden interfejs, przy czym każde nowe połączenie (do nowego systemu końcowego) jest kierowane na kolejny interfejs sieciowy. Jeżeli lista dostępnych interfejsów się wyczerpie, wybierany jest pierwszy z interfejsów. Mechanizm taki stosowany jest m.in. w systemach Windows firmy Microsoft, poczynając od systemu Windows Vista [6], [11]. Opisany mechanizm zwiększa ogólną wydajność i niezawodność połączeń sieciowych. Nie zwiększa jednak w sposób znaczący wydajności i niezawodności pojedynczego połączenia sieciowego. W wielu obecnie oferowanych aplikacjach, do transmisji danych masowych stosowana jest technika zestawiania wielu połączeń pomiędzy dwoma systemami końcowymi tak, aby za pomocą zwiększonej liczby połączeń zwiększyć szybkość transmisji danych masowych [12]. Takie rozwiązanie jest dosyć skuteczne. Również i dlatego, że pozwala ominąć ograniczania na maksymalną wydajność pojedynczego połączenia TCP, jakie są w stosowane w wielu systemach operacyjnych (np. brak załączonej opcji skalowania okna TCP). Rozwiązanie takie może jednak zwiększyć w sposób niekontrolowany opóźnienia i spowodować nierównomierny podział zasobów sieciowych w łączach stanowiących wąskie gardło [12]. Dodatkowo wymaga nowych protokołów lub mechanizmów [...]

  A COMPARATIVE ANALYSIS OF CHOSEN MODELS OF THE WEBRTC ARCHITECTURE Streszczenie: WebRTC to technika multimedialna oparta na nowej wersji języka opisu stron WWW, HTML 5, i skryptach JavaScript. Pozwala ona na budowę systemów wideotelefonicznych, telekonferencyjnych, monitorujących i im podobnych, dla których interfejsem użytkownika jest strona WWW. Niniejszy artykuł jest poświęcony modelom architektury WebRTC. Przedstawiono w nim oraz porównano trzy, znane z literatury, modele WebRTC. Abstract: The WebRTC is based on the new version of the HyperText Markup Language, the HTML 5, and JavaScript programming. It allows Web programmers to build multimedia systems (videotelephony, conferencing and monitoring systems, and the like) that use Web pages as the user interface. This paper is devoted to a models of the WebRTC architecture. Three different models, known from the literature, are presented and comprised. Słowa kluczowe: architektura, model, stos protokołowy, WebRTC Keywords: architecture, model, protocol stack, WebRTC 1. WSTĘP WebRTC (ang. Web Real-Time Communications) jest techniką obecnie rozwijaną i standaryzowaną przez IETF1 w ramach grupy roboczej MMUSIC (z ang. Multiparty MUltimedia SessIon Control). Jest ona przeznaczona do budowania interaktywnych systemów multimedialnych czasu rzeczywistego (jak systemy telefoniczne, wideokonferencyjne itp.), pracujących zgodnie z modelem peer-to-peer i zorientowanych na WWW. W systemach multimedialnych strona WWW stanowi interfejs użytkownika, zaś "silnikiem" zapewniającym transmisję informacji multimedialnych w czasie rzeczywistym jest technika WebRTC. WebRTC łączy w sobie elementy języka HTML 5 (do opisu zawartości strony WWW) oraz skryptów języka JavaScript z bibliotekami WebRTC (do oprogramowania funkcji komunikacyjnych oraz kontrolno-sterujących). Podstawą WebRTC jest udostępnianie przeglądarce informacji 1 Internet Engineering Task Force multimedialnej z lokalnych prze[...]

  WebRTC (ang. Web Real-Time Communications) [1][2] to nowa, alternatywna dla obecnie stosowanej architektury MMUSIC (z ang. Multiparty MUltimedia SessIon Control) [3], architektura aplikacji tele- i wideokonferencyjnych, w której rolę interfejsu użytkownika pełni przeglądarka WWW. Architektury te, choć zostały opracowane w odstępie kilkunastu lat, łączy wiele podobieństw. Podobnie, jak MMUSIC, WebRTC do transmisji informacji multimedialnej wykorzystuje protokół RTP (ang. Real-time Transport Protocol). Również ustanawianie sesji WebRTC [4] (pomimo istotnej różnicy w stosie protokołowym) odbywa się w sposób zbliżony do ustanawiania sesji MMUSIC, co pozwala na w miarę bezproblemowe łączenie się ze sobą aplikacji zbudowanych w oparciu o te dwie architektury [5][6][7]. Wspomniana wyżej różnica to zastąpienie protokołu SIP (ang. Session Initiation Protocol), będącego sztandarowym protokołem MMUSIC, protokołem JSEP (ang. JavaScript Session Establishment Protocol). Istotną różnicą pomiędzy WebRTC a MMUSIC jest zmiana podejścia do gwarancji jakości usługi (ang. Quality of Service, QoS) oferowanej przez każdą z tych architektur. MMUSIC zakładała, iż zapewnienie odpowiedniej jakości usługi tele- i wideokonferencyjnej będzie się odbywać z wykorzystaniem elementu architektury usług zintegrowanych (ang. Integrated Services, Int- Serv) - protokołu RSVP (ang. Resource Reservation Protocol). WebRTC zakłada użycie, alternatywnej do IntServ, architektury usług zróżnicowanych (ang. Differentiated Services, DiffServ) [8]. Architektura DiffServ opiera się na podziale ruchu na klasy o zróźnicowanym sposobie obsługi. Obsługa zależy od tzw. PHB (ang. Per-Hop Behavior) [10], definiującego zachowanie (ang. behavior) ruchu w sieci Internet (de facto definiuje on właściwości przekazywania pakietów w ruterze). Wybór PHB jest tożsamy z wyborem danej klasy ruchu. Rutery pośredniczące informowane są o wybranym PHB (wybranej klasie) za pomocą sześciobit[...]

  AN ANALYSIS OF COOPERATION BETWEEN WEBRTC-BASED MOBILE TERMINALS WITH SIPBASED VOIP TELEPHONY Streszczenie: Technika WebRTC pozwala na realizację mobilnych terminali (wideo)konferencyjnych i (wideo)telefonicznych, które korzystają z przeglądarki WWW jako interfejsu użytkownika. Technika ta różni się, niekiedy znacząco, od klasycznej telefonii VoIP. Artykuł przedstawia analizę współpracy terminali mobilnych wykorzystujących technikę WebRTC z terminalami telefonii VoIP, które klasycznie budowane są z zastosowaniem protokołu SIP. W artykule dokonano analizy współpracy sygnalizacji WebRTC z sygnalizacją VoIP oraz przedyskutowano zagadnienia transmisji mediów. Abstract: The WebRTC allows the developer to create mobile terminals for (video)conferencing and (video) telephony purposes. Such terminals use Web browsers as user interfaces. The WebRTC technology differs, sometimes significantly, from the classic VoIP telephony. This paper presents an analysis of cooperation of mobile terminals that use the WebRTC conferencing systems with terminals that use the SIP-based telephony. Some aspects of cooperation of WebRTC and SIP signaling, as well as media transmission are also discussed. Słowa kluczowe: bramka, SIP, sygnalizacja, WebRTC Keywords: gateway, SIP, signaling, WebRTC 1. WSTĘP Technika WebRTC [7][12] oraz protokół SIP (ang. Session Initiation Protocol) powstały w tej samej grupie roboczej IETF (ang. Internet Engineering Task Force) - grupie MMUSIC (z ang. Multiparty MUltimedia SessIon Control). Oba te rozwiązania są podstawą budowy systemów transmisji informacji multimedialnej w czasie rzeczywistym, jak np. systemy (wideo)konferencyjne czy (wideo)telefoniczne. Różnią się jednak znacząco. Z punktu widzenia użytkownika różnica dotyczy interfejsu - przeglądarki WWW (strony WWW) w przypadku terminali bazujących na WebRTC i osobnej aplikacji multimedialnej w przypadku terminali implementujących protokół SIP. Z punktu widzenia [...]

  APPLICABILITY OF THE SDP PROTOCOL IN WEBRTC-BASED MULTIMEDIA SYSTEMS Streszczenie: Artykuł przedstawia opis sesji multimedialnej za pomocą protokołu SDP, jednego z elementów sygnalizacji WebRTC. Omówiono protokół SDP wraz z odniesieniami do techniki WebRTC oraz komponenty semantyczne sesji WebRTC. Opis formalny zilustrowano przykładami praktycznej realizacji transmisji, z uwzględnieniem danych przesyłanych na poziomach: sesji i mediów. Abstract: The paper presents a description sessions using the SDP protocol, functional component of WebRTC signaling. The paper describes the SDP with reference to the WebRTC, as well as semantic components of SDP for the WebRTC. Formal description is illustrated by an example of SDP offer and answer, accomplished with the use of the WebRTC. Signaling data, generated and transferred at the session and media layers, are also presented. Słowa kluczowe: opis sesji, SDP, sygnalizacja, WebRTC Keywords: session description, SDP, signaling, WebRTC 1. WSTĘP Protokół warstwy sesji SDP (ang. Session Description Protocol) [4] modelu OSI/ISO został opisany w roku 1998 dokumentem RFC 2327 [5]. Standard ten został zmieniony w roku 2006 po opublikowaniu RFC 4566 [6]. Wprowadzone zmiany były na tyle duże, że wymagały opracowania nowego dokumentu RFC i jednocześnie na tyle małe, że pozostawiono poprzedni numer wersji protokołu (wersja 0). Jeszcze wcześniej, bo w 2002 roku, pojawiły się rozszerzenia SDP do modelu komunikacji typu oferta-odpowiedź (Offer/Answer) [15] oraz do grupowania strumieni mediów [2]. Oba te rozszerzenia są intensywnie wykorzystywane przez technikę WebRTC (ang. Web Real-Time Communications) [1][18] przeznaczoną do realizacji systemów multimedialnych zorientowanych na WWW i do realizacji transmisji bezpośrednio pomiędzy przeglądarkami WWW. Protokół SDP jest protokołem opisu sesji. Jest to protokół ogólnego przeznaczenia, który może być używany do sporządzania opisu sesji na potrzeby ró[...]

  A COOPERATION OF THE WEBRTC ARCHITECTURE WITH CONFERENCING SYSTEMS BASED ON USAGE OF SIP PROTOCOL Streszczenie: Sygnalizacja w technice WebRTC wykorzystuje protokół SDP do opisu sesji. Typowo protokół SDP współpracuje z protokołem SIP, tworząc stos protokołowy SDP/SIP. Aby uprościć przetwarzanie protokołowe, w WebRTC zastosowano stos protokołowy SDP/JSEP. Artykuł omawia metody współpracy systemów multimedialnych, zbudowanych z zastosowaniem WebRTC, z systemami konferencyjnymi korzystającymi z protokołu SIP. Ilustruje również aspekty praktyczne współpracy WebRTC z systemami multimedialnymi implementującymi protokoły SDP/SIP. Abstract: Signaling implemented in WebRTC technology describes session parameters using SDP protocol. Typically, SDP cooperates with SIP protocols, making the SDP/SIP protocol stack. However, in order to simplify control information processing, WebRTC technology uses the SDP/JSEP protocol stack. This paper discusses methods of cooperation of WebRTC-based multimedia systems with teleconferencing systems based on SIP protocol. The paper also presents practical aspects of cooperation of the WebRTC with multimedia systems implementing SDP/SIP protocols. Słowa kluczowe: bramka, SIP, sygnalizacja, WebRTC Keywords: gateway, SIP, signaling, WebRTC 1. WSTĘP Grupa robocza MMUSIC (z ang. Multiparty MUltimedia SessIon Control) IETF (ang. Internet Engineering Task Force) znana jest z opublikowanej przed laty architektury nazwanej jej imieniem [6][11]. Najnowszą propozycją tej grupy roboczej jest technika WebRTC (ang. Web Real-Time Communications) [10][16]. WebRTC wykorzystuje złożoną sygnalizację, dla której wspólną platformą protokołową jest, znany z architektury MMUSIC, protokół SDP (ang. Session Description Protocol). Protokół ten jest wykorzystywany również do przesyłania szczegółowych opisów konfiguracyjnych sesji WebRTC [7]. Architektura MMUSIC opisuje współpracę SDP m.in. z protokołem SIP (ang. Session [...]

  Współczesne systemy konferencyjne budowane są jako scentralizowane lub zdecentralizowane [1]. W rozwiązaniach scentralizowanych istnieje centralne urządzenie, zwane mostkiem konferencyjnym, które zarządza konferencją, steruje przebiegiem konferencji, a także dokonuje przetwarzania strumieni mediów (najczęściej miksowania i/lub translacji do zadanego formatu). Rozwiązania zdecentralizowane charakteryzują się brakiem mostka konferencyjnego, a zadania związane z zarządzaniem i sterowaniem konferencją oraz przetwarzaniem strumieni mediów realizowane są w sposób rozproszony, na terminalach klienckich. Rozwiązania zdecentralizowane są bardziej elastyczne, rozwiązania scentralizowane pozwalają na łatwiejsze zarządzanie konferencją. Istnieją również rozwiązania hybrydowe, w których mostek konferencyjny stanowi przejście pomiędzy scentralizowaną i zdecentralizowaną częścią konferencji. Kilkanaście lat temu grupa robocza MMUSIC (z ang. Multiparty MUltimedia SessIon Control) IETF (ang. Internet Engineering Task Force) opracowała architekturę systemu konferencyjnego MMUSIC [1][2]. Ze względu na wykorzystanie multikastu, architektura ta pozwalała na tworzenie telekonferencji zdecentralizowanych lub mieszanych, jednak użycie protokołu sygnalizacyjnego SIP (ang. Session Initiation Protocol), wymagającego istnienia centralnego serwera SIP, oraz ogólna niechęć dostawców Internetu do szerokiego udostępniania usługi multikastowej sprawiły, że MMUSIC stał się de facto standardem systemów scentralizowanych. Obecnie IETF pracuje nad kolejnym standardem, WebRTC (ang. Web Real-Time Communications) [3][4][5]. Bazuje on na języku JavaScript oraz języku HTML 5 i wykorzystuje przeglądarkę WWW (stronę WWW) jako interfejs użytkownika. Protokół SIP został w WebRTC zastąpiony protokołem JSEP (ang. JavaScript Session Establishment Protocol), nie wymagającym serwera. Architektura WebRTC zakłada zestawianie bezpośrednich połączeń peer-to-peer pomiędzy pr[...]