Să luăm î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 de nivel înalt & cerințe ale TelSP:

• Partenerul intenționează să utilizeze sip.telsp.com ca domeniu de nivel superior, 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 semna certificate pentru acest domeniu și subdomeniile sale.

• Partenerul poate implementa două controlere distincte de graniță de sesiune (fizice sau virtuale) ca gateway-uri locale pentru acces PSTN partajat între clienții finali.

• Partenerul are două locații fizice, ambele locații partajând conectivitate PSTN:

  • Miami

  • Chicago

• TelSP operează gateway-urile sale locale în numele celor doi clienți, CustA și CustB, așa cum vor fi denumiți în continuare.

Scenariul dorit este să existe PSTN origination/termination pentru ambii clienți care utilizează gateway-urile Miami și Chicago furnizate de partener, așa cum se arată în ilustrație:

Asocierea locației clientului cu trunchiul și gateway-ul

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

Pentru Clientul A, detaliile trunchiului sunt următoarele:

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

În această implementare, trunchiul asociat cu locația este conexiunea PSTN principală pentru locația respectivă. Celălalt trunchi este utilizat ca o conexiune sau rută PSTN secundară pentru intrări specifice în planul de apelare. Implementarea relației de conexiune PSTN primară și secundară se face printr-un concept de grup de rute. Consultați secțiunea Configurarea clientului Webex pentru detalii.

Pentru CustB, este creată o configurație similară cu următoarele trunchiuri:

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

Ilustrația prezintă o a treia locație, și anume New York, pe care o puteți adăuga ulterior și care poate indica trunchiul trunk_chicago ca conexiune PSTN principală.

La implementarea unui gateway local care partajează mai multe trunchiuri, Cisco IMPLICE utilizarea unui FQDN unic per trunchi. Consultați Configurarea trunchiurilor, a grupurilor de rute și a planurilor de apelare pentru Webex Calling pentru detalii.

Utilizarea unei adrese IP și a unui port cunoscut per trunk este o alegere ideală. Totuși, obținerea unei adrese IPv4 publice poate fi dificilă pentru unii parteneri care doresc să utilizeze o singură adresă per gateway per site.

Prin urmare, citiți aceste sfaturi importante:

• Cisco nu impune o adresă IP per trunk.

• O adresă de trunk se poate rezolva într-o adresă IP unică sau în adresa partajată între un alt trunk.

• Cisco recomandă configurarea fiecărei conexiuni trunk cu o combinație unică de adresă IP și port pe Local Gateway din următoarele motive:

  1. Menținerea unor legături de conexiune TCP separate per trunchi permite atingerea capacității maxime de apeluri simultane per trunchi. Partajarea combinațiilor de adrese IP și porturi între linii interconectate poate avea un impact negativ asupra capacității apelurilor.

  2. Oferă izolare la nivel de rețea între clienți

  3. Este tipic pentru controlerele de graniță de sesiune să reutilizeze conexiunea socket TCP efemeră, cu excepția cazului în care există izolare furnizată ca un chiriaș unic partiționat printr-o adresă IP sau un port de ascultare unic pentru chiriaș.

  4. Conexiunea sau conexiunile per trunk prin izolarea chiriașului oferă un randament 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: Configurația trunchiului și recomandări

Consultați aceste exemple de modele diferite pentru planificare:

Model 1: Adresă IP unică per trunk

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

Reprezentarea informațiilor sub formă de tabel:

În același model, partenerul poate utiliza o adresă SRV. Webex Calling permite doar „_sips._tcp” ca combinație de serviciu și protocol pentru a descoperi adresa peer-ului dacă este o înregistrare SRV.

Un exemplu de rezolvare a unei înregistrări 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: IP partajat pe un gateway, dar porturi de ascultare diferite

În acest model, toate trunchiurile găzduite pe gateway-ul local din Chicago se rezolvă la aceeași adresă IP, iar toate trunchiurile găzduite pe gateway-ul local din Miami se rezolvă la o adresă IP diferită. Totuși, atunci când se utilizează aceeași adresă IP, fiecare trunchi este configurat folosind un FQDN în hub-ul de control și este configurat cu un port unic.

În același model, partenerul folosește o adresă SRV. Webex Calling permite doar „_sips._tcp” ca combinație de serviciu și protocol pentru a descoperi adresa peer-ului dacă este o înregistrare SRV.

Un alt exemplu al modului în care se rezolvă o înregistrare SRV este următorul. În acest exemplu, există 1 înregistrare A per adresă IP. Totuși, portul este unic per adresă și este reprezentat printr-o configurație DNS specifică care leagă o adresă SRV de portul corect.

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

Partenerul deține telsp.com și subdomeniile sale. Prin urmare, serverul DNS și autoritatea de a obține certificate semnate de o autoritate de certificare aprobată aparțin partenerului.

• Cisco Webex se așteaptă ca partenerul să publice adresa FQDN sau SRV, inclusiv înregistrările A, în domeniul public.

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

Când utilizați un FQDN ca adresă de trunchi, configurați certificatele semnate cu Numele comun (CN) sau Numărul alternativ al numărului de subiect (SAN) setat pentru FQDN-urile pentru trunchiuri.

Folosiți una dintre aceste metode pentru a genera FQDN-urile în certificat:

• Alegeți unul dintre FQDN-uri ca și Nume Comun (CN) și restul ca Număr Alternativ al Numărului Subiect (SAN).

• Plasați domeniul de nivel superior (sip.telsp.com) ca CN și toate FQDN-urile ca SAN-uri.

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

Când utilizați un SRV ca adresă trunk, configurați certificate semnate cu CN sau SAN pentru porțiunea gazdă a adresei SRV. Înregistrarea A sau CNAME-ul la care se rezolvă adresa SRV nu este obligatoriu.

Configurați Gateway-ul

Folosește 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 instrucțiuni: Începeți să utilizați gateway-ul local

Configurați fiecare trunchi conform instrucțiunilor 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 clasele de voce, apelați colegii și apelați grupurile de colegi pentru traficul de intrare și de ieșire pentru trunchi, conform imaginii:

Din Centrul pentru parteneri, puteți lansa Centrul de control fie pentru Clientul A, fie pentru Clientul B și puteți configura gateway-ul. Folosiți această procedură pentru a configura pentru fiecare client:

1. Creați portbagajul — Adăugați un portbagaj sub Calling/Call Routing/Trunk pentru fiecare gateway partajat de partener. Pentru a configura un trunchi, consultați Configurarea trunchiurilor, a grupurilor de rutare și a planurilor 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 trunk sub Management/Organization Settings/Domains.

   ClientA	ClientB
   sip.telsp.com	sip.telsp.com

   La adăugarea unui domeniu, se generează un token și se plasează în înregistrarea TXT pentru domeniul respectiv pe serverul DNS al partenerului. Această înregistrare permite Control Hub să verifice dacă domeniul este deținut de partener. Pentru detalii, consultați Gestionați-vă domeniile

   Întrucât domeniul comun este utilizat pentru verificarea fiecărui client. Totuși, deoarece această verificare are loc la nivelul organizației clientului, asigurați-vă că este generat și utilizat un token diferit pentru verificare pe fiecare organizație client. Deoarece un singur domeniu este utilizat în mai multe organizații cliente, nicio organizație nu poate revendica dreptul de proprietate asupra domeniului.
3. Configurați adresa SBC cu FQDN—

   Pentru poarta de acces din Miami:

   Parametru	ClientA	ClientB
   Locație	Denver	Boston
   Nume trunchi	trunk_miami	trunk_miami
   Tip de trunchi	Pe bază de certificat	Pe bază de certificat
   Tip dispozitiv	de exemplu, Cisco Unified Border Element (sau alt dispozitiv acceptat)	de exemplu, Cisco Unified Border Element (sau alt dispozitiv acceptat)
   Tipul de 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ăr maxim de apeluri simultane (250-6500)	500	500

   Pentru poarta de acces din Chicago:

   Parametru	ClientA	ClientB
   Locație	Detroit	Dallas
   Nume trunchi	trunk_chicago	trunk_chicago
   Tip de trunchi	Pe bază de certificat	Pe bază de certificat
   Tip dispozitiv	de exemplu, Cisco Unified Border Element (sau alt dispozitiv acceptat)	de exemplu, Cisco Unified Border Element (sau alt dispozitiv acceptat)
   Tipul de 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ăr maxim de apeluri simultane (250-6500)	500	500

   • (Opțional) Nu aveți un nume unic pentru trunchi pentru toți clienții, iar același nume poate ajuta la 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. Vedeți definițiile trunchiurilor cu locațiile asociate:

   

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

   

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

6. Trunchiurile și grupurile de rute definite sunt acum disponibile în opțiunea Conexiune apelant PSTN pentru fiecare locație. În imagine, vedeți locația din Denver.

   

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