Să ia în considerare un partener Webex ipotetic numit TelSP pentru a ilustra diferitele modele de implementări pe care partenerul le poate adopta.

Iată specificațiile și cerințele de nivel înalt ale TelSP:

• Partenerul intenționează să utilizeze sip.telsp.com ca domeniu de nivel superior, care este partajat între toți clienții pe care îi gestionează.

• Partenerul deține sip.telsp.com și poate administra infrastructura DNS și autoritățile de certificare, gestiona adresele DNS și semnează certificate pentru acest domeniu și domeniile sale secundare.

• Partenerul poate implementa doi controlori de frontieră de sesiune distincți (fizici sau virtuali) ca gateway-uri locale pentru accesul PSTN partajat în rândul clienților finali.

• Partenerul are două site-uri fizice, iar ambele aceste site-uri partajează conectivitate PSTN:

  • Miami

  • Chicago

• TelSP își operează gateway-urile locale în numele celor doi clienți CustA și CustB, după cum se menționează în prezentul document.

Scenariul dorit este de a avea originare/terminare PSTN atât pentru clienții care utilizează gateway-urile Miami și Chicago furnizate de partener, după cum se arată în ilustrație:

Asocierea locației clientului la trunchi și gateway

Webex Calling permite crearea de trunchiuri și partajarea unui trunchi în mai multe locații. Atunci când creați trunchiul, asociați trunchiul cu o locație.

Pentru CustA, detaliile trunchiului sunt după cum urmează:

Ilustrația arată asocierea locației clientului cu Gateway și Trunk pentru CustA:

În această implementare, trunchiul asociat locației este conexiunea primară PSTN pentru acea locație. Celălalt trunchi este utilizat ca o conexiune PSTN secundară sau o rută pentru intrări specifice ale planului de apelare. Implementarea relației de conexiune primară și secundară PSTN se realizează printr-un concept Route Group. Consultați secțiunea Configurare clienți Webex pentru detalii.

Pentru CustB, se creează o configurare similară cu următoarele trunchiuri:

Ilustrația arată asocierea locației clientului cu Gateway și Trunk pentru CustB:

Ilustrația arată o a treia locație și anume New York, pe care o puteți adăuga mai târziu și indica trunk_chicago trunchiul ca conexiune primară PSTN.

Când implementați un gateway local care partajează mai multe trunchiuri, Cisco MANDATĂ folosind un singur FQDN pe trunchi. Consultați Configurare-trunchiuri,-rute-grupuri,-și-planuri de apelare-pentru-Webex-Calling pentru detalii.

Utilizarea unei adrese IP și a unui port bine cunoscut pe trunchi este o alegere ideală. Cu toate acestea, achiziționarea unei adrese IPv4 publice poate fi o provocare pentru unii parteneri care doresc să utilizeze o adresă per gateway per site.

Prin urmare, citiți aceste indicii importante:

• Cisco nu trimite o adresă IP pe trunchi.

• O adresă de trunchi se poate rezolva la o adresă IP unică sau la adresa partajată între un alt trunchi.

• Cisco recomandă să aveți un port unic de ascultare pe trunchi din următoarele motive:

  1. Oferă izolație la nivel de rețea între clienți

  2. Este tipic pentru controlorii de frontieră Sesiune să reutilizeze conexiunea efemerală a prizei TCP, cu excepția cazului în care există izolație furnizată ca o entitate găzduită unică partiționată de o adresă IP sau un port de ascultare unic pentru entitate găzduită.

  3. Conexiunea sau conexiunile pe trunchi prin izolarea chiriașilor asigură un flux mai bun în special în condiții de rețea cu pierderi mari de date. Prin urmare, traficul de la un client nu îl afectează pe celălalt.

Adresă IP per gateway: Configurarea trunchiurilor și recomandări

Consultați aceste exemple de modele diferite de planificare:

Modelul 1: Adresă IP unică pe trunchi

În acest model, toate trunchiurile găzduite de ambele gateway-uri se rezolvă la o adresă IP unică, iar fiecare dintre aceste trunchiuri poate sau nu utiliza același port, dar în mod ideal același port.

Reprezentând informațiile într-un format tabelar:

În același model, partenerul poate utiliza o adresă SRV. Webex Calling permite numai „_sips._tcp” ca combinație de servicii și protocol să descopere adresa peer dacă este o înregistrare SRV.

Un eșantion de modul în care se rezolvă o înregistrare SRV

nslookup

-type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Server:		8.8.8.8 Adresă:	8.8.8.8#53 Răspuns neautorizat: _sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com 

Modelul 2: IP partajat pe un gateway, dar diferite porturi de ascultare

În acest model, toate trunchiurile găzduite pe gateway-ul local din Chicago se rezolvă la aceeași adresă IP și toate trunchiurile găzduite pe gateway-ul local din Miami se rezolvă la un alt IP. Cu toate acestea, atunci când utilizați același IP, fiecare trunchi este configurat folosind un FQDN în hubul de control și este configurat cu un port unic.

În același model, partenerul utilizează o adresă SRV. Webex Calling permite numai „_sips._tcp” ca combinație de servicii și protocol să descopere adresa peer dacă este o înregistrare SRV.

Un alt exemplu al modului în care o înregistrare SRV se rezolvă este după cum urmează. În acest exemplu, există 1 Înregistrare per adresă IP. Cu toate acestea, portul este unic per adresă și este reprezentat printr-o configurație DNS specifică care leagă o adresă SRV de portul din dreapta.

nslookup

-type=srv_sips._tcp.trunk.miami.custa.sip.telsp.com Server:		8.8.8.8 Adresă:	8.8.8.8#53 Răspuns neautorizat: _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 Adresă:	8.8.8.8#53 Răspuns neautorizat: _sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com 

Partenerul deține telsp.com și subdomeniile sale. Prin urmare, serverul DNS și autoritatea de a obține certificatele semnate de o autoritate de certificare aprobată se află cu partenerul.

• Cisco Webex se așteaptă ca partenerul să publice adresa FQDN sau SRV, inclusiv O Înregistrare în domeniul public.

• Cisco Webex se așteaptă ca partenerul să utilizeze una dintre autoritățile de certificare enumerate în acest document.

Atunci când utilizați un FQDN ca adresă de trunchi, configurați certificatele semnate cu numele comun (CN) sau numărul subiectului numărul alternativ (SAN) setat la FQDN pentru trunchiuri.

Utilizați una dintre aceste metode pentru a genera FQDN în certificat:

• Alegeţi unul dintre FQDN ca nume comun (CN) şi restul ca număr de subiect număr alternativ (SAN).

• Plasați domeniul de nivel superior (sip.telsp.com) ca CN și toate FQDN ca SANS.

  În viitor, puteți valida certificatul pe baza domeniului de nivel superior pe care această configurație îl potrivește.

Atunci când utilizați un SRV ca adresă de trunchi, configurați certificate semnate cu CN sau SAN la porțiunea gazdă a adresei SRV. Nu este necesară Înregistrarea sau CNAME la care se rezolvă adresa SRV.

Configurați gateway-ul

Utilizați aceste resurse pentru a configura un gateway local.

Pentru a configura Cisco CUBE, utilizați această procedură: Configurați gateway-ul local în Cisco IOS XE pentru Webex Calling

Puteți configura SBC-uri terțe aprobate, consultați: Începeți să utilizați gateway-ul local

Configurați gateway-ul găzduit de partener în conformitate cu aceste orientări: Începeți să utilizați gateway-ul local

Setați fiecare trunchi în conformitate cu instrucțiunile relevante pentru dispozitivul SBC. Pentru instrucțiunile Cisco CUBE, consultați: Configurați gateway-ul local în Cisco IOS XE pentru Webex Calling

Configurați clase de voce, grupuri de apelare și grupuri de apelare pentru traficul de intrare și de ieșire pentru trunchi conform imaginii:

Din Hubul pentru parteneri, puteți lansa Control Hub pentru CustA sau CustB și puteți configura gateway-ul. Utilizați această procedură pentru a configura pentru fiecare client:

1. Creați trunchiul – Adăugați un trunchi în timpul apelării/rutării apelurilor/trunchiului pentru fiecare gateway partajat al partenerului. Pentru a configura un trunchi, consultați Configurați trunchiuri, grupuri de rutare și planuri de apelare pentru Webex Calling

2. Adăugați un domeniu și verificați – Adăugați și verificați următorul domeniu care este utilizat pentru a crea un trunchi în Setări/Domenii de administrare/organizație.

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

   La adăugarea unui domeniu, un token este generat și plasat în înregistrarea TXT pentru domeniul din serverul DNS al partenerului. Această înregistrare permite Control Hub să verifice dacă domeniul este deținut de partener. Pentru detalii, consultați Gestionați domeniile dvs.

   Deoarece Domeniul comun este utilizat pentru verificarea fiecărui client. Cu toate acestea, deoarece această verificare are loc la nivelul organizației clientului, asigurați-vă că este generat și utilizat un token diferit pentru verificarea fiecărei organizații client. Deoarece un singur domeniu este utilizat în cadrul organizațiilor clienților, nicio organizație nu poate revendica proprietatea asupra domeniului.
3. Configurați adresa SBC cu FQDN—

   Pentru gateway Miami:

   Parametru	CustA	Custă B
   Loc	Denver	Boston
   Nume trunchi	trunk_miami	trunk_miami
   Tip de trunchi	Pe bază de certificat	Pe bază de certificat
   Tip dispozitiv	de ex. Element de frontieră Cisco Unified (sau alt dispozitiv acceptat)	de ex. Element de frontieră Cisco Unified (sau alt dispozitiv acceptat)
   tip Adresă SBC	FQDN	FQDN
   Nume gazdă	trunk.miami.custa	trunk.miami.custb
   Domeniu	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Numărul maxim de apeluri simultane (250-6500)	500	500

   Pentru gateway Chicago:

   Parametru	CustA	Custă B
   Loc	Detroit	Dallas
   Nume trunchi	trunk_chicago	trunk_chicago
   Tip de trunchi	Pe bază de certificat	Pe bază de certificat
   Tip dispozitiv	de ex. Element de frontieră Cisco Unified (sau alt dispozitiv acceptat)	de ex. Element de frontieră Cisco Unified (sau alt dispozitiv acceptat)
   tip Adresă SBC	FQDN	FQDN
   Nume gazdă	trunk.chicago.custa	trunk.chicago.custb
   Domeniu	sip.telsp.com	sip.telsp.com
   Port	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Numărul maxim de apeluri simultane (250-6500)	500	500

   • (Opțional) Nu aveți un nume unic pentru trunchi în rândul clienților și același nume vă poate ajuta în urmărirea trunchiului.

   • Anumite SBC-uri permit configurarea aceluiași port, dar această configurație poate afecta capacitatea. Prin urmare, utilizați porturi diferite.

4. Utilizarea Trunchiurilor – alegeți orice locație arbitrară pentru trunchi, datorită următoarelor:

   • Orice locație poate utiliza trunchiul într-o conexiune PSTN.

   • Puteți accesa trunchiul printr-un grup de rute.

   • Orice plan de apelare poate utiliza trunchiul.

5. Consultați definițiile trunchiurilor cu locațiile asociate:

   

   Puteți utiliza aceste trunchiuri pentru a crea grupuri de rutare. În imagine rg_miami_chicago este definit un grup de rute care rutează apelurile către trunk_miami trunchi ca opțiune principală și către trunk_chicago trunchi ca opțiune secundară.

   

   Puteți defini un al doilea grup de rute rg_chicago_miami care rutează apelurile către trunk_chicago trunchi ca opțiune principală și către trunk_miami trunchi ca opțiune secundară.

6. Trunchiurile și grupurile de rutare definite sunt acum disponibile în opțiunea PSTN Calling Connection pentru fiecare locație. În imagine, a se vedea locația Denver.

   

7. Puteți utiliza trunchiurile și grupurile de rutare din definiția planului de apelare. De exemplu, o gamă de numere prestabilite din Chicago pentru client este împărțită pentru a se termina la grupul de rg_chicago_miami rute (pentru toate locațiile) din imagine: