- Pagină de pornire
- /
- Articol
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.
Pentru a cunoaște informațiile de referință la port pentru firewall-ul și cerințele de acces, consultați Informații de referință port pentru Cisco Webex Calling.
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 semnat de un CA menționat în Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platforme Cisco Webex audio și video?
-
Încărcați pachetul de încredere menționat în Ce autorități de certificare rădăcină sunt acceptate pentru apelurile către platforme Cisco Webex audio și video? Să trecem la Cube.
-
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