Vegyünk egy hipotetikus Webex partnert, a TelSP-t, hogy bemutassuk a partner által alkalmazható különböző telepítési modelleket.

Íme a magas szintű specifikációk & A TelSP követelményei:

• A partner azt tervezi, hogy a sip.telsp.com domaint fogja használni legfelső szintű domainként, amelyet az összes általuk kezelt ügyfél között megosztanak.

• A partner birtokolja sip.telsp.com a domaint, és felügyelheti a DNS-infrastruktúrát és a hitelesítésszolgáltatókat, kezelheti a DNS-címeket, valamint aláírhatja a tanúsítványokat ehhez a domainhez és aldomainjeihez.

• A partner két különálló munkamenet-határvezérlőt (fizikait vagy virtuálisat) telepíthet helyi átjáróként a végfelhasználók közötti megosztott PSTN-hozzáféréshez.

• A partnernek két fizikai telephelye van, és mindkét telephelyen közös PSTN-kapcsolat van:

  • Miami

  • Chicago

• A TelSP a helyi átjárókat a CustA és CustB ügyfelek nevében üzemelteti – a továbbiakban őket említjük.

A kívánt forgatókönyv a PSTN origination/termination mindkét ügyfél számára, akik a partner által biztosított Miami és Chicago átjárókat használják, az ábrán látható módon:

Ügyfél helyének társítása a törzshöz és az átjáróhoz

A Webex Calling lehetővé teszi trönkök létrehozását és egy trönk megosztását több helyszínen. A törzs létrehozásakor társítsa a törzset egy helyszínhez.

A CustA esetében a törzsadatok a következők:

Az ábra az ügyfél helyének az átjáróhoz és a törzshöz való társítását mutatja a CustAesetében. :

Ebben a telepítésben a helyszínhez társított törzsvonal az adott helyszín elsődleges PSTN-kapcsolata. A másik trönköt másodlagos PSTN-kapcsolatként vagy útvonalként használják meghatározott tárcsázási terv bejegyzésekhez. Az elsődleges és másodlagos PSTN kapcsolati viszony megvalósítása útvonalcsoport-koncepción keresztül történik. A részletekért lásd a Webex ügyfél beállítása című részt.

A CustB esetében egy hasonló beállítás jön létre a következő törzsekkel:

Az ábra a CustBügyfélhelyének az átjáróhoz és a törzshöz való társítását mutatja. :

Az ábra egy harmadik helyszínt mutat, nevezetesen New Yorkot, amelyet később hozzáadhat, és a trunk_chicago trunk-ra mutathat elsődleges PSTN-kapcsolatként.

Több trunkot megosztó helyi átjáró telepítésekor a Cisco KÖTELEZŐ egyedi FQDN használatát trunkonként. Részletekért lásd a Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling című részt.

Ideális választás egy IP-cím és egy jól ismert port használata trunkonként. Azonban egy nyilvános IPv4-cím beszerzése kihívást jelenthet egyes partnerek számára, akik átjárónként és telephelyenként egy címet szeretnének használni.

Ezért olvassa el ezeket a fontos tudnivalókat:

• A Cisco nem ír elő IP-címet trunkonként.

• Egy törzscím feloldható egyedi IP-címre vagy egy másik törzs között megosztott címre.

• A Cisco azt javasolja, hogy minden egyes törzskapcsolatot egyedi IP-címmel és portkombinációval konfiguráljanak a helyi átjárón a következő okok miatt:

  1. A trönkönkénti külön TCP-kapcsolatok fenntartása támogatja a trönkönkénti maximális egyidejű híváskapacitást. Az IP-címek és portkombinációk trunkok közötti megosztása negatívan befolyásolhatja a híváskapacitást.

  2. Hálózati szintű izolációt biztosít az ügyfelek között

  3. A munkamenet-határ vezérlőire jellemző, hogy újra felhasználják az efemer TCP socket-kapcsolatokat, kivéve, ha egyedi bérlőként van elkülönítve, amelyet egy IP-cím vagy egy egyedi figyelőport oszt meg a bérlő számára.

  4. A bérlői elkülönítésen keresztüli kapcsolat vagy kapcsolatok trunkonként jobb átviteli sebességet biztosítanak, különösen nagy adatvesztéssel járó hálózati körülmények között. Ezért az egyik ügyfél forgalma nincs hatással a másikra.

IP-cím átjárónként: Csomagtartó konfiguráció és ajánlások

Tekintse meg a különböző tervezési modellek alábbi példáit:

Modell 1: Egyedi IP-cím törzsönként

Ebben a modellben a mindkét átjáró által üzemeltetett összes trunk egyedi IP-címre van feloldva, és ezek a trunkok használhatják ugyanazt a portot, de ideális esetben ugyanazt a portot.

Az információk táblázatos formában történő ábrázolása:

Ugyanebben a modellben a partner használhat SRV címet. A Webex hívás csak a „_sips._tcp” szolgáltatás- és protokollkombinációt engedélyezi a partnercím felderítéséhez, ha az egy SRV rekord.

Példa arra, hogyan oldódik fel egy SRV rekord

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

Modell 2: Megosztott IP-cím egy átjárón, de különböző figyelőportok

Ebben a modellben a chicagói helyi átjárón üzemeltetett összes trunk ugyanarra az IP-címre, míg a miami helyi átjárón üzemeltetett összes trunk egy másik IP-címre kapcsolódik. Ugyanazon IP-cím használata esetén azonban minden egyes trunk egy FQDN használatával van konfigurálva a vezérlőközpontban, és egyedi porttal van konfigurálva.

Ugyanebben a modellben a partner egy SRV címet használ. A Webex hívás csak a „_sips._tcp” szolgáltatás- és protokollkombinációt engedélyezi a partnercím felderítéséhez, ha az egy SRV rekord.

Egy másik példa arra, hogyan oldható fel egy SRV rekord a következő. Ebben a példában IP-címenként 1 A rekord létezik. A port azonban címenként egyedi, és egy adott DNS-konfiguráción keresztül van jelölve, amely egy SRV-címet a megfelelő porthoz kapcsol.

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

A partner a telsp.com és aldomainjeinek tulajdonosa. Ezért a DNS-kiszolgáló és a jóváhagyott hitelesítésszolgáltató által aláírt tanúsítványok beszerzésének jogosultsága a partnert illeti.

• A Cisco Webex elvárja a partnertől, hogy nyilvánosan közzétegye az FQDN vagy SRV címet, beleértve az A rekordokat is.

• A Cisco Webex elvárja a partnertől, hogy a jelen dokumentumbanközzétettek szerint felsorolt hitelesítésszolgáltatók egyikét használja.

Ha FQDN-t használ törzscímként, akkor az aláírt tanúsítványokat a törzsek FQDN-jeihez beállított Common Name (CN) vagy Subject Number Alternative Number (SAN) értékkel állítsa be.

A tanúsítványban található FQDN-ek létrehozásához használja az alábbi módszerek egyikét:

• Válasszon ki egyet az FQDN-ek közül köznévként (CN), a többit pedig alanyazonosító alternatív számként (SAN).

• A legfelső szintű domaint (sip.telsp.com) CN-ként, az összes FQDN-t pedig SAN-ként kell elhelyezni.

  A jövőben a tanúsítványt a konfiguráció által lefoglalt legfelső szintű domain alapján ellenőrizheti.

Ha SRV-t használ törzscímként, akkor aláírt tanúsítványokat kell beállítani a CN-nel vagy a SAN-nal az SRV-cím gazdagép részéhez. Az SRV-cím által feloldott A-rekord vagy CNAME nem kötelező.

Az átjáró beállítása

Használja ezeket az erőforrásokat egy helyi átjáró beállításához.

A Cisco CUBE beállításához kövesse az alábbi eljárást: Helyi átjáró konfigurálása a Cisco IOS XE-rendszeren a Webex Calling számára

Beállíthat jóváhagyott harmadik féltől származó SBC-ket, lásd: Első lépések a helyi átjáró használatában

Állítsa be a partner által üzemeltetett átjárót az alábbi irányelveknek megfelelően: Első lépések a helyi átjáró használatában

Állítsa be az egyes fővonalakat az SBC eszközre vonatkozó utasításoknak megfelelően. A Cisco CUBE utasításait lásd itt: Helyi átjáró konfigurálása a Cisco IOS XE-rendszeren a Webex Calling számára

Állítson be hangosztályokat, tárcsázza a partnereket és tárcsázza a partnercsoportokat a bejövő és kimenő forgalomhoz a trunkon a képen látható módon:

A Partner Hubból elindíthatja a CustA vagy a CustB Control Hub-ját, és konfigurálhatja az átjárót. Az egyes ügyfelek konfigurálásához kövesse az alábbi eljárást:

1. Törzs létrehozása – Adjon hozzá egy törzset alá Calling/Call Routing/Trunk minden partner megosztott átjárójához. Fővonal beállításához lásd: Fővonalak, útvonalcsoportok és tárcsázási tervek konfigurálása Webex Callinghoz

2. Tartomány hozzáadása és ellenőrzése – Adja hozzá és ellenőrizze a következő tartományt, amelyet egy törzs létrehozásához használ a következő alatt: Management/Organization Settings/Domains.

   ÜgyfélA	ÜgyfélB
   sip.telsp.com	sip.telsp.com

   Egy domain hozzáadásakor egy token generálódik, és a partner DNS-kiszolgálóján a domainhez tartozó TXT rekordba kerül. Ez a rekord lehetővé teszi a Control Hub számára annak ellenőrzését, hogy a domain a partner tulajdonában van-e. Részletekért lásd: Domainek kezelése

   Mivel a közös domaint minden ügyfél ellenőrzésére használják. Mivel azonban ez az ellenőrzés az ügyfél-szervezet szintjén történik, ügyeljen arra, hogy minden ügyfél-szervezet esetében külön token generálódjon és használatos legyen az ellenőrzéshez. Mivel egyetlen domaint használnak több ügyfélszervezet is, egyik szervezet sem igényelheti a domain tulajdonjogát.
3. SBC-cím beállítása FQDN-nel—

   Miami kapujához:

   Paraméter	ÜgyfélA	ÜgyfélB
   Hely	Denver	Boston
   Fővonal neve	trunk_miami	trunk_miami
   Fővonal típusa	Tanúsítvány alapú	Tanúsítvány alapú
   Eszköztípus	pl. Cisco Unified Border Element (vagy más támogatott eszköz)	pl. Cisco Unified Border Element (vagy más támogatott eszköz)
   SBC-cím típusa	FQDN	FQDN
   Állomásnév	trunk.miami.custa	trunk.miami.custb
   Tartomány	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Egyidejű hívások maximális száma (250-6500)	500	500

   A chicagói átjáróhoz:

   Paraméter	ÜgyfélA	ÜgyfélB
   Hely	Detroit	Dallas
   Fővonal neve	trunk_chicago	trunk_chicago
   Fővonal típusa	Tanúsítvány alapú	Tanúsítvány alapú
   Eszköztípus	pl. Cisco Unified Border Element (vagy más támogatott eszköz)	pl. Cisco Unified Border Element (vagy más támogatott eszköz)
   SBC-cím típusa	FQDN	FQDN
   Állomásnév	trunk.chicago.custa	trunk.chicago.custb
   Tartomány	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Egyidejű hívások maximális száma (250-6500)	500	500

   • (Választható) Ne legyen egyedi neve a törzsnek az ügyfelek között, és ugyanaz a név segíthet a törzs nyomon követésében.

   • Bizonyos SBC-k lehetővé teszik ugyanazon port konfigurálását, de ez a konfiguráció befolyásolhatja a kapacitást. Ezért használjon különböző portokat.

4. Trunkok használata – válasszon tetszőleges helyet a törzsnek a következők miatt:

   • Bármely helyszín használhatja a trönköt PSTN-kapcsolaton.

   • A törzset egy útvonalcsoporton keresztül érheti el.

   • Bármelyik tárcsázási terv használhatja a fővonalat.

5. Lásd a törzsdefiníciókat a hozzájuk tartozó helyekkel:

   

   Ezeket a törzseket útvonalcsoportok létrehozására használhatja. A képen egy rg_miami_chicago útvonalcsoport van definiálva, amely a hívásokat elsődleges opcióként a trunk_miami törzsvonalra, másodlagos opcióként pedig a trunk_chicago törzsvonalra irányítja.

   

   Meghatározhat egy második útvonalcsoportot rg_chicago_miami, amely elsődleges opcióként a trunk_chicago trönkre, másodlagos opcióként pedig a trunk_miami trönkre irányítja a hívásokat.

6. A definiált trönkök és útvonalcsoportok mostantól elérhetők a Hívókapcsolat PSTN opcióban minden helyszínhez. A képen látható a denveri helyszín.

   

7. A tárcsázási terv definíciójában használhatja a trönköket és az útvonalcsoportokat. Például egy chicagói helyszíni számtartomány az ügyfél számára fel van osztva, hogy a képen látható rg_chicago_miami útvonalcsoporthoz (minden helyszínhez) tartozzon: