Risoluzione dei problemi dei trunk di connessione vocale

Opzioni per il download

  • PDF     (212.9 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (91.1 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (84.3 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:2 febbraio 2006
ID documento:23443

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Introduzione

I trunk della connessione vocale stabiliscono in modo permanente le chiamate vocali, o Voice over IP (VoIP), Voice over Frame Relay (VoFR) o Voice over ATM (VoATM). Le chiamate vengono stabilite non appena il router viene acceso e la configurazione è completata. Non appena le porte vocali sono accese, le porte vocali compongono automaticamente il numero di telefono fittizio specificato sotto la porta vocale e chiamano la località. Le porte vocali completano la chiamata all'altra estremità tramite i peer di composizione corrispondenti. Una volta stabilita la connessione, per quanto riguarda il router, la chiamata vocale è in sessione ed è connessa.

Prerequisiti

Requisiti

Non sono previsti prerequisiti specifici per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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 LAN è 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.

Problema

I problemi comuni che riguardano i trunk sono trasparenti per il router e molto difficili da risolvere. I problemi comuni osservati con i tronchi vocali si manifestano quando si fa una chiamata sui tronchi e non si sente nulla. Questo è uno dei problemi noti con i trunk di connessione ed è causato da molti problemi diversi. Un altro problema è rappresentato dai toni DTMF (Dual Tone Multifrequency) che non vengono passati correttamente e la segnalazione da PBX (Private Branch Exchange) a PBX non viene trasportata correttamente. In questo documento vengono risolti questi problemi.

Quando i camion voce sono attivi, i segnali si comportano in modo diverso nei camion di connessione. I comandi che normalmente vengono emessi dalla porta voce per le caratteristiche di segnalazione non sono pertinenti e utili. Il trunk vocale diventa un condotto di segnalazione e trasmette il segnale attraverso il collegamento VoIP. Quando si utilizzano i trunk voce, la segnalazione PBX deve corrispondere da un'estremità all'altra. Per quanto riguarda le due macchine PBX, l'obiettivo è quello di rendere la connessione voice trunk identica a una linea T1 in leasing verso il PBX, con i router completamente trasparenti mentre viene stabilito un chiaro collegamento tra i due PBX nell'intero processo.

Quando il trunk si solleva, il trunk diventa un cavo software e il tipo di segnale è considerato un tipo di connettore. Al trunk non interessa il tipo di segnale utilizzato. Il trunk continua a salire anche se il segnale non corrisponde su entrambe le estremità. Finché i PBX a entrambe le estremità effettuano la stessa segnalazione, i trunk funzionano correttamente.

Soluzione

L'approccio da adottare per la risoluzione dei problemi relativi al trunk della connessione è diverso da quello utilizzato per le chiamate commutate. Per vedere cosa succede veramente dopo che i trunk sono verificati, è necessario guardare la segnalazione PBX. Prima di procedere con l'analisi del segnale, verificare che i trunk siano attivi e che i DSP (Digital Signal Processor) elaborino i pacchetti voce.

Nota: probabilmente si desidera disabilitare il rilevamento attività voce (VAD) per risolvere il problema. Una volta verificato che i trunk funzionano correttamente, è necessario controllare la segnalazione telefonica per risolvere ulteriormente il problema.

Se i trunk vengono stabiliti e nessuno tenta di effettuare una chiamata, i messaggi trunk keepalive vengono inviati avanti e indietro tra le caselle remote. I pacchetti keepalive verificano la connettività del trunk e trasportano le informazioni di segnalazione da un'estremità all'altra. Per verificare i pacchetti keepalive, usare il comando debug vpm signal. Se sono presenti molti trunk, ossia l'output dei comandi debug vpm, è possibile limitare l'output a una singola porta usando l'opzione del comando debug vpm port x, dove "x" è la porta voce in questione. Di seguito viene riportato l'output del comando debug vpm signal emesso quando si esaminano tutte le porte:

21:18:12: [3/0:10(11)] send to dsp sig DCBA state 0x0
21:18:12: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:18:12: [3/0:12(13)] rcv from dsp SIG DCBA state 0x0
21:18:12: [3/0:20(21)] rcv from dsp SIG DCBA state 0x0
21:18:12: [3/0:12(13)] send to dsp SIG DCBA state 0x0
21:18:12: [3/0:20(21)] send to dsp SIG DCBA state 0x0
21:18:12: [3/0:0(1)] send to dsp SIG DCBA state 0x0
21:18:12: [3/0:3(4)] rcv from dsp SIG DCBA state 0x0
21:18:12: [3/0:9(10)] rcv from dsp SIG DCBA state 0x0
21:18:12: [3/0:3(4)] send to dsp SIG DCBA state 0x0
21:18:13: [3/0:9(10)] send to dsp SIG DCBA state 0x0
21:18:13: [3/0:19(20)] rcv from dsp SIG DCBA state 0x0

Se si limita questo valore, con il comando debug vpm port x è più facile interpretare i debug, come mostrato nell'esempio:

21:21:08: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:21:12: [3/0:0(1)] send to dsp SIG DCBA state 0x0
21:21:13: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:21:17: [3/0:0(1)] send to dsp SIG DCBA state 0x0
21:21:18: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:21:22: [3/0:0(1)] send to dsp SIG DCBA state 0x0
21:21:23: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:21:27: [3/0:0(1)] send to dsp SIG DCBA state 0x0
21:21:28: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
21:21:32: [3/0:0(1)] send to dsp SIG DCBA state 0x0

I pacchetti keepalive vengono inviati e ricevuti ogni cinque secondi. I termini "inviato a dsp" e "ricevuto da dsp" sono dal punto di vista di Cisco IOS®. Sostituire PBX con DSP per renderlo più comprensibile. Questi sono i messaggi che vengono visualizzati quando non c'è attività sui tronchi. I messaggi keepalive comunicano ai router su ciascuna estremità del circuito che i trunk sono ancora attivi. Quando cinque di questi messaggi non vengono visualizzati di seguito, il trunk si blocca. Una delle cause è se i trunk fluttuano costantemente in una rete. Per verificare se i pacchetti vocali trunk keepalive sono inviati e ricevuti, usare il comando debug vpm trunk-sc. Questo debug non genera alcun output finché i pacchetti keepalive del trunk non vengono rilevati. Questo è un esempio di output del comando debug vpm trunk-sc quando i pacchetti keepalive vengono omessi:

22:22:38: 3/0:22(23): lost Keepalive
22:22:38: 3/0:22(23): TRUNK_SC state : TRUNK_SC_CONN_WO_CLASS, event TRUNK_RTC_LOST_KEEPALIVE
22:22:38: 3/0:22(23): trunk_rtc_set_AIS on
22:22:38: 3/0:22(23): trunk_rtc_gen_pattern : SIG pattern 0x0
22:22:38: 3/0:22(23): TRUNK_SC, TRUNK_SC_CONN_WO_CLASS ==> TRUNK_SC_CONN_DEFAULT_IDLE
22:22:39: 3/0:13(14): lost Keepalive
22:22:39: 3/0:13(14): TRUNK_SC state : TRUNK_SC_CONN_WO_CLASS, event TRUNK_RTC_LOST_KEEPALIVE
22:22:39: 3/0:13(14): trunk_rtc_set_AIS on
22:22:39: 3/0:13(14): trunk_rtc_gen_pattern : SIG pattern 0x0
22:22:39: 3/0:13(14): TRUNK_SC, TRUNK_SC_CONN_WO_CLASS ==> TRUNK_SC_CONN_DEFAULT_IDLE

se non viene visualizzato alcun output quando si esegue il comando debug vpm trunk-sc, non viene perso alcun elemento keepalive. Anche se i messaggi keepalive vengono omessi, il trunk rimane attivo fino a cinque messaggi sequenziali. Ciò significa che una connessione deve essere interrotta per 25 secondi prima che i trunk si spengano.

Problemi comuni dei trunk di connessione

Sono presenti diversi bug associati alle connessioni voice trunk. Controlla questi bug se vedi qualcosa di insolito. Al momento del rilascio del software Cisco IOS versione 12.2, la maggior parte di questi problemi era stata risolta e integrata. È possibile analizzare i bug per rendersi conto che queste sono le cause dei problemi del codice meno recente. Uno dei problemi più comuni è ottenere il corretto segnale dei PBX sulla connessione trunk. Sembra una buona idea abbattere i tronchi e configurare i router in modo che funzionino a entrambe le estremità, ma l'approccio è davvero controproducente, poiché tutto ciò che è stato modificato diventa inutile una volta stabiliti i tronchi. Il modo migliore per risolvere il problema è con i tronchi funzionanti.

Inizia la risoluzione dei problemi

È necessario esaminare le basi per stabilire che questi funzionano correttamente:

  • I tronchi sono stati creati? Eseguire il comando show voice call summary e verificare che i trunk siano nello stato S_CONNECTED.

  • I DSP elaborano i pacchetti? Per verificare questa condizione, eseguire il comando show voice dsp. Se non si vede che i pacchetti vengono elaborati dai DSP, è perché il VAD è abilitato e i pacchetti vengono eliminati. Spegnere VAD, ristabilire i trunk e guardare di nuovo. Verificare inoltre che i contatori del pacchetto incrementino quando viene emesso il comando show call active voice brief. Questo comando mostra anche se VAD è abilitato per il log delle chiamate in questione.

Se i trunk vengono collegati a porte analogiche in qualsiasi sito, è consigliabile verificare il funzionamento del PBX in modalità non trunked. Per risolvere i problemi relativi alla connettività analogica di E&M, consultare il documento sulla descrizione e la risoluzione dei problemi relativi ai tipi di interfaccia analogica di E&M e alle configurazioni dei cavi. Una volta verificato che tutto funzioni correttamente, sollevare i trunk e osservare il segnale trasmesso tra i PBX.

Il modo ideale per risolvere i problemi di connessione del trunk vocale è esaminare la segnalazione che viene passata tra i PBX. È meglio stabilire una sessione Telnet con ciascun router in modo che la segnalazione possa essere osservata mentre viene passata da un'estremità all'altra. Questo documento utilizza la segnalazione wink di E&M poiché è piuttosto popolare e la temporizzazione wink deve essere presa in considerazione.

Questo è l'output del router collegato al PBX da cui proviene la chiamata:

May 22 19:39:03.582: [3/0:0(1)] rcv from dsp sig DCBA state 0x0

!--- It is in idle state.

May 22 19:39:07.774: [3/0:0(1)] send to dsp SIG DCBA state 0x0

!--- ABCD bits=0000.

May 22 19:39:08.586: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:12.778: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:13.586: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:17.777: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:18.593: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:22.781: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:23.593: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:27.781: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:28.597: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:32.785: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:33.597: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:37.789: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:38.601: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:39.777: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:39.797: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:39.817: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF

!--- Receives off-hook from PBX, and passes to remote end.

May 22 19:39:39.837: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.857: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.877: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.897: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.917: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.937: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.957: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.977: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:39.997: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.017: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.037: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.057: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.077: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.089: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.097: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.109: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.117: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF

!--- Receiving wink from remote side, and passes to PBX.

May 22 19:39:40.129: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.137: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.149: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.157: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.169: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.177: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.189: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.197: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.213: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.217: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.229: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.237: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.249: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.257: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.269: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.289: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.309: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.329: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.349: [3/0:0(1)] send to dsp SIG DCBA state 0x0

!--- Wink ended from remote side, and passes to PBX.

May 22 19:39:40.369: [3/0:0(1)] send to dsp SIG DCBA state 0x0			
May 22 19:39:40.389: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.409: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.429: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.449: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.469: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.493: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.509: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.529: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.549: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.569: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.589: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.613: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.629: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.649: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.669: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.689: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.709: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.729: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.749: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:40.769: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:45.773: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:50.081: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:50.101: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:50.121: [3/0:0(1)] send to dsp SIG DCBA state 0xF

!--- Wink ends, the remote end is now off-hook, the conversation happens.

May 22 19:39:50.141: [3/0:0(1)] send to dsp SIG DCBA state 0xF		
May 22 19:39:50.161: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.181: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.197: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.221: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.241: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.261: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.261: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.281: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.301: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.321: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.341: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.361: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.381: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.401: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.421: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.441: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.461: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.481: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.501: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.521: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.541: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.561: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:55.265: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:55.561: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:00.269: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:00.565: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:05.268: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:05.564: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:10.272: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:10.568: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:15.276: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:15.572: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:19.676: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:19.696: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:19.716: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.736: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.756: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.776: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.796: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.796: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:19.816: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.816: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:19.836: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.836: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0

!--- Both side hung up, back to idle state.

May 22 19:40:19.856: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.856: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.876: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.876: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.896: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.896: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.916: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.916: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.936: [3/0:0(1)] send to dsp SIG DCBA state 0x0

Questo output visualizza il termine della chiamata da parte del router. Protocollo NTP (Network Time Protocol) sincronizzato.

May 22 19:39:03.582: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:07.774: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0

!--- Idle state, both side on-hook.

May 22 19:39:08.586: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:12.774: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:13.586: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:15.383: [1/0:0(1)] Signaling RTP packet has no particle

!--- You will see this message if you are running Cisco IOS !--- Software Release 12.2(1a) or later. It is not an error !--- message, it is a normal functioning state.

May 22 19:39:17.774: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:18.590: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:22.778: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:23.594: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:27.782: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:28.598: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:32.782: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:33.598: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:37.786: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:38.602: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:39.778: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:39.798: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:39:39.818: [3/0:0(1)] send to dsp SIG DCBA state 0xF

!--- Remote side off-hook, this is conveyed to the PBX.

May 22 19:39:39.838: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.858: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.878: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.898: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.918: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.938: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.958: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.978: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:39.998: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.018: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.038: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.058: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.078: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.090: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.098: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.110: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.118: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.130: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF

!--- Receive wink from PBX.

May 22 19:39:40.138: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.150: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.158: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.170: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.178: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.190: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.198: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.210: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.218: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.230: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.238: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.250: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.258: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:40.270: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.290: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.310: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.330: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:40.350: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0

!--- Wink ended, waiting for an answer.

May 22 19:39:40.370: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.390: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.410: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.430: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.450: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.470: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.490: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.510: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.530: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.550: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.570: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.590: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.610: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.630: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.650: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.670: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.690: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.710: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.730: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.750: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:40.770: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:45.262: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:45.770: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:50.077: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:50.097: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:39:50.117: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF

!--- Receive off-hook from PBX.

May 22 19:39:50.137: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.157: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.177: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.197: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.217: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.237: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.257: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.261: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:50.277: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.297: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.317: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.337: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.357: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.377: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.397: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.417: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.437: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.457: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.477: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.497: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.517: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.537: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:39:50.557: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF

!--- Both sides off-hook, the conversation happens.

May 22 19:39:55.265: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:39:55.557: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:00.269: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:00.561: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:05.269: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:05.561: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:10.273: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:10.565: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:15.273: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:15.569: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:19.673: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:19.693: [3/0:0(1)] rcv from dsp SIG DCBA state 0xF
May 22 19:40:19.713: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.733: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.753: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.773: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.793: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.797: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:19.813: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.817: [3/0:0(1)] send to dsp SIG DCBA state 0xF
May 22 19:40:19.833: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.837: [3/0:0(1)] send to dsp SIG DCBA state 0x0

!--- Both sides are back on-hook, back to idle.

May 22 19:40:19.853: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.857: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.873: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.877: [3/0:0(1)] send to dsp SIG DCBA state 0x0
May 22 19:40:19.893: [3/0:0(1)] rcv from dsp SIG DCBA state 0x0
May 22 19:40:19.897: [3/0:0(1)] send to dsp SIG DCBA state 0x0

Nota: questo output mostra la segnalazione che si verifica su entrambi i lati di un trunk vocale che utilizza la segnalazione Wink E&M. Si possono vedere altri tipi di segnalazione che usano gli stessi debug. Se le chiamate vengono stabilite correttamente (come illustrato qui), deve essere presente l'audio bidirezionale. È possibile verificare questa condizione se si controlla l'output del comando show voice dsp o show call active voice brief. Se tutto sembra funzionare correttamente e si verificano problemi audio (assenza di audio o unidirezionale) con le connessioni analogiche, controllare nuovamente queste connessioni.

Determinare quali chiamate sono attive

Poiché non è utile esaminare l'output del comando show call active voice o show voice call summary per le chiamate trunked, è necessario un metodo semplice per determinare quali trunk vocali supportano le chiamate attive. Uno dei modi più semplici per eseguire questa operazione è usare il comando show voice trunk-conditioning signaling in combinazione con il parametro include e usare ABCD come stringa inclusa, come mostrato di seguito: 

Phoenix#show voice trunk-conditioning signaling | include ABCD
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=1111, last-RX-ABCD=0000

!--- Timeslot 8.

last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=1111, last-RX-ABCD=1111

!--- Timeslot 10.

last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000
last-TX-ABCD=0000, last-RX-ABCD=0000

Nota: in questo output viene visualizzata una chiamata attiva nella fascia oraria 10 e un'altra chiamata avviata nella fascia oraria 8. Si desidera creare un alias per questo comando piuttosto lungo se viene utilizzato spesso.

Risoluzione dei problemi relativi a DTMF

A parte i segnali off-hook e on-hook, l'unica altra cosa che i router passano tra i PBX (oltre alla voce) sono i toni DTMF. Esiste anche un percorso audio, quindi in genere non si tratta di un problema, ma di un problema. Il problema si verifica quando eseguite l'audio su quel percorso. A volte è preferibile usare i codec con bassa velocità bit per risparmiare larghezza di banda. Viene fuori che questi codec a bassa velocità di trasmissione sono progettati per mezzo di algoritmi scritti per linguaggio umano. I toni DTMF non si conformano molto bene a questi algoritmi e necessitano di un altro metodo di trasmissione, a meno che il cliente non utilizzi il codec g711. La risposta si trova nel comando dtmf-relay. Questa funzione consente ai DSP alla fine, all'inizio del tono, di riconoscere il tono DTMF e di separarlo dal normale flusso audio. A seconda della configurazione, il DSP codifica questo segnale come un diverso tipo di pacchetto Real Time Protocol (RTP) o come messaggio h245 da inviare attraverso il collegamento separatamente dallo streaming audio. Questo è lo stesso processo che si basa sui comandi fax-relay e modem-relay.

Questa funzionalità pone un altro problema di debug per la risoluzione dei problemi del trunk. Come è possibile verificare quali cifre vengono passate se non è disponibile una configurazione di chiamata e si devono estrarre le informazioni dal flusso di pacchetto tra i router? La procedura da seguire dipende dal tipo di comando dtmf-relay utilizzato.

Come mostrato nell'esempio, il comando dtmf-relay cisco-rtp usa un tipo di payload Cisco proprietario, quindi è necessario esaminare i DSP per verificare questa condizione. È possibile eseguire il comando debug vpm signal insieme al comando debug vpm port x/x:y.z (per limitare l'output alla porta in questione) per visualizzare le cifre passate ai DSP sul lato di origine. Questo output viene visualizzato sul lato di origine, non su quello di terminazione.

*Mar  1 00:22:39.592: htsp_digit_ready: digit = 31                
*Mar  1 00:22:39.592: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:40.021: htsp_digit_ready: digit = 32
*Mar  1 00:22:40.021: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:40.562: htsp_digit_ready: digit = 33
*Mar  1 00:22:40.562: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:40.810: [1/0:1(2)] rcv from dsp SIG DCBA state 0xF
*Mar  1 00:22:41.131: htsp_digit_ready: digit = 34
*Mar  1 00:22:41.131: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:41.499:  [1/0:1(2)] Signaling RTP packet has no partical
*Mar  1 00:22:41.499: [1/0:1(2)] send to dsp SIG DCBA state 0xF
*Mar  1 00:22:41.672: htsp_digit_ready: digit = 35
*Mar  1 00:22:41.672: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:42.192: htsp_digit_ready: digit = 36
*Mar  1 00:22:42.192: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:42.789: htsp_digit_ready: digit = 37
*Mar  1 00:22:42.789: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:43.350: htsp_digit_ready: digit = 38
*Mar  1 00:22:43.350: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:44.079: htsp_digit_ready: digit = 39
*Mar  1 00:22:44.079: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:45.249: htsp_digit_ready: digit = 30
*Mar  1 00:22:45.249: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:45.810: [1/0:1(2)] rcv from dsp SIG DCBA state 0xF
*Mar  1 00:22:46.007: htsp_digit_ready: digit = 2A
*Mar  1 00:22:46.011: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:46.572: [1/0:1(2)] Signaling RTP packet has no partical
*Mar  1 00:22:46.572: [1/0:1(2)] send to dsp SIG DCBA state 0xF
*Mar  1 00:22:46.628: htsp_digit_ready: digit = 23
*Mar  1 00:22:46.628: [1/0:1(2), S_TRUNKED, E_VTSP_DIGIT] 
*Mar  1 00:22:50.815: [1/0:1(2)] rcv from dsp SIG DCBA state 0xF
all digits 0-9 are represented by 30-39, * = 2A and # = 23.

È possibile verificare quali cifre vengono inviate dal lato di origine con il comando dtmf-relay h245-alfanumeric. Il comando dtmf-relay h245-alfanumeric utilizza la parte alfanumerica di h.245 per trasmettere i toni. Come mostrato nell'esempio, quando il comando debug h245 asn1 è abilitato, le cifre possono essere viste facilmente sui lati di origine e di fine del trunk:

Origine: 

*Mar  1 00:34:17.749: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1"

*Mar  1 00:34:17.749: H245 MSC OUTGOING ENCODE BUFFER::= 6D 400131
*Mar  1 00:34:17.753: 
*Mar  1 00:34:18.350: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "2"

*Mar  1 00:34:18.350: H245 MSC OUTGOING ENCODE BUFFER::= 6D 400132
*Mar  1 00:34:18.350: 
*Mar  1 00:34:18.838: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "3"

*Mar  1 00:34:18.838: H245 MSC OUTGOING ENCODE BUFFER::= 6D 400133

Terminazione: 

*Mar  1 17:45:16.424: H245 MSC INCOMING ENCODE BUFFER::= 6D 400131
*Mar  1 17:45:16.424: 
*Mar  1 17:45:16.424: H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1"

*Mar  1 17:45:17.025: H245 MSC INCOMING ENCODE BUFFER::= 6D 400132
*Mar  1 17:45:17.025: 
*Mar  1 17:45:17.025: H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "2"

*Mar  1 17:45:17.514: H245 MSC INCOMING ENCODE BUFFER::= 6D 400133
*Mar  1 17:45:17.514: 
*Mar  1 17:45:17.514: H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "3"

il comando dtmf-relay h245-signal è molto simile e può essere visto quando si eseguono gli stessi debug del comando dtmf-relay h245-alfanumeric. In generale, risolvere i problemi dei trunk di connessione con il comando dtmf-relay è piuttosto difficile senza i debug menzionati.

Informazioni correlate

Cronologia delle revisioni

Revisione Data di pubblicazione Commenti
1.0
02-Feb-2006
Versione iniziale

Questo documento ti è stato utile?

FeedbackFeedback

Contattaci