Partner által üzemeltetett átjáró konfigurálása

Tekintsünk egy TelSP nevű hipotetikus Webex -partnert, hogy bemutassa a partner által elfogadott különböző telepítési modelleket.

Itt vannak a TelSP magas szintű specifikációi és követelményei:

• A partner a használatát tervezi sip.telsp.com mint a legfelső szintű tartomány, amely meg van osztva az összes általuk kezelt ügyfél között.

• A partner tulajdonában van sip.telsp.com és felügyelheti a DNS infrastruktúrát és a hitelesítésszolgáltatókat, kezelheti a DNS -címeket, és aláírhatja a tanúsítványokat ehhez a tartományhoz és altartományaihoz.

• A partner két különálló (fizikai vagy virtuális) munkamenethatár-vezérlőt telepíthet helyi átjáróként a végfelhasználók közötti megosztott PSTN-elérés .

• A partnernek két fizikai telephelye van, és mindkét oldal PSTN-kapcsolaton osztozik:

  • Miami

  • Chicago

• A TelSP a helyi átjáróit a két ügyfél, a CustA és a CustB nevében üzemelteti, ahogyan a jelen dokumentumban hivatkozunk rájuk.

A kívánt forgatókönyv az, hogy a partner által biztosított Miami és Chicago átjárót használó PSTN-kezdeményezés/lezárás mindkét ügyfél számára megtörténjen, amint az az ábrán látható:

ügyfél helyszíne társítása a fővonalhoz és az átjáróhoz

A Webex Calling lehetővé teszi a fővonalak létrehozását és a fővonal több helyszín közötti megosztását. A törzs létrehozásakor rendelje hozzá a törzset egy helyszínhez.

A CustA esetében a fővonal adatai a következők:

Az ábra az ügyfél helyszíne az átjáróhoz és a fővonalhoz való hozzárendelését mutatja CustA :

Ebben a telepítésben a helyszínhez társított törzs az adott hely elsődleges PSTN-kapcsolat . A másik fővonal másodlagos PSTN-kapcsolat vagy útvonalként használható meghatározott tárcsázási terv bejegyzésekhez. Az elsődleges és másodlagos PSTN-kapcsolat kapcsolat megvalósítása egy Útvonalcsoport-koncepción keresztül történik. Lásd a Webex szakaszban a részletekért.

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

Az ábra az ügyfél helyszíne az átjáróhoz és a fővonalhoz való hozzárendelését mutatja CustB :

Az ábrán egy harmadik helyszín, New York látható, amelyet később hozzáadhat, és rámutathat atrunk_chicago trunk elsődleges PSTN-kapcsolat.

Több törzsön megosztó helyi átjáró telepítésekor a Cisco FELHASZNÁLJA törzsenkénti egyedi FQDN használatát. Lásd Configure-trunks,-route-groups,-and-dial-plans-for-Webex-Calling a részletekért.

Az IP-cím és a törzsenként jól ismert port használata ideális választás. A nyilvános IPv4-cím beszerzése azonban kihívást jelenthet néhány olyan partner számára, akik átjárónként és telephelyenként egy címet szeretnének használni.

Ezért olvassa el az alábbi fontos tudnivalókat:

• A Cisco nem ír elő törzsenkénti IP-cím .

• A fővonali címek feloldása lehet egyedi IP-cím vagy egy másik fővonal között megosztott cím.

• A Cisco a következő okok miatt javasolja, hogy törzsenként egyedi figyelési portot használjon:

  1. Hálózati szintű leválasztást biztosít az ügyfelek között

  2. A munkamenethatár-vezérlőkre jellemző, hogy újrafelhasználják az ideiglenes TCP szoftvercsatorna-kapcsolatot, kivéve, ha a bérlő számára IP-cím particionált egyedi bérlőként vagy egyedi figyelési portként van biztosítva az elkülönítés.

  3. A fővonalonkénti kapcsolat vagy kapcsolatok bérlői elkülönítéssel nagyobb átviteli sebességet biztosítanak, különösen nagy adatveszteséggel járó hálózati körülmények között. Ezért az egyik ügyféltől érkező forgalom nincs hatással a másikra.

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

A tervezéshez tekintse meg a különböző modellekre vonatkozó alábbi példákat:

1. modell: Fővonalonként egyedi IP-cím

Ebben a modellben a mindkét átjáró által üzemeltetett összes törzs egyedi IP-cím ad fel, és előfordulhat, hogy ezek a törzsek ugyanazt a portot használják, de ideális esetben ugyanazt a portot.

Az információk megjelenítése táblázatos formátumban:

Ugyanebben a modellben a partner használhat SRV-címet. A Webex Calling csak a „_sips ._tcp ” szolgáltatás és protokoll kombinációja a társcím felderítéséhez, ha SRV rekordról van szó.

Példa az SRV rekordok feloldására

nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com Szerver:		8.8.8.8 Cím:	8.8.8.8#53 Nem hiteles válasz:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

2. modell: Megosztott IP egy átjárón, de különböző figyelő portok

Ebben a modellben a Chicago helyi átjáró üzemeltetett összes törzs ugyanazt az IP-cím oldja fel, a Miami helyi átjáró üzemeltetett összes törzs pedig egy másik IP-t. Ha azonban ugyanazt az IP-címet használja, minden törzs egy FQDN használatával van konfigurálva a vezérlőhubban, és egyedi porttal van konfigurálva.

Ugyanebben a modellben a partner SRV-címet használ. A Webex Calling csak a „_sips ._tcp ” szolgáltatás és protokoll kombinációja a társcím felderítéséhez, ha SRV rekordról van szó.

Az SRV rekordok feloldásának egy másik példája a következő. Ebben a példában IP-cím 1 A rekord létezik. A port azonban címenként egyedi, és egy speciális DNS -konfiguráción keresztül jelenik meg, amely egy SRV-címet kapcsol a megfelelő porthoz.

nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com Szerver:		8.8.8.8 Cím:	8.8.8.8#53 Nem hiteles válasz:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com nslookup -type=srv_sips ._tcp .trunk.miami.custa.sip.telsp.com Szerver:		8.8.8.8 Cím:	8.8.8.8#53 Nem hiteles válasz:_sips ._tcp .trunk.miami.custa.sip.telsp.com = 3600 50 5062 miami.custa.sip.telsp.com

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

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

• A Cisco Webex elvárja, hogy a partner a jelen cikkben közzétett hitelesítésszolgáltatók valamelyikét használja dokumentumot .

Ha FQDN-t használ fővonali címként, állítsa be az aláírt tanúsítványokat a közös név (CN) vagy az alanyszám alternatív szám (SAN) FQDN-jére a törzseknél.

Az alábbi módszerek egyikével hozza létre az FQDN-eket a tanúsítványban:

• Válassza ki az egyik FQDN-t közös névként (CN), a többit pedig alanyszám alternatív számként (SAN).

• Helyezze el a legfelső szintű tartományt (sip.telsp.com) CN-ként, és az összes FQDN-t SAN-ként.

  A jövőben a tanúsítvány az adott konfiguráció által megfelelő legfelső szintű tartomány alapján ellenőrizhető.

Ha SRV-t használ fővonali címként, állítson be aláírt tanúsítványokat a CN- vagy SAN-hálózattal az SRV-cím gazdagép részének. Az SRV-cím által feloldott A-rekord vagy CNAME nem kötelező.

Állítsa be az átjárót

Ezekkel az erőforrásokkal állíthat be egy helyi átjáró.

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 biztosított á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ások szerint. A Cisco CUBE utasításaiért lásd: Helyi átjáró konfigurálása a Cisco IOS XE-rendszeren a Webex Calling számára

Állítsa be a hangosztályokat, a tárcsázó társakat és a tárcsázási társcsoportokat a fővonal bejövő és kimenő forgalmához az alábbi kép szerint:

A Partner Hubról elindíthatja a Control Hubot CustA vagy CustB esetén, és konfigurálhatja az átjárót. Az alábbi eljárás segítségével konfigurálhatja az egyes ügyfelek számára:

1. A fővonal létrehozása—Adjon hozzá egy fővonalat a Hívás/Hívástovábbítás/Fővonal alatt minden partner megosztott átjárójához. A fővonal beállításához lásd: Fővonalak, útvonalcsoportok és tárcsázási tervek konfigurálása a Webex Calling számára

2. Tartomány hozzáadása és ellenőrzése—Adja hozzá és ellenőrizze a következő, törzs létrehozásához használt tartományt a Kezelés/Szervezeti beállítások/Tartományok alatt.

   CustA	Cust B
   sip.telsp.com	sip.telsp.com

   Tartomány hozzáadásakor egy tokent generál, és elhelyezi a tartomány TXT rekordjában a partner DNS-kiszolgáló. Ez a rekord lehetővé teszi, hogy a Control Hub ellenőrizze, hogy a tartomány a partner tulajdonában van-e. A részletekért lásd: A tartományok kezelése

   Mivel A közös tartomány az egyes ügyfelek ellenőrzésére szolgál. Mivel azonban ez az ellenőrzés az ügyfélszervezet szintjén történik, győződjön meg arról, hogy más tokent állít elő és használ az ellenőrzéshez az egyes ügyfélszervezeteknél. Mivel az ügyfélszervezetek egyetlen tartományt használnak, egyetlen szervezet sem igényelheti a tartomány tulajdonjogát.
3. SBC-cím beállítása FQDN-nel—

   A Miami átjáró esetében:

   Paraméter	CustA	Cust B
   helymeghatározás	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ímtípus	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ó esetében:

   Paraméter	CustA	Cust B
   helymeghatározás	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ímtípus	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

   • (Opcionális) Ne adjon egyedi nevet a fővonalnak az ügyfelek között, mert ugyanaz a név segíthet a törzs nyomon követésében.

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

4. Fővonalak használata—válassza ki a fővonal tetszőleges helyét a következők miatt:

   • A fővonalat bármely hely használhatja PSTN-kapcsolat.

   • A fővonalat egy útvonalcsoport keresztül érheti el.

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

5. Tekintse meg a fővonal-meghatározásokat a hozzárendelt helyekkel:

   

   Ezekkel a törzsekkel útvonalcsoportokat hozhat létre. A képen egy útvonalcsoportrg_miami_chicago van megadva, amely a hívásokat atrunk_miami trunk elsődleges opcióként, és atrunk_chicago trunk másodlagos opcióként.

   

   Megadhat egy második útvonalcsoportrg_chicago_miami amely a hívásokat atrunk_chicago trunk elsődleges opcióként, és atrunk_miami trunk másodlagos opcióként.

6. A meghatározott fővonalak és útvonalcsoportok mostantól elérhetők a következőben: Hívási kapcsolat PSTN opció az egyes helyszíneken. A képen lásd a denveri helyszínt.

   

7. A tárcsázási terv meghatározásban használhatja a fővonalakat és az útvonalcsoportokat. Például: a chicagói körzeti NPA-k ketté vannak osztva, hogy az arg_chicago_miami útvonalcsoport (minden helyszínre) a képen: