În acest articol
dropdown icon
Cerințe privind obiectivele finale
    IPv4 versus IPv6
dropdown icon
Cerințe pentru SIP și media
    Cerințe pentru SIP securizat cu MTL (TLS reciproc)
Cerințe de securitate pentru Webex Calling
list-menuÎn acest articol
list-menuFeedback?

Acest articol este destinat administratorilor de rețea, în special administratorilor de securitate firewall și proxy care doresc să utilizeze Webex Calling în cadrul organizației lor.

Cerințe privind obiectivele finale

Webex Callingmargine

Pentru a efectua o înregistrare sau un apel SIP, parcurgeți acești pași:

  • Descoperiți adresa gazdă a unui punct final SIP pentru nodurile Edge active.

  • Completați orice condiții prealabile legate de configurarea utilizatorului și a dispozitivului.

  • Asigurați-vă că punctul final are conectivitate la rețea publică pentru a începe descoperirea serviciului.

  • Finalizați condițiile prealabile de pornire a punctului final cu o configurație de aprovizionare specifică regiunii sau centrului de date. Această configurație ajută la obținerea sufixului de nume de domeniu relevant pentru descoperirea serviciului.

IPv4 versus IPv6

Dispozitivele pot funcționa într-o singură versiune sau în modul dual-stack. Configurația determină modificările protocolului preferat și aceste modificări nu fac parte din descoperirea serviciului.

  • Modul stivă unică - activează un singur protocol IP (de exemplu, IPv4) și ignoră celelalte adrese de protocol.

  • Modul dual-stack — selectează o versiune IP preferată prin configurare.

Clientul consideră că prioritatea pentru toate adresele preferate este mai mică (adică preferată) decât toate adresele IP. Dacă se preferă IPv4, toate adresele IPv4 sunt încercate înainte de a încerca o adresă IPv6. Dacă toate adresele eșuează, ciclul începe din nou cu adresa de protocol preferată cu cea mai mică prioritate.

Un client mobil care se înregistrează la primirea unei notificări push poate decide să optimizeze modul pe baza înregistrărilor anterioare.

Rezoluția adresei gazdă de la DNS SRV adresă

În fișierul de configurare punct final obținut din provizionare, indicatorul de domeniu specifică numele domeniului pentru a descoperi serviciul de margine de acces. Un exemplu de nume de domeniu este:

wxc.edge.bcld.webex.com

Din exemplu, punctul final care efectuează o DNS SRV căutare pentru acest domeniu poate produce un răspuns similar cu următorul:


# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

În acest caz, înregistrarea SRV indică înregistrări 3 A.


sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

În exemplu, toate gazdele sunt anunțate să contacteze portul 5061 cu greutate și prioritate diferite.

Luați în considerare aceste cerințe pentru obiectivele finale.

  • Un punct final trebuie să utilizeze _sips._tcp(combinație serviciu și protocol) ca prefix pentru a efectua o căutare pentru obținerea adre DNS SRV sei gazdă pentru inițierea comunicării bazate pe TLS.

  • Un punct final trebuie să facă DNS SRV o căutare pentru condițiile explicate în Rezoluția adresei gazdei din secțiunea DNS SRV adresă.

  • Un punct final trebuie să onoreze gazda, portul, greutatea și prioritatea așa cum sunt anunțate pentru fiecare adresă gazdă. De asemenea, trebuie să creeze o afinitate de gazdă la port atunci când creați o conexiune socket în timpul înregistrării SIP.

  • Specific utilizării DNS SRV înregistrării, criteriile de selecție ale gazdelor bazate pe prioritate și greutate sunt explicate în RFC 2782.

Cerințe pentru SIP și media

Cerință

Descriere

Certificat de încredere necesar pentru criptarea cheii publice

Consultați articolul, pentru a afla despre autoritatea de semnare a certificatelor Webex și CA Root necesare pe dispozitive

Versiunea TLS acceptată pentru SIP securizat

TLS 1.2 și TLS 1.3

Cifere TLS acceptate pentru SIP securizat

TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

Cheile SRTP acceptate pentru suporturi media securizate

AES_CM_128_HMAC_SHA1_80

Cerințe pentru SIP securizat cu MTL (TLS reciproc)

Cerințele sunt explicate în detaliu aici.

Un certificat semnat este necesar pentru o autorizare și autentificare reușită a apelurilor din trunchi. Certificatul trebuie să îndeplinească următoarele cerințe:

  • Certificatul trebuie să fie valabil întotdeauna:

    • Certificatele semnate trebuie să aibă întotdeauna o expirare valabilă.

    • Certificatele rădăcină sau intermediare trebuie să aibă o expirare valabilă și nu trebuie revocate.

    • Sunt acceptate certificate care conțin numai utilizarea extinsă a cheilor de autentificare a serverului (EKU). Webex Callingnu validează și nu impune prezența EKU de autentificare client în timpul stabilirii strângerii de mână TLS.

      Unii controlori de frontieră de sesiune terți (SBC) pot impune o validare strictă EKU și pot respinge certificatele care nu includ EKU de autentificare client. În astfel de cazuri, asigurați-vă că SBC este configurat să accepte certificate numai cu Server Authentication EKU sau să dezactiveze validarea strictă EKU (dacă este acceptată).

    • Certificatele trebuie să conțină Numele de domeniu complet calificat (FQDN) ca nume comun sau nume alternativ al subiectului în certificatul cu FQDN ales în Hub de control. De exemplu:

      • Un trunchi configurat din hub-ul de control al organizației dvs. cu london.lgw.cisco.com:5061 ca FQDN trebuie să conțină london.lgw.cisco.com în certificatul CN sau SAN.

      • Un trunchi configurat din Centrul de control al organizației dvs. cu london.lgw.cisco.com a fost că SRV trebuie să conțină london.lgw.cisco.com în certificatul CN sau SAN. Înregistrările la care se rezolvă adresa SRV (CNAME/înregistrare A/ Adresă IP) sunt opționale în SAN.

    • Puteți partaja certificate cu mai multe gateway-uri locale, cu toate acestea, asigurați-vă că cerințele FQDN sunt îndeplinite.

În afara domeniului de aplicare

Acest articol nu include următoarele informații referitoare la securitatea rețelei:

  • Cerințe F5 pentru CA și Cifre

  • Un API bazat pe HTTP pentru a descărca regulile firewall pentru Webex.

  • API pentru un pachet de încredere

  • Cerință de firewall și dezactivare ALG

A fost util acest articol?
A fost util acest articol?