Denne artikkelen er ment for nettverksadministratorer, spesielt sikkerhetsadministratorer for brannmur og proxy som ønsker å bruke Webex Calling i organisasjonen.
Informasjon om portreferanse for brannmur- og tilgjengelighetskrav finnes i Portreferanseinformasjon for Cisco Webex Calling.
Krav til endepunkter
Webex Calling Edge
Følg denne fremgangsmåten for å foreta en SIP-registrering eller et anrop:
Oppdag vertsadressen for et SIP-endepunkt for aktive Edge-noder.
Fullfør eventuelle betingelser knyttet til bruker- og enhetskonfigurasjon.
Kontroller at endepunktet har offentlig nettverkstilkobling for å starte tjenestesøk.
Fullfør betingelsene for oppstart av endepunktet med område- eller datasenterspesifikk klargjøringskonfigurasjon. Denne konfigurasjonen hjelper deg med å hente det relevante domenenavnet for tjenestesøk.
IPv4 vs. IPv6
Enheter kan fungere i enkeltversjons- eller dobbelstakkmodus. Det er konfigurasjonen som bestemmer endringene i den foretrukne protokollen, og disse endringene er ikke del av tjenestesøk.
Enkeltstakkmodus – aktiverer bare én IP-protokoll (f.eks. IPv4) og ignorerer de andre protokolladressene.
Dobbeltstakkmodus – velger en foretrukket IP-versjon gjennom konfigurasjonen.
Klienten vurderer prioriteten for alle foretrukne adresser som lavere (dvs. foretrukket) enn alle adressene til IP-en. Hvis IPv4 er foretrukket, forsøkes alle IPv4-adresser før en IPv6-adresse forsøkes. Hvis alle adresser mislykkes, starter syklusen på nytt med den foretrukne protokolladressen med lavest prioritet.
En mobilklient som registrerer seg ved mottak av et push-varsel, kan velge å optimalisere modusen basert på tidligere registreringer.
Løsning av vertsadresse fra DNS SRV-adresse
I konfigurasjonsfilen for endepunkter som ble hentet fra klargjøringen, angir domeneindikatoren domenenavnet som skal oppdage tjenesten for tilgang til Edge. Et eksempel på domenenavn er:
wxc.edge.bcld.webex.com
Fra eksemplet kan endepunktet som utfører et DNS SRV-oppslag for dette domenet, gi et svar som ligner på det følgende:
# 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 dette tilfellet peker SRV-oppføringen til tre A-oppføringer.
sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com
I eksemplet annonseres alle verter for kontaktport 5061 med forskjellig vekt og prioritet.
Vurder disse kravene for endepunkter.
Et endepunkt må bruke
_sips._tcp
(tjeneste- og protokollkombinasjon) som prefiks for å foreta et DNS SRV-oppslag for å hente vertsadresse for å initiere TLS-basert kommunikasjon.Et endepunkt må foreta et DNS SRV-oppslag for betingelsene som er forklart i delen Løsning av vertsadresse fra DNS SRV-adresse.
Et endepunkt må respektere vert, port, vekt og prioritet som annonsert for hver av vertsadressene. Det må også opprette affinitet fra vert til port ved oppretting av en socket-tilkobling under SIP-registrering.
Valgkriteriene for verter basert på prioritet og vekt spesifikt for bruk av DNS SRV-oppføringen, er forklart i RFC 2782.
Krav til SIP og medier
Krav |
Beskrivelse |
---|---|
Klarert sertifikat kreves for offentlig nøkkelkryptering |
Se artikkelen for informasjon om Webex-sertifikatenes signeringsinstans og påkrevd rotsertifiseringsinstans på enheter |
TLS-versjon støttes for sikker SIP |
TLS 1.2 |
TLS-chiffreringer støttes for sikker 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-nøkler støttes for sikre medier |
AES_CM_128_HMAC_SHA1_80 |
Krav for sikker SIP med mTLS (felles TLS)
Kravene er forklart i detalj her.
Et signert sertifikat kreves for vellykket godkjenning og autentisering av anrop fra trunk. Sertifikatet må oppfylle følgende krav:
Sertifikatet må være signert av en CA som er nevnt i Hvilke rotsertifiseringsinstanser støttes for samtaler til Cisco Webex-lyd- og videoplattformer?
Last opp klareringspakken nevnt i Hvilke rotsertifiseringsinstanser støttes for samtaler til Cisco Webex-lyd- og videoplattformer?, til CUBE.
Sertifikatet skal alltid være gyldig:
Signerte sertifikater må alltid ha gyldig utløpsdato.
Rot- eller mellomsertifikater må ha gyldig utløpsdato og ikke være tilbakekalt.
Sertifikater må være signert for klient- og serverbruk.
Sertifikater må inneholde det fullstendig kvalifiserte domenenavnet (FQDN) som et fellesnavn eller et alternativt emnenavn i sertifikatet med FQDN valgt i Control Hub. For eksempel:
En trunk konfigurert fra organisasjonens Control Hub med london.lgw.cisco.com:5061 som FQDN, må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN.
En trunk konfigurert fra organisasjonens Control Hub med london.lgw.cisco.com som SRV, må inneholde london.lgw.cisco.com i sertifikatets CN eller SAN. Oppføringene som SRV-adressen løser til (CNAME/A-post/IP-adresse), er valgfrie i SAN.
Du kan dele sertifikater med mer enn én lokal gateway, men sørg for at FQDN-kravene er oppfylt.
Ikke inkludert
Denne artikkelen inkluderer ikke den følgende informasjonen knyttet til nettverkssikkerhet:
F5-krav for CA og chiffrering
et HTTP-basert API for nedlasting av brannmurregler for Webex
API for en klareringspakke
brannmurkrav og ALG-deaktivering