Hvala za povratne informacije.

Razmislimo o hipotetičnem partnerju Webexu z imenom TelSP, ki ponazarja različne modele uvajanja, ki jih lahko partner sprejme.

Tu so specifikacije in zahteve TelSP na visoki ravni:

• Partner namerava uporabiti sip.telsp.com kot domeno najvišje ravni, ki jo delijo vse stranke, ki jih upravljajo.

• Partner je lastnik sip.telsp.com in lahko upravlja infrastrukturo DNS in organe za certifikate, upravlja naslove DNS in podpisuje potrdila za to domeno in njene poddomene.

• Partner lahko namesti dva ločena kontrolorja meja sej (fizične ali virtualne) kot lokalna prehoda za skupni dostop do PSTN med končnimi strankami.

• Partner ima dve fizični strani in obe strani si delita povezljivost PSTN:

  • Miami

  • Chicago

• TelSP upravlja svoje lokalne prehode v imenu obeh strank CuSTA in CustB, kot sta navedena od tukaj.

Želeni scenarij je nastajanje/prekinitev PSTN za obe stranki, ki uporabljata prehode v Miamiju in Chicagu, ki jih dobavlja partner, kot je prikazano na sliki:

Poenostavljeni primer uvajanja

Naslednji poenostavljeni primer prikazuje, kako identiteta Peer certifikata omogoča, da en sam certifikat podpira več skupin strank:

• Certifikat —sip. telsp.com

• Prtljažniki

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identiteta vrstniškega certifikata —sip.tel sp.com

• Rezultat

  • Uporablja se enotno potrdilo

  • Podprtih je več prtljažnikov strank

Povezovanje lokacije stranke s prtljažnikom in prehodom

Naslednji razdelki ponujajo podrobne preslikave konfiguracije za zgoraj opisano uvajanje.

Webex Callingomogoča ustvarjanje debla in skupno rabo prtljažnika na več lokacijah. Pri ustvarjanju prtljažnika povežite prtljažnik z lokacijo.

Za CuSta so podrobnosti prtljažnika naslednje:

Na sliki je prikazana povezava lokacije stranke z Gateway in Trunk za CuSTA:

Pri tej uvajanju je prtljažnik, povezan z lok acijo, primarna povezava PSTN za to lokacijo. Drugi prtljažnik se uporablja kot sekundarna povezava PSTN ali pot za določene vnose načrta klicanja. Izvajanje primarnega in sekundarnega razmerja povezave PSTN poteka prek koncepta skupine poti. Za podrobnosti glejte Konfiguriranje sklopov prehoda v razdelku Nadzorno sredi šče.

Za CustB je ustvar jena podobna nastavitev z naslednjimi debli:

Na sliki je prikazana povezava lokacije stranke z Gateway in Trun k za CustB:

Ilustracija prikazuje tretjo lokacijo, in sicer New York, ki jo lahko dodate kasneje in pokažete na prtljažnik trunk_chicago kot njegovo primar no povezavo PSTN.

Pri uvajanju lokalnega prehoda, ki ima skupno rabo več debla, Cisco naloži uporabo edinstvenega FQDN na prtljažnik. Za podrobnosti glejte Konfiguriranje sklopov, -skupin poti, -and-dial-plans-for-webex-klicanje.

Uporaba naslova IP in dobro znanih vrat na prtljažnik je idealna izbira. Vendar pa je lahko pridobitev javnega naslova IPv4 zahtevna za nekatere partnerje, ki želijo uporabiti en naslov na prehod na spletno mesto.

Zato preberite te pomembne napotke:

• Cisco ne določa naslova IP na prtljažnik.

• Naslov prtljažnika se lahko loči na edinstven naslov IP ali naslov, ki je v skupni rabi med drugim prtljažnikom.

• Cisco priporoča, da na lokalnem prehodu konfigurirate vsako povezavo z edinstvenim naslovom IP in kombinacijo vrat iz naslednjih razlogov:

  1. Vzdrževanje ločenih povezav povezave TCP na prtljažnik podpira največjo zmogljivost sočasnih k licev na prtljažnik. Skupna raba naslovov IP in kombinacij vrat med omrežji lahko negativno vpliva na zmogljivost klicev.

  2. Zagotavlja izolacijo na ravni omrežja med strankami

  3. Za nadzornike meja sej je značilno, da ponovno uporabijo kratkotrajno povezavo z vtičnico TCP, razen če je zagotovljena izolacija kot edinstven najemnik, razdeljen z naslovom IP ali edinstvenim poslušnim vratom za najemnika.

  4. Povezava ali povezave na prtljažnik prek izolacije najemnikov zagotavljajo boljšo prepustnost, zlasti v omrežnih pogojih z visoko izgubo podatkov. Zato promet ene stranke ne vpliva na drugo.

IP naslov na prehod: konfiguracija prtljažnika in priporočila

Oglejte si te primere različnih modelov načrtovanja:

Model 1: Edinstven naslov IP na prtljažnik

V tem modelu se vsi sklopi, ki jih gostita oba prehoda, ločijo na edinstven naslov IP in vsak od teh prtljažnikov lahko uporablja ista vrata ali pa ne, v idealnem primeru pa ista vrata.

Predstavitev informacij v obliki tabele:

V tem istem modelu lahko partner uporabi naslov SRV. Webex Callingdovoljuje samo »_sips. _tcp« kot kombinacija storitve in protokola za odkrivanje medsebojnega naslova, če gre za zapis SRV.

Vzorec, kako se reši zapis 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: skupni IP na prehod, edinstvena vrata za poslušanje

V tem modelu se vsi sklopi, ki gostujejo na lokalnem prehodu v Chicagu, ločijo na isti naslov IP, vsi sklopi, ki gostujejo na lokalnem prehodu v Miamiju, pa se ločijo na drug IP. Pri uporabi istega IP-ja pa je vsak prtljažnik konfiguriran s pomočjo FQDN v nadzornem vozlišču in je konfiguriran z edinstvenimi vrati.

V istem modelu partner uporablja naslov SRV. Webex Callingdovoljuje samo »_sips. _tcp« kot kombinacija storitve in protokola za odkrivanje medsebojnega naslova, če gre za zapis SRV.

Drug vzorec, kako se reši zapis SRV, je naslednji. V tem primeru obstaja 1 zap is na naslov IP. Vendar so vrata edinstvena na naslov in so predstavljena prek posebne konfiguracije DNS, ki povezuje naslov SRV z desnimi vrati.

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

Za debla, ki temeljijo na SRV, se identiteta Peer certifikata prvotno izpolni iz konfiguriranih vrednosti SRV in jo je mogoče prilagoditi ob upoštevanju istih pravil za preverjanje veljavnosti.

Partner je lastnik telsp.com in njegovih poddomen. Zato je strežnik DNS in pooblastilo za pridobitev potrdil, ki jih podpiše odobreni certifikacijski organ, pri partnerju.

• Cisco Webexpričakuje, da bo partner objavil naslov FQDN ali SRV, vključno z zapisi A, v javni domeni.

• Cisco Webexpričakuje, da bo partner uporabil enega od certifikacijskih organov, navedenih v tem dokumentu.

Pri konfiguriranju debla z uporabo FQDN ali SRV:

• Vsak prtljažnik mora imeti še vedno edinstven FQDN za usmerjanje in identifikacijo

• Zapisi DNS (A Record ali SRV) morajo biti pravilno konfigurirani in ločljivi

• Ti FQDNS se uporabljajo za signalizacijo in usmerjanje. Preverjanje potrdila se iz vede glede na konfigurirano identiteto Peer cert, ki privzeto ustreza osnovnim vrednostim FQDN, vendar jo je mogoče prilagoditi identiteti v skupni rabi v lasti partnerja.

  Polje identitete Peer cert je vnaprej napolnjeno iz osnovnega FQDN in ga je mogoče preglasiti z domeno v skupni ra bi, ki je v lasti partnerja, da se uporabi en certifikat v več vrstah strank.

Nastavite prehod

Uporabite te vire za nastavitev lokalnega prehoda.

Če želite nastaviti Cisco CUBE, uporabite ta postopek: Konfigurirajte lokalni prehod na Cisco IOS XE za Webex Calling

Nastavite lahko odobrene SBC drugih proizvajalcev, glejte: Začetek uporabe lokalnega prehoda

Nastavitev partnerskega gostujočega prehoda v skladu s temi smernicami: Začnite z lokalnim prehodom

Vsak prtljažnik nastavite v skladu z ustreznimi navodili za napravo SBC. Za navodila Cisco CUBE glejte: Konfiguriranje lokalnega pre Cisco IOS hoda na XE Webex Calling

Nastavite glasovne razrede, klicanje vrstnikov in kličite skupine vrstnikov za dohodni in odhodni promet za prtljažnik v skladu s sliko:

Med zagotavljanjem prtljažnika Control Hub ponuja možnost konfiguriranja identitete vrstniškega certifikata na strani Dodaj točko. Ta izboljšava poenostavi potek dela, saj partnerjem omogoča konfiguriranje in ponovno uporabo ene domene najvišje ravni v več organizacijah strank. Ta pristop odpravlja potrebo po ločenih certifikatih na stranko ali prtljažnik, kar zmanjšuje operativni napor in poenostavlja postopek nastavitve.

Ko konfigurirate debla v nadzornem središču, določite identiteto vrstniškega certifikata, da omogočite uporabo enega samega certifikata za domeno najvišje ravni v vseh organizacijah stran k. Prepričajte se, da CN ali SAN certifikata vključuje to domeno najvišje ravni. Z identiteto Peer cert lokalni prehod uporablja en sam certifikat, katerega CN ali SAN vsebuje partnerjevo domeno v skupni rabi (na primer sip.telsp.com). Potrdila nadomestnih znakov (npr. *.sip.telsp.com) niso podprta. Webex Callingsprejema to potrdilo za vsak sistem strank, ki je izrecno konfiguriran s to vred nostjo kot svojo identiteto Peer certifikata. Certifikat mora vsebovati natančno konfigurirano vrednost identitete Peer certifikata v svojem CN ali SAN. To odpravlja potrebo po konfiguriranju ločenih potrdil ali vnosov CN/SAN za posamezne magistralne FQDNS.

Preverjanje domene in uporaba certifikata

Pomembno je razumeti, kako se preverjanje domene razlikuje od uporabe potrdil:

• Preverjanje domene (na stranko) —Vsaka organizacija strank mora samostojno preveriti domeno (na primer sip.telsp.com) tako, da v DNS doda edinstven zapis TXT. To zagotavlja, da je partner lastnik domene in preprečuje nepooblaščeno uporabo.

• Upravljanje certifikatov (globalno) — en sam certifikat, izdan za partnerjevo domeno najvišje ravni, je mogoče skupno rabiti med vsemi strankami z uporabo identitete Peer cert. Ni potrebe po vzdrževanju ločenih certifikatov na stranko ali na prtljažnik.

Vedenje identitete vrstniških certifikatov

Identnost vrstniškega certifikata opredeljuje identiteto, ki Webex Calling jo pričakuje v potrdilu, ki ga predloži lokalni prehod.

Ko je konfiguriran:

• Webex Callingpotrdilo potrdi tako, da se konfigurirana identiteta Peer certifik ata uskladi s CN ali SAN v certifikatu

• Če se vrednosti ujemajo, je povezava TLS sprejeta

• Če se vrednosti ne ujemajo, se povezava zavrne

Preverjanje pristnosti je dovoljeno samo debla, ki so izrecno konfigurirani z ustrezno identiteto Peer cert .

Samo preverjanje potrdila ni edino preverjanje, ki se izvaja med preverjanjem pristnosti. Poleg potrditve certifikata CN ali SAN glede na konfigurirano identiteto Peer certifikata preverja Webex Calling tudi, ali je osnovni FQDN izrecno konfiguriran in povezan z ustrezno identiteto Peer certifik ata v Control Hub.

Identiteta Peer cert je vnaprej izpolnjena iz osnovnih vrednosti FQDN/SRV. Če ohranite privzete nastavitve, se obstoječe obnašanje potrdila za posamezno deblo ne spremeni. Obstoje ča debla, ki temeljijo na certifikatih, še naprej delujejo brez sprememb. Na novih ali obstoječih prtljažnikih lahko sprejmete skupno identiteto Peer cert s svojim tempom in oba modela lahko sobivata.

1. Primer veljavne konfiguracije:

   • Certifikat CN —sip.tel sp.com

   • Potrdilo SAN —custa.sip. telsp.com

   • Identiteta vrstniškega certifikata —custa.sip.telsp.com

   • Prtljažnik FQ DN —trunk.miami.custa.sip.telsp.com

   Rezultat —Povezava je uspešna, ker se identiteta Peer cert (custa.sip.telsp.com) ujema z vrednostjo SAN v certifikatu, osnovni FQDN (trunk.miami.custa.sip.telsp.com) pa je poddomena konfigurirane identitete Peer cert.

2. Primer okvare povezave:

   • Certifikat CN —sip.tel sp.com

   • Potrdilo SAN —custa.sip. telsp.com

   • Identiteta vrstniškega certifikata —custb.sip.telsp.com

   • Prtljažnik FQ DN —trunk.miami.custb.sip.telsp.com

   Rezultat —Povezava ne uspe pri stiskanju roke TLS, ker identiteta Peer certifikata (custb.sip.telsp.com) ni prisotna v CN ali SAN certifikatu. Trunk FQDN je pravilno poddomena identitete Peer cert, vendar certifikat ne nosi te identitete.

3. Primer neveljavne konfiguracije:

   • Certifikat CN —sip.tel sp.com

   • Potrdilo SAN —custa.sip. telsp.com

   • Identiteta vrstniškega certifikata —custa.sip.telsp.com

   • Prtljažnik FQ DN —trunk.miami.custb.sip.telsp.com

   Rezultat — Control Hub zavrne to konfiguracijo ob prihranku časa, ker osnovni FQDN (trunk.miami.custb.sip.telsp.com) ni enak ali poddomeni konfigurirane identitete Peer cert (custa.sip.telsp.com).

V središču partnerjev lahko zaženete nadzorno središče za CuSTA ali CustB in konfigurirate prehod. S tem postopkom nastavite za vsako stranko:

1. Ustvarite okvir — dodajte prtljažnik v razdelku Klicanje/Usmerjanje klicev/Trunk za vsak prehod v skupni rabi partnerja. Če želite nastaviti prtljažnik, glejte Konfiguriranje prtljažnikov, skupin poti in načrtov klicanja za Webex Calling

2. Dodajte domeno in preverite — dodajte in preverite naslednjo domeno, ki se uporablja za ustvarjanje debla v razdelku Nastavitve upravljanja/organizacije/domene.

   StrankB	CustomerC
   sip.telsp.com	sip.telsp.com

   Ob dodajanju domene se žeton ustvari in ga vstavi v zapis TXT za domeno v partner jevem strežniku DNS. Ta zapis omogoča Control Hub, da preveri, ali je domena v lasti partnerja. Za podrobnosti glejte U pravljanje domen

   Skupna domena se uporablja za preverjanje pri vsaki stranki. Ker pa se to preverjanje zgodi na ravni organizacije strank, zagotovite, da se ustvari in uporabi druga čen žeton za preverjanje v vsaki organizaciji strank. Ker se v organizacijah strank uporablja ena domena in vsaka organizacija strank mora neodvisno preveriti domeno z edinstvenim zapisom TXT, tudi če si deli isto domeno.

   Za identiteto Peer cert je potrebno samo preverjanje domene. Ne uveljavljajte domene v skupni rabi v organizaciji strank. Domeno lahko uveljavlja samo ena organizacija, med tem ko lahko isto domeno preverite v več organizacijah.

3. Nastavite naslov SBC s FQDN—

   Za prehod v Miamiju:

   Parameter	StrankB	CustomerC
   Lokacija	Denver	Boston
   Ime prtljažnika	trunk_miami	trunk_miami
   Vrsta prtljažnika	Na podlagi certifikata	Na podlagi certifikata
   Vrsta naprave	npr. Cisco Unified Border Element(ali druga podprta naprava)	npr. Cisco Unified Border Element(ali druga podprta naprava)
   SBC Vrsta naslova	FQDN	FQDN
   Ime gostitelja	lgw.miami	lgw.miami
   Domena	sip.telsp.com	sip.telsp.com
   Pristanišče	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Največje število sočasnih klicev (250-6500)	500	500

   Za prehod v Chicagu:

   Parameter	StrankB	CustomerC
   Lokacija	Detroit	Dallas
   Ime prtljažnika	prtlja_Chicago	prtlja_Chicago
   Vrsta prtljažnika	Na podlagi certifikata	Na podlagi certifikata
   Vrsta naprave	npr. Cisco Unified Border Element(ali druga podprta naprava)	npr. Cisco Unified Border Element(ali druga podprta naprava)
   SBC Vrsta naslova	FQDN	FQDN
   Ime gostitelja	lgw.Chicago	lgw.Chicago
   Domena	sip.telsp.com	sip.telsp.com
   Pristanišče	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Največje število sočasnih klicev (250-6500)	500	500

   • (Neobvezno) Imena prtljažnikov ni nujno, da so edinstvena v organizacijah strank. Ponovna uporaba istega imena (na primer trunk_miami) olajša sledenje prtljažniku.

   • Nekateri SBC omogočajo konfiguriranje istih vrat, vendar lahko ta konfiguracija vpliva na zmogljivost. Zato uporabite različna vrata.

4. Identiteta vrstniškega certifikata—

   • Predpona —Predpona ni obvezna. Pustite ga prazno, da nastavite identiteto Peer cert samo za domeno. To je model deljenega certifikata, uporabljen v tem članku (identiteta Peer cert — sip.telsp.com, ki zajema vse skupine strank). Po želji vnesite predpono, da določite natančnejšo identiteto potrdila (na primer predpona: Customer B, Domena: Customerb.sip.telsp.com za potrdilo za posamezno stranko). Sam osnov ni FQDN ostane definiran z naslovom SBC Ime gostitelja in polja Domena in mora biti enak ali poddomeni nastale identitete Peer cert.

     Primer:

     Predpona-strankaB

     Domena — sip.telsp.com

     Rezult—customerb.sip.telsp.com

   • Domena: izberite domeno s seznama domen, preverjenih v organizaciji strank. Nastala identiteta Peer certifikata (predpona + domena) se mora ujemati s CN ali SAN certifikatom, ki ga predstavlja vaš SBC. Webex Callinguporablja to vrednost za preverjanje pristnosti povezave TLS.

     

     Control Hub zavrne to konfiguracijo ob prihranku časa, ker osnovni FQDN ni pod konfigurirano identiteto Peer cert.

     Če se identiteta Peer certifikata ne ujema s CN ali SAN v potrdilu, ki ga predloži SBC, zavrne povez Webex Calling avo TLS in prtljažnik ne vzpostavi .

5. Uporaba prtljažnikov — izberite poljubno lokacijo za prtljažnik zaradi naslednjega:

   • Vsaka lokacija lahko uporablja prtljažnik v povezavi PSTN.

   • Do prtljažnika lahko dostopate prek skupine poti.

   • Vsak načrt klicanja lahko uporablja prtljažnik.

6. Oglejte si definicije prtljažnika s povezanimi lokacijami:

   

   Te debla lahko uporabite za ustvarjanje skupin poti. Na sliki je definirana skupina poti rg_miami_chicago, ki poti kliče na trunk_ miami prtl jažnik kot primarno možnost in na trunk_ chicago deblo kot sekundarno možnost.

   

   Določite lahko drugo skupino poti rg_chicago_miami, ki klice usmerja na trunk_ chicago kot primarno možnost in na trunk_ miami deblo kot sekundarno možnost.

7. Določena debla in skupine poti so zdaj na voljo v možnosti PSTN za klicanje povez ave za vsako lokacijo. Na sliki si oglejte lokacijo Denverja.

   

8. V definiciji načrta številčnice lahko uporabite debla in skupine poti. Na primer, obseg lokalnih številk v Chicagu za stranko je razdeljen na skupino poti rg_chicago_miami (za vse lokacije) na sliki:

   

   

Zagotavljanje v obsegu z API-ji

Partnerji, ki upravljajo veliko število organizacij strank, lahko namesto uporabniškega vmesnika zagotavljajo domene v obsegu z uporabo API-jev.

• Preverite domeno

• Usmerjanje klicev