Grazie per il feedback.

Prendiamo in considerazione un ipotetico partner Webex chiamato TelSP per illustrare i diversi modelli di implementazione che il partner può adottare.

Ecco le specifiche e i requisiti di alto livello di TelSP:

• Il partner prevede di utilizzare sip.telsp.com come dominio di primo livello condiviso tra tutti i clienti che gestiscono.

• Il partner è proprietario di sip.telsp.com e può amministrare l'infrastruttura DNS e le autorità di certificazione, gestire gli indirizzi DNS e firmare i certificati per questo dominio e i suoi sottodomini.

• Il partner può implementare due distinti controller di sessione (fisici o virtuali) come gateway locali per l'accesso PSTN condiviso tra i clienti finali.

• Il partner ha due siti fisici ed entrambi condividono la connettività PSTN:

  • Miami

  • Chicago

• TelSP gestisce i propri gateway locali per conto dei due clienti CuSTA e CuSTB, come vengono indicati di seguito.

Lo scenario desiderato è avere l'origine/terminazione PSTN per entrambi i clienti che utilizzano i gateway di Miami e Chicago forniti dal partner, come mostrato nell'illustrazione:

Esempio di implementazione semplificato

Il seguente esempio semplificato dimostra come l'identità del certificato peer consenta a un singolo certificato di supportare più tronchi di clienti:

• Certificato — sip.telsp.com

• Bauli

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identità con certificato peer — sip.telsp.com

• Risultato

  • Viene utilizzato un certificato unico

  • Sono supportati più gruppi di clienti

Associare la sede del cliente al trunk e al gateway

Le sezioni seguenti forniscono mappature di configurazione dettagliate per la distribuzione sopra descritta.

Webex Callingconsente la creazione di bauli e la condivisione di un baule in più sedi. Quando crea il baule, associa il baule a una posizione.

Per CuSTA, i dettagli del bagagliaio sono i seguenti:

L'illustrazione mostra l'associazione della sede del cliente a Gateway e Trunk for CuSTA:

In questa distribuzione, il trunk associato alla posizione è la connessione PSTN principale per quella posizione. L'altro trunk viene utilizzato come connessione o percorso PSTN secondario per voci specifiche del dial plan. L'implementazione della relazione di connessione PSTN primaria e secondaria avviene tramite un concetto di Route Group. Per i dettagli, consulti la sezione Configurazione dei gateway trunk nella sezione Control Hub.

Per CustB, viene creata una configurazione simile con i seguenti trunk:

L'illustrazione mostra l'associazione della sede del cliente a Gateway and Trunk for CustB:

L'illustrazione mostra una terza località, New York, che può aggiungere in un secondo momento e puntare al trunk trunk_chicago come connessione PSTN principale.

Quando si implementa un gateway locale che condivide più trunk, Cisco impone l'utilizzo di un FQDN univoco per trunk. Vedere Configure-trunks, -route-groups, -and-Dial-Plans-for-Webex-Calling per i dettagli.

L'utilizzo di un indirizzo IP e di una porta nota per trunk è la scelta ideale. Tuttavia, procurarsi un indirizzo IPv4 pubblico può essere difficile per alcuni partner che desiderano utilizzare un indirizzo per gateway per sito.

Quindi legga questi importanti suggerimenti:

• Cisco non impone un indirizzo IP per trunk.

• Un indirizzo trunk può trasformarsi in un indirizzo IP univoco o nell'indirizzo condiviso tra un altro trunk.

• Cisco consiglia di configurare ogni connessione trunk con una combinazione univoca di indirizzo IP e porta sul Local Gateway per i seguenti motivi:

  1. Il mantenimento di collegamenti di connessione TCP separati per trunk supporta la capacità massima di chiamate simultanee per trunk. La condivisione di combinazioni di indirizzi IP e porte tra trunk può influire negativamente sulla capacità di chiamata.

  2. Fornisce isolamento a livello di rete tra i clienti

  3. È tipico dei Session Border Controller riutilizzare la connessione socket TCP effimera a meno che non venga fornito l'isolamento come tenant univoco partizionato da un indirizzo IP o da una porta di ascolto univoca per il tenant.

  4. La connessione o le connessioni per trunk tramite l'isolamento dei tenant offrono un throughput migliore, in particolare in condizioni di rete con elevata perdita di dati. Pertanto il traffico proveniente da un cliente non ha alcun impatto sull'altro.

Indirizzo IP per gateway: configurazione del trunk e consigli

Si riferisca a questi esempi di diversi modelli di pianificazione:

Modello 1: indirizzo IP univoco per trunk

In questo modello, tutti i trunk ospitati da entrambi i gateway si risolvono in un indirizzo IP univoco e ognuno di questi trunk può utilizzare o meno la stessa porta, ma idealmente la stessa porta.

Rappresentare le informazioni in formato tabellare:

In questo stesso modello, il partner può utilizzare un indirizzo SRV. Webex Callingconsente solo «_sips. _tcp» come combinazione di servizio e protocollo per scoprire l'indirizzo peer se si tratta di un record SRV.

Un esempio di come si risolve un record SRV

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modello 2: IP condiviso per gateway, porte di ascolto uniche

In questo modello, tutti i trunk ospitati sul gateway locale di Chicago si risolvono con lo stesso indirizzo IP e tutti i trunk ospitati sul gateway locale di Miami si risolvono in un IP diverso. Tuttavia, quando si utilizza lo stesso IP, ogni trunk è configurato utilizzando un FQDN nell'hub di controllo ed è configurato con una porta univoca.

In questo stesso modello, il partner utilizza un indirizzo SRV. Webex Callingconsente solo «_sips. _tcp» come combinazione di servizio e protocollo per scoprire l'indirizzo peer se si tratta di un record SRV.

Un altro esempio di come si risolve un record SRV è il seguente. In questo esempio, esiste 1 record A per indirizzo IP. Tuttavia, la porta è unica per indirizzo ed è rappresentata da una configurazione DNS specifica che collega un indirizzo SRV alla porta giusta.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

Per i trunk basati su SRV, l'identità del certificato Peer viene inizialmente compilata in base ai valori SRV configurati e può essere personalizzata, in base alle stesse regole di convalida.

Il partner possiede telsp.com e i suoi sottodomini. Pertanto, il server DNS e l'autorità per far firmare i certificati da un'autorità di certificazione approvata sono del partner.

• Cisco Webexsi aspetta che il partner pubblichi l'FQDN o l'indirizzo SRV, inclusi i record A, di pubblico dominio.

• Cisco Webexsi aspetta che il partner utilizzi una delle autorità di certificazione elencate in questo documento.

Quando si configurano i trunk utilizzando FQDN o SRV:

• Ogni trunk deve avere ancora un FQDN univoco per il routing e l'identificazione

• I record DNS (A Record o SRV) devono essere configurati correttamente e risolvibili

• Questi FQDN vengono utilizzati per la segnalazione e il routing. La convalida del certificato viene eseguita rispetto all'identità del certificato Peer configurata, che per impostazione predefinita sono i valori FQDN del trunk ma può essere personalizzata con un'identità condivisa di proprietà del partner.

  Il campo Peer cert identity viene precompilato dal nome di dominio completo principale e può essere sovrascritto con un dominio condiviso di proprietà del partner per utilizzare un unico certificato su più trunk di clienti.

Configurare il Gateway

Usa queste risorse per configurare un gateway locale.

Per configurare Cisco CUBE, utilizzare questa procedura: Configurare Local Gateway su Cisco IOS XE per Webex Calling

Può configurare SBC di terze parti approvati, vedere: Guida introduttiva a Local Gateway

Configurare il gateway ospitato dai partner in conformità con queste linee guida: Inizia con Local Gateway

Impostare ogni baule in base alle istruzioni pertinenti per il dispositivo SBC. Per le istruzioni di Cisco CUBE, vedere: Configurare Local Gateway su Cisco IOS XE per Webex Calling

Configura classi vocali, chiamate peer e gruppi di dialpeer per il traffico in entrata e in uscita per il trunk come da immagine:

Durante il provisioning di un trunk, Control Hub offre un'opzione per configurare l'identità del certificato Peer nella pagina Aggiungi trunk. Questo miglioramento semplifica il flusso di lavoro consentendo ai partner di configurare e riutilizzare un singolo dominio di primo livello in più organizzazioni clienti. Questo approccio elimina la necessità di certificati separati per cliente o trunk, riducendo lo sforzo operativo e semplificando il processo di configurazione.

Quando configura i trunk in Control Hub, definisca un'identità di certificato Peer per consentire l'uso di un unico certificato per il suo dominio di primo livello in tutte le organizzazioni clienti. Si assicuri che il CN o SAN del certificato includa questo dominio di primo livello. Con l'identità del certificato peer, il gateway locale utilizza un singolo certificato il cui CN o SAN contiene il dominio condiviso del partner (ad esempio, sip.telsp.com). I certificati Wildcard (ad esempio, *.sip.telsp.com) non sono supportati. Webex Callingaccetta questo certificato per ogni trunk di clienti configurato esplicitamente con quel valore come identità del certificato Peer. Il certificato deve contenere l'esatto valore di identità del certificato Peer configurato nel suo CN o SAN. Ciò elimina la necessità di configurare certificati o voci CN/SAN separati per gli FQDN dei singoli trunk.

Verifica del dominio e utilizzo dei certificati

È importante capire in che modo la verifica del dominio differisce dall'utilizzo dei certificati:

• Verifica del dominio (per cliente): ogni organizzazione cliente deve verificare in modo indipendente il dominio (ad esempio, sip.telsp.com) aggiungendo un record TXT univoco nel DNS. Ciò garantisce che il partner sia proprietario del dominio e ne previene l'uso non autorizzato.

• Gestione dei certificati (globale): un singolo certificato emesso per il dominio di primo livello del partner può essere condiviso tra tutti i tronchi dei clienti utilizzando l'identità del certificato Peer. Non è necessario mantenere certificati separati per cliente o per trunk.

Comportamento identitario con certificato paritario

L'identità del certificato peer definisce l'identità Webex Calling prevista nel certificato presentato dal gateway locale.

Se configurato:

• Webex Callingconvalida il certificato confrontando l'identità del certificato Peer configurato con il CN o la SAN nel certificato

• Se i valori corrispondono, la connessione TLS è accettata

• Se i valori non corrispondono, la connessione viene rifiutata

Solo i trunk configurati in modo esplicito con l'identità del certificato Peer corrispondente possono autenticarsi.

La sola convalida del certificato non è l'unico controllo eseguito durante l'autenticazione. Oltre a convalidare il certificato CN o SAN rispetto all'identità del certificato Peer configurata, verifica Webex Calling anche che l'FQDN del trunk sia configurato in modo esplicito e associato all'identità del certificato Peer corrispondente in Control Hub.

L'identità del certificato Peer è precompilata a partire dai valori FQDN/SRV del trunk. Se mantiene le impostazioni predefinite, il comportamento esistente dei certificati per trunk rimane invariato. I trunk basati su certificati esistenti continuano a funzionare senza modifiche. Può adottare un'identità peer cert condivisa su trunk nuovi o esistenti secondo i suoi ritmi ed entrambi i modelli possono coesistere.

1. Esempio di configurazione valido:

   • Certificato CN — sip.telsp.com

   • Certificato SAN —custa.sip.telsp.com

   • Identità con certificato peer — custa.sip.telsp.com

   • FQDN del baule — trunk.miami.custa.sip.telsp.com

   Risultato: la connessione ha esito positivo perché l'identità del certificato Peer (custa.sip.telsp.com) corrisponde al valore SAN nel certificato e l'FQDN del trunk (trunk.miami.custa.sip.telsp.com) è un sottodominio dell'identità del certificato Peer configurata.

2. Esempio di errore di connessione:

   • Certificato CN — sip.telsp.com

   • Certificato SAN —custa.sip.telsp.com

   • Identità con certificato peer — custb.sip.telsp.com

   • FQDN del baule — trunk.miami.custb.sip.telsp.com

   Risultato: la connessione non riesce durante l'handshake TLS perché l'identità del certificato Peer (custb.sip.telsp.com) non è presente nel CN o nella SAN del certificato. L'FQDN trunk è correttamente un sottodominio dell'identità del certificato Peer, ma il certificato non riporta tale identità.

3. Esempio di configurazione non valido:

   • Certificato CN — sip.telsp.com

   • Certificato SAN —custa.sip.telsp.com

   • Identità con certificato peer — custa.sip.telsp.com

   • FQDN del baule — trunk.miami.custb.sip.telsp.com

   Risultato: Control Hub rifiuta questa configurazione in fase di salvataggio perché l' FQDN del trunk (trunk.miami.custb.sip.telsp.com) non è uguale o non è un sottodominio dell'identità del certificato Peer configurata (custa.sip.telsp.com).

Dal Partner Hub, può avviare il Control Hub per CuSTA o CuSTB e configurare il gateway. Utilizza questa procedura per configurare per ogni cliente:

1. Crea il trunk: aggiungi un trunk in Calling/Call Routing/Trunk per ogni gateway condiviso del partner. Per configurare un trunk, vedere Configurare i trunk, i gruppi di percorsi e chiamare i piani per Webex Calling

2. Aggiungere un dominio e verificare: aggiungere e verificare il seguente dominio utilizzato per creare un trunk in Gestione/Impostazioni organizzazione/Domini.

   Cliente B	Cliente C
   sip.telsp.com	sip.telsp.com

   Quando si aggiunge un dominio, viene generato un token e inserito nel record TXT del dominio nel server DNS del partner. Questo record consente a Control Hub di verificare che il dominio sia di proprietà del partner. Per i dettagli, veda Gestire i suoi domini

   Il dominio comune viene utilizzato per la verifica di ogni cliente. Tuttavia, poiché questa verifica avviene a livello di organizzazione del cliente, si assicuri che venga generato e utilizzato un token diverso per la verifica su ciascuna organizzazione cliente. Perché un singolo dominio viene utilizzato in tutte le organizzazioni clienti e ogni organizzazione cliente deve verificare in modo indipendente il dominio utilizzando un record TXT univoco, anche quando condivide lo stesso dominio.

   È richiesta solo la verifica del dominio per l'identità del certificato peer. Non rivendichi il dominio condiviso a un'organizzazione clienti. Un dominio può essere richiesto da una sola organizzazione, mentre lo stesso dominio può essere verificato in più organizzazioni.

3. Configura l'indirizzo SBC con FQDN—

   Per il gateway di Miami:

   Parametro	Cliente B	Cliente C
   Ubicazione	Denver	Boston
   Nome del baule	baulo_miami	baulo_miami
   Tipo di baule	Basato su un certificato	Basato su un certificato
   Tipo di dispositivo	ad es. Cisco Unified Border Element(o un altro dispositivo supportato)	ad es. Cisco Unified Border Element(o un altro dispositivo supportato)
   Tipo di indirizzo SBC	FQDN	FQDN
   Nome host	lgw.miami	lgw.miami
   Dominio	sip.telsp.com	sip.telsp.com
   Porto	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com: 5061	lgw.miami.customerc.sip.telsp.com: 5062
   Numero massimo di chiamate simultanee (250-6500)	500	500

   Per il Chicago Gateway:

   Parametro	Cliente B	Cliente C
   Ubicazione	Detroit	Dallas
   Nome del baule	trunk_chicago	trunk_chicago
   Tipo di baule	Basato su un certificato	Basato su un certificato
   Tipo di dispositivo	ad es. Cisco Unified Border Element(o un altro dispositivo supportato)	ad es. Cisco Unified Border Element(o un altro dispositivo supportato)
   Tipo di indirizzo SBC	FQDN	FQDN
   Nome host	lgw.chicago	lgw.chicago
   Dominio	sip.telsp.com	sip.telsp.com
   Porto	5061	5062
   FQDN	lgw.chicago.customerb.sip.telsp.com: 5061	lgw.chicago.customerc.sip.telsp.com: 5062
   Numero massimo di chiamate simultanee (250-6500)	500	500

   • (Facoltativo) I nomi dei trunk non devono essere univoci tra le organizzazioni clienti. Riutilizzare lo stesso nome (ad esempio, trunk_miami) rende il baule più facile da tracciare.

   • Alcuni SBC consentono di configurare la stessa porta, ma questa configurazione può influire sulla capacità. Pertanto, utilizzi porte diverse.

4. Identità con certificato peer—

   • Prefisso: il prefisso è facoltativo. Lasciare vuoto per impostare l'identità del certificato Peer solo sul dominio. Questo è il modello di certificato condiviso utilizzato in questo articolo (Peer cert identity—sip.telsp.com, che copre tutti i gruppi di clienti). Facoltativamente, inserisca un prefisso per definire un'identità del certificato più specifica (ad esempio, prefisso: customerB, Dominio: customerB.sip.telsp.com per un certificato per cliente). L'FQDN del trunk stesso rimane definito dai campi dell'indirizzo SBC, del nome host e del dominio e deve essere uguale o un sottodominio dell'identità del certificato Peer risultante.

     Esempio:

     Prefisso: cliente B

     Dominio — sip.telsp.com

     Risultato — customerb.sip.telsp.com

   • Dominio: Seleziona un dominio dall'elenco dei domini verificati nell' organizzazione del cliente. L'identità del certificato Peer risultante (prefisso + dominio) deve corrispondere al CN o SAN del certificato presentato dal suo SBC. Webex Callingutilizza questo valore per autenticare la connessione TLS.

     

     Control Hub rifiuta questa configurazione in fase di salvataggio perché l'FQDN del trunk non è sotto l'identità del certificato Peer configurato.

     Se l'identità del certificato Peer non corrisponde al CN o alla SAN nel certificato presentato dall'SBC, Webex Calling rifiuta la connessione TLS e il trunk non riesce a stabilirsi.

5. Uso di Trunks: scelga una posizione arbitraria per il baule, a causa di quanto segue:

   • Qualsiasi sede può utilizzare il trunk in una connessione PSTN.

   • Può accedere al tronco tramite un gruppo di itinerari.

   • Qualsiasi piano telefonico può utilizzare il baule.

6. Vedi le definizioni dei tronchi con le relative ubicazioni:

   

   Può usare questi trunk per creare gruppi di itinerari. Nell'immagine, è definito un gruppo di rotte rg_miami_chicago che indirizza le chiamate al trunk trunk_miami come opzione principale e al trunk trunk_chicago come opzione secondaria.

   

   Può definire un secondo gruppo di rotte rg_chicago_miami che instrada le chiamate al trunk trunk_chicago come opzione principale e al trunk trunk_miami come opzione secondaria.

7. I trunk e i gruppi di rotte definiti sono ora disponibili nell'opzione PSTN di Calling Connection per ogni sede. Nell'immagine, veda la sede di Denver.

   

8. Può utilizzare i tronchi e i gruppi di itinerari nella definizione del piano di chiamata. Ad esempio, un intervallo di numeri locale a Chicago per il cliente è suddiviso in modo da terminare nel gruppo di rotte rg_chicago_miami (per tutte le sedi) nell'immagine:

   

   

Fornitura su larga scala con API

I partner che gestiscono un gran numero di organizzazioni clienti possono fornire domini su larga scala utilizzando le API anziché l'interfaccia utente.

• Verifica il dominio

• Routing delle chiamate