Köszönjük visszajelzését.

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

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

• A partner azt tervezi, hogy a sip.telsp.com webhelyet a legfelső szintű tartományként használja, amelyet megosztanak az általuk kezelt összes ügyféllel.

• A partner a sip.telsp.com tulajdonosa, és felügyelheti a DNS-infrastruktúrát és a Tanúsítványhatóságokat, kezelheti a DNS-címeket és aláírhatja a tanúsítványokat ehhez a tartományhoz és annak altartományaihoz.

• A partner két különböző munkamenet-határvezérlőt (fizikai vagy virtuális) 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 webhelye van, és mindkét oldal megosztja a PSTN-kapcsolatot:

  • Miami

  • Chicago

• A TelSP a két ügyfél, a CuStA és a CustB nevében üzemelteti helyi átjáróit, ahogyan az itt hivatkoznak rájuk.

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

Egyszerűsített telepítési példa

A következő egyszerűsített példa bemutatja, hogy a Peer cert identitás hogyan teszi lehetővé egyetlen tanúsítvány több ügyfélkör támogatását:

• Tanúsítvány —sip. telsp.com

• Csomagtartó

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Partner tanúsítvány identitása —sip.tel sp.com

• Eredmény

  • Egyetlen tanúsítványt használnak

  • Több ügyfélkör támogatott

Az ügyfél helyének társítása a törzshez és az átjáróhoz

A következő szakaszok részletes konfigurációs leképezéseket tartalmaznak a fent leírt telepítéshez.

Webex Callinglehetővé teszi a törzsek létrehozását és a törzs megosztását több helyen. A csomagtartó létrehozásakor társítsa össze a csomagtartót egy helyhez.

A CuSta esetében a csomagtartó részletei a következők:

Az ábra az ügyfél helyének társítását mutatja a CustA Gateway and Trunk-hoz:

Ebben a telepítésben a helyhez társított törzs az adott hely elsődleges PSTN-kapcsolata. A másik csomagtartót má sodlagos PSTN-kapcsolatként vagy útvonalként használják meghatározott tárcsázási terv bejegyzésekhez. Az elsőd leges és másodlagos PSTN kapcsolat megvalósítása útvonalcsoport koncepcióján keresztül történik. Részletekért lásd a Vezérlőközpont átjárócsomagok konfigur álása című részt.

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

Az ábra az ügyfél helyének társítását mutatja a CustB Gateway és Trunk-hoz:

Az ábra egy harmadik helyet mutat, nevezetesen New York, amelyet később hozzáadhat, és első dleges PSTN kapcsolatként a trunk_chicago törzsre mutathat.

A több csomagot megosztó helyi átjáró telepítésekor a Cisco egy egyedi FQDN használatát kötelezi törzsenként. További részletekért lásd: Configuration-Trunks, -Route-groups, -and-dial-plans-for-WebEx -Calling.

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

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

• A Cisco nem ír elő IP-címet egy csomagtartónként.

• A törzscím egyedi IP-címre vagy egy másik törzs között megosztott címre képes megoldani.

• A Cisco azt javasolja, hogy a helyi átjárón minden egyes törzskapcsolat egyedi IP-címével és port kombinációval konfiguráljon a következő okok miatt:

  1. A csomagtartóonként külön TCP-csatlakozási kapcsolatok fenntartása támogatja a csomagtartóonkénti maximális egyidej ű hívási kapacitást. Az IP-cím és a portok kombinációi közötti megosztása neg atívan befolyásolhatja a hívási kapacitást.

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

  3. A munkamenet-határvezérlőkre jellemző, hogy újra felhasználják az átmeneti TCP aljzatkapcsolatot, kivéve, ha az elszigetelés biztosított egyedi bérlőként, amelyet IP-cím vagy egy egyedi hallgatási port oszt meg a bérlő számára.

  4. A csatlakozás vagy a csomagtartó-csatlakozás a bérlőszigetelés révén jobb átviteli teljesítményt biztosít, 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 nem befolyásolja a másikat.

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

Lásd a tervezés különböző modelljeinek ezeket a példáit:

1. modell: Egyedi IP-cím csomagtartónként

Ebben a modellben a két átjáró által üzemeltetett összes csomag egyedi IP-címre szolgál, és ezek a csomagok mindegyike ugyanazt a portot használhatja vagy nem, de ideális esetben ugyanazt a portot használja.

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

Ugyanebben a modellben a partner használhat egy SRV címet. Webex Callingcsak a „_kortyokat engedélyezi. _tcp” mint szolgáltatás és protokoll kombinációja, amely felfedezi a társ címet, ha ez SRV rekord.

Egy minta az SRV rekord megoldásának módjáról

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

2. modell: Megosztott IP átjárónként, egyedi hallgatási portok

Ebben a modellben a chicagói helyi átjárón tárolt összes hálózat ugyanarra az IP-címre szolgál, és a Miami helyi átjárón tárolt összes trakk más IP-re szolgál. Ugyanazon IP használatakor azonban minden törzs konfigurálódik egy FQDN segítségével a vezérlőközpontban, és egyedi porttal van konfigurálva.

Ugyanebben a modellben a partner SRV címet használ. Webex Callingcsak a „_kortyokat engedélyezi. _tcp” mint szolgáltatás és protokoll kombinációja, amely felfedezi a társ címet, ha ez SRV rekord.

Az SRV rekord feloldásának másik mintája a következő. Ebben a példában egy IP-címre vonat kozóan 1 A rekord létezik. A port azonban címenként egyedi, és egy adott DNS-konfiguráción keresztül jelenik meg, amely egy SRV-címet összekapcsolja a jobb porthoz.

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

SRV-alapú törzsek esetében a Peer cert azonosító eredetileg a konfigurált SRV értékekből van kitöltve, és ugyanazon érvényesítési szabályok betartásával testreszabható.

A partner birtokolja a telsp.com és annak aldomaineit. Ezért a DNS-kiszolgáló és a jóváhagyott Tan úsítványhatóság által aláírt tanúsítványok megszerzésének jogköre a partnerre tartozik.

• Cisco Webexelvárja a partnertől, hogy közzétesse az FQDN vagy SRV címet, beleértve az A Records szolgáltat ást is.

• Cisco Webexelvárja, hogy a partner az ebben a dokumentumban felsorolt tanúsító hatóságok egyikét használja.

FQDN vagy SRV használatával történő törzsek konfigurálásakor:

• Minden csomagtartónak továbbra is egyedi FQDN-vel kell rendelkeznie az útválasztáshoz és az azonosításhoz

• A DNS-rekordoknak (A Record vagy SRV) helyesen kell konfigurálniuk és feloldhatónak kell lenniük

• Ezeket az FQDNS-eket jelzéshez és útválasztáshoz használják. A tanúsítvány érvényesítése a konfigurált Peer tanúsítványazonossággal történik, amely alapértelmezés szerint a törzs FQDN értékekkel rendelkezik, de a megosztott, partner tulajdonában lévő identitáshoz testreszab ható.

  A Peer cert identitás mező előzetesen kitölthető a törzs FQDN-ből, és felülírható egy megosztott, partner tulajdon ában lévő tartománnyal, hogy egyetlen tanúsítványt használjon több ügyfélkörön keresztül.

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

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

A Cisco CUBE beállításához használja ezt az eljárást: Helyi átjáró konfigurálása az Cisco IOS XE rendszeren Webex Calling

Beállíthatja a jóváhagyott harmadik féltől származó SBC-ket, lásd: Első lépések a Local Gateway használatával

A partner által üzemeltetett átjáró beállítása az alábbi irányelveknek megfelelően: Első lépések a Local Gateway használatával

Állítsa be az egyes csomagtartókat az SBC eszköz vonatkozó utasításainak megfelelően. A Cisco CUBE utasításokat lásd: Helyi átjáró konfigurálása az Cisco IOS XE rendszeren Webex Calling

Állítsa be a hangosztályokat, tárcsázza a tárcsákat és tárcsázza tárcsázó csoportokat a csomagtartó bejövő és kimenő forgalmához a kép szerint:

A Trunk biztosítása közben a Control Hub lehetőséget ad a Peer Certificat-azonosság konfigurálására a Trun k hozzáadása lapon. Ez a fejlesztés egyszerűsíti a munkafolyamatot azáltal, hogy lehetővé teszi a partnerek számára, hogy egyetlen felső szintű tartományt konfiguráljanak és új rafelhasználhassák több ügyfélszervezetben Ez a megközelítés kiküszöböli az ügyfélenként vagy csomagonként külön tanúsítványok szükségességét, csökkentve az üzemeltetési erőfeszítéseket és egyszerűsítve a telep ítési folyamatot.

Amikor a vezérlőközpontban konfigurálja a folyamatokat, akkor határozzon meg egy Peer tanúsítványazonos ságot, amely lehetővé teszi egyetlen tanúsítvány használatát a legfelső szintű tartományhoz minden ügyfél szervezetben. Győződjön meg róla, hogy a tanúsítvány CN vagy SAN tartalmazza ezt a legfelső szintű tartományt. A Peer cert identitás esetén a helyi átjáró egyetlen tanúsítványt használ, amelynek CN vagy SAN tartalmazza a partner megosztott tartományát (például a sip.telsp.com). A helyettesítő tanúsítványok (pl. *.sip.telsp.com) nem támogatottak. Webex Callingelfogadja ezt a tanúsítványt minden ügyfélkörzetben, amelyet kifejezetten konfigurálnak ezzel az érté kkel a Peer cert azonosítójaként. A tanúsítványnak tartalmaznia kell a pontosan konfigurált Peer cert azonosító értékét a CN- vagy SAN-ban. Ez kiküszöböli a különálló tanúsítványok vagy CN/SAN bejegyzések konfigurálásának szükségességét az egyes törzs FQDNS-ekhez.

Domain-ellenőrzés és tanúsítványhasználat

Fontos megérteni, hogy a tartományellenőrzés miben különbözik a tanúsítvány használatától:

• Tartomány-ellenőrzés (ügyfélenként) — Minden ügyfélszervezetnek önállóan ellenőriznie kell a tartományt (például sip.telsp.com) egy egyedi TXT rekord hozzáadásával a DNS-be. Ez biztosítja, hogy a partner birtokolja a domain tulajdonát, és megakadályozza a jogosulatlan használatot.

• Tanúsítványkezelés (globális) — A partner legfelső szintű tartományához kiadott egyetlen tanúsítvány megosztható az összes ügyfélkörön a Peer cert identitás használatával. Nincs szükség külön tanúsítványok fenntartására ügyfélenként vagy csomag tartóonként.

Peer Certificate identitás-viselkedés

A peer cert identitás meghatározza azt a személyazonosságot, Webex Calling amely a helyi átjáró által bemutatott tanúsítványban várható.

Konfiguráláskor:

• Webex Callingérvényesíti a tanúsítványt úgy, hogy a konfigurált Peer tanúsítvány azonosítását a tanú sítvány KN-jével vagy SAN-jával párosítja

• Ha az értékek megegyeznek, akkor a TLS-kapcsolat elfogadásra kerül

• Ha az értékek nem egyeznek meg, a kapcsolat visszautasításra kerül

Csak a megfelelő Peer cert azonosítással kifejezetten konfigurált transzkök hitelesíthetők.

A hitelesítés során nem egyedül a tanúsítvány érvényesítése az egyetlen ellenőrzés. Amellett , hogy a CN vagy SAN tanúsítványt a konfigurált Peer cert identitáshoz viszonyítva érvényesíti, azt Webex Calling is ellenőrzi, hogy a törzs FQDN kifejezetten konfigurálva van-e és társítva van-e a Control Hub megfelelő Peer tanúsí tványazonosságához.

A Peer cert identitás előzetesen van kitöltve a törzs FQDN/SRV értékekből. Ha megtartja az alapértelmezett beállí tásokat, a meglévő törzsenkénti tanúsítvány viselkedése változatlan marad. A meglévő tanúsítvány-alapú csomagok továbbra is módosítás nélkül működnek. Megosztott Peer cert identitást alkalmazhat új vagy meglévő csomagokon a saját tempójában, és mindkét modell együtt létezhet.

1. Érvényes konfigurációs példa:

   • KN-tanúsítvány —sip. telsp.com

   • Tanúsítvány SAN —custa.sip. telsp.com

   • Partner tanúsítvány identitása —custa.sip.telsp.com

   • Csomagtartó FQ DN —trunk.miami.custa.sip.telsp.com

   Ered@@ mény —A kapcsolat azért sikeres, mert a Peer cert identitás (custa.sip.telsp.com) megegyezik a tanúsítvány SAN értékével, és a törzs FQDN (trunk.miami.custa.sip.telsp.com) a konfigurált Peer cert identitás altartománya.

2. Csatlakozási hiba példa:

   • KN-tanúsítvány —sip. telsp.com

   • Tanúsítvány SAN —custa.sip. telsp.com

   • Partner tanúsítvány identitása —custb.sip.telsp.com

   • Csomagtartó FQ DN —trunk.miami.custb.sip.telsp.com

   Eredmény — A kapcsolat nem sikerül a TLS kézfogáskor, mert a Peer cert azonosító (custb.sip.telsp.com) nem szerepel a tanúsítvány CN- vagy SAN-jában. A törzs FQDN helyesen a Peer cert identitás altartománya, de a tanúsítvány nem tartalmazza ezt az azonosságot.

3. Érvénytelen konfigurációs példa:

   • KN-tanúsítvány —sip. telsp.com

   • Tanúsítvány SAN —custa.sip. telsp.com

   • Partner tanúsítvány identitása —custa.sip.telsp.com

   • Csomagtartó FQ DN —trunk.miami.custb.sip.telsp.com

   Eredmény — A Control Hub időtakarékos idővel elutasítja ezt a konfigurációt, mivel a törzs FQDN (trunk.miami.custb.sip.telsp.com) nem egyenlő a konfigurált Peer cert azonossággal (custa.sip.telsp.com) vagy annak altartományával.

A Partner Hubban elindíthatja a Control Hub alkalmazást a CuStA vagy a CustB rendszerhez, és konfigurálhatja az átjárót. Ezzel az eljárással konfigurálhatja az egyes ügyfelek számára:

1. Trunk létrehozása — Adjon hozzá egy törzset a Hívás/Hívás-útvonal/Trunk területen minden partner megosztott átjáróhoz. A csomagtartó beállításához tekintse meg a Hálózatok, útv onalcsoportok és tárcsázási tervek konfigurálása című témakörben: Webex Calling

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

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

   Tartomány hozzáadásakor egy token jön létre, és a partner DNS-kiszolgálójának tartomány ának TXT rekordjába kerül. Ez a rekord lehetővé teszi a Control Hub számára, hogy ellenőrizze, hogy a domain a partner tulajdonában van-e. További részletekért lásd: Dom ainek kezelése

   A közös domain minden ügyfél ellenőrzésére szolgál. Mivel azonban ez az ellenőrz és ügyfélszervezeti szinten történik, győződjön meg arról, hogy az egyes ügyfélszervezeteknél más token jön létre és használjon az ellenőrzéshez. Mivel az ügyfélszervezetek között egyetlen tartom ányt használnak, és minden ügyfélszervezetnek önállóan ellenőriznie kell a tartományt egy egyedi TXT rekord segítségével, még akkor is, ha ugyanazt a tartom ányt használja.

   A Peer cert azonosításához csak domain hitelesítés szükséges. Ne igényelje a megosztott tar tományt ügyfélszervezetnek. Egy tartományt csak egy szervezet igényelhet, míg ugyanazt a tartományt több szervezetben is ellenőrizheti.

3. Állítsa be az SBC-címet az FQDN segítségével

   A Miami kapuhoz:

   paraméter	ÜgyfélB	CustomERC
   Elhelyezkedés	Denver	Boston
   Csomagtartó neve	trunk_miami	trunk_miami
   Csomagtartó típusa	Tanúsítvány alapú	Tanúsítvány alapú
   Eszköz típusa	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
   Hostnév	lgw.miami	lgw.miami
   Domain	sip.telsp.com	sip.telsp.com
   Kikötő	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.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	ÜgyfélB	CustomERC
   Elhelyezkedés	Detroit	Dallas
   Csomagtartó neve	Trunk_Chicago	Trunk_Chicago
   Csomagtartó típusa	Tanúsítvány alapú	Tanúsítvány alapú
   Eszköz típusa	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
   Hostnév	lgw.Chicago	lgw.Chicago
   Domain	sip.telsp.com	sip.telsp.com
   Kikötő	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Egyidejű hívások maximális száma (250-6500)	500	500

   • (Opcionális) A csomagtartóknak nem kell egyedieknek lenniük az ügyfélszervezetek között. Az azonos név újbóli használata (például trunk_miami) megkönnyíti a csomagtartó nyomon követését.

   • 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. Peer tanúsítvány identitása—

   • Előtag —Az előtag opcionális. Hagyja üresen, hogy a Peer cert azonosságát csak a tartományra állítsa be. Ez a cikkben használt megosztott tanúsítvány modell (Peer cert identity—sip.telsp.com, amely lefedi az összes ügyfélkört). Opcionálisan adjon meg egy előtagot egy konkrétabb tanúsítvány azonosításához (például előtag: Customer B, Domain: CustomerB.sip.telsp.com ügyfélenkénti tanúsítvány esetén). Maga a törzs FQDN-t az SBC-cím Host name és a Domain mezők határozzák meg, és egyenlőnek kell lennie a kapott Peer cert azonossággal vagy annak altartományával.

     Példa:

     Előtag — CustomerB

     Domain—sip.telsp.com

     Eredmény — customerb.sip.telsp.com

   • Tartomány: Válasszon ki egy tartományt az ügyfél szervezetben ellenőrzött tartományok listájából. Az így kapott Peer Certificat-azonosságnak (előtag + domain) meg kell egyeznie az SBC által bemutatott tanúsítvány KN-jével vagy SAN-jával. Webex Callingezt az értéket használja a TLS-kapcsolat hitelesítésére.

     

     A Control Hub időtakarékos idővel elutasítja ezt a konfigurációt, mivel a törzs FQDN nem a konfigurált Peer cert azonosító alatt van.

     Ha a Peer tanúsítvány azonosító Webex Calling ja nem egyezik meg az SBC által bemutatott tanúsítványban szereplő KN-vel vagy SAN-val, elutasítja a TLS-kapcsolatot, és a csomagtartó nem jön létre .

5. Csomagok használata — válassza ki a csomagtartó tetszőleges helyét az alábbiak miatt:

   • Bármely hely használhatja a csomagtartót PSTN csatlakozásban.

   • A csomagtartóhoz útvonalcsoporton keresztül érheti el.

   • Bármely tárcsázási terv használhatja a csomagtartót.

6. Tekintse meg a csomagtartó definíciókat a társított helyekkel:

   

   Ezekkel a törzsekkel útvonal csoportokat hozhat létre. A képen egy rg_miami_chicago útvonalcsoport van definiálva, amely útvonalak elsődleges opcióként a trunk_miami törzset, másodlagos opcióként pedig a trunk_ chicago törzset hívják.

   

   Megadhat egy második rg_chicago_miami útvonalcsoportot, amely elsődleges lehetőségként a trunk_ chicago törzsre és másodlagos lehetőségként a trunk_ miami törzsre irányítja a hívásokat.

7. A megadott törzsek és útvonalcsoportok mostantól elérhetők a Hívási kapcsolat PSTN opcióban minden helyre vonatkozóan. A képen lásd a Denver helyét.

   

8. A tárcsázási terv definíciójában használhatja a törzseket és útvonalcsoportokat. Például egy helyszíni szám tartományt Chicagóban az ügyfél számára felosztják a képen látható rg_chicago_miami útvonalcsoportra (minden helyre vonatkozóan):

   

   

Nagyfokú ellátás API-kkal

A nagyszámú ügyfélszervezetet kezelő partnerek a felhasználói felület helyett API-k használatá val nagyszabású tartományokat biztosíthatnak.

• Domain ellenőrzése

• Hívásátirányítás