Za ponazoritev različnih modelov uvajanja, ki jih lahko partner sprejme, si oglejmo hipotetičnega partnerja Webex z imenom TelSP.

Tukaj so specifikacije na visoki ravni & zahteve TelSP-a:

• Partner načrtuje uporabo domene sip.telsp.com kot domene najvišje ravni, ki si jo delijo vse stranke, ki jih upravlja.

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

• Partner lahko namesti dva različna krmilnika meje sej (fizična ali virtualna) kot lokalna prehoda za skupni dostop do PSTN med končnimi strankami.

• Partner ima dve fizični lokaciji, ki si delita PSTN povezljivost:

  • Miami

  • Chicago

• TelSP upravlja svoje lokalne prehode v imenu obeh strank, CustA in CustB, kot sta v nadaljevanju imenovani.

Želeni scenarij je imeti PSTN origination/termination za obe stranki, ki uporabljata prehoda Miami in Chicago, ki ju zagotavlja partner, kot je prikazano na sliki:

Povezovanje lokacije stranke s prenosnim omrežjem in prehodom

Webex Calling omogoča ustvarjanje linij in skupno rabo linije na več lokacijah. Pri ustvarjanju debla ga povežite z lokacijo.

Za stranko CustA so podrobnosti o trunku naslednji:

Ilustracija prikazuje povezavo lokacije stranke s prehodom in operaterjem za CustA:

V tej uvedbi je trunk, povezan z lokacijo, primarna PSTN povezava za to lokacijo. Drugi kanal se uporablja kot sekundarna povezava ali pot PSTN za določene vnose klicnega načrta. Implementacija primarnega in sekundarnega povezovalnega razmerja PSTN poteka prek koncepta skupine poti. Za podrobnosti glejte razdelek Nastavitev za stranke Webex.

Za CustB je ustvarjena podobna postavitev z naslednjimi prenosnimi linijami:

Ilustracija prikazuje povezavo lokacije stranke s prehodom in operaterjem za CustB:

Ilustracija prikazuje tretjo lokacijo, in sicer New York, ki jo lahko dodate pozneje in nanjo usmerite trunk_chicago kot primarno povezavo PSTN.

Pri uvajanju lokalnega prehoda, ki si deli več trunkov, Cisco NALOŽUJE uporabo edinstvenega FQDN-ja na trun. Za podrobnosti glejte Konfiguriraj kanale, skupine poti in načrte klicanja za Webex klicanje.

Uporaba IP-naslova in dobro znanih vrat na trunk je idealna izbira. Vendar pa je pridobitev javnega naslova IPv4 lahko izziv za nekatere partnerje, ki želijo uporabljati en naslov na prehod na lokacijo.

Zato preberite te pomembne nasvete:

• Cisco ne zahteva IP-naslova na trunk.

• Naslov trunčnega omrežja se lahko razreši v enoličen IP-naslov ali v naslov, ki si ga deli drug trunčni sistem.

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

  1. Vzdrževanje ločenih povezav TCP na kanal podpira največjo zmogljivost sočasnih klicev na kanal. Souporaba kombinacij IP-naslovov in vrat med posredniškimi omrežji lahko negativno vpliva na zmogljivost klicev.

  2. Zagotavlja izolacijo med strankami na ravni omrežja

  3. Za krmilnike meje sej je značilno, da ponovno uporabijo kratkotrajno povezavo vtičnice TCP, razen če je izolacija zagotovljena kot edinstven najemnik, razdeljen z naslovom IP ali edinstvenimi vrati za poslušanje za najemnika.

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

IP-naslov na prehod: Konfiguracija in priporočila za prtljažnik

Za načrtovanje si oglejte te primere različnih modelov:

Model 1: Edinstven IP-naslov na trunk

V tem modelu se vsi trunki, ki jih gostita oba prehoda, razrešijo na edinstven IP-naslov in vsak od teh trunkov lahko uporablja ista vrata ali pa tudi ne, idealno pa ista vrata.

Predstavitev informacij v tabelarni obliki:

V istem modelu lahko partner uporabi naslov SRV. Webex Calling dovoljuje le kombinacijo storitve in protokola »_sips._tcp« za odkrivanje naslova vrstnika, če gre za zapis SRV.

Primer razreševanja zapisa 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: Deljeni IP na prehodu, vendar različna poslušalna vrata

V tem modelu se vsi trunki, ki gostujejo na lokalnem prehodu v Chicagu, razrešijo na isti IP-naslov, vsi trunki, ki gostujejo na lokalnem prehodu v Miamiju, pa na drug IP-naslov. Vendar pa je pri uporabi istega IP-naslova vsak trunk konfiguriran z uporabo FQDN v nadzornem središču in je konfiguriran z edinstvenimi vrati.

V istem modelu partner uporablja naslov SRV. Webex Calling dovoljuje le kombinacijo storitve in protokola »_sips._tcp« za odkrivanje naslova vrstnika, če gre za zapis SRV.

Drug primer razreševanja zapisa SRV je naslednji. V tem primeru obstaja 1 zapis A na IP-naslov. Vendar pa so vrata edinstvena za vsak naslov in so predstavljena s posebno konfiguracijo DNS, ki povezuje naslov SRV s pravimi 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

Partner je lastnik telsp.com in njegovih poddomen. Zato je strežnik DNS in pooblastilo za pridobitev potrdil, podpisanih s strani odobrenega overitelja potrdil, v rokah partnerja.

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

• Cisco Webex pričakuje, da bo partner uporabil enega od overiteljev potrdil, navedenih v tem dokumentu.

Ko kot naslov trunksa uporabljate FQDN, nastavite podpisana potrdila z možnostjo Common Name (CN) ali Subject Number Alternative Number (SAN), nastavljeno na FQDN-je za trunksa.

Za ustvarjanje FQDN-jev v potrdilu uporabite eno od teh metod:

• Izberite eno od FQDN-jev kot splošno ime (CN), preostale pa kot alternativno številko subjekta (SAN).

• Vrhnjo domeno (sip.telsp.com) postavite kot CN in vse FQDN-je kot SAN.

  V prihodnje lahko potrdilo preverite na podlagi domene najvišje ravni, ki si jo prilašča ta konfiguracija.

Ko kot naslov trunksa uporabljate SRV, nastavite podpisana potrdila s CN ali SAN na gostiteljski del naslova SRV. Zapis A ali CNAME, na katerega se razreši naslov SRV, ni potreben.

Nastavite prehod

S temi viri nastavite lokalni prehod.

Za nastavitev Cisco CUBE uporabite ta postopek: Konfigurirajte lokalni prehod na Cisco IOS XE za Webex Calling

Nastavite lahko odobrene SBC-je tretjih oseb, glejte: Začetek uporabe lokalnega prehoda

Nastavite prehod, ki ga gosti partner, v skladu s temi smernicami: Začetek uporabe lokalnega prehoda

Vsako linijo nastavite v skladu z ustreznimi navodili za napravo SBC. Za navodila za Cisco CUBE glejte: Konfigurirajte lokalni prehod na Cisco IOS XE za Webex Calling

Nastavite glasovne razrede, klicne točke in skupine klicnih točk za dohodni in odhodni promet za linijo, kot je prikazano na sliki:

V središču za partnerje lahko zaženete središče za nadzor za stranko A ali stranko B in konfigurirate prehod. Za konfiguracijo za vsako stranko uporabite ta postopek:

1. Ustvari deblo – Dodaj deblo pod Calling/Call Routing/Trunk za vsak skupni prehod partnerja. Za nastavitev zunanje linije glejte Konfiguracija zunanjih linij, skupin poti in klicnih načrtov za Webex Calling

2. Dodaj domeno in preveri – Dodaj in preveri naslednjo domeno, ki se uporablja za ustvarjanje trunk omrežja pod Management/Organization Settings/Domains.

   StrankaA	StrankaB
   sip.telsp.com	sip.telsp.com

   Ob dodajanju domene se ustvari žeton in se shrani v zapis TXT za domeno na DNS strežniku partnerja. Ta zapis omogoča Control Hubu, da preveri, ali je domena v lasti partnerja. Za podrobnosti glejte Upravljanje domen

   Ker se skupna domena uporablja za preverjanje vsake stranke. Ker pa se to preverjanje izvaja na ravni organizacije stranke, zagotovite, da se za preverjanje v vsaki organizaciji stranke ustvari in uporabi drugačen žeton. Ker se v več organizacijah strank uporablja ena domena, nobena organizacija ne more zahtevati lastništva domene.
3. Nastavitev naslova SBC s FQDN –

   Za prehod v Miami:

   Parameter	StrankaA	StrankaB
   Lokacija	Denver	Boston
   Ime združenih linij	trunk_miami	trunk_miami
   Vrsta združene linije	Na podlagi potrdila	Na podlagi potrdila
   Vrsta naprave	npr. Cisco Unified Border Element (ali druga podprta naprava)	npr. Cisco Unified Border Element (ali druga podprta naprava)
   Vrsta naslova SBC	FQDN	FQDN
   Ime gostitelja	trunk.miami.custa	trunk.miami.custb
   Domena	sip.telsp.com	sip.telsp.com
   Vrata	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Največje število sočasnih klicev (250–6500)	500	500

   Za prehod v Chicago:

   Parameter	StrankaA	StrankaB
   Lokacija	Detroit	Dallas
   Ime združenih linij	trunk_chicago	trunk_chicago
   Vrsta združene linije	Na podlagi potrdila	Na podlagi potrdila
   Vrsta naprave	npr. Cisco Unified Border Element (ali druga podprta naprava)	npr. Cisco Unified Border Element (ali druga podprta naprava)
   Vrsta naslova SBC	FQDN	FQDN
   Ime gostitelja	trunk.chicago.custa	trunk.chicago.custb
   Domena	sip.telsp.com	sip.telsp.com
   Vrata	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Največje število sočasnih klicev (250–6500)	500	500

   • (Neobvezno) Za operaterja med strankami ne uporabljajte edinstvenega imena, isto ime pa lahko pomaga pri sledenju operaterja.

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

4. Uporaba kanalov – izberite poljubno lokacijo za kanal zaradi naslednjega:

   • Katera koli lokacija lahko uporablja trunk v PSTN povezavi.

   • Do prtljažnika lahko dostopate prek skupine poti.

   • Prenosnik lahko uporablja kateri koli klicni načrt.

5. Glejte definicije prtljažnikov s pripadajočimi lokacijami:

   

   Te trunčne linije lahko uporabite za ustvarjanje skupin poti. Na sliki je definirana skupina poti rg_miami_chicago, ki usmerja klice na trunk_miami trunk kot primarno možnost in na trunk_chicago trunk kot sekundarno možnost.

   

   Določite lahko drugo skupino poti rg_chicago_miami, ki usmerja klice na trunk_chicago trunk kot primarno možnost in na trunk_miami trunk kot sekundarno možnost.

6. Določene skupine operaterjev in poti so zdaj na voljo v možnosti Klicna povezava PSTN za vsako lokacijo. Na sliki si oglejte lokacijo v Denverju.

   

7. Skupine operaterjev in poti lahko uporabite v definiciji klicnega načrta. Na primer, obseg številk na lokaciji v Chicagu za stranko je razdeljen tako, da se konča s skupino poti rg_chicago_miami (za vse lokacije) na sliki: