www.SAMURAJ-cz.com 

17.12.2017 Daniel Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Cisco Expressway část 3 - B2B videokonference pomocí DNS

Sobota, 23.04.2016 13:56 | Samuraj - Petr Bouška |
V tomto díle dokončíme konfiguraci Business-to-Business Communication pomocí Expressway serverů a CUCM. Minule jsme nastavili hlavní část konfigurace pro audio video volání přes internet, ale omezili jsme se na volání pomocí IP adres. Dnes přidáme využití DNS vyhledávání a umožníme volání na SIP a H.323 adresy, obecně URI (či Directory URI). Jde již o relativně jednoduché rozšíření. A nejde pouze o řešení pro volání na speciální videokonference, ale můžeme přiřadit Directory URI běžným telefonům a umožnit tak volání přes internet, stejně jako přes PSTN.

Úvod do volání pomocí URI

Já jsem se rozhodl rozdělit konfiguraci volání na videokonference na dvě části. Pomocí IP adres (tak začínal protokol H.323), a vytáčení IP adres na zařízeních připojených k Cisco Unified Communications Manager (CUCM), to se obecně označuje jako IP address dialing. Což jsme si popsali minule, v tomto případě nemusíme řešit různé DNS SRV záznamy a další a zjednoduší se testování a hledání chyb.

A volání pomocí Directory URI, tedy často SIP adresy (ale může jít také o různé varianty H.323 ID, aliasů a adres využívající Gatekeeper), kde adresa obsahuje uživatele či zařízení v organizaci a DNS doménu (FQDN) či IP adresu. Tomu se říká URI dialing a budeme se mu věnovat v tomto díle.

Pro zajímavost si uvedeme odkaz na docela zajímavé porovnání protokolů H.323 a SIP H.323 versus SIP: A Comparison.

Různé adresy používané pro SIP a H.323

Když chceme volat na nějaké externí zařízení pomocí protokolu SIP (Session Initiation Protocol) nebo H.323, tak musíme zadat určitou adresu, která cílové zařízení identifikuje. V případě SIP protokolu je SIP adresa či SIP URI docela jednoznačná. Ale H.323 protokol začínal nejprve s využitím veřejné IP adrese (která identifikovala jedno zařízení) a postupem času doplnil řadu dalších možných formátů adresy (různí výrobci podporují různé možnosti).

U H.323 protokolu záleží také na tom, jestli zařízení, na které voláme, je přímo terminál (klient) nebo může jít o MCU (Multipoint Control Unit) či Gatekeeper. Adresa pak může obsahovat identifikaci konference a formát vypadá IP_adresa_nebo_DNS_jméno##ID_konference, tedy třeba 1.2.3.4##00158843254. Pokud využíváme Gatekeeper, ke kterému se registrují H.323 koncová zařízení, tak získají H.323 alias. Tento alias může mít řadu formátů, ale nejčastěji se využívá obdoba emailové adresy, což je podobné jako SIP URI, případně číslo ve formátu E164. Další možnost je H.323 ID, což je alfanumerický řetězec. V případě H.323 se alias podobný emailové adrese, tedy zde řešený URI Dialing, označuje jako H.323 Annex O URL formát.

V tomto článku řešíme primárně URI Dialing, tedy volání cílového účastníka pomocí jeho URL či URI adresy, ať za použití protokolu SIP, tak H.323. V řadě případů se využívá DNS pro překlad adres a buď FQDN (Fully Qualified Domain Name) či doménové jméno spolu se SRV (Service) záznamem. Takže se ještě podíváme na obecné termíny. URI je zkratka pro Uniform Resource Identifier, což je obecně textový řetězec pro identifikaci prostředku (resource). Možná více známý termín Uniform Resource Locator (URL) je podmnožinou URI.

SIP URI adresa nebo H.323 Annex O URL alias má formát podobný emailu, takže může jít třeba o bouska@firma.cz, ale také 123@firma.cz nebo petr.bouska@100.1.2.3. Obecně jde o protokol:jmeno@host:port, příklad sip:bouska@firma.cz:5060, ale při běžném použití neurčujeme protokol a většinou nepotřebujeme ani port. Jméno identifikuje uživatele (nebo zařízení, případně službu/konferenci) v rámci organizace (serveru). Host je buď FQDN nebo IP adresa, která přímo určuje server, nebo doména a pak se hledá SRV záznam, který obsahuje údaje o serveru (včetně portu). Volitelná položka port určuje, na jakém portu server poslouchá, pokud nezadáme, tak se uvažuje defaultní port SIP 5060, SIPS 5061, H.323 1720.

Pro Cisco formát Directory URI platí určitá pravidla (omezení), která jsou podrobně popsána v Directory URI Format.

Schéma konfigurace

Minule jsme použili určité grafické zobrazení pro workflow / konfiguraci komunikace. Níže je toto schéma rozšířené o části, které budeme dále konfigurovat. Již minule jsme při zpracování na Expressway serverech používali doménová jména (a třeba IP adresy převáděli na doménu). Takže nyní stačí jen doplnit na ExpE směrování cílových adres, kde je použita jiná než lokální doména, skrze DNS Zone (levá spodní část diagramu). A na CUCM přidat směrování všech ne-lokálních URI (ať za použití doménového jména nebo IP adresy) na ExpC (pravá spodní část diagramu).

Expressway schéma konfigurace - workflow

Celá konfigurace se bude skládat ze čtyř kroků:

  • Zprovoznění URI Dialing na CUCM
  • Směrování URI aliasu z CUCM na Expressway
  • Směrování URI aliasu z Expressway do internetu
  • Nastavení veřejných DNS záznamů pro příchozí hovory

Zprovoznění URI Dialing na CUCM

První částí konfigurace je zprovoznění URI Dialing na Cisco Unified Communications Manager (CUCM), takže pak můžeme mezi interními telefony volat nejen pomocí linky (Directory Number - DN), ale také pomocí URI. To není příliš složité, ale musíme mít minimálně CUCM verze 9. Pár odkazů na oficiální popis:

CUCM ve verzi 9 přinesl možnost využít volání pomocí URI. V rámci CUCM clusteru vše funguje téměř automaticky. URI Dialing je dostupné na podporované skupině SIP a SCCP telefonů. Některé telefony umožňují při zadávání čísla přepnout na písmena a pak můžeme zadat URI. Pokud toto nepodporují, tak můžeme využít nakonfigurované Speed Dial.

Přiřazení Directory URI k uživateli nebo DN

Hlavní konfigurace spočívá v nastavení (přiřazení) SIP adresy, přesněji Directory URI. Máme více možností, jak toto provést. K Directory Number (DN) můžeme přidat jedno nebo více Directory URI, jedná se o alias pro toto DN. Nastavujeme v Call Routing - Directory Number položka pod Directory URIs, nastavíme URI a můžeme zvolit Partition, do které je zařazeno.

Další možnost je nepřiřadit URI k DN, ale k End User. Podmínka je, že musí mít přiřazeno číslo v Primary Extension. Nastavujeme položku Directory URIUser Management - End User. Když se pak podíváme na DN, tak zde uvidíme nastavené URI od uživatele. Také vidíme, že URI je zařazeno do speciální Partition Directory URI. Takže buď musíme upravit všechny Calling Search Space (CSS), kde má být oprávnění volat na interní telefony pomocí URI. Nebo můžeme upravit Enterprise parameter (System - Enterprise Parameters) Directory URI Alias Partition, kde zvolíme nějakou naši (interní) partition a Directory URI je pak pouze alias pro tuto partition.

CUCM Directory URI

Způsob vyhledání Directory URI

Na pravé straně Directory URI (část host za zavináčem) můžeme použít IP adresu CUCM serveru nebo libovolnou doménu (může jít i o neexistující doménu, dokud ji budeme chtít využít lokálně, aby fungovala z jiných nezávislých systémů, tak musíme mít nastaveno DNS a další směrování). CUCM používá následující pravidla pro směrování hovoru:

  1. podle vytočeného řetězce určí, zde jde o DN nebo URI, DN směruje standardním způsobem
  2. CUCM hledá v lokální Directory URI tabulce, pokud nalezne, tak jde o lokální hovor v rámci CUCM clusteru a směruje se na zařízení
  3. CUCM hledá v naučeném nebo importovaném katalogu, propojené clustery si mohou vyměňovat katalogy pomocí Intercluster Lookup Service (ILS), při nalezení se route string z katalogu dále hledá v SIP Route Pattern a směruje dle tohoto
  4. CUCM zkusí nalézt vyhovující SIP Route Pattern pomocí host části Directory URI (pravá strana adresy - FQDN či IP adresa) a v případě nalezení směruje do přiřazeného SIP Trunku, můžeme tak nastavit defaultní směrování pro všechny SIP URI neznámé lokálně ani v propojených systémech
  5. hovor je blokován

Telefon registrovaný k CUCM má přiřazeno Directory Number a může mít také Directory URI. Volat cílový telefon pak můžeme oběma způsoby, ale každá hodnota je uložena v jiné tabulce a CUCM musí vědět, kde hledat. Proto můžeme definovat, jaká kombinace znaků se považuje za Directory Number a ostatní je Directory URI.

Nastavení je v  Device - Device Settings - SIP Profile, položka Dial String Interpretation. Zároveň zde můžeme zatrhnout Use Fully Qualified Domain Name in SIP Requests.

Pozn.: Některá nastavení CUCM jsme provedli již minule, například Cluster Fully Qualified Domain Name.

Automatické adresy DN@FQDN

Zajímavá vlastnost je, že i když nenastavíme k Directory Number žádné Directory URI, tak jedno funguje automaticky. Jde o volání adresy vlastní Directory-Number@Cluster-Fully-Qualified-Domain-Name, příklad 111@firma.cz. Tedy všechny linky se dají rovnou volat jako třeba SIP URI lokálně a až zprovozníme další kroky, tak i z internetu. Důležitá je doména, kterou nastavíme v Enterprise Parameters položce Cluster Fully Qualified Domain Name.

Směrování URI z CUCM na Expressway

Minulým krokem jsme umožnili volání pomocí URI v rámci našeho CUCM clusteru. A pokud bychom doplnili další konfiguraci (hlavně zprovoznění ILS), tak i v rámci propojených clusterů. Nyní chceme nastavit, aby volání na všechna neznámá URI byla směrována na ExpC.

Úprava SIP Trunk

Volitelně můžeme upravit nastavení SIP Trunku, který jsme vytvořili minule, aby se v hovorech předávalo Directory URI místo Directory Number (případně oboje).

Pod  Device - Trunk nalezneme náš trunk směřující na Expressway server a v sekci Outbound Calls upravíme položku Calling and Connected Party Info Format na Deliver URI only in connected party, if available.

Je tu ještě jedno nastavení, které jsme měli provést již minule, pokud chceme dovolit hovory, kdy voláme číslo a to je přesměrováno na jiné číslo. V části SIP Information je potřeba nastavit položku Rerouting Calling Search Space na některou naši hodnotu (na přesměrování se reaguje automaticky vytvořením nového hovoru na přesměrovanou adresu, ale kontroluje se CSS a pokud není zadána žádná hodnota, tak se hovor nenaváže).

Vytvoření SIP Route Pattern

Aby se volání na veřejné URI adresy dostalo na Expressway, který by je dále směroval do internetu, tak musíme definovat pattern pro dané doménové jméno (host část adresy). Nejjednodušší je vytvořit SIP Route Pattern pro všechna doménová jména (nejprve se hledají lokální adresy a pak se teprve porovnává pattern, takže to znamená všechny adresy mimo lokálních).

Nastavení je v Call Routing - SIP Route Pattern, přidáme nové pravidlo Add New. Jako Pattern Usage zvolíme Domain Routing, IPv4 Pattern pro všechny domény využijeme zástupný znak *, Route Partition zvolíme, kam chceme hovory zařadit (případně vytvoříme novou partition), SIP Trunk/Route List vybereme náš trunk na Expressway.

CUCM SIP Route Pattern

Pokud chceme, abychom mohli volat URI adresy, kde je v host části použita IP adresa, tak musíme přidat další SIP Route Pattern typu IPAddress Routing. CUCM nedovolí definovat všechny IP adresy jedním pravidlem, ale můžeme je rozdělit na dvě poloviny. Takže jako IPv4 Pattern v jednom pravidle použijeme adresu 1.0.0.0/1 a v druhém 128.0.0.0/1 (tím pokryjeme celý rozsah). Ostatní nastavení provedeme stejné jako v případě Domain Routing.

Směrování URI z Expressway do internetu

Poslední část konfigurace provedeme na Expressway serveru, aby se hovor dostal do internetu na cílový server. Na ExpC již máme vše hotovo, protože minule jsme vytvořili Traversal Zone for B2B a pomocí Traversal zone B2B search rule nastavili směrování všeho do této zóny. Pouze, pokud jsme v CUCM neighbor search rule nastavili velké omezení na cílové adresy u příchozích hovorů, které směrujeme na CUCM. Tak musíme toto pravidlo upravit, aby akceptovalo všechna Directory URI, která na CUCM použijeme, například regex .*@firma.com (nebo sufix).

Zbývající konfigurace odchozích hovorů se provádí na ExpE. Tam případně také musíme upravit Call Policy pokud by blokovala i požadované hovory.

Konfigurace DNS Zone

DNS Zone slouží pro vyhledání externích systémů pomocí DNS dotazů. To funguje plně automaticky (Expressway musí mít definován alespoň jeden systémový DNS server) a na zóně nastavujeme hlavně parametry pro použité protokoly. Vyváříme na ExpE.

Configuration - Zones - Zones

Jméno zóny můžeme volit například DNS Zone a typ DNS. Většinu hodnot můžeme nechat v defaultním stavu, využijeme protokol SIP i H.323, Fallback transport protocol nastavíme na TCP.

ExpE DNS Zone

Konfigurace DNS Zone Search rule

A stejně jako dříve ještě musím určit, jaké hovory budou směrovány do vytvořené DNS zóny. Využijeme regulární výraz, který má zabránit použití DNS Zone pro URI s lokální doménou.

Configuration - Dial plan - Search rules

Pravidlo pojmenujeme třeba DNS Zone search rule, prioritu můžeme nastavit 90, mód Alias pattern match, typ Regex a pattern (?!.*@%localdomains%.*$).*, Pattern behavior zvolíme Leave (aby se nemodifikoval alias) a On successful match dáme Stop, poslední jako Target vybereme DNS Zone. Můžeme také nastavit omezení Source na Named a Source name na Traversal Zone for B2B, aby se uplatnilo pouze na hovory z ExpC.

Pozn.: Proměnná %localdomains% bere hodnoty nastavené v Configuration - Domains na ExpC, což patrně funguje pouze při MRA (Mobile Remote Access).

ExpE DNS Zone search rule

Nastavení veřejných DNS záznamů

V předchozích krocích jsme nakonfigurovali odchozí volání na Directory URI. Většinu konfigurace pro příchozí volání již máme také hotovou. Záleží pouze na tom, jaký je formát URI adresy. Pokud je v části host použita veřejná IP adresa našeho ExpE serveru, tak již volání funguje. Když se využívají doménová jména, tak záleží na vytvořených DNS záznamech. Již při instalaci jsme použili klasické A-čkové DNS záznamy, abychom mohli na servery ExpC a ExpE (včetně veřejné NATované adresy) odkazovat pomocí FQDN.

Pokud tedy v části host použijeme FQDN ExpE serveru (třeba expe.firma.cz), tak by také vše mělo fungovat. Běžnější je situace, kdy se v host části použije pouze doména (třeba firma.cz) obdobně jako u emailu. Pak je potřeba mít definované určité SRV záznamy, které určí adresu serveru (a také komunikační port).

SRV záznamy musíme vytvořit na veřejné doméně, kterou použijeme pro SIP nebo H.323 Annex O adresy. Použité záznamy záleží na použitých protokolech. SRV záznam se skládá z názvu služby, protokolu a domény a určujeme prioritu, váhu, číslo portu a DNS A záznam hosta.

Protokol SIP a SIPS

Pro SIP a SIP protokol vytvoříme SRV záznamy _sip._tcp.firma.cz a _sips._tcp.firma.cz směřující na veřejné jméno ExpE serveru, tedy expe.firma.cz, a odpovídající porty, defaultně 5060 a 5061.

SRV     _sip._tcp.firma.cz.    3600    IN      SRV     0  0 5060 expe.firma.cz.
SRV     _sips._tcp.firma.cz.   3600    IN      SRV     0  0 5061 expe.firma.cz.

Pokud na ExpE používáme i SIP UDP, tak přidáme záznam _sip._udp.firma.cz.

Protokol H.323

Pro H.323 protokol vytvoříme SRV záznamy _h323ls._udp.firma.cz a _h323cs._tcp.firma.cz směřující na expe.firma.cz a defaultní porty 1719 a 1720.

SRV     _h323ls._udp.firma.cz. 3600    IN      SRV     0  0 1719 expe.firma.cz.
SRV     _h323cs._tcp.firma.cz. 3600    IN      SRV     0  0 1720 expe.firma.cz.

Další služby

Pokud používáme TRUN protokol, tak ještě přidáme SRV záznam _turn._udp.firma.cz.

Pro určité situace (hlavně Mobile Remote Access) potřebujeme definovat SRV záznamy také na interní doméně směrující na ExpC. Myslím, že v tomto případě to není třeba.

Testovací hovory

Ve chvíli kdy dokončíme konfiguraci, tak se určitě těšíme vyzkoušet, že nám volání funguje. Můžeme k tomu využít veřejné testovací servery nebo i softwarové klienty.

Testovací servery

Minule jsme si uvedli testovací IP adresy, kde běžel H.323 videokonferenčí systém. Teď se podíváme na testovací SIP adresy.

Již minule jsme si uvedli Cisco Loopback Site., která se volá pomocí URI loopback@rtp.ciscotac.net.  Může se stát, že se nám hovor nespojí, protože tato adresa je přesměrována dynamicky na jinou. V logu na Expressway serveru uvidíme stav 302 Moved Temporarily. Pak by se měl automaticky navázat hovor na přesměrovanou adresu, ale musíme mít nastaven Rerouting Calling Search Space u SIP Trunku (zmíněno výše v kapitole Úprava SIP Trunk).

Další Cisco testovací adresy jsou uvedeny v diskusi Loopback Testing for TelePresence, jde o loopback@cisco.com, loopback2@cisco.com, loopback3@cisco.com.

Na webu KBZ Public Test Systems jsou uvedeny testovací adresy jak H.323, tak SIP. Jako SIP adresy můžeme vyzkoušet zcare@kbz.com, zcare.6000@kbz.com, zcare.c90@kbz.com.

Na adrese SIP5060 Test calls jsou uvedeny testovací adresy (třeba test.time@sip5060.net), ale nepodařilo se mi na ně spojit (chyba Authentication Failed for peer cert), zdá se, že nemají korektní certifikát (pro dané jméno).

Open Source VOIP Software

Pro další testování můžeme využít softwarové klienty či jiné aplikace, ideálně Open Source. Velice rozsáhlý seznam přináší článek Open Source VOIP applications, both clients and servers.

V nějaké Cisco prezentaci jsem viděl využít softwarový SIP telefon X-Lite Free X-Lite Softphone, který se může registrovat k CUCM (na internetu je řada návodů). Neměl jsem moc času a rychle se mi registraci zprovoznit nepodařilo.

Jako užitečnější asi bude softphone, který nainstalujeme na nějaký počítač mimo firmu, a umožní nám provést přímý hovor bez toho, aby se musel registrovat k nějaké SIP proxy. Tedy abychom mohli otestovat volání na naše Directory URI skrze Expressway a nepotřebovali účet u nějaké služby. Existují různí softwaroví klienti, kteří umí fungovat napřímo bez serveru. Úspěšně jsem otestoval klienta Blink, který umožní navázat SIP hovor na SIP URI. Musel jsem s ním nainstalovat i Bonjour SDK, protože tento účet se využije v případě, kdy nemáme žádnou SIP službu (server).

Zajímavé by mi přišel podobný softphone pro mobilní telefon (u mne Android). Podle diskusí by to měl umět CSipSimple, kde můžeme přidat účet typu Local. Na Samsung telefonu je problém, že port 5060 je obsazen službou SecurityLogAgent, takže lokální účet nenastartuje. Na telefonu Sony se vše spustilo, ale hovor se vůbec nedovolal na ExpE.

Hledání problémů na CUCM

Ještě malá zmínka na závěr. Na CUCM podle mne chybí řada informací o provozu, které by měl zobrazovat. K dispozici je nástroj Cisco Unified Real-Time Monitoring Tool (RTMT), který opravdu hodně věcí zobrazí, ale jeho obsluha mi nepřijde zrovna User Friendly. Pro sledování SIP hovorů má ale velice pěknou funkci.

V menu Voice/Video - Call Process - Session Trace Log View - Real Time Data zobrazí pro zadané období proběhlé hovory a dají se zobrazit detaily včetně grafu průběhu komunikace.

RTMT Session Trace Log View
zobrazeno: 3924krát | Komentáře [0]

Autor:

Související články:

Cisco Expressway

Cisco TelePresence Video Communication Server (VCS) servery (Collaboration Edge) umožňují propojení interní Cisco Unified Communications (jako CUCM, CUP) do internetu. Díky tomu získáme Mobile Remote Access (MRA), připojení našich vzdálených a mobilních uživatelů, a Business to Business (B2B) komunikaci, spojení s dalšími organizacemi pomocí videokonference.

Pokud se Vám článek líbil, tak mne potěšíte, když uložíte odkaz na některý server:

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže. Pokud chcete poradit s nějakým problémem či diskutovat na nějaké téma, tak použijte fórum.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O


Ochrana proti SPAMu, zdejte následující čtyři znaky image code

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách