Mulțumim pentru feedback.

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 și cerințele la nivel înalt ale TelSP:

• Partenerul intenționează să utilizeze sip.telsp.com ca domeniu de nivel superior care este partajat tuturor clienților 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 frontieră de sesiune (fizice sau virtuale) ca gateway-uri locale pentru accesul PSTN partajat între clienții finali.

• Partenerul are două site-uri fizice și ambele site-uri împărtășesc conectivitate PSTN:

  • Miami

  • Chicago

• TelSP își operează gateway-urile locale în numele celor doi clienți CuSTA și CustB așa cum sunt menționați în continuare.

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

Exemplu de implementare simplificată

Următorul exemplu simplificat demonstrează modul în care identitatea certificatului peer permite unui singur certificat să accepte mai multe trunchiuri de clienți:

• Certificat —sip.tel sp.com

• Trunchiuri

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identitate de certificat de la egal la egal —sip.telsp.com

• Rezultat

  • Se utilizează un singur certificat

  • Sunt acceptate mai multe trunchiuri de clienți

Asocierea locației clientului la trunchi și gateway

Următoarele secțiuni oferă mapări detaliate de configurare pentru implementarea descrisă mai sus.

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

Pentru CUsta, detaliile portbagajului sunt următoarele:

Ilustrația arată asocierea locației clientului la Gateway și Trunk pentru CUsta:

În această implementare, trunchiul asociat loc ației este conexiunea PSTN principală pentru locația respectivă. Celălalt trunchi este utilizat ca conexiune sau rută secundară PSTN pentru intrări specifice ale planului de apelare. Implementarea relației de conexiune PSTN primară și secundară se face printr-un concept de grup de rute. Consultaţi Configurarea trunchiurilor gateway din secţiunea Control Hub pentru detalii.

Pentru CustB, se creează o configurație similară cu următoarele trunchiuri:

Ilustrația arată asocierea locației clientului la Gateway și Tr unk 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ți trunchiul trunk_chicago ca conexiune principală PSTN.

Atunci când implementați un gateway local care partajează mai multe trunchiuri, Cisco mandatează utilizarea unui FQDN unic pe trunchi. Consultați Configurarea trunchiurilor, grupurilor de rute-și planuri dial-pentruapelare WebEx 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ă pe gateway pe site.

Prin urmare, citiți aceste indicații importante:

• Cisco nu impune o adresă IP pe trunchi.

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

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

  1. Menținerea legăturilor de conexiune TCP separate pe trunchi acceptă capacitatea maximă de apel concomitent pe trunchi. Partajarea adreselor IP și a combinațiilor de porturi între trunchiuri poate avea un impact negativ asupra capacității apelurilor.

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

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

  4. Conexiunile sau conexiunile pe trunchi prin izolarea chiriașilor 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: configurarea trunchiului și recomandări

Consultați aceste exemple de modele diferite pentru planificare:

Model 1: Adresă IP unică pe trunchi

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

Reprezentarea informațiilor într-un format tabelar:

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

O mostră a modului în care se rezolvă o înregistrare 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

Modelul 2: IP partajat pe gateway, porturi de ascultare unice

În acest model, toate trunchiurile găzduite pe gateway-ul local Chicago se rezolvă la aceeași adresă IP și toate trunchiurile găzduite pe gateway-ul local Miami se rezolvă la un IP diferit. Cu toate acestea, atunci când utilizați același IP, fiecare trunchi este configurat utilizând 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 Callingpermite doar „_sips. _tcp” ca combinație de servicii și protocol pentru a descoperi adresa peer dacă este o înregistrare SRV.

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

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

Pentru trunchiurile bazate pe SRV, identitatea certificatului Peer este inițial populată din valorile SRV configurate și poate fi personalizată, sub rezerva acelorași reguli de validare.

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ă revine partenerului.

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

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

Când configurați trunchiurile utilizând FQDN sau SRV:

• Fiecare trunchi trebuie să aibă în continuare un FQDN unic pentru rutare și identificare

• Înregistrările DNS (A Record sau SRV) trebuie să fie corect configurate și rezolvabile

• Aceste FQDN sunt utilizate pentru semnalizare și rutare. Validarea certificatului se efectuează în raport cu identitatea de certificat Peer configurată, care este implicită la valorile FQDN trunchiului, dar care poate fi personalizată la o identitate partajată, deținută de partener.

  Câmpul identitate de certificat peer se prepopulează din FQDN-ul de trunchi și poate fi înlocuit cu un domeniu partajat, deținut de partener, pentru a utiliza un singur certificat în mai multe trunchiuri de clienți.

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 pe Cisco IOS XE pentru Webex Calling

Puteți configura SBC-uri terțe aprobate, consultați: Noțiuni de bază cu Gateway-ul local

Configurați gateway-ul găzduit de partener în conformitate cu următoarele reguli: Începeți cu Local Gateway

Setați fiecare trunchi conform instrucțiunilor relevante pentru dispozitivul SBC. Pentru instrucțiunile Cisco CUBE, consultați: Configurarea gateway-ului local pe Cisco IOS XE pentru Webex Calling

Configurați clase de voce, apelați colegii și formați grupuri de colegi pentru traficul de intrare și de ieșire pentru trunchi, conform imaginii:

În timp ce furnizați un trunchi, Control Hub oferă o opțiune pentru a configura identitatea certificatului peer în pagina Adăugare trunchi. Această îmbunătățire simplifică fluxul de lucru, permițând partenerilor să configureze și să reutilizeze un singur domeniu de nivel superior în mai multe organizații clienți. Această abordare elimină necesitatea certificatelor separate pentru fiecare client sau trunchi, reducând efortul operațional și simplificând procesul de configurare.

Când configurați trunchiuri în Control Hub, definiți o identitate de certificat Peer pentru a permite utilizarea unui singur certificat pentru domeniul dvs. de nivel superior în toate organizațiile client . Asigurați-vă că CN-ul sau SAN-ul certificatului include acest domeniu de nivel superior. Cu identitatea de certificat Peer, gateway-ul local utilizează un singur certificat al cărui CN sau SAN conține domeniul partajat al partenerului (de exemplu, sip.telsp.com). Certificatele wildcard (de exemplu, *.sip.telsp.com) nu sunt acceptate. Webex Callingacceptă acest certificat pentru fiecare trunchi de client configurat în mod explicit cu acea valoare ca identitate de certificat Peer. Certificatul trebuie să conţină valoarea exactă de identitate a certificatului Peer configurată în CN sau SAN. Acest lucru elimină necesitatea de a configura certificate separate sau intrări CN/SAN pentru FQDN-uri individuale de trunchi.

Verificarea domeniului și utilizarea certificatului

Este important să înțelegeți cum diferă verificarea domeniului de utilizarea certificatului:

• Verificarea domeniului (per client) — Fiecare organizație client trebuie să verifice independent domeniul (de exemplu, sip.telsp.com) adăugând o înregistrare TXT unică în DNS. Acest lucru asigură faptul că partenerul deține domeniul și previne utilizarea neautorizată.

• Gestionarea certificatelor (Global) —Un singur certificat emis pentru domeniul de nivel superior al partenerului poate fi partajat între toate trunchiurile de clienți utilizând identitatea certificatului Peer. Nu există nicio cerință de a menține certificate separate pe client sau pe portbagaj.

Comportamentul identității de certificat de la egal la egal

Identitatea certificatului peer definește identitatea care se Webex Calling așteaptă în certificatul prezentat de gateway-ul local.

Când este configurat:

• Webex Callingvalidează certificatul prin potrivirea identității Peer cert configur ate cu CN sau SAN din certificat

• Dacă valorile se potrivesc, conexiunea TLS este acceptată

• Dacă valorile nu se potrivesc, conexiunea este respinsă

Numai trunchiurile configurate explicit cu identitatea certificatului Peer corespunzătoare au permisiunea de autentificare.

Validarea certificatului nu este singura verificare efectuată în timpul autentificării. Pe lângă validarea certificatului CN sau SAN în raport cu identitatea certificatului Peer configurat, verifică, de Webex Calling asemenea, dacă FQDN-ul trunchiului este configurat explicit și asociat cu identitatea de certificat Peer care coresp unde în Control Hub.

Identitatea certificatului Peer este pre-populată din valorile trunchiului FQDN/SRV. Dacă păstrați valorile implicite , comportamentul existent al certificatului per trunchi este neschimbat. Trunchiurile existente bazate pe certificate continuă să funcționeze fără modificări. Puteți adopta o identitate de certificat Peer partajată pe trunchiuri noi sau existente în ritmul propriu și ambele modele pot coexista.

1. Exemplu de configurare valid:

   • Certificat CN —sip.tel sp.com

   • Certificat SAN —custa.sip.telsp.com

   • Identitatea certificatului peer —custa.sip.telsp.com

   • Trunchi FQDN —trunk.miami.custa.sip.telsp.com

   Rezultat —Conexiunea reușește deoarece identitatea certificatului peer (custa.sip.telsp.com) se potrivește cu valoarea SAN din certificat, iar FQDN-ul trunchiului (trunk.miami.custa.sip.telsp.com) este un subdomeniu al identității de certificat Peer configurate.

2. Exemplu de eșec al conexiunii:

   • Certificat CN —sip.tel sp.com

   • Certificat SAN —custa.sip.telsp.com

   • Identitate de certificat de la egal la egal —custb.sip.telsp.com

   • Trunchi FQDN —trunk.miami.custb.sip.telsp.com

   Rezultat —Conexiunea eșuează la strângerea de mână TLS, deoarece identitatea certificatului peer (custb.sip.telsp.com) nu este prezentă în CN sau SAN al certificatului. FQDN-ul trunchiului este corect un subdomeniu al identității certificatului Peer, dar certificatul nu poartă acea identitate.

3. Exemplu de configurare nevalid:

   • Certificat CN —sip.tel sp.com

   • Certificat SAN —custa.sip.telsp.com

   • Identitatea certificatului peer —custa.sip.telsp.com

   • Trunchi FQDN —trunk.miami.custb.sip.telsp.com

   Rezultat —Control Hub respinge această configurație la timp de salvare, deoarece FQDN trunchiului (trunk.miami.custb.sip.telsp.com) nu este egal sau un subdomeniu al identității de certificat Peer configurate (custa.sip.telsp.com).

Din Partner Hub, puteți lansa Hub de control fie pentru CUSTa, fie pentru 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 sub Apeluri/Rutare apeluri/Trunk pentru fiecare gateway partajat partener. Pentru a configura un trunchi, consultați Configurarea trunchiurilor, grupurilor de rute și 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 trunchi în Setări de gestionare/organizație/domenii.

   ClientB	ClientRC
   sip.telsp.com	sip.telsp.com

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

   Domeniul comun este utilizat pentru verificarea fiecărui client. Cu toate acestea, deoarece această verificare are loc la nivelul organizației clienților, asigurați-vă că un jet on diferit este generat și utilizat pentru verificare pe fiecare organizație client. Deoarece un singur domeniu este utilizat în toate organizațiile client și fiecare organizație client trebuie să verif ice independent domeniul utilizând o înregistrare TXT unică, chiar și atunci când partajează același domeniu.

   Doar verificarea domeniului este necesară pentru identitatea certificatului Peer. Nu revendicați domeniul partajat într-o organizație client. Un domeniu poate fi revendicat de o singură organizație, în timp ce același domeniu poate fi verificat în mai multe organizații.

3. Configurați adresa SBC cu FQDN—

   Pentru poarta de acces din Miami:

   Parametru	ClientB	ClientRC
   Locaţie	Denver	Boston
   Numele trunchiului	trunk_miami	trunk_miami
   Tipul portbagajului	Bazat pe certificat	Bazat pe certificat
   Tipul dispozitivului	de exemplu Cisco Unified Border Element(sau alt dispozitiv acceptat)	de exemplu Cisco Unified Border Element(sau alt dispozitiv acceptat)
   Tip de adresă SBC	FQDN	FQDN
   Numele gazdei	lgw.miami	lgw.miami
   Domeniul	sip.telsp.com	sip.telsp.com
   Portul	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Numărul maxim de apeluri concomitente (250-6500)	500	500

   Pentru poarta de acces din Chicago:

   Parametru	ClientB	ClientRC
   Locaţie	Detroit	Dallas
   Numele trunchiului	trunk_chicago	trunk_chicago
   Tipul portbagajului	Bazat pe certificat	Bazat pe certificat
   Tipul dispozitivului	de exemplu Cisco Unified Border Element(sau alt dispozitiv acceptat)	de exemplu Cisco Unified Border Element(sau alt dispozitiv acceptat)
   Tip de adresă SBC	FQDN	FQDN
   Numele gazdei	lgw.chicago	lgw.chicago
   Domeniul	sip.telsp.com	sip.telsp.com
   Portul	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com:5061	lgw.chicago.customerc.sip.telsp.com:5062
   Numărul maxim de apeluri concomitente (250-6500)	500	500

   • (Opțional) Numele trunchiului nu trebuie să fie unice în cadrul organizațiilor clienților. Reutilizarea aceluiași nume (de exemplu, trunk_miami) face ca portbagajul să fie mai ușor de urmărit.

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

4. Identitatea certificatului de la egal la egal—

   • Prefix — Prefixul este opțional. Lăsați-l gol pentru a seta identitatea certificatului Peer numai la domeniu. Acesta este modelul de certificat partajat utilizat în acest articol (identitatea certificatului peer-sip.telsp .com, care acoperă toate trunchiurile clienților). Opțional, introduceți un prefix pentru a defini o identitate de certificat mai specifică (de exemplu, prefix: CustomerB, Domeniu: Customerb.sip.telsp.com pentru un certificat per client). FQDN-ul trunchiului în sine rămâne definit de adresa SBC Numele gazdei și câmpurile Domeniu și trebuie să fie egal sau un subdomeniu al identității cert Peer rezultate.

     Exemplu:

     Prefix—CustomerB

     Domeniul—sip.telsp.com

     Rezultat—Customerb.sip.telsp.com

   • Domeniu: Selectați un domeniu din lista de domenii verificate în organizația clientului. Identitatea certificatului Peer rezultată (prefix + domeniu) trebuie să se potrivească cu CN sau SAN a certificatului pe care SBC îl prezintă. Webex Callingutilizează această valoare pentru a autentifica conexiunea TLS.

     

     Control Hub respinge această configurație la timpul de economisire, deoarece FQDN-ul trunchiului nu se află sub identitatea certificatului Peer configurat.

     Dacă identitatea certificatului Peer nu se potrivește cu CN sau SAN din certificatul prezentat de SBC, Webex Calling respinge conexiunea TLS și trunchiul nu se stabilește.

5. Utilizarea trunchiurilor — Alegeți orice locație arbitrară pentru portbagaj, 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 folosi portbagajul.

6. Consultați definițiile trunchiului 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 rutează apelurile către trunchiul trunk_ miami ca opțiune principală și la trunk_ chicago trunchiul ca opțiune secundară.

   

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

7. Trunchiurile și grupurile de rute definite sunt acum disponibile în opțiunea Calling Connec tion PSTN pentru fiecare locație. În imagine, vedeți locația Denver.

   

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

   

   

Furnizare la scară largă cu API-uri

Partenerii care gestionează un număr mare de organizații clienți pot furniza domenii la scară largă utilizând API-uri în loc de UI.

• Verificarea domeniului

• Rutarea apelurilor