Vezměme si hypotetického partnera služby Webex s názvem TelSP, který ilustruje různé modely nasazení, které může partner přijmout.

Zde jsou high-level specifikace a požadavky TelSP:

• Partner plánuje používat sip.telsp.com jako doménu nejvyšší úrovně, která je sdílena mezi všemi zákazníky, které spravuje.

• Partner vlastní sip.telsp.com a může spravovat infrastrukturu DNS a certifikační autority, spravovat adresy DNS a podepisovat certifikáty pro tuto doménu a její dílčí domény.

• Partner může nasadit dva samostatné hraniční řadiče relace (fyzické nebo virtuální) jako místní brány pro sdílený přístup k síti PSTN mezi koncovými zákazníky.

• Partner má dvě fyzické weby a oba tyto weby sdílejí připojení k síti PSTN:

  • Miami (rozcestník)

  • Chicago

• TelSP provozuje své místní brány jménem dvou zákazníků Custa a Custb, jak jsou zde uvedeny.

Požadovaným scénářem je vytvoření/ukončení sítě PSTN pro oba zákazníky používající brány Miami a Chicago dodané partnerem, jak je znázorněno na obrázku:

Přiřazování umístění zákazníka k přenosovému spoji a bráně

Služba Webex Calling umožňuje vytváření přenosových spojů a sdílení přenosového spoje na více pobočkách. Při vytváření přenosového spoje přidružit přenosový spoj k umístění.

Pro společnost Custa jsou podrobnosti o přenosovém spoji následující:

Obrázek znázorňuje přidružení umístění zákazníka k bráně a přenosovému spoji pro společnost Custa:

V tomto nasazení je přenosový spoj přidružený k dané pobočce primárním připojením sítě PSTN pro danou pobočku. Druhý přenosový spoj se používá jako sekundární připojení nebo trasa sítě PSTN pro konkrétní položky plánu vytáčení. Implementace primárního a sekundárního vztahu PSTN probíhá prostřednictvím konceptu skupiny tras. Podrobnosti najdete v části Nastavení zákazníka služby Webex.

Pro Custb je vytvořeno podobné nastavení s následujícími přenosovými spoji:

Obrázek znázorňuje přidružení umístění zákazníka k bráně a přenosovému spoji pro společnost Custb:

Na obrázku je třetí umístění, konkrétně New York, které můžete přidat později a ukázat na trunk_chicago přenosový spoj jako primární připojení sítě PSTN.

Při nasazení místní brány, která sdílí více přenosových spojů, společnost Cisco NAŘÍDÍ použití jedinečného čísla FQDN pro každý přenosový spoj. Podrobnosti najdete v tématu Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling .

Použití IP adresy a známého portu na přenosový spoj je ideální volbou. Obstarání veřejné adresy IPV4 však může být náročné pro některé partnery, kteří chtějí používat jednu adresu na bránu a web.

Proto si přečtěte tyto důležité ukazatele:

• Společnost Cisco nenařídí IP adresu pro jeden přenosový spoj.

• Adresa přenosového spoje může přeložit na jedinečnou adresu IP nebo na adresu sdílenou mezi jiným přenosovým spojem.

• Společnost Cisco doporučuje mít jedinečný naslouchací port pro každý přenosový spoj z následujících důvodů:

  1. Zajišťuje izolaci na úrovni sítě mezi zákazníky

  2. U hraničních řadičů relace je typické znovu použít pomíjivé připojení TCP soketu, pokud není zajištěna izolace jako jedinečný klient rozdělený podle IP adresy nebo jedinečný naslouchací port pro klienta.

  3. Připojení nebo připojení na přenosový spoj prostřednictvím izolace klienta poskytuje lepší propustnost specificky v síťových podmínkách s vysokou ztrátou dat. Proto provoz od jednoho zákazníka nemá vliv na druhého.

Adresa IP na jednu bránu: Konfigurace přenosového spoje a doporučení

Podívejte se na příklady různých modelů plánování:

Model 1: Jedinečná IP adresa na přenosový spoj

V tomto modelu jsou všechny přenosové spoje hostované oběma bránami rozlišeny na jedinečnou IP adresu a každý z těchto přenosových spojů může nebo nemusí používat stejný port, ale v ideálním případě stejný port.

Znázornění informací v tabulkovém formátu:

V tomto modelu může partner použít adresu SRV. Služba Webex Calling umožňuje pouze „_sips._tcp“ jako kombinaci služby a protokolu zjistit adresu protějšku, pokud se jedná o záznam SRV.

Ukázka řešení záznamu SRV

nslookup type=srv _sips..._tcpServer .trunk.miami.custa.sip.telsp.com:		8.8.8.8 Adresa:	8.8.8.8#53 Neautoritativní odpověď: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com 

Model 2: Sdílená IP adresa na bráně, ale různé porty pro naslouchání

V tomto modelu se všechny přenosové spoje hostované na místní bráně v Chicagu řeší na stejnou IP adresu a všechny přenosové spoje hostované na místní bráně v Miami se řeší na jinou IP adresu. Při použití stejné adresy IP je však každý přenosový spoj nakonfigurován pomocí FQDN v centru Control Hub a je nakonfigurován s jedinečným portem.

V tomto modelu partner používá adresu SRV. Služba Webex Calling umožňuje pouze „_sips._tcp“ jako kombinaci služby a protokolu zjistit adresu protějšku, pokud se jedná o záznam SRV.

Další ukázka řešení záznamu SRV je následující. V tomto příkladu existuje 1 A záznam na jednu IP adresu. Port je však jedinečný pro každou adresu a je reprezentován prostřednictvím specifické konfigurace DNS spojující adresu SRV se správným portem.

nslookup type=srv _sips..._tcpServer .trunk.miami.custa.sip.telsp.com:		8.8.8.8 Adresa:	8.8.8.8#53 Neautoritativní odpověď: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com Server:		8.8.8.8 Adresa:	8.8.8.8#53 Neautoritativní odpověď: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

Partner vlastní telsp.com a jeho subdomény. Proto server DNS a oprávnění získat certifikáty podepsané schválenou certifikační autoritou leží na partnerovi.

• Služba Cisco Webex očekává, že partner zveřejní adresu FQDN nebo SRV včetně Záznamů ve veřejné doméně.

• Služba Cisco Webex očekává, že partner bude používat jednu z certifikačních autorit uvedených v tomto dokumentu.

Při použití čísla FQDN jako adresy přenosového spoje nastavte podepsané certifikáty s obecným názvem (CN) nebo alternativním číslem předmětu (SAN) nastaveným na hodnoty FQ<UNK> pro přenosové spoje.

K vygenerování FQ<UNK> v certifikátu použijte jednu z těchto metod:

• Vyberte jeden z FQ<UNK> jako obecný název (CN) a zbytek jako alternativní číslo pacienta (SAN).

• Umístěte doménu nejvyšší úrovně (sip.telsp.com) jako CN a všechny FQ<UNK> jako SANs.

  V budoucnu můžete certifikát ověřit na základě domény nejvyšší úrovně, kterou tato konfigurace využívá.

Při použití SRV jako adresy přenosového spoje nastavte podepsané certifikáty s kódem CN nebo SAN na hostitelskou část adresy SRV. Záznam A nebo CNAME, na který se adresa SRV překládá, není vyžadován.

Nastavení brány

Pomocí těchto zdrojů můžete nastavit místní bránu.

Chcete-li nastavit Cisco CUBE, použijte tento postup: Konfigurace místní brány na Cisco IOS XE pro Webex Calling

Můžete nastavit schválené protokoly S třetích stran, viz: Začínáme s místní bránou

Nastavte hostovanou bránu partnera v souladu s těmito pokyny: Začínáme s místní bránou

Každý přenosový spoj nastavte podle příslušných pokynů pro zařízení SBC. Pokyny k aplikaci Cisco CUBE naleznete zde: Konfigurace místní brány na Cisco IOS XE pro Webex Calling

Nastavte hlasové třídy, vytáčecí vrstevníky a skupiny vytáčených protějšků pro příchozí a odchozí provoz pro přenosový spoj podle obrázku:

Z centra Partner Hub můžete spustit centrum Control Hub pro Custa nebo Custb a nakonfigurovat bránu. Pomocí tohoto postupu nakonfigurujte pro každého zákazníka:

1. Vytvoření přenosového spoje – přidejte přenosový spoj v části Volání / Směrování hovorů / přenosový spoj pro každou sdílenou bránu partnera. Informace o nastavení přenosového spoje najdete v tématu Konfigurace přenosových spojů, skupin směrování a plánů vytáčení pro službu Webex Calling

2. Přidání domény a ověření – Přidejte a ověřte následující doménu, která se používá k vytvoření přenosového spoje v části Nastavení správy/organizace/domény.

   Kyselina L-askorbová	Zákusek B
   sip.telsp.com	sip.telsp.com

   Po přidání domény se vygeneruje token a umístí do záznamu TXT pro doménu na serveru DNS partnera. Tento záznam umožňuje centru Control Hub ověřit, zda je doména vlastněna partnerem. Podrobnosti najdete v tématu Správa domén

   Protože Společná doména se používá pro ověření na každém zákazníkovi. Protože však k tomuto ověření dochází na úrovni organizace zákazníka, ujistěte se, že je generován jiný token a použit pro ověření v každé organizaci zákazníka. Protože se napříč organizacemi zákazníků používá jedna doména, nemůže si vlastnictví domény nárokovat žádná organizace.
3. Nastavit adresu SBC pomocí FQDN—

   Pro bránu Miami:

   Parametr	Kyselina L-askorbová	Zákusek B
   Pobočka	Denver	bostonském
   Název přenosového spoje	trunk_miami	trunk_miami
   Typ přenosového spoje	Na základě certifikátu	Na základě certifikátu
   Typ zařízení	např. Cisco Unified Border Element (nebo jiné podporované zařízení)	např. Cisco Unified Border Element (nebo jiné podporované zařízení)
   Typ adresy SBC	Plně kvalifikovaný název domény (FQDN)	Plně kvalifikovaný název domény (FQDN)
   Název hostitele	trunk.miami.custa	trunk.miami.custb
   Doména	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   Plně kvalifikovaný název domény (FQDN)	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Maximální počet souběžných hovorů (250–6500)	500	500

   Pro Chicago Gateway:

   Parametr	Kyselina L-askorbová	Zákusek B
   Pobočka	Detroit (řeka)	Dallas
   Název přenosového spoje	trunk_chicago	trunk_chicago
   Typ přenosového spoje	Na základě certifikátu	Na základě certifikátu
   Typ zařízení	např. Cisco Unified Border Element (nebo jiné podporované zařízení)	např. Cisco Unified Border Element (nebo jiné podporované zařízení)
   Typ adresy SBC	Plně kvalifikovaný název domény (FQDN)	Plně kvalifikovaný název domény (FQDN)
   Název hostitele	Trunk (rozcestník)	Trunk (rozcestník)
   Doména	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   Plně kvalifikovaný název domény (FQDN)	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Maximální počet souběžných hovorů (250–6500)	500	500

   • (Volitelně) Nemáte jedinečný název přenosového spoje mezi zákazníky a stejný název vám může pomoci při sledování přenosového spoje.

   • Některé S umožňují konfiguraci stejného portu, ale tato konfigurace může ovlivnit kapacitu. Proto používejte různé porty.

4. Použití přenosových spojů – vyberte libovolné umístění přenosového spoje z následujících důvodů:

   • Přenosový spoj může v připojení PSTN použít libovolné umístění.

   • Přístup k přenosovému spoji můžete získat prostřednictvím skupiny směrování.

   • Přenosový spoj může použít jakýkoli plán vytáčení.

5. Viz definice přenosového spoje s přidruženými pobočkami:

   

   Tyto přenosové spoje můžete použít k vytvoření skupin směrování. V obrázku rg_miami_chicago je definována skupina směrování, která směruje hovory na trunk_miami přenosový spoj jako primární možnost a na trunk_chicago přenosový spoj jako sekundární možnost.

   

   Můžete definovat druhou skupinu směrování, rg_chicago_miami která směruje hovory do přenosového trunk_chicago spoje jako primární možnost a do přenosového trunk_miami spoje jako sekundární možnost.

6. Definované přenosové spoje a skupiny směrování jsou nyní k dispozici v možnosti Připojení k volání pro každou pobočku. Na obrázku se podívejte na umístění v Denveru.

   

7. V definici plánu vytáčení můžete použít přenosové spoje a skupiny směrování. Například rozsah místních čísel v Chicagu pro zákazníka je rozdělen a ukončen do skupiny rg_chicago_miami směrování (pro všechny pobočky) na obrázku: