Děkujeme za vaši zpětnou vazbu.

Uvažujme hypotetického partnera Webex s názvem TelSP, který ilustruje různé modely nasazení, které může partner přijmout.

Zde jsou specifikace a požadavky na vysoké úrovni 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é spravují.

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

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

• Partner má dvě fyzické stránky a obě tyto weby sdílejí připojení PSTN:

  • Miami

  • Chicago

• TelSP provozuje své místní brány jménem dvou zákazníků CuSTA a CustB, jak jsou dále označováni.

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

Příklad zjednodušeného nasazení

Následující zjednodušený příklad ukazuje, jak identita Peer cert umožňuje jednomu certifikátu podporovat více kmenů zákazníků:

• Certifikát —sip. telsp.com

• Kufry

  • zákazník.sip.telsp.com

  • custb.sip.telsp.com

• Identita vzájemného certifikátu —sip.telsp.com

• Výsledek

  • Používá se jediný certifikát

  • Podporováno je více zákaznických kmenů

Přiřazení polohy zákazníka ke kmeni a bráně

V následujících částech jsou uvedeny podrobné mapování konfigurace pro výše popsané nasazení.

Webex Callingumožňuje vytváření kmenů a sdílení ku fru na více místech. Při vytváření kufru přiřaďte kmen k míst u.

U CUsta jsou podrobnosti kufru následující:

Obrázek ukazuje přidružení umístění zákazníka k bráně a kmene pro CUsta:

V tomto rozmístění je kmen přidružený k umístění primárním připojením PSTN pro dané umístění. Druhý kmen se používá jako sekundární připojení PSTN nebo trasa pro konkrétní položky číselného plánu. Implementace primárního a sekundárního vztahu připojení PSTN probíhá prostřednictvím konceptu skupiny tras. Podrobnosti naleznete v části Konfigurace kmenů brány v části Řídicí centrum.

Pro CustB je vytvo řeno podobné nastavení s následujícími trunky:

Obrázek ukazuje přidružení umístění zákazníka k bráně a k mene pro CustB:

Obrázek ukazuje třetí místo, konkrétně New York, které můžete přidat později a ukázat na trunk_chicago trunk jako primární připojení PSTN.

Při nasazení místní brány, která sdílí více kmenů, společnost Cisco nařizuje použití jedinečného FQDN na kmen. Podrobnosti najdete v tématu Konfigurace kmenů, skupin směrování a vytáčených plánů pro volání přes WebEx.

Ideální volbou je použití IP adresy a dobře známého portu na kmen. Pořízení veřejné adresy IPv4 však může být náročné pro některé partnery, kteří chtějí použít jednu adresu na bránu na web.

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

• Společnost Cisco neukládá IP adresu pro každý kmen.

• Adresa kmene se může rozlišit na jedinečnou IP adresu nebo na adresu sdílenou mezi jiným kmenem.

• Společnost Cisco doporučuje nakonfigurovat každé kmenové připojení s jedinečnou kombinací IP adresy a portů na místní bráně z následujících důvodů:

  1. Udržování samostatných připojení TCP na kmen podporuje maximální kapacitu souběžného volání na kmen. Sdílení IP adres a kombinací portů mezi kmeny může negativně ovlivnit kapacitu hovorů.

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

  3. U hraničních řadičů relací je typické opětovné použití pomíjivého připojení soketu TCP, pokud není zajištěna izolace jako jedinečný tenant rozdělený na oddíl IP adresou nebo jedinečným portem pro poslech pro klienta.

  4. Připojení nebo připojení na kmen prostřednictvím izolace klienta poskytuje lepší propustnost zejména v síťových podmínkách s vysokou ztrátou dat. Provoz od jednoho zákazníka tedy nemá vliv na druhého.

IP adresa na bránu: Konfigurace kmene a doporučení

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

Model 1: Jedinečná IP adresa na kmen

V tomto modelu se všechny kmeny hostované oběma branami přeloží na jedinečnou IP adresu a každý z těchto kmenů může nebo nemusí používat stejný port, ale ideálně stejný port.

Reprezentace informací v tabulkovém formátu:

Ve stejném modelu může partner použít adresu SRV. Webex Callingpovoluje pouze „_sips. _tcp“ jako kombinace služby a protokolu pro zjištění adresy peer, pokud se jedná o záznam SRV.

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

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Model 2: Sdílená IP na bránu, jedinečné porty pro poslech

V tomto modelu jsou všechny kmeny hostované na místní bráně v Chicagu přeloženy na stejnou IP adresu a všechny kmeny hostované na místní bráně Miami přeloží na jinou IP adresu. Při použití stejné IP adresy je však každý kmen nakonfigurován pomocí FQDN v řídicím rozbočovači a je nakonfigurován s jedinečným portem.

Ve stejném modelu používá partner adresu SRV. Webex Callingpovoluje pouze „_sips. _tcp“ jako kombinace služby a protokolu pro zjištění adresy peer, pokud se jedná o záznam SRV.

Další příklad toho, jak se záznam SRV řeší, je následující. V tomto příkladu existuje 1 záznam A na adresu IP. Port je však jedinečný pro každou adresu a je reprezentován specific kou konfigurací DNS propojující adresu SRV se správným portem.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_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
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

U kmenů založených na SRV je identita Peer cert původně vyplněna z nakonfigurovaných hodnot SRV a lze ji přizpůsobit podle stejných ověřovacích pravidel.

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ží partnerovi.

• Cisco Webexočekává, že partner zveřejní adresu FQDN nebo SRV včetně záznamů A ve veřejné doméně.

• Cisco Webexočekává, že partner použije jednu z certifikačních autorit uvedených v tomto dokumentu.

Při konfiguraci kmenů pomocí FQDN nebo SRV:

• Každý kmen musí mít stále jedinečné FQDN pro směrování a identifikaci

• Záznamy DNS (záznam A nebo SRV) musí být správně nakonfigurovány a řešitelné

• Tyto FQDN se používají pro signalizaci a směrování. Ověření certifikátu se provádí proti nakonfigurované identitě Peer cert, která má výchozí hodnoty kmenového FQDN, ale lze ji přizpůsobit sdílené identitě vlastněné partnerem.

  Pole identity Peer cert se předem vyplní z kmenového FQDN a lze jej přepsat sdílenou domé nou vlastněnou partnerem a používat jeden certifikát ve více kmenech zákazníků.

Nastavení brány

Tyto prostředky použijte k nastavení místní brány.

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é SBC třetích stran, viz: Začínáme s místní bránou

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

Nastavte každý kufr podle příslušných pokynů pro zařízení SBC. Pokyny k řešení Cisco CUBE naleznete v tématu: Konfigurace místní brány na Cisco IOS XE Webex Calling

Nastavte hlasové třídy, vytáčecí vrstevníky a vytáčecí skupiny pro příchozí a odchozí provoz pro kufr podle obrázku:

Při zřizování kmene poskytuje Control Hub možnost konfigurovat identitu Peer cert na stránce Přidat kmen. Toto vylepšení zjednodušuje pracovní postup tím, že umožňuje partnerům konfigurovat a znovu použít jednu doménu nejvyšší úrovně napříč více zákaznickými organizacemi. Tento přístup eliminuje potřebu samostatných certifikátů pro každého zákazníka nebo kmen, což snižuje provozní úsilí a zjednodušuje proces nastavení.

Při konfiguraci kmenů v Řídicím centru definujte identitu Peer cert, abyste povolili použití jediného certifikátu pro vaši doménu nejvyšší úrovně ve všech zákaz nických organizacích. Ujistěte se, že CN nebo SAN certifikátu zahrnuje tuto doménu nejvyšší úrovně. S identi tou Peer cert používá místní brána jediný certifikát, jehož CN nebo SAN obsahuje sdílenou doménu partnera (například sip.telsp.com). Certifikáty se zástupnými znaky (např. *.sip.telsp.com) nejsou podporovány. Webex Callingpřijímá tento certifikát pro každý kufr zákazníka, který je výslovně nakonfigurován s touto hodno tou jako identitou Peer cert. Certifikát musí obsahovat přesně nakonfigurovanou hodnotu identity Peer cert v CN nebo SAN. To eliminuje potřebu konfigurovat samostatné certifikáty nebo položky CN/SAN pro jednotlivé kmenové FQDN.

Ověření domény a použití certifikátu

Je důležité pochopit, jak se ověření domény liší od používání certifikátu:

• Ověření domény (na zákazníka) — Každá zákaznická organizace musí nezávisle ověřit doménu (například sip.telsp.com) přidáním jedinečného záznamu TXT v DNS. Tím je zajištěno, že partner vlastní doménu a zab rání neoprávněnému použití.

• Správa certifikátů (globální) — jediný certifikát vydaný pro doménu nejvyšší úrovně partnera lze sdílet ve všech kmenech zákazníků pomocí identity Peer cert. Neexistuje žádný požadavek na udržování samostatných certifikátů pro každého zákazníka nebo na kufr.

Chování identity peer cert

Identita peer cert definuje identitu, která se Webex Calling očekává v certifikátu prezentovaném místní bránou.

Když je nakonfigurován:

• Webex Callingověří certifikát porovnáním nakonfigurované identity Peer cert s CN nebo SAN v certifikátu

• Pokud se hodnoty shodují, připojení TLS je přijato

• Pokud se hodnoty neshodují, připojení je odmítnuto

Ověřovat se mohou pouze kmeny explicitně nakonfigurované s odpovídající identitou Peer cert .

Ověření certifikátu samo o sobě není jedinou kontrolou prováděnou během ověřování. Kromě ověření certifikátu CN nebo SAN proti nakonfigurované identitě Peer cert ověřuje Webex Calling také, zda je kmenové FQDN explicitně nakonfigurováno a přidruženo k odpovídající identitě Peer cert v Řídicím centru.

Identita Peer cert je předem vyplněna z kmenových hodnot FQDN/SRV. Pokud zachováte výchozí hodnoty, chování existujícího certifikátu pro jednotlivé kmeny se nezmění. Stávající kmen ové systémy založené na certifikátech nadále fungují beze změn. Sdílenou identitu Peer cert můžete přijmout na nových nebo stávajících kmenech svým vlastním tempem, a oba modely mohou koexistovat.

1. Platný příklad konfigurace:

   • Certifikát CN —sip.tel sp.com

   • Certifikát SAN —custa.sip.telsp.com

   • Identita vzájemného certifikátu —custa.sip.telsp.com

   • Kufr FQDN —trunk.miami.custa.sip.telsp.com

   Výsledek — Připojení je úspěšné, protože identita Peer cert (custa.sip.telsp.com) odpovídá hodnotě SAN v certifikátu a kmenový FQDN (trunk.miami.custa.sip.telsp.com) je subdoménou nakonfigurované identity certifikátu Peer.

2. Příklad selhání připojení:

   • Certifikát CN —sip.tel sp.com

   • Certifikát SAN —custa.sip.telsp.com

   • Identita vzájemného certifikátu —custb.sip.telsp.com

   • Kufr FQDN —trunk.miami.custb.sip.telsp.com

   Výsledek — Připojení selže při podání TLS, protože identita Peer cert (custb.sip.telsp.com) není přítomna v CN nebo SAN certifikátu. Kmen FQDN je správně subdoménou identity Peer cert, ale certifikát tuto identitu nenese.

3. Neplatný příklad konfigurace:

   • Certifikát CN —sip.tel sp.com

   • Certifikát SAN —custa.sip.telsp.com

   • Identita vzájemného certifikátu —custa.sip.telsp.com

   • Kufr FQDN —trunk.miami.custb.sip.telsp.com

   Výsledek — Řídicí centrum tuto konfiguraci odmítne v době uložení, protože kmenový FQDN (trunk.miami.custb.sip.telsp.com) není roven nebo subdoména nakonfigurované identity Peer cert (custa.sip.telsp.com).

V partnerském centru můžete spustit Control Hub pro CuSTa nebo CustB a nakonfigurovat bránu. Tento postup slouží ke konfiguraci pro každého zákazníka:

1. Vytvoření kanálu — přidejte kufr pod položkou Volání/Směrování hovorů/Trunk pro každou sdílenou bránu partnera. Postup nastavení kmene naleznete v tématu Konfigurace kmenů, skupin tras a vytáčecích plánů pro 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í kmene v části Spravání/Nastavení organizace/Domény.

   ZákazníkB	ZákazníkC
   sip.telsp.com	sip.telsp.com

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

   Společná doména se používá pro ověření u každého zákazníka. Vzhledem k tomu, že k tomuto ověření dochází na úrovni organizace zákazníků, ujistěte se, že je vygenerován jiný token a použit pro ověření u každé zákaznické organizace. Protože jedna doména se používá napříč organizacemi zákazníků a každá zákaznická organizace musí nezávisle ověřit doménu pomocí jedinečného záznamu TXT, a to i při sdílení stejné domény.

   Pro identitu Peer cert je vyžadováno pouze ověření domény. Nenahrazujte sdílen ou doménu u zákaznické organizace. Doménu si může nárokovat pouze jedna organizace, zatímco stejnou doménu lze ověřit ve více organizacích.

3. Nastavte adresu SBC pomocí FQDN—

   Pro bránu Miami:

   Parametr	ZákazníkB	ZákazníkC
   Lokace	Denveru	Boston
   Název kufru	trunk_miami	trunk_miami
   Typ kufru	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	FQDN	FQDN
   Název hostitele	lgw.miami	lgw.miami
   Doména	sip.telsp.com	sip.telsp.com
   Přístav	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Maximální počet souběžných hovorů (250-6500)	500	500

   Pro bránu v Chicagu:

   Parametr	ZákazníkB	ZákazníkC
   Lokace	Detroit	Dallas
   Název kufru	trunk_chicago	trunk_chicago
   Typ kufru	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	FQDN	FQDN
   Název hostitele	lgw.chicago	lgw.chicago
   Doména	sip.telsp.com	sip.telsp.com
   Přístav	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Maximální počet souběžných hovorů (250-6500)	500	500

   • (Volitelné) Názvy kmenů nemusí být jedinečné napříč organizacemi zákazníků. Opětovné použití stejného jména (například trunk_miami) usnadňuje sledování kufru.

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

4. Identita rovnocenného certifikátu—

   • Předpona — Předpona je volitelná. Ponechte prázdné, chcete-li nastavit identitu Peer cert pouze pro doménu. Toto je model sdíleného certifikátu použitý v tomto článku (Peer cert identity — sip.telsp.com, pokrývající všechny kmeny zákazníků). Volitelně zadejte předponu pro definování konkrétnější identity certifikátu (například předpona: CustomerB, Doména: Customerb.sip.telsp.com pro certifikát na zákazníka). Samotný kmenový FQDN zůstává definován adresou SBC Hostitel a poli Domain a musí být roven nebo subdoménou výsledné identity Peer cert.

     Příklad:

     Předpona — zákazníkB

     Doména—sip.telsp.com

     Výsledek—customerb.sip.telsp.com

   • Doména: Vyberte doménu ze seznamu domén ověřených v organizaci zákazníka. Výsledná identita Peer cert (předpona + doména) se musí shodovat s CN nebo SAN certifikátu, který váš SBC předkládá. Webex Callingpoužije tuto hodnotu k ověření připojení TLS.

     

     Řídicí centrum tuto konfiguraci odmítne v době uložení, protože kmenové FQDN není pod nakonfigurovanou identitou Peer cert.

     Pokud identita Peer cert neodpovídá CN nebo SAN v certifik átu předloženém SBC, Webex Calling odmítne připojení TLS a kmen se nepodaří navázat.

5. Použití kmenů — vyberte libovolné umístění pro kufr, a to z následujících důvodů:

   • Kmen může použít libovolné místo v připojení PSTN.

   • K kufru můžete přistupovat prostřednictvím skupiny tras.

   • Jakýkoli číselný plán může použít kufr.

6. Podívejte se na definice kmene s přidruženými umístěními:

   

   Tyto kmeny můžete použít k vytvoření skupin tras. Na obrázku je definována skupina tras rg_miami_chicago, která směru je volání do kmene trunk_miami jako primární možnost a do trunk_ chicago jako sekundární možnost.

   

   Můžete definovat druhou skupinu tras rg_chicago_miami, která směruje volání na trunk_chicago trunk jako primární možnost a do trunk_ miami jako sekundární možnost.

7. Definované kmeny a skupiny tras jsou nyní k dispozici ve volbě Vol ající připojení PSTN pro každé umístění. Na obrázku viz umístění v Denveru.

   

8. V definici číselného plánu můžete použít kmeny a skupiny tras. Například rozsah místních čísel v Chicagu pro zákazníka je rozdělen a ukončen na skupinu tras rg_chicago_miami (pro všechna místa) na obrázku:

   

   

Zřizování ve velkém měřítku pomocí rozhraní API

Partneři spravující velký počet zákaznických organizací mohou zřizovat domény ve velkém měřítku pomocí rozhraní API namísto uživatelského rozhraní.

• Ověření domény

• Směrování hovorů