Interakcja serwera mediów z serwerem aplikacji jest kluczowa w kontekście realizacji usług multimedialnych w danej sieci V2OIP. Zagadnienie to wymaga zatem dokładnego rozważenia.
Poniżej opisano rolę, jaką pełni AS w interakcji z serwerem mediów. Dokonano prezentacji czterech zaproponowanych przez ETSI ([3GPP TR 24.880 “Media Server Control using the IP Multimedia (IM) Core Network (CN) subsystem”, Maj 2007]) modeli sterowania serwerem mediów oraz przedstawiono krytyczne uwagi wskazując braki tych modeli. Zaproponowano także dodatkowy model oparty na wiadomości SIP REFER.
- Rola serwera aplikacji
Można wyróżnić trzy typy ról, jakie AS pełni wobec MS:
- Wywoływanie serwera mediów (invoke role) – serwer aplikacji wywołuje MS (wysyła żądania SIP) i w efekcie zestawia z nim ścieżkę sygnalizacyjną SIP.
- Sterowanie serwerem mediów (Control role) – AS decyduje, które spośród funkcjonalności serwera mediów zostaną wykorzystane i w jaki sposób
- Dostarczanie danych (service role) – AS udostępnia serwerowi mediów dane potrzebne do realizacji żądanych funkcji (np. adresy terminali, pliki a/v, skrypty VXML[1] etc) [2]
W szczególności:
- AS przeprowadza wszystkie operacje zgodnie z logiką zlokalizowanych w nim aplikacji usługowych
- AS korzysta z B2BUA89 [3] celem zestawienia połączeń (sesji RTP) pomiędzy MS a terminalami SIP, sterowania przebiegiem i parametrami tych połączeń
- AS wykorzystuje funkcjonalności multimedialne MS poprzez protokół SIP oraz (w sytuacji gdy SIP nie wspiera odpowiedniej funkcjonalności) poprzez dedykowany protokół sterowania serwerem mediów, którego wiadomości są transportowane w ciele wiadomości protokołu SIP.
- AS może odbierać od MS następujące informacje:
o Stan pracy MS (zajęte zasoby, pojemność MS etc.) o Stan realizacji żądanych funkcjonalności (zakończone sukcesem, niepowodzeniem, przerwane)
o Dane na temat realizowanych funkcjonalności (np. dla konferencji – lista uczestników, ich adresy, kodeki, lista N najgłośniejszych uczestników etc).
o Zaistniałe błędy i awarie w pracy MS o Pobrane od użytkowników cyfry i symbole DTMF o Rezultaty rozpoznawania mowy użytkownika (np. dla menu głosowego)
Informacje te są przesyłane poprzez wiadomości SIP lub wiadomości dedykowanego protokołu na styku AS-MS
- W kontekście usługi konferencji AS:
o Implementuje funkcjonalność bloku:
o Jest wywoływane przez abonentów poprzez adres konferencji (Conference URI)[6]
o Jest wykonawcą polityk konferencji – cyklu życiowego konferencji (Life Cycle), zarządzania członkami konferencji (Membership), autoryzacji (Authorisation), za wyjątkiem tzw. polityki dotyczącej mediów (media conferencepolicy, [41]), która jest wykonywana przez serwer mediów (MRFC lub warstwę sterowania w MS). o Może implementować Conference Notification Server, poprzez wykorzystanie mechanizmu opartego na wiadomościach SIP SUBSCRIBE oraz NOTIFY, jak opisano w IETF RFC 4575 “A Session Initiation Protocol (SIP) Event Package for Conference State”, Sierpień 2006.
o Implementuje różne modele billingowe związane z konferencją: prepaid, postpaid, dzielenie opłaty pomiędzy uczestników, opłata za konferencję, opłata w zależności od wykorzystywanego kodeka etc. o Wspiera naliczanie opłaty za innego typu funkcjonalności: opłata za odtwarzanie pliku audio/video, opłata za ilość przesłanych danych, za jakość kodeka/szerokość wykorzystywanego pasma, opłata za transkodowanie etc.
Sprzężenie AS-MS
Często można spotkać stwierdzenie, iż serwer mediów to moduł, który samodzielnie odpowiada za realizację usługi multimedialne. W taki sposób np. reklamowane są rzeczywiste implementacje MS, a ich producenci często przytaczają zestaw usług, które są wg nich realizowane przez ich produkt.
Należy zwrócić uwagę na fakt, iż jest to stwierdzenie błędne. Jak wspomniano w rozdziale 5, MS nie zawiera żadnej logiki usługowej, a jest jedynie pewnego rodzaju „biernym procesorem sygnałowym”, który realizuje żądania innych modułów sieciowych.
Przyjmijmy zatem następującą tezę:
W sieciach V2OIP zachodzi sprzężenie funkcjonalne serwera aplikacji (AS) i serwera mediów (MS), w którym to AS steruje pracą serwera mediów i wykorzystuje jego zasoby zgodnie z logiką aplikacji usługowej, a MS udostępnia funkcjonalności przetwarzania strumieni multimedialnych. Z tego powodu w kontekście realizacji usług multimedialnych należy zawsze rozpatrywać współpracę obu modułów.
W odniesieniu do przytoczonej w rozdziale 4 definicji usługi multimedialnej, można powiedzieć, że to MS dostarcza niezbędnych funkcjonalności, natomiast AS decyduje o sposobie i kolejności ich wykorzystania.
Poparciem powyżej tezy niech będzie fakt, iż ETSI w dokumencie [41] definiuje moduł Conferencing Application Server (Konferencyjny Serwer Aplikacji), który odpowiada za logikę tej właśnie usługi i jest „nieodzownie” sprzężony z serwerem mediów [9] (oba moduły tworzą „blok konferencyjny”).
[1] Patrz rozdział 6.6.4.1. [cytowanej pracy magisterskiej]
[2] Przy rejestrowaniu SIP UA odpowiadających funkcjonalnościom Media Servera nie ujętym w notacji Netann, niestandardowe nazewnictwo w SIP URI jest konieczne. Notacja wspiera bowiem tylko trzy grupy funkcjonalności (patrz rozdział 6.6.2.3).
[3] Funkcja B2BUA została omówiona w rozdziale 4 niniejszej pracy.
[4] IETF RFC 4353 „A Framework for Conferencing with the Session Initiation Protocol (SIP)”, Luty 2006, patrz też rozdział 2.2.
[5] Jest to logiczny blok funkcjonalny, który przechowuje polityki konferencji (conference policies)i udostępnia je blokowi focus do zaadoptowania. Blok ten może być np. zintegrowany z focusem. Opisano go w IETF RFC 4353 „A Framework for Conferencing with the Session Initiation Protocol (SIP)”.
[6] IETF RFC 4353 „A Framework for Conferencing with the Session Initiation Protocol (SIP)”, patrz też rozdział 2.2. [cytowanej pracy magisterskiej]
[7] Jest to logiczny blok, będący częścią focusa. Opisano go w IETF RFC 4353 „A Framework for Conferencing with the Session Initiation Protocol (SIP)”. Umożliwia przesyłanie powiadomień o stanie konferencji tym użytkownikom, którzy dokonali subskrypcji związanej z tym stanem.(mechanizmy powiadamiania i subskrypcji z wykorzystaniem protokołu SIP opisano w IETF RFC 3265 “Session Initiation Protocol (SIP)-Specific Event Notification”, Czerwiec 2002).
[8] Dokładna analiza roli serwera aplikacji w realizacji bililingu leży poza zakresem niniejszej pracy.
[9] Informacje na temat rozproszenia pomiędzy serwer aplikacji i Media Server (MRF) bloków funkcjonalnych dla usługi konferencji opartej na protokole SIP, zdefiniowanych w RFC 4353, zawarto w 3GPP TR 24.880 “Media Server Control using the IP Multimedia (IM) Core Network (CN) subsystem”, Maj 2007.
