Služby Inteligentní sítě ENUMem

Nejprve bylo provedeno experimentální ověření realizace služby Inteligentní sítě „Přenositelnost čísla“ mechanismem ENUM, které je popsáno v sekci Využití mechanismu ENUM pro přenositelnost čísla.

Rozšíření využití mechanismu ENUM k realizaci co největšího počtu služeb Inteligentní sítě je popsáno zde.

Návrh DDDS aplikace

Rozšíření možností mechanismu ENUM

Vstupem mechanismu ENUM je právě jedno telefonní číslo podle formátu ITU-T doporučení E.164. Z této vlastnosti vyplývají dvě omezení.

Telefonní číslo jako identifikátor volajícího nebo volaného je základem zpracování ve většině služeb Inteligentní sítě. Existují však služby, které vyžadují zpracování řetězce s nečíselnými znaky (např. písmena a speciální znaky). Příkladem jsou bezpečnostní hesla PIN a čísla předplacených karet.

ENUM nabízí vyhledání jednoho telefonního čísla. Po nalezení v databázi jsou vybrána odpovídající pravidla pro zpracování čísla, případně jeho náhradu. Existují však případy, kdy jsou potřeba více druhů zpracování pro identické identifikátory. Například stejná zkrácená předvolba, která u více přípojek může znamenat rozdílné identifikátory volaného. ENUM mechanismus v současné podobě nenabízí odpověď, jak takové rozlišení realizovat.

Proto navrhuji vlastní aplikaci řešící dvě výše uvedené překážky. Aplikace je obdobně jako ENUM aplikací DDDS systému, která rozšiřuje počet realizovaných IN služeb při zachování výhod mechanismu ENUM.

Název aplikace v tomto případě nemůže být mechanismus ENUM, jelikož toto označení se podle doporučení využívá pouze pro veřejný systém umístěný v doméně e164.arpa a nikoliv pro privátní systém v síti operátora.

Odvození DDDS aplikace

Rozšíření možností mechanismu při zachování jeho výhod umožní nový návrh DDDS aplikace pro realizaci pokročilých hlasových služeb uvedený v této sekci.

Realizovatelné služby

Doporučení ITU je ve specifikaci služeb Inteligentní sítě velmi obecné. Vycházíme li z doporučení můžeme vyhodnotit shodu služeb a navrhované DDDS aplikace na základě rozboru vstupů, výstupů a způsobů zpracování.

K tomu využijeme soubor služeb CS-1 (standardy ITU-T řady Q.121x) doplněný o služby Přenositelnosti čísla a Výběr operátora (Carrier Selection, CS) umožňující zvolit operátora obsluhujícího hovor.

Odvození vstupů, způsobu zpracování a výstupů uvedených služeb na základě specifikace v doporučeních je v tabulce.

Služba & Fixní v.& Dyn.v. & Pravidlo & Výstup/y
ABD & A & B & vyhledání A, analýza B & alt. B číslo
ACC & CK+PIN & B & vyhledání CN+PIN, nahrazení B & B číslo
AAB & CK+PIN & B & vyhledání CN+PIN, nahrazení B & B číslo
CD & B & & vyhledání B a náhrada & alt. B číslo
CF & B & & vyhledání B a náhrada & alt. B číslo
CRD & B & & vyhledání B a náhrada & alt. B číslo
CCC & CK+PIN & B & vyhledání CN+PIN, nahrazení B & B číslo
CON & B+PIN & A & vyhledání A, analýza PIN & B / nepovoleno
DCR & B & & vyhledání B a náhrada & alt. B číslo
FMD & B & & vyhledání B a náhrada & alt. B číslo
FPH & B & A & vyhledání B, analýza A & alt. B číslo
OCS & A & B & vyhledání A, analýza B & B / nepovoleno
SEC & A+PIN & B & vyhledání A, analýza PIN & B / nepovoleno
SCF B & B & & vyhledání B a náhrada & alt. B číslo
SCF & B & A & vyhledání B, analýza A & B / nepovoleno
CF B & B & & vyhledání B a náhrada & alt. B číslo
CF N & B & & vyhledání B a náhrada & alt. B číslo
TCS & B & A & vyhledání B, analýza A & B / nepovoleno
UAN & B & A & vyhledání B, analýza A & alt. B číslo
UPT & B & & vyhledání B a náhrada & alt. B číslo
UDR & A & B & vyhledání A, analýza B & alt. B číslo
VPN & A & B & vyhledání A, analýza B & alt. B číslo
NP & B & & vyhledání B a náhrada & alt. B číslo
CS & B & & vyhledání B a náhrada & alt. B číslo
CCBS & B & & sledovat stav linky & dokončit spojení
MCI & B & A & čekat na povel & ne/označit A
PRM & B & A & extra účtovat A & uložit účet
SPL & B & A & extra účtovat A & uložit účet
MAS & B & & operace +1 & uložit výsledek
VOT & B & & operace +1 & uložit výsledek

Zkratka služby vychází z doporučení, vstupy „A“ resp. „B“ reprezentují identifikátor volajícího resp. volaného a „CK“ resp. PIN označují číslo karty resp. identifikační kód.

Pravidla představují elementární operace, které služba provádí.

S pomocí tabulky lze jednoduše porovnat principy DDDS aplikace a IN služeb. Nejprve se zaměříme na způsob zpracování. Služby Inteligentní sítě poskytují vyhledávání, analýzu řetězce, náhradu, sledování stavu linky, čekání, speciální účtování a operaci přičítání. Naproti tomu DDDS aplikace podle specifikace algoritmu umožňuje vyhledávání, analýzu a náhradu. (Více o DDDS v IETF RFC 3401, 3402.)

Z pohledu realizovatelných principů zpracování je poměr možností zpracování DDDS aplikace k možnostem IN služeb je zhruba 50%. Avšak celkové množství služeb realizovatelných pomocí DDDS představuje cca 80%.

Specializované funkce, kterými jsou sledování stavu linky, čekání na uvolnění účastnické přípojky, přičítání a speciální účtování je tak nutno realizovat přímo ve spojovacím zařízení. Těmito službami se dále nebudeme zabývat.

Volba databáze

Místem uložení převodních pravidel DDDS aplikace je databáze. Vhodnou databází pro navrhovanou aplikaci je Systém doménových jmen. Jedná se o snadno rozšiřitelný systém s hierarchickou strukturou založený na paketovém protokolovém modelu TCP/IP. Výhodou je jednoznačně rozšířené využití a znalost systému, spolu s možností aplikace v privátní síti operátora. Systému má z pohledu použití pro převody mezi řetězci číslic a znakovými řetězci v pokročilých hlasových službách vhodný formát vstupů a výstupů.

Návrh DDDS databáze založené na DNS existuje v RFC 3403. Základním zvoleným formátem pro ukládání a přenos informací je kódování UTF-8. V tomto kódování je také definován vyhledávací klíč pro nalezení záznamů v databázi v podobě doménového jména, jehož formát specifikuje RFC 1034.

Způsobem dotazu do databáze je žádost o NAPTR záznamy odpovídající doménovému jménu klíče. Odpovědí databáze na tento dotaz jsou všechny záznamy daného typu obsahující převodní pravidla, případně chybová hláška.

Způsob vkládání nových záznamů odpovídá aktualizaci DNS zón s daty obsaženými v souboru nebo relační databázi. Záznamy mohou být pouze ve formátu NAPTR.

Návrh unikátního vstupu

Vstupní řetězec DDDS aplikace musí být jedinečný. Tím se zamezí nalezení různých výstupů na základě unikátního vstupu a zároveň je zajištěno vrácení vždy stejného výsledku v podobě převodních pravidel.

Vstupní řetězec musí také obsahovat veškeré informace nutné k určení výstupu. Jedná se primárně o informace nutné k vytvoření vyhledávacího klíče a případně další parametry nutné k vytvoření očekávaného výstupu.

Analýzou pokročilých hlasových služeb pro prostředí IP telefonie byly odvozeny tři druhy vstupních formátů pro navrhovanou DDDS aplikaci:

  • Jediné E.164 číslo
  • Dvojice E.164 čísel (volající a volaný)
  • Číslo s řetězcem znaků (PIN, číslo karty)

Systém DNS umožňuje ukládat libovolné znaky kódované v UTF-8. Výše uvedené vstupní formáty jsou vhodné pro přímé uložení v databázi.

Vstupy navržené DDDS aplikace je potřeba rozdělit na fixní a dynamické.

Fixní vstupy jsou při poskytování služby neměnné, zatímco dynamické se mění s každý hovorem. Část fixní je známá již před poskytnutím služby. Proto může být tato statická část součástí vyhledávacího klíče a stejně tak je uložena v databázi. Fixní složka je povinnou součástí vstupu z důvodů konstrukce vyhledávacího klíče pro dotaz do databáze.

Dynamické vstupy jsou proměnné s každým hovorem. Není tudíž předem známa a není vhodná jako součást vyhledávacího procesu DDDS aplikace. Dynamická složka, pokud je přítomna, musí tvořit unikátní vstup. Tím je zaručena jednoznačnost procesu zpracování poskytnutých služeb.

Otázkou zůstává, jak rozlišit služby v rámci databáze? V případě přímé implementace veškerých služeb v podobě pravidel umístěných v jedné tabulce databáze by nebylo možné zaručit příslušnost ke správné službě.

Zřejmé jsou dvě možnosti řešení. Tou první je vytvoření samostatné domény pro každou nabízenou službu. Obsahem budou identifikátory vážící se pouze k dané službě a převodní pravidla realizující službu. V tomto případě musí být součástí unikátního vstupu označení služby, které slouží k výběru odpovídající domény při vyhledávání příslušných pravidel podle klíčů.

Druhou možností je uvedení typu služby v označení služby, které je součástí NAPTR záznamu. Tento přístup má výhodu v efektivnosti a jednoduchosti navrhované DDDS aplikace a zaručuje větší integritu databázového systému.

Volba znaku oddělovače jednotlivých částí unikátního vstupu musí splňovat dvě podmínky. Znak by se neměl vyskytovat v žádném ze vstupů a neměl by mít zvláštní úlohu v regulárních výrazech. Za výsledný znak oddělující části unikátního vstupního řetězce byl zvolen „\&“, který je minimálně využíván. Navrhovaný unikátní vstup DDDS aplikace vyjádřený ABNF gramatikou:

unik-vstup = fixni-slozka delim-char dyn-slozka
delim-char = “&“
fixni-slozka = uri / e164cislo
dyn-slozka = uri / e164cislo
uri = <URI definované v RFC 2396>
e164cislo = <telefonní číslo definované v ITU-T E.164>

Návrh prvního pravidla

Následující krok ve specifikaci DDDS aplikace je stanovení prvního pravidla. Jeho úkolem je zpracování unikátního vstupu na vyhledávací klíč. První pravidlo je navrženo podle formátu přepisovacího pravidla.

!^([^&]*)&!\1.DOMÉNA_OPERÁTORA!

Cílem pravidla je vytvoření vyhledávacího klíče ve tvaru doménového jména. Aby bylo možné propojit údaje o službách s hierarchickou strukturou DNS je nutné k údajům pro realizaci služeb připojit doménu operátora.

První pravidlo aplikované na unikátní vstup připojuje fixní parametry na začátek domény operátora a fixní vstup je tak součástí vyhledávacího klíče pro zaručení jednoznačnosti ve vyhledávacím procesu.

Příklad vysvětluje princip pravidla. V síti operátora „Poskytovatel“ je zavolána služba Bezplatné volání na telefonní číslo 800 111 111 od volajícího 222 333 444. První pravidlo převede unikátní vstup na vyhledávací klíč:

420800111111 & 420222333444 → 420800111111.poskytovatel.cz

Pravidla

Pravidla, která algoritmus vyhledává v podobě záznamů v databázi slouží k úpravě unikátního vstupu. Jejich aplikací je získán buď další vyhledávací klíč nebo očekávaný výstup. Pravidla se skládají ze čtyř částí, kterými jsou: priorita, příznaky, služba a převodní regulární výraz.
Prioritou označujeme pořadí zpracování pravidel. Je možné určit, že vyšší priorita definuje výhodnější cestu a nižší priorita například cestu záložní.
Příznaky určují vlastnosti pravidla, například jedná li se o koncový záznam.
Část označená jako převodní výraz specifikuje samotný převod textových řetězců. Definice převodu je nezávislá na použité databázi a na navrhované DDDS aplikaci. Samotný převodní výraz, označený jako „subst-expr“, využívá substitučního regulárního výrazu ve formátu ABNF:

subst-expr = delim-char ere delim-char repl delim-char *flags
delim-char = “/“ / “!“ / <znak, kromě 'POS-DIGIT' a 'flags'>
ere = <POSIX Extended Regular Expression>
repl = *(string / backref)
string = *(anychar / escapeddelim)
anychar = <any character other than delim-char>
escapeddelim = „\“ delim-char
backref = „\“ POS-DIGIT
flags = „i“
POS-DIGIT = „1“ / „2“ / „3“ / „4“ / „5“ / „6“ / „7“ / „8“ / „9“

Převodní pravidlo lze vysvětlit jako substituční výraz skládájící se ze dvou částí. Regulárního výrazu ere s jehož pomocí lze ve vstupním řetězci označit oblasti pro další zpracování. A z řetězce nahrazení repl obsahujícího vybrané části vstupu doplněné o další řetězce. Výsledný výraz tvoří výstupní řetězec.

Označení služby definuje význam daného pravidla. Platí, že v rámci jedné domény mohou být dvě pravidla totožná, avšak dvě služby nikoliv. %Tím je dána možnost aplikaci zvolit vhodnější službu například pro navázání spojení.

Jelikož podstatou většiny služeb Inteligentní sítě je převod nebo úprava identifikátorů volajících stran definuji dva druhy služby složené z označení převodu a typu IN služby:

  • E2E+typ = převod mezi E.164 čísly
  • E2U+typ = převod E.164 čísla na URI

V případě E2E je provedena úprava nebo náhrada původního telefonního čísla za cílové číslo. V případě E2U je původní E.164 číslo nahrazeno cílovou adresou. Typ služby je zkratka služeb IN sítě, tak jak je uvedena v doporučení ITU. Například u služby Bezplatné volání s využitím telefonních čísel na obou stranách bude označení služby E2E+FPH (Freephone).

Výstup

Výstup DDDS aplikace se odvíjí od vstupního formátu a od požadované služby. Může jím být E.164 číslo nebo identifikátor URI. %V navrhované DDDS aplikaci odpovídá výstupní formát vstupním identifikátorům uživatelů. Některé služby, které využívají elementární blok Prověření, však očekávají také chybový výstup. Z tohoto důvodu definuji následující výstupní formáty:

  • E.164 číslo
  • URI
  • Chybový výstup (povolení služby nebo chyba zpracování)

U služeb ověřujících bezpečnostní řetězce (hesla) je tedy potřeba vrátit informaci o výsledku ověření. Standardní DNS nabízí tři typy odpovědí.

  1. Záznam odpovídající jménu a typu
  2. Záznam neexistuje („Name error“)
  3. Záznam existuje avšak nikoliv požadovaný typ („Data not found error“)

Standardní \textit{záznam odpovídající jménu a typu} odpovídá výstupu v podobě čísla nebo URI. V případě výsledku informujícího o neúspěchu vyhledání požadovaných hesel je využita chybová hláška DNS \textit{Záznam neexistuje}.

Model DDDS aplikace se vstupy a výstupy je znázorněn na obrázku.

E.164 číslo  --->  -----------------  --->  E.164 číslo\\
Číslo karty  --->  | DDDS Aplikace |  --->  Identifikátor URI\\
PIN          --->  -----------------  --->  Chyba\\

Specifikace DDDS aplikace

Jednoznačná specifikace systému DDDS aplikace včetně popisu jejího chování je vyjádřená formou SDL (Specification and Description Language) grafické reprezentace (SDL/GR).

Funkce aplikace

Nejprve navrhl jsem obecné funkce DDDS aplikace, které jsou uvedeny na obrázku. Aplikaci tvoří procedury s funkcemi ověření správného formát vstupů, vytváření klíče pro vyhledávání v databázi, aplikování pravidel na unikátní vstup a kontroly výstupu. Pro jednoznačnou specifikaci systému včetně popisu jeho chování jsem využil zápisu v podobě SDL.

Funkční návrh DDDS aplikace

Struktura a chování aplikace

Detaily struktury systému vyjádřené třemi bloky se čtyřmy procesy budou uvedeny v technické zprávě.

Implementace DDDS aplikace

Systém DDDS aplikace byl implementován v prostředí IP telefonie.

Architektura

V současnosti již existuje množství softwaru realizující spojovací funkce v IP telefonii. Systémy se liší v počtu současně obsloužených uživatelů služby od několika tisíc v případě pobočkových ústředen (IP-PBX) až po milióny uživatelů v případě zařízení zvaných softswitch.

Dominantním protokolem v oblasti řízení spojení v IP telefonii je v současné době SIP. Rozhodnutí o spojovacím systému využitém pro implementaci DDDS aplikace se tak orientovalo především na ústředny využívající protokol SIP.

Jedním z cílů práce je zvýšit konkurenceschopnost v oblasti služeb malým operátorům. Ti často používají pobočkovou ústřednu jako spojovací systém.

Zvoleným prostředím pro realizaci služeb se tak stala pobočková ústředna Asterisk, která je nejen podle posledních statistik nejrozšířenější IP-PBX, ale která podporuje celou škálu programovatelných rozhraní.

Volba databázového systému byla usnadněna předchozím experimentem pro ověření služby Přenositelnost čísla. Jako úložiště pravidel realizujících IN služby byl zvolen jmenný server BIND.

Architektura implementovaného systému je znázorněna na obrázku.

IP telefon  ---  Asterisk PBX  ---   IP síť  ---  BIND NS  ---  DDDS pravidla

Služba je poskytována Asterisk PBX ve spolupráci s BIND serverem. Uživatelé přistupují ke službě prostřednictvím IP telefonu.

Instalace a konfigurace

Instalace ústředny Asterisk lze provést nezávisle na použitém operačním systému překladem zdrojového kódu (configure - make - make install) nebo existuje množství instalačních balíčků pro konkrétní systémy.

Z programovatelných rozhraní Asterisku bylo zvoleno pro implementaci jako nejvhodnější volání skriptu příkazového interpretu. Skript DDDS aplikace se tak stává na Asterisku nezávislý a do značné míry přenositelný.

Konfigurace Asterisku spočívá v úpravě pravidel pro zpracování hovoru umístěných v souboru extensions.conf. Pro poskytnutí služby DDDS aplikace je zavolána funkce SHELL(), které jsou formou parametrů předány umístění skriptu a vstupní parametry DDDS aplikace. Výstupem je identifikátor, se kterým bude pokračovat sestavování spojení nebo informace o (ne)povolení poskytnutí dané služby. Modifikace extensions.conf pro Asterisk v1.6:

exten ⇒ _800XXXXXX,1,NoOp(FPH service called, A=${CALLERID(num)}, B=${EXTEN})
exten ⇒ _800XXXXXX,n,Set(Result=${SHELL(/opt/asterisk/bin/ddds_application E2E+FPH ${CALLERID(num)} ${EXTEN})})
exten ⇒ _800XXXXXX,n,GotoIf($[„${Result}“ != ““]?default,${Result},1)
exten ⇒ _800XXXXXX,n,Macro(incept,1)

Instalace jmenného serveru BIND překladem ze zdrojového kódu včetně nastavení databázového ovladače a konfigurace serveru bude uvedena v TZ. Zde uveďme pouze příklad NAPTR záznamu obsahující přepisovací pravidlo pro realizaci služby Bezplatné volání.

$ORIGIN blue.comtel.cz.
800111112 NAPTR 10 100 „U“ „E2E+FPH“ “!(^800)(.*)(&.*$)!222\\2!“ .

Skript DDDS Aplikace

Pro implementaci principů navržené DDDS aplikace byl vytvořen skript v příkazovém interpretu bash. Zdrojový kód včetně komentářů popisujících procedury aplikace bude umístěn v TZ.

Testování

Rozhodl jsem se vyzkoušet implementaci pomocí služby Bezplatného volání. Voláním na číslo 800 se aktivovala DDDS aplikace. Nejprve vytvořila vyhledávací klíč a získala pravidla z databáze v podobě NAPTR záznamu. Převod obsažený v záznamu byl aplikován na volané číslo. Výpis zpracování hovoru z pobočkové ústředny:

– Executing [800111112@default:1] NoOp(„SIP/602336334-084cac8b“,“FPH service called, A=602336334, B=800111112“) in new stack
– Executing [800111112@default:2] Set(„SIP/602336334-084cac8b“,“Result=222111112“) in new stack
– Executing [800111112@default:3] GotoIf(„SIP/602336334-084cac8b“,“1?default,222111112,1“) in new stack
– Goto (default,222111112,1)

Výsledky a závěr

V předchozí práci bylo provedeno experimentální ověření realizace služby Inteligentní sítě „Přenositelnost čísla“ mechanismem ENUM.

Cílem této práce bylo rozšíření využití mechanismu ENUM k realizaci co největšího počtu služeb Inteligentní sítě. Nejprve analýzou pokročilých hlasových služeb v prostředí Inteligentní sítě a poté implementací služeb v IP síti. Zaměření bylo na alternativní přístupy k řešení implementace služeb v prostředí IP telefonie.

Identifikoval jsem omezení mechanismu ENUM. Pro rozšíření počtu realizovatelných služeb při zachování výhod mechanismu jsem navrhl novou DDDS aplikaci. V rámci návrhu jsem z důvodů rozšíření poznatků o zkoumané oblasti analyzoval pokročilé hlasové služby z pohledu vyšší vrstvy služeb. Vyhodnotil jsem shodu služeb a navrhované DDDS aplikace rozborem vstupů, výstupů a způsobu zpracování. Výsledkem je zhruba 80% pokrytí služeb Inteligentní sítě DDDS aplikací.

V návrhu DDDS aplikace jsem určil následující parametry. Unikátní vstup je navržený v obecné podobě vhodné pro všechny realizovatelné služby. Převodní pravidlo jsem definoval pro tvorbu vyhledávacího klíče z unikátního vstupu. Zvolil jsem databázi v podobě Systému doménových jmen pro uložení převodních pravidel. Definoval jsem identifikátor sloužící k jednoznačnému označení reprezentovaných služeb v pravidlech. Pravidla určují zpracování unikátního vstupu a jsou jimi realizovány jednotlivé služby. Výstup byl definován v obecné formě vhodné pro širokou škálu spojovacích zařízení.

Provedl jsem jednoznačnou specifikaci systému. Struktura DDDS aplikace včetně popisu chování je vyjádřená formou SDL grafické reprezentace. Struktura je navržena jako systém tří bloků o třech paralelních procesech komunikujících souborem definovaných signálů. Chování systému je definováno v procesních diagramech stavy a přechody rozšířeného stavového automatu.

Pro implementaci systému jsem vybral z množství softwaru realizujícího spojovací funkce v IP telefonii pobočkovou ústřednu Asterisk, vzhledem k rozšířenosti, využití protokolu SIP a k množství podporovaných programovatelných rozhraní. Zdrojem převodních pravidel byl vybrán prověřený jmenný server BIND. Dále jsem nastínil možnost konfigurace systému.

Samotná DDDS aplikace byla implementována v prostředí příkazového interpretu operačního systému Linux. Vzniklý skript je díky vybranému prostředí je nezávislý na spojovacím systému a přenositelný mezi interprety téhož typu.

Za účelem validace implementovaného systému jsem experimentálně ověřil principy DDDS aplikace na službě Bezplatné volání. Validace proběhla úspěšně.

V prostředí IP telefonie se pro vyhledání uživatele primárně využívají identifikátory URI. Současný Systém doménových jmen zatím nenabízí možnosti uložení těchto identifikátorů v plném rozsahu a je zde prostor k rozšíření.

Směrem v pokračování práce na navrženém systému by zcela jistě byla optimalizace z pohledu zvýšení výkonu systému pro poskytování pokročilých hlasových služeb IP telefonii.

cs/protokoly/enuminserv.txt · Poslední úprava: 2009/12/15 14:38 autor: janru@cesnet.cz
Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0