Podsumowanie pracy inżynierskiej

Przedstawiona praca stanowi źródło wiedzy dotyczącej zagadnień związanych z sieciami komputerowymi.

Pisząc tą pracę, pomimo wielu trudności udało się zrealizować założenia, jakie zostały wytyczone na jej początku. Zebrane materiały pozwoliły połączyć zarówno teorie związaną z sieciami komputerowymi jak i stworzyć część praktyczną tzn. okablowanie strukturalne pod rzeczywistą sieć komputerową.

Największym problemem było zebranie wszelkich materiałów – norm opisów itp. – dotyczących projektowania okablowania strukturalnego. Szukając tych materiałów w dostępnych publikacjach nie byłem w stanie znaleźć konkretnego opisu, który zawierałby wszelkie potrzebne informacje. Dlatego przy części projektowej starałem się połączyć wszystkie ważniejsze informacje (znajduj ą się tam nie tylko same obliczenia, ale również objaśnienia podstawowych pojęć związanych z nimi), aby stanowiły przejrzystą całość.

W części teoretycznej pracy zawarte są i opisane podstawowe pojęcia związane z zagadnieniami sieciowymi. Przedstawione są: sposoby komunikacji wykorzystywane wewnątrz sieci komputerowych (opisy protokołów z wyszczególnieniem obecnie najbardziej popularnego TCP/IP), rodzaje sieci komputerowych (ze względu na obszar jaki obejmuj ą swym zasięgiem, przeznaczenie i przepustowość), sposoby ich łączenia.

Oprócz tych zagadnień opisane zostały elementy fizyczne wchodzące w skład sieci, takie jak: nośniki informacji (kabel miedziany, światłowód, fale radiowe), elementy wzmacniające, elementy łączące.

Zwieńczeniem pracy jest projekt sieci (okablowania ) wykonany dla Lokalnej Sieci Osiedlowej „Stokplanet” (www.stokplanet.one.pl) oraz opis instalacji i konfiguracji serwera w Środowisku Linux/Unix. System operacyjny został wybrany nieprzypadkowo. Głównym atutem Linuxa jako systemu serwerowego są jego niezawodność (dobrze skonfigurowany potrafi pracować latami bez restartu), oraz licencja GPU czyli jest to produkt darmowy co ma niebagatelny wpływ na całkowite koszty przedsięwzięcia. Mój projekt został również wykorzystany (po przystosowaniu do lokalnych warunków) przy budowie sieci LAN, www.hirszfelda.one.pl której byłem współtwórcą i doradcą technicznym.

W dzisiejszych czasach, kiedy sieci komputerowe w coraz większym stopniu są wykorzystywane przez różnego rodzaju instytucje stworzona praca może stanowić źródło wiedzy dla ludzi zainteresowanych tym zagadnieniem. Pomoże ona również tym wszystkim którzy szukają wszystkich skompensowanych materiałów potrzebnych do wykonania komputerowej sieci osiedlowej.

Migracja usługowa do sieci NGN

W chwili obecnej można stwierdzić, iż na rynku telekomunikacyjnym dokonuje się proces migracji sieci operatorów do sieci typu NGN. Oczywiście jest to długotrwały proces, w którym istotne jest zachowanie ciągłości usługowej w ofercie operatora. Oznacza to, iż jeżeli docelową siecią operatora będzie sieć NGN, konieczne jest w pierwszej kolejności zapewnienie w tej sieci wszystkich usług świadczonych do tej pory w tradycyjnych sieciach telefonicznych. Dopiero wówczas można rozważać usługi w pełni wykorzystujące możliwości „nowej” architektury sieciowej.

Etapy migracji usługowej do sieci NGN można zatem ująć w dwóch punktach:

  • Emulacja usług klasycznych – „przeniesienie” do sieci NGN wszystkich usług realizowanych w sieciach typu PSTN/ISDN
  • Rozwój usług o wartości dodanej

Opisane podejście jest prezentowane przez organizację standaryzacyjną TISPAN , gdzie w specyfikacji NGN Release 1 zdefiniowano system PES – PSTN/ISDN Emulation Subsystem ([51], [52]). Zadaniem systemu PES jest właśnie emulacja klasycznych usług sieci telefonicznej w ramach architektury NGN opisanej przez TISPAN.

W odniesieniu do rozważań związanych z usługami multimedialnymi, należy podkreślić, iż w kontekście migracji usługowej do NGN kluczowe jest zapewnienie niezbędnych funkcjonalności multimedialnych. Na potrzeby emulacji klasycznych usług PSTN/ISDN do grupy tych funkcjonalności zaliczyć można odtwarzanie zapowiedzi oraz interakcję z abonentem czy połączenia konferencyjne. Jak wspomniano, wszystkie takie funkcjonalności są dostarczane przez serwer mediów. Zgodnie z koncepcją wysuniętą przez ciała standaryzacyjne, serwer ten zastępuje w sieci NGN wszystkie tradycyjne systemy, jak IVR, centrale SSP z modułami Intelligent Peripheral, a także mostki audio- / videokonferencyjne.

Ilustruje to poniższy rysunek: [1] [2]

Rys. 1 Migracja funkcjonalności multimedialnej z sieci PSTN/ISDN do sieci NGN

Schowek01Oczywiście migracja odnosi się również do sieci komórkowych(2G), gdzie obecnie wykorzystuje się dedykowane systemy zapewniające tylko jedną grupę funkcjonalności multimedialnych na potrzeby konkretnej usługi.

Serwer mediów, jako część architektury NGN opartej na koncepcji IMS[3], staje się zatem uniwersalnym zasobem sieciowym, który zastępuje dotychczasowe rozwiązania i którego różnorodne funkcjonalności są wykorzystywane do symulacji klasycznych jak i realizacji „nowych” usług multimedialnych.

W tym kontekście kluczowym zagadnieniem jest problem sterowania pracą serwera mediów i jego interakcją z innymi modułami sieci. Przyjęty dla sieci V OIP wzorzec architektoniczny[4] zakłada, iż sterowanie to odbywa się z poziomu aplikacji usługowej zlokalizowanej w module Application Server (serwer aplikacji). Różna może być relacja, jaką poprzez wymianę sygnalizacji nawiązują moduły AS i MS, co znacząco wpływa na kształt logiki usługowej i nierzadko implikuje zastosowanie dedykowanych mechanizmów. Ponadto, nierozstrzygniętą w standaryzacji kwestię stanowi problem odwzorowania funkcji serwera mediów na wiadomości protokołów sygnalizacyjnych służących do komunikacji z tym modułem.

Okazuje się również, że MS jest niekiedy postrzegany jako moduł pracujący na styku sieci z komutacją kanałów i sieci pakietowej.

Wobec takiego stanu rzeczy istnieje wyraźna konieczność uporządkowania wiedzy w obrębie omawianej tematyki.

—

[1]  Telecoms & Internet converged Services & Protocols for Advanced Networks – ciało standaryzacyjne w ramach ETSI, które ma na celu opracowanie architektury łączacej sieci stacjonarne z komutacją kanałów z siecią Internet. Pierwsza wersja specyfikacji takiej architektury nosi nazwę TISPAN Release 1 i bazuje na architekturze 3GPP IMS.

[2] Pierwsza wersja specyfikacji sieci NGN

[3] Patrz też rozdziały 4.2 oraz 5.3.

[4]  Sieć NGN jest siecią opartą na technologii V2OIP, patrz też rozdział 4.3.

[51] TISPAN DES/TISPAN-02019-NGN-R1 “PSTN/ISDN Emulation Sub-system (PES); Functional architecture“, Marzec 2006

[52] TISPAN DTS/TISPAN-03044-NGN-R1 „ IMS-based PSTN/ISDN Emulation Stage 3 specification”, Maj 2006

Prawo Pascala, wykorzystywanie płynów w układzie zamkniętym

Hydraulika  –  jest  to nauka badająca  prawa  stanu  równowagi  i  ruchu cieczy.  Zagadnienia dotyczą między innymi urządzeń i budowli hydrotechniczych maszyn hydraulicznych i mechanizmów.

Żyjący w latach 1623-1662 – francuski matematyk, fizyk, pisarz i filozof Blaise Pascal badał między innymi zjawiska dotyczące ciśnienia atmosferycznego  i hydrostatyki.

W roku 1651 sformułował prawo przyjęte jako prawo Pascala mówiące, że: „Ciśnienie wywarte w jednym punkcie cieczy znajdującej się w równowadze (mechanicznej i cieplnej) rozchodzi się jednakowo we wszystkich kierunkach”.

Ciśnienie cieczy i gazu mierzymy wartością siły z jaką ciecz naciska na jednostkę powierzchni stykającego się z nią ciała.

Rys. 1   Ciecz w naczyniu zamkniętym poddana naciskowi tłoka.

rys1

Na pewną masę cieczy wywiera się za pomocą tłoka nacisk siłą F. Jeżeli pole przekroju poprzecznego tłoka wynosi A, to ciśnienie P jakie wywierane jest na jednostkę powierzchni wynosi       P = F / A

Gdzie:

F – siła w N

A – pole przekroju w m2

P – ciśnienie cieczy w Pa (paskalach)

Jednostką ciśnienia i naprężenia mechanicznego w układzie SI jest pascal – Pa

1 Pa = 1 N / m2

Współczynniki zamiany jednostek

1 N / m2 = 1 Pa

1 bar = 105 Pa = 0,1 Mpa

1 kG / m2 = 9,8066 Pa

1 kG / cm2 = 98,066 Pa

1 atm = 1 kG / cm2 = 98,066 Pa

Napęd hydrauliczny  – jest to napęd wywołany ruchem cieczy pod ciśnieniem, oparty na prawie Pascala, natomiast sterowanie hydrauliczne jest procesem kierowania pracą maszyny lub urządzenia, za pomocą cieczy pod ciśnieniem.

Każdy rodzaj napędu posiada swe zalety i wady. Oto niektóre z nich.

Więcej informacji na temat tej pracy znajdziecie na stronie:

Hydrauliczny sprzęt ratowniczy na wyposażeniu Straży Pożarnej

Ręczne i nożne pompy hydrauliczne

Występują w postaci jedno, dwu i trzystopniowej o mocnej zwartej konstrukcji i dużej sprawności. Pompy posiadają automatyczne zawory przełączające na poszczególne stopnie sprężania, zawory spustowo-ciśnieniowe ustawione na wymagane maksymalne ciśnienie i automatyczne odpowietrzenie.

Praca ich odbywać się może w pomieszczeniach zamkniętych i strefach zagrożonych wybuchem.

Rys. 11  Pompy mechaniczne, od lewej – dwustopniowa pompa nożna, trójstopniowa pompa ręczna.

r11Źródło: Archiwum autora

Architektura funkcjonalna i interfejsy sieciowe modułu MS/MRF

Architektura funkcjonalna i interfejsy MRF wg ETSI

Rys. 6 Architektura funkcjonalna MRF wg ETSI.

1-1

Powyższy rysunek przedstawia architekturę funkcjonalną bloku MRF wg ETSI ([39], [38];.

Wyróżnione na rysunku interfejsy zestawiono w poniższej tabeli:

Nazwa interfejsu Protokół w ramach interfej su Opis
Mr SIP + dodatkowy protokół Jest to interfejs pomiędzy MRF a serwerem S-CSCF.

Służy do sterowania pracą MRFC za pomocą protokołu SIP, przez aplikację usługową zlokalizowaną na serwerze aplikacji (AS). S-CSCF pracuje tutaj jako element routujący wiadomości pomiędzy serwerem aplikacji a modułem MRF51. Funkcjonalność         multimedialna serwera mediów wykraczająca poza standardowe mechanizmy SIP jest kontrolowana poprzez dodatkowy protokół przenoszony w polu SDP.52
Mp H.248 / Megaco Interfejs do sterowania blokiem MRFP przez MRFC. Interfejs ten powinien wspierać w pełni standard H.248 ([39]), ponadto umożliwiać późniejsze wprowadzanie rozszerzeń,jeśli zostaną zdefiniowane.

Styk Mp jest wykorzystywany tylko w przypadku, gdy implementacja MRF zakłada funkcjonalną separację bloków MRFP i MRFC. Wówczas możliwe jest aby jeden MRFC zarządzał pracą kilku bloków MRFP.

W sytuacji, gdy MRF stanowi jeden moduł funkcjonalny, interfejs Mp nie jest implementowany i nie wyróżnia się bloków MRFP i MRFC. Szczegółowe wymagania funkcjonalne dla styku Mp (listę obowiązkowych i opcjonalnych funkcjonalności) zdefiniowano w [42], specyfikację protokołu na tym styku opisano w [43].
51  Patrz rozdział 6.

52  ETSI nie określiło jednoznacznie dodatkowego protokołu na styku Mr. W rozdziale 7 niniejszej pracy zawarto analizę protokołów możliwych do wprowadzenia na tym styku.
Mb RTP Zdefiniowany w [38]jako interfejs do usług sieciowych IPv6, w tym usług transportowych.

W rzeczywistych implementacjach modułu MRF wykorzystywany jest transport w ramach sieci z adresacją IPv4.

W ramach tego interfejsu w pakietach protokołu RTP transportowane są strumienie multimedialne.
Sr HTTP Interfejs zdefiniowany w [40]. Umożliwia pobieranie różnych dokumentów przez MRFC (np. pliki ze skryptami VXML) w ramach delegacyjnego modelu sterowania modułem MS.[1] W tym celu wykorzystuje się protokół HTTP.
Cr HTTP

TCP/SCP

 Interfejs zdefiniowany w [40] na potrzeby protokolarnego modelu sterowania serwerem mediów z wykorzystaniemdedykowanego kanału sterowania. Przesyłane są tutaj wiadomości sterujące blokiem MRFC (Jako protokół transportowy ETSI zaleca TCP/SCTP).

Interfejs umożliwia również pobieranie przez MRFC różnych dokumentów z sieci (np. pliki ze skryptami VXML)[2] – w tym celu wykorzystywany jest protokół HTTP.
Rf DIAMETER Interfejs do przesyłania informacji taryfikacyjnej w ramach off-line charging w architekturze IMS[3].
Ro DIAMETER Interfejs do przesyłania informacji taryfikacyjnej w ramach on-line charging w architekturze IMS[4].
Tabela 1 Interfejsy modułu MRF wg ETSI

Architektura funkcjonalna i interfejsy serwera mediów w architekturze V2OIP

Jeżeli blok MS nie jest rozpatrywany w kontekście sieci IMS, wówczas architekturę funkcjonalną oraz interfejsy można przedstawić następująco:

Rys. 7 Ogólna architektura funkcjonalna i interfejsy serwera mediów

2Na rysunku wyróżniono następujące warstwy funkcjonalne:

  • Warstwa sterowania

Do zadań tej warstwy należy:

o komunikacja z otoczeniem poprzez protokoły sieciowe

  • SIP – komunikacja z serwerem aplikacji, który korzysta z zasobów MS na potrzeby aplikacji usługowych
  • DIAMETER – przesyłanie danych taryfikacyjnych do systemów bilingowych na potrzeby mechanizmu chargingu
  • HTTP – pobieranie dokumentów, plików audio/video na potrzeby konkretnych operacji niższych warstw MS
  • TCP/SCTP – obsługa wymiany wiadomości protokołu sterowania serwerem mediów [5]

o Zarządzanie pracą dwóch niższych warstw na podstawie logiki usługi, która korzysta z zasobów MS

o Zarządzanie zasobami operacyjnymi MS – przydzielanie zasobów do poszczególnych operacji celem obsłużenia przychodzących żądań. Zasoby zależą od fizycznej implementacji MS. W razie braku zasobów na obsłużenie danego żądania, serwer mediów wysyła odpowiedź opisującą zaistniały problem.

  • Warstwa przetwarzania sygnałów

W tej warstwie MS wykonuje wszelkie operacje na sygnałach cyfrowych (przetwarzanie sygnałów, syntetyzowanie, miksowanie etc)

  • Warstwa transportowa

Jest to warstwa odpowiedzialna za wysyłanie/odbieranie strumieni multimedialnych z wykorzystaniem protokołu RTP.

Na rysunku pominięto interfejsy pomiędzy poszczególnymi warstwami. MS jest tutaj rozpatrywany jako jeden blok funkcjonalny . Wewnętrzne mechanizmy MS są nieistotne z punktu widzenia realizacji usług multimedialnych.

Istotne jest natomiast, aby interfejsy adresowały wszystkie funkcje MS. Protokoły wspierane w ramach przedstawionej na powyższym rysunku generycznej architektury serwera mediów dla sieci V OIP są identyczne z protokołami wymienionymi przez ETSI dla MRF. Zbieżność ta wynika z faktu, iż na rynku telekomunikacyjnym serwery oferujące funkcjonalność MS obecne były zanim wyklarowała się idea IMS. MRF stanowi zatem abstrakcję MS w ramach koncepcji IMS.

Porównanie architektury MS i MRF

Potwierdzeniem tezy, iż nie jest błędem zamienne stosowanie terminów MS i MRF na określenie tego samego bloku funkcjonalnego, jest porównanie przedstawionych wyżej architektur funkcjonalnych. Ilustruje to poniższy rysunek: [6]

Rys. 8 Zestawienie architektury MS i MRF

3Jeżeli MS jest postrzegany jako blok MRF, wówczas można mówić o interfejsie pomiędzy warstwą sterującą a warstwami przetwarzania sygnałów i transportową, w postaci protokołu H.248 / MEGACO.

Serwer mediów typu I

W sytuacji gdy MS pełni następujący zbiór funkcji:

  • Operacje na sygnałach cyfrowych audio/video
  • Transkodowanie
  • Odtwarzanie zapowiedzi, plików audio/video, pobieranie cyfr i symboli DTMF
  • Rejestrowanie strumieni audio / video (nagrywanie głosu, obrazu, Lawful Interception)
  • Miksowanie strumieni na potrzeby prostych konferencji (trójstronnych połączeń)

wówczas można mówić o tzw. serwerze mediów typu I (MS typu I). Jego architekturę przedstawia rysunek:

Rys. 9 Serwer mediów typu I

4

Jak widać, funkcjonalnie MS typu I odpowiada blokowi MRFP. Jego praca sterowana jest za pomocą protokołu H.248/Megaco, który adresuje wymienione funkcje. Warstwa sterowania, opisana w ramach architektury MS, jest w tej sytuacji zlokalizowana na serwerze aplikacji, wspierającym protokół H.248.

Serwer mediów typu II

Można mówić o serwerze mediów typu II w sytuacji, gdy MS wspiera wszystkie funkcje MS typu I oraz dodatkowo:

  • W spomaga realizacj ę zaawansowanych usług konferencyj nych
  • Zawiera funkcje IVR, ASR, TTS etc.
  • Wspiera standard VXML oraz inne języki oparte na XML (CCXML, SCXML)
  • Wspiera inne funkcjonalności MS wymienione w rozdziale
  • Wspiera interfejs oparty na protokole SIP, poprzez który adresowane są wszystkie jego funkcjonalności

Architekturę MS typu II ilustruje rysunek:

Rys. 10 Serwer mediów typu II

5MS typ II to serwer mediów o rozproszonej architekturze, w której warstwa sterowania funkcjonalnie odpowiada blokowi MRFC i jest oddzielona od pozostałych warstw poprzez interfejs oparty na protokole H.248. Pozostałe dwie warstwy tworzą blok odpowiadający blokowi MRFP.

Pracą całego MS steruje serwer aplikacji poprzez protokół SIP wzbogacony o dodatkowe funkcjonalności[7].

Można zatem powiedzieć, że MS typu I to „podstawowy” typ serwera mediów, udostępniający proste operacje na strumieniach multimedialnych. MS typu II to „zaawansowany” MS udostępniający szeroki wachlarz funkcjonalności[8].

Należy dodać, iż w sytuacji, w której nie rozpatruje się interfejsu opartego na H.248 i nie ma funkcjonalnej separacji pomiędzy warstwą sterowania a pozostałymi warstwami MS, również mówi się MS typu II.

Architektura MS/MRF a funkcje TTS, ASR, IVR.

W przypadku serwerów mediów dostępnych na rynku telekomunikacyjnym bardzo często zdarza się, że producenci nie implementują wszystkich funkcjonalności w ramach swojego produktu. Oferowana jest natomiast integracja MS z rozwiązaniami zewnętrznych firm, zapewniającymi określone funkcje. Dotyczy to najczęściej funkcjonalności ASR / TTS, nierzadko jednak bloki odpowiedzialne za interpretację skryptów VXML[9], jak również repozytoria plików audio/video czy skryptów dla różnych języków opartych o XML, stanowią oddzielne moduły od innych dostawców. Pozostałe funkcje (takie jak przetwarzanie sygnałów odtwarzanie/nagrywanie multimediów) są zwykle wspierane przez producentów MS.

W związku z powyższym możliwe jest różne usytuowanie bloków odpowiadających za wymienione funkcje na tle opisanej powyżej architektury funkcjonalnej MS/MRF. Można wyróżnić dwa podejścia opisane w poniższych podrozdziałach.

Wsparcie wszystkich funkcjonalności w ramach bloków funkcjonalnych MS/MRF

To podejście ilustruje poniższy rysunek:

Rys. 11 Funkcjonalności MS/MRF wspierane przez wewnętrzne bloki funkcjonalne

9

Rysunek obrazuje serwer mediów, który nie wymaga dodatkowej integracji z zewnętrznymi blokami funkcjonalnymi. Taki MS jest „widziany” jako jednolite „czarne pudełko” o określonym zestawie funkcjonalności. Z punktu widzenia współpracy z innymi elementami sieci istotne jest jedynie, aby wspierane były określone interfejsy.

Rysunek ilustruje również logiczne usytuowanie wyróżnionych funkcji względem MRFP i MRFC. IVR, TTS i ASR są rozproszone pomiędzy MRFC i MRFP, ponieważ ich realizacja wymaga sterowania pracą MRFP (synteza sygnałów cyfrowych, transport strumieni) wg. skryptów interpretowanych przez MRFC. Repozytoria skryptów oraz interpretery języków skryptowych należy funkcjonalnie przypisać do MRFC. Z kolei repozytoria plików A/V mogą być logicznie zlokalizowane w ramach MRFC lub MRFP.

Takie podejście znajduje odzwierciedlenie w specyfikacji ETSI, w dokumencie [42]. Wymieniono w nim zestaw funkcjonalności wspieranych przez interfejs Mp. Zawarta tam lista obejmuje:

  • Odgrywanie tonów rozmównych
  • Odgrywanie komunikatów
  • Nagrywanie strumieni audio
  • Text to Speech
  • Automatic Speech Recognition
  • Pobieranie cyfr i symboli DMTF
  • Odtwarzanie multimediów
  • Nagrywanie multimediów
  • Konferencja audio
  • Konferencja multimedialna
  • Transkodowanie strumieni
  • Audio o Video

Wymienione funkcjonalności są podzielone pomiędzy MRFP i MRFC i w całości przez nie realizowane, przy czym dla każdej z nich wyróżniono zbiór obowiązkowych jak i opcjonalnych operacji.

Lokalizacja pewnych funkcjonalności w zewnętrznych blokach funkcjonalnych i ich integracja z MS/MRF.

Ten wariant został przedstawiony na poniższym rysunku:

Rys. 12 MS/MRF zintegrowany z zewnętrznymi blokami funkcjonalnymi

9-1

Na rysunku przedstawiono MS „w otoczeniu” zewnętrznych modułów o określonej funkcjonalności. Ich współpraca z serwerem mediów przebiega poprzez wyróżnione interfejsy, które podzielić można na dwie grupy:

  • Interfejsy sterujące: A, B

Są to interfejsy pomiędzy modułami ASR/TTS a MRFC służące do sterowania pracą tych modułów. W rzeczywistych implementacjach wykorzystywanym tutaj protokołem jest zazwyczaj Media Resource Control Protocol (MRCP), zdefiniowany w [17]. Został on zaprojektowany specjalnie celem kontrolowania i wykorzystywania takich zasobów sieciowych jak syntezatory mowy, elementy rozpoznające mowę, faksy, detektory sygnałów etc.

  • Interfej sy transportowe

o a, b – służą do pobierania plików audio/video na potrzeby odtwarzania treści multimedialnej dla abonentów. Wykorzystuje się tutaj protokół HTTP. Pliki mogą być pobierane przez MRFC (interfejs a) w sytuacji, gdy do ich dystrybucji z MRFC do MRFP nie jest konieczny osobny interfejs (bloki te zintegrowane są ze sobą). W przeciwnym razie MRFP pobiera pliki (interfejs b), po uprzednim wskazaniu właściwego pliku przez MRFC.

o c – służy do pobierania przez MRFC plików zawierających skrypty języków opartych na XML (VXML, SCXML, CCXML). Tutaj również wykorzystuje się protokół HTTP.

o 1, 2 – interfejsy do przesyłania strumieni multimedialnych do/z bloków ASR/TTS. Wykorzystuje się tutaj protokół RTP.

Należy podkreślić, iż w rzeczywistych implementacjach sieci telekomunikacyjnej serwer mediów oraz współpracujące z nim moduły (zilustrowane na powyższym rysunku) są najczęściej traktowane „całościowo” jako jeden blok funkcjonalny MS/MRF (mimo, iż moduły „składowe” pochodzą od różnych producentów i nie stanowią jednolitego elementu sieciowego). Upraszcza to sterowanie wszystkimi modułami, oczywiście przy spełnionym warunku, iż są one zintegrowane ze sobą oraz ich funkcjonalności zostają wyeksponowane poprzez standardowe interfejsy zdefiniowane dla serwera mediów.

Rzeczywiste implementacje zależą silnie od producentów i operatorów telekomunikacyjnych i mogą znacznie różnić się między sobą.

[1]   Patrz rozdział 6.6.2.1

[2]   Patrz rozdział 6.6.2.2.

[3]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

[4]   Dokładniejsze omówienie tego interfejsu wykracza poza zakres niniejszej pracy.

[5]   Patrz rozdział 6.6.2.1

[6]    W rozdziałach 5.4.3.1 oraz 5.4.3.2 rozważono podział MS na bloki funkcjonalne odpowiadające architekturze MRF.

[7]   Patrz rozdział 6.

[8]   Możliwe jest oczywiście, aby MS typu II udostępniał jedynie zbiór funkcji MS typu I. Będą one dostępne poprzez protokół SIP.

[9]   Można rozważać również interpretery innych języków skryptowych, przykładowo CCXML, SCXML etc. Patrz rozdział 6.6.4.

Wnioski

System Joomla! okazał się przyjaznym w użytkowaniu systemem oraz w pełni potwierdził on swoją przynależność do zaawansowanych systemów CMS liczących się w Internecie. [niestety, coraz mniej]

Na podstawie opisanych wcześniej wybranych stron internetowych stwierdzam, że systemy CMS są rozpowszechnione i z powodzeniem wykorzystywane nawet przez amatorów.

Strona wykonana w systemie Joomla umożliwia równoczesne publikowanie treści prze wiele osób bez informatycznego doświadczenia.

Zaletą systemu Joomla jest fakt, że ciągle jest on rozwijany i ulepszany – nowe wersje pojawiają się średnio co dwa miesiące.

Systemy CMS należące do otwartego oprogramowania stosuje się w tworzeniu serwisów, gdzie niepożądana zmiana treści nie będzie miała istotnego wpływu na działanie danej instytucji, a więc przede wszystkim w portalach informacyjnych, komunikacyjnych i edukacyjnych.

W wielu wypadkach system CMS nie jest w stanie zastąpić profesjonalnych programów, również stworzenie nowych komponentów jest czasochłonne i kosztowne.

Często problemem oprogramowania open source jest brak pełnej dokumentacji. Użytkownik może skorzystać z wiedzy zawartej na stronach internetowych, forach dyskusyjnych lub zamówić płatne wsparcie techniczne. Należy zauważyć, że czas odpowiedzi na zadane na oficjalnym forum pytanie, to od kilkunastu minut do około godziny, co jednak nie gwarantuje rozwiązania problemu.

Wspieranie i upowszechnianie systemów open-source może dać realne korzyści finansowe.

Joomla! to ciekawe rozwiązanie dla osób prywatnych oraz instytucji pragnących mieć stronę internetową i warto przyjrzeć się temu systemowi bliżej.

Literatura

Boiko B., „Content Management Bible (2nd Edition)”, Wiley 2004 Danowski B., „Tworzenie stron WWW w praktyce.”, Helion, Gliwice 2007 Frankowski P., „CMS. Jak szybko i łatwo stworzyć stronę WWW i zarządzać nią.”, Helion, Gliwice 2007

Graf H., „Joomla! System zarządzania treścią.”, Helion, Gliwice 2007

Howil W., „CMS. Praktyczne projekty”, Helion, Gliwice 2007

Jarosz D., „Płatny hosting czyli gdzie się ulokować”, Magazyn Internet 2006

Kolbusz E., „Informatyka w zarządzaniu”, Zeszyt naukowy Instytutu Informatyki w Zarządzaniu, Uniwersytet Szczeciński, Szczecin 1999

Krug S., „Nie każ mi myśleć o życiowym podejściu do funkcjonalności stron internetowych”, Helion, Gliwice 2006

Linderman M., Fried J., “Przyjazne witryny WWW”, Helion, Gliwice 2005 Nielsen J., „Projektowanie funkcjonalnych serwisów internetowych”, Helion, Gliwice 2004

Rosenfeld L., Morville P., „Architektura informacji”, Helion, Gliwice 2003 Sosna Ł., „Drupal. CMS system zarządzania treścią”, Nakom, Poznań 2008 Ullman L., „Dynamiczne strony WWW. PHP i MySQL”, Helion, Gliwice 2004 Zeldman J., „Projektowanie serwisów WWW. Standardy sieciowe.”, Helion, Gliwice 2007

Niederst Robbins J., „HTML i XHTML. Leksykon kieszonkowy.”, Helion, Gliwice, 2006

Serwer mediów – definicja, funkcjonalność i architektura

Niniejszy rozdział zawiera definicję bloku funkcjonalnego serwera mediów (Media Server, MS). Przedstawiono zakres jego funkcjonalności, opisano architekturę funkcjonalną oraz interfejsy do innych elementów sieciowych. Zaproponowano wprowadzenie dwóch typów serwera w zależności od roli pełnionej w sieci i zbioru wspieranych funkcji.

Definicja pojęcia serwera mediów

Przyjmijmy, że:

Serwer mediów (Media Server, MS) to element funkcjonalny pracujący w sieci pakietowej typu VOIP [1], który dokonuje operacji na strumieniach audio i video oraz integruje funkcjonalności niezbędne do realizacji różnego typu usług multimedialnych. Źródłem strumieni mogą być inne elementy sieciowe jak również lokalne zasoby serwera mediów (np. pliki multimedialne, syntezatory mowy etc).

Odnosząc się do przedstawionej w rozdziale 4.1 definicji, serwer mediów wspiera realizację usługi multimedialnej poprzez udostępnienie swojej funkcjonalności. Inne elementy sieciowe mogą przesyłać do MS żądanie dokonania pewnej operacji na strumieniu multimedialnym.

MS to bierny moduł, który nie zawiera żadnej logiki usługowej, nie ma więc możliwości samodzielnego świadczenia usług. Jego zasoby są dostępne dla wielu aplikacji usługowych jednocześnie, wykorzystywane zgodnie ze zdefiniowaną w aplikacjach logiką. Innymi słowy, MS to pewnego rodzaju zaawansowany „procesor sygnałowy” w sieci VOIP.

Umiejscowienie w danej sieci VOIP modułu MS pozwala na zlokalizowanie wszelkich operacji na sygnałach w jednym elemencie, do którego mogą odwoływać się istniejące i nowo wprowadzane aplikacje usługowe. Eliminuje to konieczność dodawania osobnych, dedykowanych modułów.

[1]   Należy podkreślić, iż definicja nie określa styku pomiędzy MS a sieciami z komutacją kanałów. Ten styk jest realizowany poprzez bramy medialne (Media Gateways), które są modułami o innej funkcjonalności niż MS. MS pracuje tylko w sieci z komutacją pakietów.

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).

Rozszerzenia protokołu w kontekście usług multimedialnych

Protokół SIP dzięki prostemu mechanizmowi działania oraz przejrzystości składni jest szeroko wykorzystywany w ramach rozmaitych usług telekomunikacyjnych i internetowych. Nie pozwala jednak na realizację wyrafinowanych usług multimedialnych.

W odpowiedzi na ograniczenia protokołu, w ramach IETF podjęto prace, których rezultatem są liczne dokumenty opisujące rozszerzenia „podstawowej” specyfikacji SIP zawartej w [1]. Ponadto nieustannie opisywane są nowe możliwości zastosowania protokołu SIP.

W kontekście zastosowań multimedialnych, spośród opublikowanych draftów i norm RFC można wyróżnić m.in.:

  • [6] – definicja wiadomości SIP REFER
  • [7] – definicja wiadomości SIP INFO
  • [14] – definiuje architekturę usługi konferencji opartej na SIP
  • [24] – specyfikuje mechanizm reprezentowania pewnych usług multimedialnych w postaci adresów agentów SIP
  • [33] – opisuje sposób sterowania rozproszonym systemem konferencyjnym z wykorzystaniem protokołu SIP
  • [34] – specyfikuje mechanizm wskazywania skryptów VXML w wiadomości SIP przesyłanej do elementu sieciowego zdolnego do interpretacji tych skryptów
  • [36] – definicja zbioru funkcjonalności podstawowej interakcji z użytkownikiem w oparciu o protokół
  • [37] – definicja zbioru podstawowych funkcjonalności konferencyjnych

Wykorzystanie protokołu SIP do realizacji różnych usług multimedialnych to temat aktualnie szeroko rozważany w ramach organizacji standaryzacyjnych. Niniejsza praca dyplomowa pokazuje, jak wiele kwestii w tej dziedzinie wymaga jeszcze doprecyzowania.

—

[1] IETF RFC 3261 “SIP: Session Initiation Protocol”, Czerwiec 2002