Grazie per il feedback.

Webex CallingBordo

Per effettuare una registrazione o una chiamata SIP, completi questi passaggi:

• Scopra l'indirizzo host di un endpoint SIP per i nodi Edge attivi.

• Completa tutti i prerequisiti relativi alla configurazione di utenti e dispositivi.

• Assicurarsi che l'endpoint abbia una connettività di rete pubblica per iniziare la scoperta dei servizi.

• Completa i presupposti per il bootstrap dell'endpoint con una configurazione di provisioning specifica per regione o data center. Questa configurazione aiuta a ottenere il suffisso del nome di dominio pertinente per il rilevamento dei servizi.

IPv4 contro IPv6

I dispositivi possono funzionare in modalità a versione singola o dual-stack. È la configurazione che determina le modifiche al protocollo preferito e queste modifiche non fanno parte della scoperta dei servizi.

• Modalità single-stack: abilita solo un protocollo IP (ad esempio, IPv4) e ignora gli altri indirizzi di protocollo.

• Modalità dual-stack: seleziona una versione IP preferita tramite configurazione.

Il cliente ritiene che la priorità per tutti gli indirizzi preferiti sia inferiore (cioè preferita) rispetto a tutti gli indirizzi IP. Se si preferisce IPv4, tutti gli indirizzi IPv4 vengono tentati prima di tentare un indirizzo IPv6. Se tutti gli indirizzi falliscono, il ciclo ricomincia con l'indirizzo di protocollo preferito con la priorità più bassa.

Un client mobile che si registra al ricevimento di una notifica push può decidere di ottimizzare la modalità in base alle registrazioni precedenti.

Risoluzione dell'indirizzo dell'host dall'DNS SRVindirizzo

Nel file di configurazione degli endpoint ottenuto dal provisioning, l'indicatore di dominio specifica il nome di dominio per scoprire il servizio Access Edge. Un esempio di nome di dominio è:

wxc.edge.bcld.webex.com

Dall'esempio, l'endpoint che esegue una DNS SRV ricerca per questo dominio può produrre una risposta simile alla seguente:

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

In questo caso, il record SRV indica 3 record A.

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

Nell'esempio, si dice che tutti gli host contattino la porta 5061 con peso e priorità diversi.

Consideri questi requisiti per gli endpoint.

• Un endpoint deve utilizzare _sips._tcp(combinazione servizio e protocollo) come prefisso per eseguire una DNS SRV ricerca per ottenere l'indirizzo host per avviare una comunicazione basata su TLS.

• Un endpoint deve DNS SRV cercare le condizioni spiegate nella Risoluzione dell'indirizzo dell'host nella sezione DNS SRV indirizzi.

• Un endpoint deve rispettare host, porta, peso e priorità come pubblicizzato per ciascuno degli indirizzi dell'host. Inoltre, deve creare un'affinità tra host e porta quando si crea una connessione socket durante la registrazione SIP.

• Specifici per l'utilizzo del DNS SRV record, i criteri di selezione degli host in base alla priorità e al peso sono spiegati nella RFC 2782.

Requisiti per un SIP sicuro con MTLS (TLS reciproco)

I requisiti sono spiegati in dettaglio qui.

È necessario un certificato firmato per l'autorizzazione e l'autenticazione corrette delle chiamate dal trunk. Il certificato deve soddisfare i seguenti requisiti:

• Il certificato deve essere firmato da una CA menzionata in Quali autorità di certificazione root sono supportate per le chiamate verso piattaforme Cisco Webex audio e video?

• Carica il pacchetto di fiducia menzionato in Quali autorità di certificazione principali sono supportate per le chiamate verso piattaforme Cisco Webex audio e video? sul CUBE.

• Il certificato deve essere sempre valido:

  • I certificati firmati devono sempre avere una scadenza valida.

  • I certificati radice o intermedi devono avere una scadenza valida e non devono essere revocati.

  • Sono supportati i certificati contenenti solo Server Authentication Extended Key Usage (EKU). Webex Callingnon convalida né impone la presenza dell'autenticazione del cliente EKU durante l'istituzione dell'handshake TLS.

    Alcuni Session Border Controller (SBC) di terze parti possono imporre una rigorosa convalida EKU e rifiutare i certificati che non includono l'autenticazione del cliente EKU. In questi casi, si assicuri che l'SBC sia configurato per accettare certificati solo con autenticazione server EKU o per disabilitare la convalida EKU rigorosa (se supportata).

  • I certificati devono contenere il nome di dominio completo (FQDN) come nome comune o nome alternativo del soggetto nel certificato con l' FQDN scelto nel Control Hub. Ad esempio:

    • Un trunk configurato dal Control Hub della sua organizzazione con london.lgw.cisco.com:5061 come FQDN deve contenere london.lgw.cisco.com nel certificato CN o SAN.

    • Un trunk configurato dal Control Hub della sua organizzazione con london.lgw.cisco.com era l'SRV che deve contenere london.lgw.cisco.com nel certificato CN o SAN. I record in cui viene risolto l'indirizzo SRV (record CNAME/A/ Indirizzo IP) sono opzionali in SAN.

  • Può condividere i certificati con più di un Local Gateway, tuttavia, si assicuri che i requisiti FQDN siano soddisfatti.

Fuori dall'ambito

Questo articolo non include le seguenti informazioni relative alla sicurezza della rete:

• Requisiti F5 per CA e cifrari

• Un'API basata su HTTP per scaricare le regole del firewall per Webex.

• API per un pacchetto di fiducia

• Requisiti del firewall e disabilitazione ALG