Monthly Archives: Lipiec 2020

Funkcjonalność MS

Funkcjonalność podstawowa

Podstawowa funkcjonalność serwera mediów obejmuje:

  • Przesyłanie strumieni danych cyfrowych audio/video do terminali użytkowników:

o Pochodzących z plików multimedialnych, silników syntezy mowy, audio lub video lub innych zasobów wewnętrznych serwera mediów

  • Rejestrowanie strumieni audio/video (do różnych formatów) i przechowywanie ich w ramach zasobów lokalnych
  • Operacje na strumieniach audio/video:

o Zmiana parametrów sygnałów cyfrowych (filtrowanie, zmiana głośności, zmiana rozdzielczości video etc.)

o Miksowanie strumieni audio/video (sumowanie sygnałów audio, łączenie strumieni video w jeden strumień)

o Transkodowanie pomiędzy strumieniami danych audio/video kodowanymi różnymi kodekami

■ W połączeniach dwustronnych, w konferencjach, przy nagrywaniu / odtwarzaniu (np. gdy dane w pliku są kodowane innym kodekiem niż wspierany przez terminal użytkownika) o Funkcjonalność Text-To-Video (TTV), Text-Insertion-In-Video – dodawanie tekstu do strumienia video, tak aby widoczny był na ekranie

  • Pobieranie cyfr i symboli od abonenta (DTMF collection)

o W paśmie – Inband

o Poza pasmem – Outband

  • Funkcjonalność IVR – wsparcie interakcji z abonentem poprzez interpretację skryptów języka VXML, odtwarzanie odpowiednich komunikatów audio/video, pobieranie cyfr i symboli DTMF (cyfry i symbole mogą zostać przekazane do innego elementu sieciowego).
  • Funkcjonalność TTS – synteza mowy z tekstu oraz przesyłanie zsyntetyzowanego strumienia audio
  • Funkcjonalność ASR – automatyczne rozpoznawanie mowy – wykorzystywane często w ramach IVR, rezultaty rozpoznania mowy mogą zostać przekazane do innego elementu sieciowego

Obsługa kodeków i transkodowania

Należy zapewnić, aby MS wspierał możliwie najszerszy zbiór kodeków audio/video stosowanych w sieciach V OIP (nie jest to niestety regułą w przypadku dostępnych implementacji serwerów mediów).

Ponadto należy podkreślić, iż wsparcie jak najszerszego zbioru kodeków oraz wsparcie transkodowania pomiędzy każdą ich parą to funkcjonalności, które są obowiązkowe dla każdego serwera mediów (nawet jeżeli nie jest on w sieci wykorzystywany do transkodowania strumieni w dwustronnych połączeniach).

Wymaganie to można uzasadnić następująco: rozważmy sytuację, w której dla terminala obsługującego jedynie kodek A zażądano od serwera mediów odegrania pewnej zapowiedzi. Zapowiedź jest zapisana w pliku, w którym dane audio zakodowano kodekiem B. Jeśli MS wspiera zarówno kodek A jak i B w ramach sesji RTP zestawianych z terminalami, ale nie wspiera transkodowania kodeka B (dane audio w pliku) na A, nie będzie mógł odegrać zapowiedzi dla terminala.

Inny przykład to usługa konferencji/miksowanie strumieni. Załóżmy, że serwer mediów wykorzystywany jest do miksowania strumieni audio dla trzech terminali, z których każdy wspiera tylko jeden kodek, różny od dwóch pozostałych. Jeżeli MS wspiera wszystkie trzy kodeki dla sesji RTP z terminalami, ale nie wspiera transkodowania pomiędzy każdą parą spośród nich, wówczas nie będzie możliwe poprawne miksowanie strumieni.

Funkcjonalność konferencyjna

Serwer mediów uczestniczy w realizacji usługi konferencji poprzez miksowanie strumieni i ich przetwarzanie. Zgodnie z rozważaniami w rozdziale 4.2, w generycznym funkcjonalnym modelu systemu konferencyjnego opartego na sygnalizacji SIP serwer mediów pełni funkcję miksera [14].

Z tego względu do funkcji serwera mediów zaliczyć można także:

  • Tworzenie „miksu” konferencyjnego – miksowanie strumieni audio i video od uczestników konferencji i przesyłanie do nich strumienia zmiksowanego audio i video
  • Rezerwację zasobów miksujących strumienie i aktywację miksowania (czyli utworzenie instancji konferencji) np. o wskazanej wcześniej porze, na wskazany okres czasu
  • Włączanie w zmiksowane strumienie a/v wysyłane do wskazanego użytkownika o dodatkowych zapowiedzi/danych audio/video o dialogu IVR[1]
  • Operowanie na sygnałach cyfrowych pochodzących od uczestników konferencji przed włączeniem ich w zmiksowany strumień

o Zwiększanie/zmniejszanie siły głosu poszczególnych uczestników konferencji

o Transkodowanie pomiędzy różnymi kodekami audio/video

  • Elastyczne modyfikowanie strumienia zmiksowanego:

o Przesyłanie w „miksie” sygnałów tylko od jednego uczestnika (tryb wykładu) do kilku wybranych uczestników, dla których poziom sygnału audio przekracza określony poziom (określany w ramach aplikacji usługowej)

o Dla danego uczestnika włączanie/eliminowanie do/ze konferencji pochodzącego od niego strumienia audio (np. dla trybu secret participating czy dla uczestnika bez prawa głosu). o Modyfikacja zmiksowanego strumienia video odpowiednio dla trybów VAS – Voice Activated Switching, Continous Presence, lecture mode o Tworzenie subkonferencji – czyli przesyłanie kilku sygnałów zmiksowanych do grup użytkowników wyróżnionych logicznie w ramach konferencji

o Łączenie dwóch lub więcej konferencji w jedną konferencję.

Wsparcie mechanizmu uprawnionego przechwytu (Lawful Interception)

Jednym ze sposobów implementacji mechanizmu przechwytywania treści w sieciach typu V OIP jest wykorzystanie serwera mediów. W tym przypadku dla wskazanych połączeń/sesji/użytkowników kopiowane są strumienie multimedialne wysyłane/odbierane przez MS. Skopiowane dane mogą być przechowywane w ramach MS lub zapisywane w osobnej lokalizacji w sieci. Do kopiowania strumieni MS może wykorzystywać funkcjonalność agenta SIP typu Back To Back User Agent (B2BUA) – kopiowane strumienie przesyłane są do innej lokalizacji w ramach ustanowionej sesji SIP, powiązanej z „kopiowaną” sesją.

Uprawniony przechwyt (Lawful Interception) wymaga zdefiniowania dodatkowych mechanizmów służących do wskazywania źródła przechwytywanej treści oraz do zarządzania nią. Funkcjonalność ta nie wchodzi jednak w zakres funkcji serwera mediów i nie jest rozpatrywana w niniejszej pracy.

Oczywiście aby przechwytywanie treści z wykorzystaniem MS było optymalnym rozwiązaniem dla danej sieci, należy zapewnić, aby wszystkie strumienie multimedialne w tej sieci „przechodziły” przez ten moduł. Nie jest to jednak optymalne podejście z punktu widzenia zarządzania ruchem w sieci.

Mechanizmy naliczania opłat – charging/billing

Strumienie multimedialne RTP przesyłane do/z modułu MS opisać można pewnym zbiorem informacji, do których zaliczyć można:

  • objętość (w bajtach) danych multimedialnych wysyłanych/odbieranych przez MS w ramach danego strumienia
  • data i godzina rozpoczęcia i zakończenia odbierania/wysyłania strumieni przez MS, czas trwania tej sesji RTP (np. w sekundach)
  • ilość otwartych strumieni RTP
  • pasmo zarezerwowane w ramach danego strumienia RTP
  • typ kodeka zastosowany w przesyłanych danych

Informacje te mogą zostać udostępnione przez MS i wykorzystane przez systemy billingowe do naliczania opłat za korzystanie z sieci (charging). Możliwe jest wsparcie dwóch typów mechanizmów:

  • on-line charging – obciążanie użytkownika „na bieżąco” – w trakcie trwania połączenia/sesji
  • off-line charging – tworzenie informacji taryfikacyjnej po zakończeniu połączenia sesji i na jej podstawie obciążanie użytkownika.

Mechanizmy te wymagają wzbogacenia funkcjonalności MS o generowanie rekordów CDR[2] oraz obsługę interfejsu do systemów bilingowych danej sieci, celem przesyłania wygenerowanych danych. W rzeczywistych implementacjach MS wykorzystuje się w tym celu protokół DIAMETER[3].

Bardziej wnikliwa analiza funkcjonalności taryfikacyjnej MS nie jest celem niniejszej pracy magisterskiej.


[1]    Dialog IVR to określenie przebiegu interakcji z abonentem, np. przejścia przez menu głosowe i dokonanie wyboru poprzez DTMF etc. Dialogi mogą być definiowane np. poprzez skrypty VXML.

[2]   CallDetailRecord- rekord danych z informacjami na temat danego połączenia takimi jak: czas trwania połączenia, adresy źródłowe i docelowe, pora dnia, kiedy nawiązano połączenie, dodatkowe parametry połączenia etc. Może reprezentować różne typy połączenia: np. połączenie PSTN/3G, sesję VoIP, sesję GPRS etc. Rekordy CDR są wykorzystywane przez systemy bilingowe w procesie taryfikacji rozmów.

[3]    DIAMETER to zdefiniowany w [10] protokół sieciowy realizujący funkcje AAA (Authentication, Authorization andAccounting- Uwierzytelnianie, Autoryzacja i Obsługa Konta Użytkownika).