Risoluzione dei problemi relativi alle operazioni da eseguire quando CUBE non viene individuato come elemento di bordo in APC

Introduzione

In questo documento viene descritto come risolvere i problemi quando Cisco Unified Border Element (CUBE) non viene rilevato come Border Element in Prime Collaboration Assurance (PCA).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• APC
• Cisco Unified Communications Manager (CUCM)
• CUBO

Componenti usati

Le informazioni fornite in questo documento si basano su Prime Collaboration Assurance.

  

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Passi da seguire se CUBE non viene individuato come elemento di bordo in APC

Per identificare un CUBO come elemento di confine nell'APC:

1. r. Distribuzione non CUCM: Tali condizioni dovrebbero essere soddisfatte:

Condizione 1: Il modello di dispositivo deve essere incluso nell'elenco delle piattaforme supportate (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - Tabella 2.

Condizione 2: SIP-UA-MIB deve restituire un valore diverso da noThisObject / noThatInstance per SipCfgPeerTable.

1. b. Distribuzione CUCM: Tali condizioni dovrebbero essere soddisfatte:

Condizione 1: Il modello di dispositivo deve essere incluso nell'elenco delle piattaforme supportate (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - Tabella 2.

Condizione 2: SIP-UA-MIB deve restituire un valore diverso da noThisObject / noThatInstance per SipCfgPeerTable.

Condizione 3: L'indirizzo IP del dispositivo deve essere associato al trunk SIP di uno dei CUCM.

Per identificare un dispositivo come CUBE SP, occorre prima identificarlo come CUBE e rispondere a CISCO_SESS_BORDER_CTRLR_CALL_STATS_MIB.csbSIPMthdCurrentStatsAdjName (1.3.6.1.4.1.9.9.757.1.3.1.1)

Se queste condizioni sono soddisfatte e ancora PCA non identifica il dispositivo come elemento bordo, verificare se la configurazione su CUCM e dispositivo.

Il lato CUBE dell'integrazione CUCM-CUBE

Quando si configura un CUBE per la prima volta, è necessario abilitare il router per instradare le chiamate come un CUBE. L'immagine mostra una configurazione VoIP di base del servizio vocale su un CUBE:

Di seguito sono riportati alcuni punti importanti relativi a questa configurazione:

• La prima riga della configurazione è mode border-element, che abilita CUBE su un router. Alcuni dispositivi non dispongono di questa configurazione quando funzionano come CUBE.
• Allow-connections sip to sip consente al CUBE di accettare le chiamate SIP (Session Initiation Protocol) e di instradarle come chiamate SIP. Ci sono anche opzioni per H323.
• Il protocollo fax t38 è una configurazione predefinita per i router ISR G2. Non è necessario per la configurazione CUBE.
• L'offerta anticipata forzata consente a CUBE di instradare le chiamate in uno scenario di offerta ritardata a offerta anticipata. Quasi tutti i provider richiedono chiamate SIP per offerta anticipata. Si consiglia di inviare un'Offerta tempestiva da CUCM per evitare problemi relativi ai media tempestivi.
• La passthru di segnalazione delle chiamate intermedie è solo per le chiamate da SIP a SIP. Per funzionare sono necessari alcuni servizi supplementari.
• G729 attachb-all è ottimale nei casi in cui CUBE negozia con i provider che non seguono il formato RFC per i codec G729r8 e G729br8.

Configurazione Dial-Peer su CUBE

I dial-peer su CUBE sono simili agli altri dial-peer sui gateway Cisco IOS. La differenza è che le chiamate vengono indirizzate da un dial-peer VoIP a un altro dial-peer VoIP.

Si noti che in questo caso sono presenti due dial-peer: in entrata e in uscita. CUBE corrisponde sempre a due dial-peer. I dial-peer in arrivo vengono dalla prospettiva CUBE, sia da CUCM che dal provider SIP. I dial-peer in uscita vengono inviati al CUCM o al provider SIP.

ICisco consiglia di eseguire la maggior parte della manipolazione delle cifre su CUCM tramite cifre significative, maschera del numero di telefono esterno e traduzioni.

Per ulteriori informazioni sui dial-peer, consultare l'articolo Comprensione della corrispondenza dei peer di composizione in entrata e in uscita sulle piattaforme IOS.

La manipolazione della cifra può essere eseguita su CUBE allo stesso modo in cui viene eseguita sui Cisco IOS Voice Gateway. Per ulteriori informazioni, fare riferimento all'articolo Traduzione del numero tramite profili di traduzione vocale.

Indirizzamento IP di base

L'indirizzamento IP su CUBE viene eseguito allo stesso modo che su altri dispositivi Cisco IOS, ma utilizza la tabella di routing per determinare da quale interfaccia il traffico SIP proviene il CUBE. Il comando show ip route A.B.C.D fornisce informazioni sull'interfaccia usata dal CUBE per originare il traffico SIP. Questo è importante quando si inviano chiamate a CUCM e quando si inviano chiamate a un provider SIP. Per eseguire questa operazione potrebbero essere necessari percorsi statici.

In alcuni casi, potrebbe essere necessario associare il SIP a un'interfaccia specifica, ad esempio un'interfaccia di loopback sul CUBE. Il binding SIP può causare effetti collaterali, ad esempio quando il CUBE non è in ascolto del traffico SIP su un'interfaccia specifica. Cisco consiglia di non utilizzare i binding e lasciare decidere alla tabella di routing, ma questa operazione non è sempre possibile. È possibile applicare i binding SIP in Voice Service VoIP > SIP o su singoli dial-peer. Per ulteriori informazioni sui binding SIP, vedere l'articolo Configurazione delle funzionalità di binding SIP.

Codec classe voce su CUBE

I codec di classe vocale vengono utilizzati per CUBE per offrire più codec quando le chiamate utilizzano un particolare dial-peer VoIP. Questo è lo stesso di Cisco IOS Voice Gateway, ma quando è un CUBE, i codec vengono filtrati da una tappa di chiamata VoIP all'altra. Utilizza codec disponibili sia sul dial-peer in ingresso che su quello in uscita. I codec corrispondenti a entrambi vengono inviati tramite offerte. Quando CUBE riceve un messaggio SIP con Session Description Protocol (SDP), lo confronta anche con i codec della classe voce. Questo consente a CUBE di filtrare i codec in base a quanto ricevuto dal messaggio SIP con SDP, il dial-peer in entrata e il dial-peer in uscita. L'altro agente utente SIP risponde quindi ai codec offerti.

Il codec di classe vocale nell'immagine precedente contiene tre codec, g729r8, g711ulaw, o g711alaw. Nell'immagine vengono mostrati nell'ordine in cui il gateway Cisco IOS assegna la priorità ai codec offerti all'estremità remota.  I codec di classe voce vengono applicati ai peer di composizione.

Il lato CUCM dell'integrazione da CUCM a CUBE

1. Per aggiungere il trunk alla configurazione CUCM, passare al seguente percorso:
   
   

2. Selezionare Add New (Aggiungi nuovo) e continuare a configurare il trunk SIP (Session Initiation Protocol) come mostrato di seguito:
   
   

3. Nella pagina di configurazione del trunk, selezionare il pool di dispositivi appropriato che consente le chiamate in entrata verso il server CUCM specifico che accetta le chiamate.
   
   

Dopo aver creato il trunk, verificare che i modelli di route vi accedano correttamente tramite un modello di route SIP o un'impostazione di elenco/gruppo di route.

L'intestazione della deviazione di reindirizzamento può essere selezionata per le chiamate in entrata o in uscita.

Quando i numeri esterni vengono inoltrati alla rete VoIP, i messaggi SIP invitano vengono forniti con informazioni sulla deviazione inoltrate in CUCM. Indica il chiamante di origine. Ad esempio, se un flusso di chiamata è integrato con UC e va nella segreteria telefonica, UC utilizza l'origine di deviazione iniziale (numero inoltrato esterno) come cassetta postale di destinazione. Quindi è possibile che ricevano il messaggio di apertura predefinito invece della casella di posta degli abbonati come previsto. La necessità di richiedere questa operazione per la configurazione dipende dal flusso di chiamate e dai requisiti della topologia.

4. Il profilo SIP per la prima offerta è spesso necessario quando si collega il CUBE a un provider. Se il trunk si connette a un altro dispositivo Cisco, si potrebbe desiderare di non selezionare l'inserimento del protocollo MTP (Media Transport Protocol), in base ai dispositivi più lontani. Nell'immagine è illustrata la posizione del profilo SIP e la posizione in cui selezionare la casella per la prima offerta. 

L'offerta precoce spesso aiuta a risolvere i problemi multimediali che si verificano quando si integrano il server CUCM e CUBE con altri prodotti di terze parti. È inoltre consigliato nell'ambito del progetto SRND (Solution Reference Network Design).

Se il profilo verrà modificato, è sempre consigliabile creare un nuovo profilo da utilizzare al posto del profilo predefinito. 

Nota: Questa casella di controllo viene utilizzata quando gli utenti finali non desiderano utilizzare un MTP a ogni chiamata.

5. Potrebbe essere necessario modificare il protocollo TCP/UDP all'interno del profilo di sicurezza SIP in base al flusso di chiamata. Per apportare questa modifica, selezionare SIP Trunk Security Profiles > Non Secure SIP Trunk Profile:

Le chiamate avranno esito negativo e sono necessarie tracce CUBE/CUCM per capire cosa succede al momento dell'errore, ma questa funzione può essere modificata per confermare che non è la causa del problema. Tuttavia, una volta modificato, è necessario reimpostare/riavviare il trunk per rendere effettiva la modifica.

6. In alcune circostanze, potrebbe essere necessario aggiungere la maschera per il telefono esterno nella configurazione del telefono per consentire la continuazione della chiamata, perché alcune schede di telefonia non consentono alla chiamata di procedere senza la maschera prevista. Per apportare questa modifica, andare alla pagina di configurazione del numero di directory (DN) del telefono del chiamante, apportare la modifica necessaria per la casella e reimpostare/riavviare il telefono dopo il salvataggio delle modifiche.
   
   

Una volta eseguita la configurazione su CUCM, avviare l'individuazione del cluster su PCA.

Il dispositivo verrà ora individuato come elemento di bordo in PCA.