Portreferensinformation för brandväggs- och åtkomstkrav finns i Portreferensinformation för Cisco Webex Calling.

Krav för slutpunkter

Webex Calling Edge

Gå igenom dessa steg om du vill göra en SIP-registrering eller ringa ett samtal:

  • Identifiera värdadressen till en SIP-slutpunkt för aktiva Edge-noder.

  • Se till att uppfylla alla förutsättningar som är relaterade till användar- och enhetskonfigurationen.

  • Säkerställ att slutpunkten har en anslutning till ett offentligt nätverk så att tjänstidentifieringen kan starta.

  • Se till att uppfylla förutsättningarna för start (bootstrapping) av slutpunkten med en region- eller datacenterspecifik etableringskonfiguration. Den här konfigurationen hjälper dig att erhålla det relevanta domännamnssuffixet för tjänstidentifiering.

IPv4 kontra IPv6

Enheter kan arbeta i ett enversions- eller dubbelstackläge. Det är konfigurationen som avgör vilka ändringar som görs i det föredragna protokollet och dessa ändringar är inte en del av tjänstidentifieringen.

  • Enkelstackläge – aktiverar endast ett IP-protokoll (till exempel IPv4) och ignorerar de andra protokolladresserna.

  • Dubbelstackläge – väljer en föredragen IP-version genom konfigurationen.

Klienten anser att prioriteten för alla föredragna adresser är lägre än (det vill säga föredras framför) alla IP-adresserna. Om IPv4 föredras prövas alla IPv4-adresser innan en IPv6-adress prövas. Om det inte går att nå någon av adresserna börjar cykeln om igen med den föredragna protokolladressen med lägst prioritet.

En mobilklient som registrerar sig vid mottagandet av ett push-meddelande kan bestämma sig för att optimera läget baserat på tidigare registreringar.

Matchning av värdadress från DNS SRV-adressen

I den slutpunktskonfigurationsfil som erhålls vid etableringen specificerar domänindikatorn det domännamn som ska identifiera Access Edge-tjänsten. Följande är ett exempel på domännamnet:

wxc.edge.bcld.webex.com

Från exemplet kan slutpunkten som utför en DNS SRV-sökning för den här domänen ge ett svar som liknar följande:


# 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.

I detta fall pekar SRV-posten på tre A-poster.


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

I exemplet annonseras alla värdar för kontaktport 5061 med olika vikt och prioritet.

Överväg dessa krav för slutpunkter.

  • En slutpunkt måste använda _sips._tcp(kombination av tjänst och protokoll) som prefix för att utföra en DNS SRV-sökning och hämta en värdadress för initiering av TLS-baserad kommunikation.

  • En slutpunkt måste göra en DNS SRV-sökning efter villkoren som beskrivs i avsnittet Matchning av värdadress från DNS SRV-adressen.

  • En slutpunkt måste använda den värd, port, vikt och prioritet som annonseras för var och en av värdadresserna. Dessutom måste den skapa tillhörighet mellan värd och port när en sockelanslutning skapas under SIP-registreringen.

  • I RFC 2782 beskrivs urvalskriterierna för värdar baserat på prioritet och vikt specifikt för användning av DNS SRV-posten.

Krav för SIP och media

Krav

Beskrivning

Förtroendecertifikat krävs för kryptering med offentlig nyckel

Se artikeln för mer information om Webex-certifikatens signeringsrättighet och vilken rotcertifikatutfärdare som krävs på enheterna

TLS-versionen stöds för säker SIP

TLS 1.2

TLS-chiffrering stöds för säker SIP

TLS_ECDHE_RSA_MED_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_MED_AES_128_GCM_SHA256

TLS_ECDHE_RSA_MED_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_MED_AES_128_CBC_SHA256

TLS_DHE_DSS_MED_AES_128_GCM_SHA256

TLS_DHE_RSA_MED_AES_128_GCM_SHA256

TLS_DHE_RSA_MED_AES_128_CBC_SHA256

TLS_DHE_DSS_MED_AES_128_CBC_SHA256

TLS_ECDH_RSA_MED_AES_128_GCM_SHA256

TLS_ECDH_ECDSA_MED_AES_128_GCM_SHA256

TLS_ECDH_RSA_MED_AES_128_CBC_SHA256

TLS_ECDH_ECDSA_MED_AES_128_CBC_SHA256

SRTP-nycklar stöds för säker media

AES_CM_128_HMAC_SHA1_80

Krav för säker SIP med mTLS (ömsesidig TLS)

Kraven förklaras i detalj här.

Ett signerat certifikat krävs för att auktorisering och autentisering av samtal från trunken ska fungera. Certifikatet måste uppfylla följande krav:

  • Certifikatet måste signeras av en certifikatutfärdare som nämns iVilka rotcertifikatutfärdare stöds vid samtal till Cisco Webex-ljud- och videoplattformar?

  • Överför bunten för betrodd grupp som nämns iVilka rotcertifikatutfärdare stöds vid samtal till Cisco Webex-ljud- och videoplattformar? till CUBE.

  • Certifikatet måste alltid vara giltigt:

    • Signerade certifikat måste alltid ha ett giltigt utgångsdatum.

    • Rotcertifikat eller mellanliggande certifikat måste ha ett giltigt utgångsdatum och får inte återkallas.

    • Certifikaten måste signeras för klient- och serveranvändning.

    • Certifikaten måste innehålla det fullständigt kvalificerade domännamnet (FQDN) som vanligt namn eller ett alternativt ämnesnamn (SAN) i certifikatet med den FQDN som har valts i Control Hub. Till exempel:

      • En trunk som konfigureras från din organisations Control Hub medlondon.lgw.cisco.com:5061 som FQDN måste innehålla london.lgw.cisco.com i certifikatets CN eller SAN.

      • En trunk som konfigureras från din organisations Control Hub med london.lgw.cisco.com som SRV måste innehålla london.lgw.cisco.com i certifikatets CN eller SAN. Posterna som SRV-adressen omvandlar till (CNAME/A-post/IP-adress) är valfria i SAN.

    • Du kan dela certifikat med fler än en lokal gateway, men du måste säkerställa att FQDN-kraven är uppfyllda.

Utanför hanteringsomfånget

Den här artikeln inkluderar inte följande information om nätverkssäkerhet:

  • F5-krav för certifikatutfärdare och chiffreringar

  • Ett HTTP-baserat API för nedladdning av brandväggsregler för Webex.

  • API för en betrodd grupp

  • Brandväggskrav och avstängning av ALG