Tekintsük meg egy TelSP nevű hipotetikus Webex-partnert, hogy szemléltesse a partner által elfogadható különböző telepítési modelleket.

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

• A partner azt tervezi, hogy a sip.telsp.com címet használja az általuk kezelt összes ügyfél között megosztott legfelső szintű tartományként.

• A partner a sip.telsp.com tulajdonosa, és kezelheti a DNS-infrastruktúrát és a hitelesítésszolgáltatókat, kezelheti a DNS-címeket, valamint aláírhatja az ehhez a tartományhoz és altartományaihoz tartozó tanúsítványokat.

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

• A partnernek két fizikai webhelye van, és mindkét webhely közös PSTN-kapcsolattal rendelkezik:

  • Miamiban

  • Chicago

• A TelSP a két ügyfél, a CustA és a CustB nevében üzemelteti a helyi átjárókat, ahogy azokra itt hivatkoznak.

A kívánt forgatókönyv az, hogy a partner által biztosított Miami és Chicago átjárót használó ügyfelek számára a PSTN-származás/megszűnés legyen, amint az az ábrán látható:

Ügyfél helyszínének társítása a fővonalhoz és az átjáróhoz

A Webex Calling lehetővé teszi fővonalak létrehozását és egy fővonal megosztását több helyszínen. Fővonal létrehozásakor társítsa a fővonalat egy helyszínhez.

A CustA fővonal adatai a következők:

Az illusztráció az ügyfél helyszínének a CustA átjáróhoz és trönkhöz való társítását mutatja:

Ebben a telepítésben a helyszínhez társított fővonal az adott helyszín elsődleges PSTN-kapcsolata. A másik fővonal másodlagos PSTN-kapcsolatként vagy útvonalként van használatban bizonyos tárcsázási terv-bejegyzésekhez. Az elsődleges és másodlagos PSTN-kapcsolati kapcsolat 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 részt.

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

Az illusztráció az ügyfél helyszínének társítását mutatja be a CustB átjáróhoz és trönkhöz:

Az ábrán egy harmadik helyszín látható, nevezetesen New York, amelyet később hozzáadhat, és a fővonalra mutathat trunk_chicago elsődleges PSTN-kapcsolatként.

Több fővonalat megosztó helyi átjáró telepítésekor a Cisco FŐVONALANKÉNT egyedi FQDN-t használ. Erről a Fővonalak, útvonalcsoportok és tárcsázási tervek konfigurálása a Webex-Callinghoz című oldalon tájékozódhat bővebben.

Fővonalanként egy IP-cím és egy jól ismert port használata ideális választás. Nyilvános IPv4-cím megszerzése azonban kihívást jelenthet egyes partnerek számára, akik átjárónként webhelyenként egy címet kívánnak használni.

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

• A Cisco nem jelöl ki fővonalankénti IP-címet.

• A fővonal címe egyedi IP-címre vagy egy másik fővonal között megosztott címre mutathat.

• A Cisco a következő okok miatt javasolja, hogy fővonalanként egyedi figyelőporttal rendelkezzenek:

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

  2. Jellemző, hogy a munkamenet-határ vezérlők újrahasználják a rövid élettartamú TCP szoftvercsatorna-kapcsolatot, kivéve, ha az izoláció egyedi bérlőként, amelyet egy IP-cím vagy egy egyedi figyelőport particionál a bérlő számára.

  3. A bérlő izolálásán keresztül az egy fővonalra eső kapcsolat vagy kapcsolatok jobb teljesítményt nyújtanak, különösen nagy adatvesztéssel járó hálózati körülmények esetén. Ezért az egyik ügyfél forgalma nem befolyásolja a másikat.

IP-cím átjárónként: Trönkkonfiguráció és ajánlások

Lásd az alábbi példákat a különböző tervezési modellekre:

1. modell: Egyedi IP-cím fővonalanként

Ebben a modellben a két átjáró által üzemeltetett összes trönk egyedi IP-címet kap, és mindegyik trönk használhatja vagy nem ugyanazt a portot, de ideális esetben ugyanazt a portot.

Az információk táblázatos formában történő megjelenítése:

Ebben a modellben a partner használhat SRV-címet. A Webex Calling csak a „_sips._tcp” szolgáltatást és protokollkombinációt engedélyezi a társcím felfedezéséhez, ha az egy SRV-rekord.

Minta egy SRV-rekord feloldódására

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com Kiszolgáló:		8.8.8.8 Cím:	8.8.8.8#53 Nem tekintélyelvű válasz: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com 

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

Ebben a modellben a chicagói helyi átjárón üzemeltetett összes trönk ugyanarra az IP-címre, és a miami helyi átjárón üzemeltetett összes trönk egy másik IP-címre oldódik fel. Azonban ha ugyanazt az IP-t használja, minden trönk egy FQDN segítségével van konfigurálva a vezérlőpulton, és egyedi porttal van konfigurálva.

Ebben a modellben a partner SRV-címet használ. A Webex Calling csak a „_sips._tcp” szolgáltatást és protokollkombinációt engedélyezi a társcím felfedezéséhez, ha az egy SRV-rekord.

Egy SRV-rekord megoldásának egy másik példája a következő. Ebben a példában IP-címenként 1 A rekord van. A port azonban címenként egyedi, és egy adott DNS-konfiguráción keresztül jelenik meg, amely egy SRV-címet a megfelelő porttal társít.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com Kiszolgáló:		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.sip.telsp.com nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com Kiszolgáló:		8.8.8.8 Cím:	8.8.8.8#53 Nem tekintélyelvű válasz: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

A partner a telsp.com és annak altartományai tulajdonában van. Ezért a DNS-kiszolgáló és a jóváhagyott hitelesítésszolgáltató által aláírt tanúsítványok lekérésének jogosultsága a partnernél van.

• A Cisco Webex arra számít, hogy a partner közzéteszi az FQDN vagy az SRV-címet, beleértve A Rekordokat a nyilvános tartományban.

• A Cisco Webex arra számít, hogy a partner az ebben a dokumentumban közzétett módon felsorolt hitelesítésszolgáltatók egyikét használja.

Amikor FQDN-t használ fővonalcímként, állítsa be az aláírt tanúsítványokat a fővonalak FQDN-jeihez beállított általános névvel (CN) vagy tárgyszám alternatív számával (SAN).

Használja az alábbi módszerek egyikét a tanúsítványban lévő FQDN-ek létrehozásához:

• Válasszon az egyik FQDN-t általános névként (CN), a többit pedig alternatív számként (SAN).

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

  A jövőben az ez a konfiguráció által megfelelő legfelső szintű tartomány alapján érvényesítheti a tanúsítványt.

Amikor SRV-t használ fővonalcímként, állítson be aláírt tanúsítványokat a CN vagy SAN karakterrel az SRV-cím állomásrészéhez. Nincs szükség az SRV-cím által feloldott A rekordra vagy CNAME-re.

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

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

A Cisco CUBE beállításához használja 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ányelvekkel összhangban: 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: 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 társakat és tárcsázza a társcsoportokat a fővonal bejövő és kimenő forgalmához a kép szerint:

A Partner Hubból elindíthatja a Control Hubot a CustA vagy a CustB esetében, és konfigurálhatja az átjárót. Ezzel az eljárással konfigurálhatja az egyes ügyfelek számára:

1. Fővonal létrehozása – Adjon hozzá egy fővonalat a Hívás/Hívásátirányítás/Trönk menüpontban az egyes partnerek megosztott átjáróihoz. Fővonal beállításához lásd: Fővonalak, útvonalcsoportok és tárcsázási tervek konfigurálása a Webex Callinghoz

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

   CustA-ban	B mellék
   sip.telsp.com	sip.telsp.com

   Tartomány hozzáadásakor a rendszer létrehoz egy tokent, és a tartomány TXT-rekordjába helyezi a partner DNS-kiszolgálóján. Ez a rekord lehetővé teszi a Control Hub számára, hogy ellenőrizze, hogy a tartomány a partner tulajdona-e. További részletekért lásd: A tartományok kezelése

   Mivel A közös tartományt használják az egyes ügyfelek ellenőrzésére. Mivel azonban ez az ellenőrzés az ügyfél szervezeti szintjén történik, győződjön meg arról, hogy minden ügyfélszervezetnél más tokent állít elő és használ az ellenőrzéshez. Mivel egyetlen tartományt használnak az ügyfélszervezetek között, egyetlen szervezet sem igényelheti a tartomány tulajdonjogát.
3. SBC-cím beállítása FQDN segítségével –

   A Miami átjáró számára:

   Paraméter	CustA-ban	B mellék
   Hely	Denver	Bostonban
   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 elem (vagy más támogatott eszköz)	pl. Cisco Unified Border elem (vagy más támogatott eszköz)
   SBC-cím típusa	FQDN	FQDN
   Állomásnév	fővonal.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ó számára:

   Paraméter	CustA-ban	B mellék
   Hely	Detroitban	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 elem (vagy más támogatott eszköz)	pl. Cisco Unified Border elem (vagy más támogatott eszköz)
   SBC-cím típusa	FQDN	FQDN
   Állomásnév	fővonal.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) Nincs egyedi neve a fővonalnak az ügyfelek között, és ugyanaz a név segíthet a fővonal nyomon követésében.

   • Egyes SBC-k engedélyezik 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álasszon tetszőleges helyet a fővonalhoz a következők miatt:

   • Bármely helyszín használhatja a fővonalat egy PSTN-kapcsolaton belül.

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

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

5. Tekintse meg a kapcsolódó helyszínekkel kapcsolatos trönkdefiníciókat:

   

   Ezekkel a fővonalakkal útvonalcsoportokat hozhat létre. A képen egy útvonalcsoport rg_miami_chicago van meghatározva, amely a trunk_miami fővonalra irányítja a hívásokat elsődleges lehetőségként, a trunk_chicago fővonalra pedig másodlagos lehetőségként.

   

   Meghatározhat egy második útvonalcsoportotrg_chicago_miami , amely a trunk_chicago fővonalra irányítja a hívásokat elsődleges lehetőségként, a trunk_miami fővonalra pedig másodlagos lehetőségként.

6. A meghatározott fővonalak és útvonalcsoportok mostantól elérhetők az egyes helyszínekhez tartozó Hívási kapcsolat PSTN-beállításban. A képen Denver helyszíne látható.

   

7. A fővonalak és az útvonalcsoportok a tárcsázási terv meghatározásában használhatók. Például egy helyszíni számtartományt Chicagóban az ügyfél számára a rendszer felosztja, hogy az rg_chicago_miami útvonalcsoportra (az összes helyszínre vonatkozóan) kerüljön sor: