Esempio di configurazione dell'integrazione da CUCM a CUBE

Introduzione

Questo documento descrive i principi di base della configurazione di Cisco Unified Border Element (CUBE) con Cisco Unified Communications Manager (CUCM).

Prerequisiti

Requisiti

Cisco consiglia di non configurare il DNS (Domain Name System) e di conoscere i seguenti argomenti:

• da CUCM versione 8.6 a versione 10.x
• Cisco IOS^® versione 15.1(2)T e successive

Nota: Gli indirizzi IP variano a seconda degli schemi di indirizzamento nella rete.

Componenti usati

Le informazioni di questo documento si basano sul fatto che qualsiasi numero di server CUCM, qualsiasi Cisco Integrated Services Router (ISR), ISR Generation 2 (G2) o Cisco Aggregation Services Router (ASR) può essere un CUBE. Non sono richiesti DSP (Digital Signal Processor) per il funzionamento CUBE di base.

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.

Configurazione

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.

Applicazione Cisco IOS Toll-Fraud

L'applicazione per la frode dei pedaggi in Cisco IOS è utile perché può impedire l'accesso SIP indesiderato, ma senza una pianificazione adeguata può causare alcuni problemi con il normale funzionamento. L'applicazione per frodi tariffarie in Cisco IOS consente al router di specificare i dispositivi che possono comunicare con esso per effettuare chiamate (H323 o SIP). Gli indirizzi IP utilizzati come destinazioni di sessione sui peer di connessione sono autorizzati automaticamente a inviare chiamate al Cisco IOS Voice Gateway senza ulteriori configurazioni. In genere sono inclusi tutti i provider SIP e i server CUCM dell'ambiente, ma non sempre. In caso contrario, è necessario aggiungerli manualmente al CUBO. È necessario aggiungere solo gli indirizzi di segnalazione, non gli indirizzi multimediali. Per ulteriori informazioni, fare riferimento all'articolo sulla funzionalità di prevenzione delle frodi a livello di pedaggio nella versione 15.1(2)T.

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 procedere con l'impostazione del trunk SIP 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 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 Cisco Unity Connection (UC) e va nella segreteria telefonica, UC utilizza l'origine della 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 durante l'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.
   
   

   

Verifica

Effettuare chiamate di prova per verificare che la configurazione funzioni correttamente. Se le chiamate di test hanno esito negativo, eseguire le tracce dei servizi CUCM o le tracce CUBE dettagliate per comprendere il problema.

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.