Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Configurazione

Considerazioni e limitazioni sulla progettazione del trunk di connessione

Linee guida per la configurazione

Esempio di rete

Configurazioni

Verifica

Risoluzione dei problemi

Comandi per la risoluzione dei problemi

Informazioni correlate

Introduzione

Un trunk (tie-line) è una linea di comunicazione point-to-point permanente tra due porte voce. Il comando connection trunk crea una chiamata Voice over IP (VoIP) permanente tra due gateway VoIP. Simula una connessione trunk tramite la creazione di linee di collegamento trunk virtuali tra due endpoint di telefonia. Ai sistemi collegati, sembra che tra di essi sia collegato direttamente un trunk T1.

Prerequisiti

Requisiti

Queste piattaforme supportano un trunk della connessione VoIP:

- Cisco serie 2600, 3600 e 3700 digital and analog interfaces

- Cisco serie 7200/7500 digital interfaces

- Interfacce digitali e analogiche Cisco MC3810

- Cisco 1750/1751 e 1760

Nota: le piattaforme AS5300/AS5400/AS5800 non supportano e non supportano i trunk di connessione, in quanto non sono adatte per la connettività WAN con volumi di traffico elevato.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

- Software Cisco IOS® versione 12.2(10a) con funzionalità IP Plus

- Cisco serie 2610 Router

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.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Configurazione

In questa sezione vengono presentate le informazioni necessarie per configurare le funzionalità descritte più avanti nel documento.

Nota: per ulteriori informazioni sui comandi menzionati in questo documento, usare lo strumento di ricerca dei comandi (solo utenti registrati)

Considerazioni e limitazioni sulla progettazione del trunk di connessione

- La modalità Connection Trunk è supportata sulle interfacce CAS (Channel Associated Signaling) T1/E1. Un trunk di connessione non è supportato sulle interfacce T1/E1 che utilizzano CCS (Common Channel Signaling); ad esempio, QSIG e PRI Q.931. Un trunk di connessione non è supportato sulle porte Foreign Exchange Office (FXO) configurate per l'avvio da terra.

- La modalità Connection Trunk è una connessione permanente; la chiamata VoIP è sempre connessa indipendentemente dalla porta POTS (Plain Old Telephone Service) che deve essere agganciata o sganciata. Trunk connessione dispone di endpoint configurati in modo statico e non richiede la composizione di chiamate per la connessione di chiamate. Permette inoltre di trasmettere sulla rete IP i segnali di chiamata supplementari, ad esempio hookflash o hoot-n-holler point-to-point tra i due dispositivi di telefonia.

- La modalità Connection Trunk è supportata con le seguenti combinazioni di porte vocali:

- recEive e transMit (E & M) to E & M (stesso tipo)

- FXO su stazione dei cambi (FXS)

- FXS - FXS (senza segnalazione)

Nota: queste combinazioni di porte vocali sono consentite tra interfacce analogiche-analogiche, digitali-digitali e analogiche-digitali. Inoltre, quando si configura da FXS a FXS, la segnalazione non può essere trasmessa perché non sarebbe un percorso trasparente. I dispositivi collegati (FXO) tenterebbero di segnalarsi a vicenda. Se si imposta il percorso vocale in modo che sia sempre aperto, è possibile che questa struttura funzioni. Configurare il segnale di testo di tipo segnale per il peer di connessione VoIP. Il router non attenderà più la segnalazione prima di aprire il percorso vocale.

- Per impostazione predefinita, un mapping da T1 CAS a E1 CAS del trunk di connessione non funziona. È necessario eseguire la manipolazione dell'ordine di bit sui gateway e potrebbe non funzionare sempre, in base al supporto PBX di vari segnali di bit ABCD.

- Un trunk di connessione permette una linea privata, il tipo di funzionalità di ridisconnessione automatica (PLAR-OPX) tra le porte FXO e FXS. Ciò consente alle stazioni remote (collegate alle porte FXS) di apparire al PBX come stazioni fisicamente collegate. Se la stazione remota non risponde a una chiamata, è possibile eseguire il rollover alla segreteria telefonica centralizzata (se configurata sul PBX).

- Il trunk di connessione, ad esempio PLAR, non richiede al router di raccogliere cifre dal dispositivo di telefonia. La chiamata VoIP permanente viene creata quando il router viene avviato e viene stabilita la connettività IP. Per questo motivo, il dial plan del cliente esistente non deve essere modificato.

- Un trunk di connessione può passare alcuni segnali di telefonia, come hookflash, ma non passa segnali PBX proprietari. Non è una funzione CCS trasparente (T-CSS).

- Per ciascuna porta voce viene definito un trunk di connessione, ad esempio PLAR. Ciò significa che la porta vocale non può funzionare sia in modalità Connection Trunk che in modalità Collect Dialed-Digits. L'unico caso in cui questo potrebbe non essere completamente desiderabile sarebbe in un ufficio remoto che deve anche comporre tra estensioni locali senza l'uso di un PBX centralizzato. In questo caso, il percorso della chiamata deve passare attraverso la rete VoIP e tornare indietro, anziché essere commutato all'interno del router. Normalmente, questo non dovrebbe essere un problema.

Linee guida per la configurazione

Il trunk di connessione deve essere configurato su entrambe le estremità del trunk. Quando si configura un trunk di connessione con interfacce analogiche, è necessario definirlo per porta voce. Quando si configura un trunk di connessione con interfacce digitali, sono disponibili diverse opzioni:

- È possibile definire un comando ds0-group separato per ciascun DS0 (ogni slot temporale) e utilizzare il comando connection trunk per definire ciascuna porta vocale creata. In questo modo il mapping da DS0 a DS0 viene mantenuto sui trunk digitali.

- È possibile definire un singolo comando ds0-group per gestire tutti i DS0s ed è possibile definire un singolo comando connection trunk sulla porta voce. Ciò riduce la quantità di configurazione manuale richiesta, ma non vi è alcuna garanzia di mapping uno-a-uno di DS0s su entrambe le estremità del trunk. Inoltre, a ogni ricaricamento del router, il mapping può essere diverso dall'ultimo. Inoltre, questa configurazione complica la risoluzione dei problemi, in quanto non è possibile isolare il problema a una singola (o anche a poche) timeline senza eliminare l'intero gruppo trunk. Questa configurazione non è consigliata anche per T-CCS con segnalazione proprietaria su entrambe le estremità dei PBX, in quanto non fornirebbe il canale di segnalazione in modo affidabile senza mappatura one-on-one.

- Si consiglia di configurare un lato della connessione con la parola chiave answer-mode specificata dopo il comando connection trunk string. Questo rende un lato del bagagliaio il "lato principale". Il gateway (router) con la parola chiave answer-mode è quindi "slave side". Il comando answer-mode specifica che il gateway non tenterà di avviare una connessione trunk, ma attenderà una chiamata in arrivo prima di stabilire il trunk. Questo schema di configurazione riduce al minimo il tempo necessario ai router per attivare i trunk e garantisce che i trunk si disattivino quando le connessioni vengono interrotte tra due gateway. In caso contrario, i gateway potrebbero non tentare di ristabilire il trunk quando la connessione è nuovamente attiva.

Nota: quando si usa il comando connection trunk, è necessario eseguire un comando shutdown/no shutdown sulla porta voce.

Esempio di rete

In questo documento vengono usate due impostazioni di rete:

Il diagramma precedente illustra lo scenario digitale-digitale in cui entrambi i lati del router dispongono di collegamenti digitali.

Il diagramma precedente illustra lo scenario digitale-analogico, con digitale su un'estremità e analogico sull'altra estremità.

Configurazioni

Nel documento vengono usate queste configurazioni:

- Da digitale a digitale

- maui-slt-01

- maui-rtr-07

- Digitale-analogico

- maui-slt-01

- maui-rtr-07

La prima configurazione (da digitale a digitale) mostra una configurazione tipica per un trunk di connessione tra due router con interfacce T1 digitali. In questo esempio, i router sostituiscono la linea di collegamento tra i PBX.

Da digitale a digitale - maui-slt-01

version 12.2

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname maui-slt-01

!

voice-card 1

!

controller T1 1/0

framing esf

linecode b8zs

ds0-group 1 timeslots 1 type e & m-wink-start

ds0-group 2 timeslots 2 type e & m-wink-start

clock source line

!--- The ds0-group command creates the logical voice-ports: !--- voice-port 1/0:1 and voice-port 1/0:2.

!

voice-port 1/0:1

connection trunk 2000

!--- “master side” !--- This starts the trunk connection using digits 2000 to match !--- a VoIP dial-peer. The digits are generated internally by the !--- router and are not received from the voice-port.

!

voice-port 1/0:2

connection trunk 2001

!

dial-peer voice 2 voip

destination-pattern 200.

!--- Matches connection trunk string 2000 and 2001.

dtmf-relay h245-alphanumeric

session target ipv4:192.168.100.2

ip qos dscp cs5 media

!

dial-peer voice 1 pots

destination-pattern 1000

port 1/0:1

!--- This dial-peer maps to maui-rtr-07’s voice-port 1/0:1.

!

dial-peer voice 3 pots

destination-pattern 1001

port 1/0:2

!--- This dial-peer maps to maui-rtr-07’s voice-port 1/0:2.

!

interface Serial0/1

ip address 192.168.100.1 255.255.255.0

Digitale-digitale - maui-rtr-07

version 12.2

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname maui-rtr-07

!

voice-card 1

!

controller T1 1/0

framing esf

linecode b8zs

ds0-group 1 timeslots 1 type e & m-wink-start

ds0-group 2 timeslots 2 type e & m-wink-start

clock source line

!

voice-port 1/0:1

connection trunk 1000 answer-mode

!--- “slave side” !--- The answer-mode specifies that the router should not attempt !--- to initiate a trunk connection, but it should wait for an !--- incoming call before it establishes the trunk.

!

voice-port 1/0:2

connection trunk 1001 answer-mode

!

dial-peer voice 1 voip

destination-pattern 100.

dtmf-relay h245-alphanumeric

session target ipv4:192.168.100.1

ip qos dscp cs5 media

!

dial-peer voice 2 pots

destination-pattern 2000

port 1/0:1

!--- This dial-peer terminates the connection !--- from maui-slt-01 voice-port 1/0:1.

!

dial-peer voice 3 pots

destination-pattern 2001

port 1/0:2

!--- This dial-peer terminates the connection !--- from maui-slt-01 voice-port 1/0:2.

!

interface Serial0/1

ip address 192.168.100.2 255.255.255.0

clockrate 128000

!

La seconda configurazione (da digitale ad analogico) mostra una configurazione tipica per un trunk di connessione tra due router simili, uno con interfacce T1 digitali e l'altro con interfacce analogiche. A tal fine, le interfacce devono essere dello stesso tipo (ad esempio, E & M wink a E & M wink, E & M immediate a E & M immediate, FXO a FXS e viceversa). Nell'esempio, il loopstart FXO sta segnalando sull'interfaccia digitale T1 e ci sono porte FXS analogiche con il segnale loopstart FXS sul lato corrispondente.

Digitale-analogico - maui-slt-01

version 12.2

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname maui-slt-01

!

voice vad-time 40000

!

voice-card 1

!

controller T1 1/0

framing esf

linecode b8zs

ds0-group 1 timeslots 1 type fxo-loopstart

clock source line

!--- The ds0-group command creates the logical voice-ports: !--- voice-port 1/0:1 and voice-port 1/0:2.

!

voice-port 1/0:1

connection trunk 2000

!--- “master side” !--- This starts the trunk connection using digits 2000 to match !--- a VoIP dial-peer. The digits are generated internally by the !--- router and are not received from the voice-port.

!

!

!

dial-peer voice 2 voip

destination-pattern 200.

!--- Matches connection trunk string 2000 and 2001.

dtmf-relay h245-alphanumeric

session target ipv4:192.168.100.2

ip qos dscp cs5 media

!

dial-peer voice 1 pots

destination-pattern 1000

port 1/0:1

!--- This dial-peer maps to maui-rtr-07's voice-port 1/0/0.

!

!

!

interface Serial0/1

ip address 192.168.100.1 255.255.255.0

!

Digitale-analogico - maui-rtr-07

version 12.2

service timestamps debug uptime

service timestamps log uptime

service password-encryption

!

hostname maui-rtr-07

!

!

voice-port 1/0/0

connection trunk 1000 answer-mode

!--- “slave side” !--- The answer-mode specifies that the router should not attempt !--- to initiate a trunk connection, but it should wait for an !--- incoming call before it establishes the trunk.

!

!

dial-peer voice 1 voip

destination-pattern 100.

dtmf-relay h245-alphanumeric

session target ipv4:192.168.100.1

ip qos dscp cs5 media

!

dial-peer voice 2 pots

destination-pattern 2000

port 1/0/0

!--- This dial-peer terminates the connection !--- from maui-slt-01 voice-port 1/0:1.

!

!

!

interface Serial0/1

ip address 192.168.100.2 255.255.255.0

clockrate 128000

!

Verifica

Le informazioni contenute in questa sezione permettono di verificare che la configurazione funzioni correttamente.

Alcuni comandi show sono supportati dallo strumento Output Interpreter (solo utenti registrati); lo strumento permette di visualizzare un'analisi dell'output del comando show.

- show voice call summary: utilizzato per verificare che tutti i trunk siano attivi e nello stato S_CONNECT.

Quando i trunk vengono attivati, sulla console viene visualizzato il messaggio %HTSP-5-UPDOWN: La porta trunk (canale) [1/0:1(1)] è attiva.

Di seguito viene riportato un esempio di output del comando show voice call summary:

PORT         CODEC    VAD VTSP STATE            VPM STATE

============ ======== === ==================== ======================

3/0:0.1       g729r8    n  S_CONNECT             S_TRUNKED

3/0:1.2       g729r8    n  S_CONNECT             S_TRUNKED

3/0:2.3       g729r8    n  S_CONNECT             S_TRUNKED

Un trunk non attivo verrà visualizzato come S_TRUNK_PEND:

PORT         CODEC    VAD VTSP STATE            VPM STATE

============ ======== === ==================== ======================

3/0:0.1       -             -      -             S_TRUNK_PEND

3/0:1.2       g729r8    n  S_CONNECT             S_TRUNKED

3/0:2.3       g729r8    n  S_CONNECT             S_TRUNKED

Risoluzione dei problemi

Le informazioni contenute in questa sezione permettono di risolvere i problemi relativi alla configurazione.

Comandi per la risoluzione dei problemi

Alcuni comandi show sono supportati dallo strumento Output Interpreter (solo utenti registrati); lo strumento permette di visualizzare un'analisi dell'output del comando show.

Nota: prima di usare i comandi di debug, consultare le informazioni importanti sui comandi di debug.

- mostra voce cronologia chiamate | Include DisconnectText: visualizza il motivo di disconnessione per le ultime chiamate non riuscite.

- show voice call summary: visualizza la chiamata attiva su entrambe le gambe di chiamata.

- show voice dsp: visualizza che i DSP (Digital Signal Processor) sono in uso e stanno elaborando i pacchetti.

Per ulteriori informazioni sulla risoluzione dei problemi relativi alle chiamate VoIP, consultare il documento sulla risoluzione dei problemi e il debug delle nozioni di base sulle chiamate VoIP e i comandi di debug VoIP.

Le porte vocali associate su entrambi i router devono essere shutdown/no shutdown dopo aver configurato il trunk di connessione. Se l'utente è occupato come causa di disconnessione, le porte vocali vengono cancellate.

In questo esempio, i risultati restituiti dal comando show voice dsp sono:

BOOT                     PAK

TYPE DSP CH CODEC   VERS STATE STATE  RST AI PORT    TS ABORT   TX/RX-PAK-CNT

==== === == ======= ==== ===== ====== === == ======= == ===== ===============

C549 000 01 g729r8   3.4 busy  idle     0  0 3/0:12  13     0 3522765/3578769

00 g729r8   .41 busy  idle     0  0 3/0:0    1     0 3505023/3560759

C549 001 01 g729r8   3.4 busy  idle     0  0 3/0:13  14     0 3522761/3578601

00 g729r8   .41 busy  idle     0  0 3/0:1    2     0 3522794/3578579

L'output di esempio successivo è l'output di debug più comune per il comando debug voip capi inout. Questo debug è stato eseguito in seguito all'errore comune di un peer POTS mancante sul lato chiamato. Nell'esempio, il router laterale analogico non ha un peer POTS per terminare il trunk; il lato chiamata digitale avrà questi debug in questa situazione:

maui-slt-01#

*Mar  1 00:11:19.903: cc_api_call_setup_ind (vdbPtr=0x620B2DE8,

callInfo={called=2000,called_oct3=0x81,calling=,calling_oct3=0x0,

calling_oct3a=0x0,calling_xlated=false,subscriber_type_str=RegularLine

,fdest=1,peer_tag=2, prog_ind=3},callID=0x621C45F0)

*Mar  1 00:11:19.903: cc_api_call_setup_ind type 3 , prot 0

*Mar  1 00:11:19.903: cc_process_call_setup_ind (event=0x62332908)

*Mar  1 00:11:19.903: >>>>CCAPI handed cid 3 with tag 2 to app "DEFAULT"

*Mar  1 00:11:19.907: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(3), disp(0)

*Mar  1 00:11:19.907: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(3), disp(0)

*Mar  1 00:11:19.907: ssaCallSetupInd

*Mar  1 00:11:19.907: ccCallSetContext (callID=0x3, context=0x621C4E90)

*Mar  1 00:11:19.907: ssaCallSetupInd cid(3), st(SSA_CS_MAPPING),oldst(0),

ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1

*Mar  1 00:11:19.907: ssaCallSetupInd finalDest cllng(1000), clled(2000)

*Mar  1 00:11:19.907: ssaCallSetupInd cid(3), st(SSA_CS_CALL_SETTING),

oldst(0), ev(24)dpMatchPeersMoreArg result= 0

*Mar  1 00:11:19.907: ssaSetupPeer cid(3) peer list:

tag(1) called number (2000)

*Mar  1 00:11:19.907: ssaSetupPeer cid(3), destPat(2000), matched(1),

prefix(), peer(61EE565C), peer->encapType (2)

*Mar  1 00:11:19.907: ccCallProceeding (callID=0x3, prog_ind=0x0)

*Mar  1 00:11:19.907: ccCallSetupRequest (Inbound call = 0x3, outbound

peer =1, dest=, params=0x6233BD30 mode=0, *callID=0x6233C098, prog_ind = 3)

*Mar  1 00:11:19.907: ccCallSetupRequest numbering_type 0x81

*Mar  1 00:11:19.907: ccCallSetupRequest encapType 2 clid_restrict_disable 1

null_orig_clg 1 clid_transparent 0 callingNumber 1000

*Mar 1 00:11:19.907: dest pattern 2..., called 2000, digit_strip 0

*Mar 1 00:11:19.907: callingNumber=1000, calledNumber=2000, redirectNumber=

display_info= calling_oct3a=0

*Mar 1 00:11:19.907: accountNumber=, finalDestFlag=1,

guid=1d0d.9a0f.14f0.11cc.8008.b3df.433e.6402

*Mar 1 00:11:19.911: peer_tag=1

*Mar 1 00:11:19.911: ccIFCallSetupRequestPrivate: (vdbPtr=0x621D74DC, dest=,

callParams={called=2000,called_oct3=0x81, calling=1000,calling_oct3=0x0,

calling_xlated=false, subscriber_type_str=RegularLine, fdest=1,

voice_peer_tag=1}, mode=0x0) vdbPtr type = 1

*Mar 1 00:11:19.911: ccIFCallSetupRequestPrivate: (vdbPtr=0x621D74DC, dest=,

callParams={called=2000, called_oct3 0x81, calling=1000,calling_oct3 0x0,

calling_xlated=false, fdest=1, voice_peer_tag=1}, mode=0x0, xltrc=-5)

*Mar 1 00:11:19.911: ccSaveDialpeerTag (callID=0x3, dialpeer_tag=0x1)

*Mar 1 00:11:19.911: ccCallSetContext (callID=0x4, context=0x624C3094)

*Mar 1 00:11:19.911: ccCallReportDigits (callID=0x3, enable=0x0)

*Mar 1 00:11:19.911: cc_api_call_report_digits_done (vdbPtr=0x620B2DE8,

callID=0x3, disp=0)

*Mar 1 00:11:19.911: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),

cid(3), disp(0)

*Mar 1 00:11:19.911: cid(3)st(SSA_CS_CALL_SETTING)ev

(SSA_EV_CALL_REPORT_DIGITS_DONE)oldst(SSA_CS_MAPPING)

cfid(-1)csize(0)in(1)fDest(1)

*Mar 1 00:11:19.911: -cid2(4)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)

*Mar 1 00:11:19.911: ssaReportDigitsDone cid(3) peer list: (empty)

*Mar 1 00:11:19.911: ssaReportDigitsDone callid=3 Reporting disabled.

*Mar 1 00:11:19.947: cc_api_call_disconnected(vdbPtr=0x621D74DC,

callID=0x4, cause=0x1)

*Mar 1 00:11:19.947: sess_appl: ev(11=CC_EV_CALL_DISCONNECTED), cid(4), disp(0)

*Mar 1 00:11:19.947: cid(4)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_DISCONNECTED)

oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(0)fDest(0)

*Mar 1 00:11:19.947: -cid2(3)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)

*Mar 1 00:11:19.951: ssaDiscSetting

*Mar 1 00:11:19.951: ssa: Disconnected cid(4) state(1) cause(0x1)

*Mar 1 00:11:19.951: ccCallDisconnect (callID=0x4, cause=0x1 tag=0x0)

*Mar 1 00:11:19.951: ccCallDisconnect (callID=0x3, cause=0x1 tag=0x0)

*Mar 1 00:11:19.951: cc_api_call_disconnect_done(vdbPtr=0x620B2DE8, callID=0x3,

disp=0, tag=0x0)

*Mar 1 00:11:19.955: sess_appl: ev(12=CC_EV_CALL_DISCONNECT_DONE), cid(3),

disp(0)

*Mar 1 00:11:19.955: cid(3)st(SSA_CS_DISCONNECTING)ev

(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_CALL_SETTING)

cfid(-1)csize(0)in(1)fDest(1)

*Mar 1 00:11:19.955: -cid2(4)st2(SSA_CS_DISCONNECTING)oldst2(SSA_CS_CALL_SETTING)

*Mar 1 00:11:19.955: ssaDisconnectDone

*Mar 1 00:11:19.963: cc_api_icpif: expect factor = 0

*Mar 1 00:11:19.963: cc_api_call_disconnect_done(vdbPtr=0x621D74DC,

callID=0x4, disp=0, tag=0x0)

*Mar 1 00:11:19.967: sess_appl: ev(12=CC_EV_CALL_DISCONNECT_DONE),

cid(4), disp(0)

*Mar 1 00:11:19.967: cid(4)st(SSA_CS_DISCONNECTING)ev

(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_CALL_SETTING)

cfid(-1)csize(1)in(0)fDest(0)

*Mar 1 00:11:19.967: ssaDisconnectDone

Informazioni correlate

- Configurazione del PLAR di connessione per gateway VoIP

- Nozioni di base sulla risoluzione dei problemi e il debug delle chiamate VoIP

- Comandi di debug VoIP

- Supporto alla tecnologia vocale

- Supporto dei prodotti per le comunicazioni voce e IP

- Risoluzione dei problemi di Cisco IP Telephony

- Supporto tecnico – Cisco Systems