OpenIMSCore

Autori:
Bc. Igor Kvasnička
Bc. Daniel Ščepka


Študijný program: PKSS
Predmet: NGN siete, služby a protokoly
Akademický rok: 2011/12

1. IMS

IP Multimedia Subsystem alebo IP Multimedia Core Network Subsystem, skrátene IMS je navrhnutý systém multimediálnych služieb pre internetový protokol IP. Vo svojej podstate nejde o technológiu ako takú, ale skôr sa dá hovoriť o sieťovej architektúre.

Ide o systém, ktorý bol pôvodne navrhnutý pre mobilné aplikácie štandardov rodín 3GPP. IMS v dnešnej dobe má veľký vplyv na telekomunikačný priemysel, a to tak na pevné drôtové ako aj bezdrôtové siete. Hlavnou úlohou pri návrh tohto systému bolo vytvorenie fixnej a mobilnej konvergencie na podporu hlasových, obrazových a iných multimediálnych služieb zo zariadení pripojených do pevných a bezdrôtových sietí. To znamená aj prepojenie internetového sveta s celulárnymi sieťami pre podporu multimediálnej komunikácie. Pre ilustráciu je zovšeobecnená konvergencia týchto sietí zobrazená na nasledujúcom obrázku.

Konvergencia sietí v spolupráci s IMS
Obrázok 1 Konvergencia sietí v spolupráci s IMS

Samotný IMS je založený na internetových štandardoch. Vedúcim, resp. kľúčovým prvkom je protokol SIP (Session Initiation Protocol), ktorého primárnou úlohou je zriadenie, správa a ukončenie spojenia v IP sieťach.

1. 1. Architektúra IMS

Celková architektúra IMS je veľmi zložitá a je zložená z množstva rôznych entít a komponentov, ktoré sú distribuované v rámci siete.

Základnú štruktúru IMS sa z logického pohľadu skladá z:

  • Užívateľské rozhranie – V podstate ide o užívateľské zariadenia (angl. User equipment), ktorými užívatelia komunikujú so IMS sieťou. Ide o tzv. koncové zariadenia siete.
  • Prístupová sieť – Ide o časť siete (Access Network), pomocou ktorej užívatelia pristupujú do celej siete.
  • Základná sieť – Táto časť siete (angl. Core Network) tvorí jadro, akísi základ celej architektúry IMS a poskytuje všetky základné funkcie.
  • Aplikačná vrstva – Táto vrstva sa skladá z aplikačných a webových serverov, ktoré poskytujú koncovým užívateľom jednotlivé služby.

Logické rozdelenie IMS architektúry
Obrázok 2 Logické rozdelenie IMS architektúry

Architektúra IMS podporuje viacero aplikačných serverov, ktoré poskytujú tradičné telefónne služby ale aj iné multimediálne služby ako instant messaging, push-to-talk, streamované video, multimediálne správy, atď.

Základné komponenty architektúry z funkčného hľadiska sú:

  • HSS (angl. Home Subscriber Server) – Databáza účastníkov domácej siete.
  • CSCF (angl. Call Session Control Server) je časť architektúry slúžiaca na registráciu koncových užívateľov. Taktiež poskytuje smerovanie SIP správ v rámci siete IMS a podporu kvality služieb (QoS).
  • BGCF (angl. Breakout gateway control function) – Vyberá sieť, v ktorej bude prepojenie s PSTN sieťou.
  • MGCF (angl. Media gateway control function) – Táto entita - brána - podporuje signalizáciu pomocou SIP správ. Zároveň podporuje rozdelenie relácií v rámci viacerých brán.
  • MSCF (angl. Media server function control) – Slúži na riadenie zdrojov na serveroch.
  • SIP-AS (angl. SIP applications server) – Server, na ktorej sú spustené služby.

Funkčné rozdelenie IMS architektúry
Obrázok 3 Funkčné rozdelenie IMS architektúry

IMS CSCF sa zároveň dajú rozdeliť na nasledujúce elementy:

  • P-CSCF (angl. Proxy CSCF) – SIP proxy.
  • I-CSCF (angl. Interrogating CSCF) – Bod, cez ktorý prechádzajú všetky SIP správy z vonkajších sietí.
  • S-CSCF (angl. Serving CSCF) – SIP server pre signalizáciu.

S-CSCF

S-CSCF plní v rámci IMS systému niekoľko činností a má rôzne rozhrania umožňujúce komunikáciu s ostatnými entitami v rámci IMS systému. Je to centrálny a dalo by sa povedať, že aj hlavný uzol pre správu a manažovanie SIP relácií v IMS systéme pre užívateľské zariadenia.

Jednou z jeho hlavných úloh je prepojenie s databázou účastníkov (HSS), v ktorej sa nachádzajú informácie o účastníkoch. S-CSCF funguje ako tzv. „registrar“ pre IMS sieť, pomocou ktorého sa napr. overuje pravosť účastníka, ktorý žiada o vstup do IMS siete. Pri tomto prepojení s HSS využíva Diameter (rozhrania Cx a Dx).

Taktiež jeho úlohou je smerovanie (typicky pomocou ENUM - Electronic Numbering) a vykonávanie politiky operátora.

Poloha S-CSCF v rámci architektúry IMS
Obrázok 4 Poloha S-CSCF v rámci architektúry IMS

P-CSCF

P-CSCF je v podstate proxy server, teda je to prvý kontaktný bod IMS Core siete. Taktiež cez neho prechádzajú všetky registračné signalizačné správy. Toto proxy zariadenie určuje, ktorý CSCF bude kontrolovať hovor. Robí tak komunikáciu s I-CSCF v rámci siete, kde bol hovor nadviazaný, alebo v domovskej sieti účastníka.

V prípade, že účastník má viac zariadení, môže na komunikáciu využívať rôzne P-CSCF, avšak S-CSCF bude vždy rovnaké, pretože S-CSCF je priamo prepojené s databázou HSS.

Rozloženie komponentov v rámci IMS siete
Obrázok 5 Rozloženie komponentov v rámci IMS siete

I-CSCF

Používa sa na propagovanie počiatočných SIP žiadostí do S-CSCF. I-CSCF taktiež používa rozhranie Cx pre prístup k informáciám o účastníkov pomocou databázy účastníkov HSS, podľa ktorých zistí, ktoré S-CSCF má kontaktovať.

2. OpenIMS Core

OpenIMS Core je open source projekt spoločnosti Fraunhofer Fokus. Ide o projekt, teda softvér, ktorý implementuje funkcionalitu IMS – troch typov CSCF (P-CSCF, S-CSCF a I-CSCF) a mierne oklieštenej, resp. odľahčenej databázy účastníkov HSS.

OpenIMSCore

Tieto komponenty tvoria základnú IMS/NGN architektúru, ktorá sa používa v štandardoch 3GPP, 3GPP2, ETSI TISPAN a PacketCable. Používajú sa na výmenu SIP správ, registráciu užívateľov a na zriadenie a ukončenie multimediálnych relácií. Všetky tieto komponenty sú na báze open source a modifikácia a redistribúcia je pod GNU General Public License. Aj to je jeden z dôvodov prečo sme si vybrali práve tento systém. Okrem toho sme sa rozhodli pre tento systém aj preto, že ponúka skvelé vývojárske prostredie, podporuje množstvo služieb, interoperabilitu s webovými službami a je škálovateľný.

3. Odporúčané systémové požiadavky

3. 1. Hardvérové požiadavky

  • Stroj schopný pracovať s bežnou distribúciou operačného systému Linux
  • Odporúčania pre zvýšenie výkonnosti:
    • pridanie niekoľko gigabajtov pamäti RAM
    • použiť čo najviac CPU/jadier
    • gigabitový Ethernet

3. 2. Sieťové požiadavky

  • Pre lepšiu prácu je odporúčané mať k dispozícií verejnú IP a nepoužívať Inter-domain NAT
  • Ovládateľný DNS server

3. 3. Softvérové požiadavky

  • ~100 MB miesta na disku
  • GCC3/4, make, JDK1.5, ant
  • Nainštalovaný MySQL, prípadne iný databázový systém
  • bison, flex
  • libxml2 (> 2.6), libmysql
  • Linux kernel 2.6 a ipsec-tools (setkey) (pri použití IPSec)
  • curl a libcurl4-gnutls-dev
  • Voliteľné: openssl pre použitie TLS
  • Nainštalovaný a spustený bind (or prípadne iný name server)
  • Nainštalovaný prehliadač

4. Naše systémové vybavenie

Vybavenie OpenIMSCore:

  • Oracle VirtualBox
  • Počet jadier: 3
  • Pamäť RAM: 2,50 GB
  • Kapacita disku HDD: 8,00 GB
  • Použitá kapacita HDD: 3,20 GB
  • Sieťové rozhranie: adaptér v stave Bridged (vo virtuálnej mašine)
  • Operačný systém: Ubuntu 10.04.4 (x86)

5. Inštalácia OpenIMSCore

5. 1. Zdrojové kódy

Aktuálne zdrojové kódy sa nachádzajú na adrese:

http://svn.berlios.de/svnroot/repos/openimscore

Tieto zdrojové kódy boli vopred nastavené tak, aby boli umiestnené v adresári /opt/OpenIMSCore. Preto vytvoríme tento adresár a pridelíme mu vlastníctvo používateľa.

mkdir /opt/OpenIMSCore/
chown-R /opt/OpenIMSCore/

*Pozn. V prípade, že nemáme práva root, použijeme pred príkazmi príkaz „sudo“. Miesto zadaného výrazu použijeme meno aktuálneho používateľa.

Následne sa presunieme do nami vytvoreného adresára a vytvoríme ďalšie adresáre, do ktorých umiestnime kód zo spomenutého SVN servera, ktoré slúžia na nainštalovanie CSCF a FHoSS.

cd /opt/OpenIMSCore
mkdir ser_ims
mkdir FHoSS

Následne tieto kódy stiahneme z SVN servera do príslušných adresárov.

cd /ser_ims
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims

cd /FHoSS
svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS

5. 2. Kompilácia

Kompilácia sa skladá z dvoch časí.

• Prvá časť sa vykonáva z adresára ser_ims a vykonáva sa nasledujúcimi príkazmi.

cd ser_ims
make install-libs all

*Pozn. Počas kompilácie sa môže vyskytnúť problém, ktorý spôsobí zlyhanie kompilácie. Pravdepodobne toto zlyhanie je spôsobené chýbajúcimi prerekvizitami, ktoré sú zahrnuté v systémových požiadavkách.

Pred druhou časťou je potrebné overiť verziu nainštalovanej verzie JDK – Java Development Kit. Pre našu inštaláciu je potrebná verzia JDK 5 (t.j. JDK verzia 1.5) alebo vyššia. Verzia JDK sa dá overiť pomocou príkazu:

java –version

Výstupom by mala byť napríklad: (pre JDK verziu 1.6)

Zistenie Java verzie

V prípade, že vaša verzia je nižšia ako JDK 5, je treba nainštalovať novšiu.

Taktiež je potrebné sa uistiť, že mám dobre nastavené cestu s premennej JAVA_HOME. Toto nastavenie môžeme otestovať príkazom

locate javac

alebo

whereis javac

Tento príkaz nám lokalizuje cestu k programu javac, ktorý je reálne v JAVA_HOME/bin adresári. V prípade, že tento príkaz nevráti nič, tak je potrebné túto premennú nastaviť manuálne pomocou príkazu:

export JAVA_HOME="<path>"

kde <path> (napr. /usr/lib/jvm/java 6 sun/) označuje cestu k adresáru, kde je nainštalovaný JDK.

Nastavenie JAVA_HOME

V prípadne, ak nechceme nastavovať systémovú premennú JAVA_HOME v každom spustenom terminály, pridáme hore uvedenú konfiguráciu tejto premennej do súboru ~/.bashrc.

• Druhá časť sa vykonáva z adresára FHoSS a vykonáva sa nasledujúcimi príkazmi.

cd FHoSS
ant compile
ant deploy

*Pozn. V prípade, že nemajú všetky súbory jar právo vykonávania, môže nastať zlyhanie vykonávanie príkazov. Vtedy je potrebné priradiť týmto súborom tieto práva a vykonať príkazy znovu.

5. 3. Konfigurácia prostredia

Prednastavené parametre sú:

  • Doména - open-ims.test
  • MySQL - len lokálny prístup

Odporúča sa najprv otestovať systém s prednastavenými nastaveniami a až potom vykonať zmeny konfigurácie ako:

  • Zmena lokálnej IP 127.0.0.1 vašou IP adresou
  • Zmena prednastavenej domény open-ims.test vlastnou doménou
  • Zmena hesla do databázy

*Pozn. Tieto zmeny sa vykonávajú v súbore ser_ims/cfg/configurator.sh

Konfigurácia DNS Server

Ako prvé je potrebné mať zapnutý DNS server. Taktiež treba skontrolovať, či je odkomentovaná možnosť

prepend domain-name-servers 127.0.0.1

v súbore /etc/dhcp3/dhclient.conf. Následne skopírujeme súbor open-ims.dnszone do adresára /etc/bind/, čiže do adresára DNS servera.

cp /opt/OpenIMSCore/ser_ims/cfg/open-ims.dnszone /etc/bind/

Zároveň do súboru /etc/bind/named.conf.local pridáme nasledujúce riadky:

zone "open-ims.test" IN {
        type master;
        file "/etc/bind/open-ims.dnszone";
};

a reštartujeme DNS server. Napr. príkazom:

sudo /etc/init.d/bind9 restart

Treba sa však uistiť, že DNS server sa dá kontaktovať pomocou počítača. To môžeme zabezpečiť pomocou modifikácie súboru /etc/resolv.conf, do ktorého pridáme nasledujúce riadky:

search open-ims.test
nameserver 127.0.0.1

*Pozn. Je potrebné mať na pamäti, že programy ako napr. DHCP-Client upravia súbor resolv.conf do pôvodného stavu. Preto je odporúčané vypnúť takéto programy.

Verifikovať funkčnosť DNS servera môžeme pomocou príkazu:

ping open-ims.test

*Pozn. V prípade, že sme postupovali korektne a ping nefunguje, za zlyhanie pravdepodobne môže sieťové rozhranie. Preto skúste reštartovať toto rozhranie príkazom: sudo /etc/init.d/networking restart

Konfigurácia databázy

Naša IMS architektúra implementuje databázový systém MySQL. Tá nám slúži na zavedenie informácií súvisiacich s I-CSCF a HSS databázou (centrálnou databázou účastníkov). Konfiguráciu databázy vykonáme príkazmi:

cd /opt/OpenIMSCore
mysql -u root -p -h localhost < ser_ims/cfg/icscf.sql
mysql -u root -p -h localhost < FHoSS/scripts/hss_db.sql
mysql -u root -p -h localhost < FHoSS/scripts/userdata.sql

*Pozn. Pri zadávaní hesla použijeme heslo, ktoré ste definovali pri konfigurácií MySQL.

Konfigurácia IMS Core

Ďalším krokom je skopírovať súbory pcscf.cfg, pcscf.sh, icscf.cfg, icscf.xml, icscf.sh, scscf.cfg, scscf.xml, scscf.sh do adresára /opt/OpenIMSCore (odporúčané), prípadne iného adresára.

cp ser_ims/cfg/*.cfg .
cp ser_ims/cfg/*.xml .
cp ser_ims/cfg/*.sh .

Zmena IP adresy

Na zmenu štandardnej IP adresy (127.0.0.1 – localhost) je potrebné zmeniť konfiguračný súbor DNS (/etc/bind/open-ims.dnszone), kde je potrebné zameniť všetky výskyty pôvodnej adresy 127.0.0.1 za novú (v našom prípade sme si zvolili adresu 192.168.0.2). Ďalším krokom je zmeniť IP adresy v konfiguračných súboroch OpenIMS. Na túto úpravu použijeme skript distribuovaný spolu s OpenIMS, ktorý sa nachádza v /opt/OpenIMSCore/ser_ims/cfg.

/opt/OpenIMSCore/ser_ims/cfg/configurator.sh

Po spustení tohto skriptu zadáme DNS názov (open-ims.test) a novú IP adresu (192.168.0.2). Následne pridáme ešte záznam do súboru /etc/hosts, aby dochádzalo k prekladu DNS názvu na IP adresu.

Spustenie OpenIMSCore

Pre spustenie IMS je potrebné vykonať nasledujúce príkazy. Tieto príkazy je odporúčané zapnúť v samostatných oknách pre funkciu sledovania stavu na jednotlivých komponentoch.

Z vlastnej skúsenosti odporúčame najprv umiestniť sa do cieľových adresárov súborov, ktoré chceme spustiť a až tam spustiť vykonávacie príkazy. Pri volaní pomocou absolútnej cesty sa vyskytli problémy vykonávania, resp. zlyhanie vykonávania celého komponentu.

Zapnutie P-CSCF, I-CSCF a S-CSCF:

cd /opt/OpenIMSCore/
./pcscf.sh
cd /opt/OpenIMSCore/
./icscf.sh
cd /opt/OpenIMSCore/
./scscf.sh

Zapnutie FHoSS:

cd /opt/OpenIMSCore/FHoSS/deploy/
./startup.sh

5. 4. Inštalácia Sailfin aplikačného serveru

Aplikačný server Sailfin je rozšírením referenčného Java aplikačného servera Glassfish v2. Vďaka tomuto máme k dispozícii plne funkčný Java kontajner (pre Java EE5), nastavovanie “Connection pool” pre prístup do databázy, Java Messaging Service (JMS) konfiguráciu a mnoho ďalšieho. Výber Sailfin serveru teda umožňuje použitie pokročilých Java technológii v ďalšej fáze nášho projektu.

Aplikačný server Sailfin stiahneme z oficiálnej webovskej stránky. Spustíme inštalátor, ktorý rozbalí všetky súbory do adresára sailfin v aktuálnom pracovnom adresári. Ešte pred spustením samotného inštalačného skriptu, zmeníme port, na ktorom Sailfin počúva z 8080 na ľubovoľný iný voľný port (v našom prípade 8081). Dôvod tejto zmeny je nasledujúci: FHoSS spúšťa Apache server, ktorý tiež počúva na porte 8080. Ak by aj Sailfin počúval na porte, došlo by ku konfliktom. Sailfin port zmením v súbore setup.xml v adresári sailfin.

Následne môžeme nainštalovať doménu Sailfin servera spustením „ant“ skriptu setup.xml. Pretože „ant“ vie primárne spracováva len súbory build.xml, je potrebné pri spúšťaním „ant“ programu zadať argument -f , ktorým donútime „ant“ spracovávať aj setup.xml.

cd sailfin
ant -f setup.xml

Týmto krokom sme nainštalovali doménu „domain1“, ktorá sa nachádza v adresári sailfin/domains/domain1. Doména obsahuje všetky konfiguračné súbory vzťahujúce sa k danému serveru (porty, na ktorých server počúva, nahrané web aplikácie, konfigurácia JSP/JSF alebo EJB kontajnerov a pod.).

Sailfin môžeme následne spustiť z konzoly príkazom start-domain ktorý musíme spustiť ako Sailfin administrátor a s argumentom popisujúcim, ktorú doménu chceme spustiť:

cd bin
./asadmin start-domain domain1

Na konci spúšťania Sailfin servera je do terminálu vypísaný SIP port, na ktorom počúva na SIP správy – tento port budeme neskôr potrebovať (pri prepájaní Sailfin servera a FHoSS).

5. 5. Konfigurácia FHoSS

Záznam o aplikačnom serveru v FHoSS nastavíme podľa obrázku č. 6, pričom:

  • IP adresa Sailfin serveru je 192.168.0.2
  • port, na ktorom Sailfin počúva na SIP správy je 41826 (tento port sa dá zmeniť v administrátorskej konzole Sailfinu)

Nastavenie aplikačného servera
Obrázok 6 Nastavenie aplikačného servera

Nastavenie „Trigger Point“-u je dôležité na správne preposielanie SIP správ z FHoSS (resp. OpenIMS jadra) na náš aplikačný server Sailfin. Nastavenie podľa obrázku č. 7 aktivuje aplikačný server pri každej SIP správe typu INVITE (táto podmienka pravdepodobne nie je potrebná) alebo pri každej správe v rámci jednej „session“. Nastavením konjuktívnej normálnej formy sme dosiahli logické operátory OR (alebo) medzi jednotlivými podmienkami.

Nastavenie trigger pointu
Obrázok 7 Nastavenie trigger pointu

Prepojenie medzi Trigger Point a aplikačným serverom nastavíme v konfigurácii iFC podľa obrázku č. 8.

Nastavenie iFC
Obrázok 8 Nastavenie iFC

Všetky ostatné nastavenia FHoSS necháme nezmenené.

Pridanie účastníka

Pre pridanie účastníka klikneme v menu FHoSS na položku „USER IDENTITIES“. Následne v ľavom menu v sekcii IMS Subscription vyberieme možnosť Vytvoriť (Create). Položky vyplníme podľa nasledujúceho obrázku.

IMS Subscription
Obrázok 9 IMS Subscription

Po vyplnení formulára stlačíme Uložiť (Save). Po uložení stlačíme v ľavom menu položku Vytvoriť (Create) v sekcii IMPI Private Identity a opäť vyplníme formulár podľa obrázku.

IMPI Private User Identity
Obrázok 10 IMPI Private User Identity

Na pravej strane formulára nemôžeme zabudnúť na pripojenie IMSU, ktoré sme vytvorili v prvom kroku. Po vyplnení formulára opäť stlačíme Uložiť (Save).

Posledným krokom je vytvorenie verejnej identity IMPU Public User Identity. Formulár opäť vyplníme podľa obrázka. Nemôžeme zabudnúť na pridanie „navštívenej siete“ (Visited Network), kde pridáme doménu. V prípade, že by sme ju nepridali, účastníkovi nebude dovolené sa registrovať. Taktiež je potrebné prepojiť IMPI s IMPU (IMPI to IMPU). Tam zadáme údaje vo forme účastník@doména.

IMPU Public User Identity
Obrázok 10 IMPU Public User Identity

Po správnom vyplnení a uložení formulárov by mal byť účastník schopný registrovať sa do siete.

5. 6. Implementácia SIP servletu

Na odchytávanie SIP správ je použitý tzv. SIP servlet, ktorý je zdedený z triedy GenericServlet. Z toho vyplýva, že správa viac-menej rovnako ako klasický Java HttpServlet - t.j. je potrebné zaregistrovať do deploynment skriptov (web.xml). Toto zaregistrovanie uskutočníme pridaným nasledovných riadkov do web.xml súboru:

<servlet>
        <servlet-name>NAZOV_SERVLETU</servlet-name>
        <servlet-class>ABSOLUTNA_CESTA_K_SERVLETU</servlet-class>
</servlet>
<servlet-mapping>
        <servlet-name>NAZOV_SERVLETU</servlet-name>
        <url-pattern>/URL_SERVLETU</url-pattern>
</servlet-mapping>

Pričom:

  • NAZOV_SERVLETU je ľubovoľný reťazec, ktorý však musí byť rovnaký pri definícii servletu aj pri definícii mapovania.
  • ABSOLUTNA_CESTA_K_SERVLETU je cesta k triede servletu aj s balíčkami (ako vždy, aj teraz je veľmi odporúčané nepoužívať triedy, ktoré nie sú v balíkoch)
  • URL_SERVLETU - je URL adresa, na ktorej bude servlet počúvať; táto adresa je dostupná (resp. aktívna) len cez webovské rozhranie, čo v našom prípade nemá opodstatnenie, lebo SipServlet nevie na rozdiel od HttpServletu spracovávať HTTP požiadavky, avšak na to, aby bolo web.xml valídne musí byť zadefinované.

Na vytvorenie samotného SipSrvletu (ktorý sme pred chvíľou zaregistrovali), stačí zdediť triedu javax.servlet.sip.SipServlet. Táto trieda obsahuje tzv. „do-metódy“, teda metódy, ktorých názvy začínajú na „do“, napr. doRegister, doAck, a pod. Toto sú hook metódy, ktoré sú volané vždy, keď SipServlet dostane a spracuje daný typ SIP správy (napr. ak servlet dostane správu typu REGISTER, zavolá sa metóda doRegister). Implementujeme všetky „hook metódy“ tak, aby volali metódu nadtriedy (nepísaná Java konvencia) a vypísali informácie o danej SIP správe. Toto vypisovanie bude v našom prípade uskutočňované do štandardného výstupu prostredníctvom knižnice Log4J, ktorý umožňuje pridať formátovanie do výpisu.

Ostáva ešte vygenerovať Web Application Archive (WAR), ktorý je archív združujúci všetky skompilované triedy a deployment deskriptory a iné konfiguračné súbory (podobne, ako v prostredí J2SE je archív JAR). Tento WAR súbor následne nahráme (angl. deploy) na aplikačný server Sailfin (resp. Glassfish).

Výstup našej aplikácie môžeme sledovať v súbore domains/domain1/logs/server.log. Je potrebné si uvedomiť, že Glassfish (Sailfin) aplikačný server rotuje log súbory, v prípade, ak dosiahli stanovený limit (v bytoch). Z toho vyplýva, možný problém, ak dôjde k rotácii log súboru, aby bol sledovaný nový log súbor a nie stále starý (ktorý sa už teda nebude meniť).

Zdroje

  • KHAN,A. H., QADEER, M. A.: IMS Network Architecture and Assessment of its Clients for Various Access Networks. 2010. [online]
    http://icast.icst.org/2010/06/ims-network-architecture-and-assessment-its-clients-various-access-networks
  • BERTRAND, G.: The IP Multimedia Subsystem in Next Generation Networks. 2007. [online]
    http://www.rennes.enst-bretagne.fr/~gbertran/files/IMS_an_overview.pdf
  • BUSHNELL, B.: Using the IMS Architecture for Service Enabling Next Generation Networks. 2004. [online]
    http://www.convergedigest.com/bp-c2p/bp1.asp?ID=158
  • RADIO-ELECTRONICS: IMS, IP Multimedia Subsystem tutorial. 2011. [online]
    http://www.radio-electronics.com/info/telecommunications_networks/ims-ip-multimedia-subsystem/tutorial-basics.php
  • FRAUNHOFER FOKUS: The Open Source IMS Core Project. 2006. [online]
    http://www.openimscore.org/
  • MEHIĆ, M.: OpenIMSCore : Installation and Configuration Guide. 2011. [online]
    http://mehic.info/2011/12/openimscore-installation-and-configuration-guide
  • HENDERSON, G.: IMS: The Catalyst For Service Convergence Across Wireless & Wireline Networks. 2005. [online]
    http://www.tmcnet.com/voip/0205/IMS-Catalyst-Service-Convergence-Across-Wireless-Wireline-Networks.htm
  • NG VOICE: A brief introduction to the IP Multimedia Subsystem. 2012. [online]
    http://www.ng-voice.com/our-vision/a-brief-introduction-to-the-ip-multimedia-subsystem
  • SUN MICROSYSTEMS: GlassFish: Project SailFin. 2008-2012. [online]
    http://sailfin.java.net
  • HOLZNER, S.: Template Method Design Pattern. 2011. [online]
    http://sourcemaking.com/design_patterns/template_method