Risoluzione dei problemi relativi agli errori fax causati da più linee M nel CUBO

Introduzione

In questo documento viene descritto come risolvere un problema relativo al CUBE (Cisco Unified Border Element) quando si verificano errori fax in uscita causati da più linee m di un provider. Il CUBE non è in grado di comprendere più linee M, ma è possibile implementare una soluzione sul CUBE per risolvere il problema con l'utilizzo dei profili SIP (Session Initiation Protocol).

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

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

• Server fax
• Cisco Unified Communications Manager (CUCM)
• CUBO

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.

Topologia della rete

L'esempio descritto in questo documento utilizza la seguente topologia di rete:

Problema

Quando un provider invia un messaggio di invito al CUBE durante un passaggio voce-fax e include un SDP (Session Description Protocol) contenente due linee m, il comportamento originale del CUBE consisteva nel rifiutare la chiamata con un messaggio SIP 488 Non accettabile qui.

Dopo l'ID bug Cisco CSCtw96549, questo comportamento è cambiato. Ora, se un provider invia un SDP con due m-line, la chiamata continua come previsto.

Di seguito è riportato un esempio di un formato di linea m accettato:

m=audio
m=immagine

Tuttavia, se un provider invia un SDP con il formato m-line invertito, il CUBE non lo elabora correttamente e invia un SDP non valido al server fax nel messaggio Invite. Pertanto, tutte le chiamate hanno esito negativo.

Di seguito è riportato un esempio di un formato di linea m non accettato:

m=immagine
m=audio

Suggerimento: Per ulteriori informazioni, fare riferimento all'ID bug Cisco CSCue70469.

Soluzione

Per risolvere il problema, eseguire una chiamata di test del fax in uscita e raccogliere i debug SIP (messaggi debug ccsip). Dall'output del comando debug, è possibile effettuare le seguenti osservazioni:

• La chiamata vocale viene stabilita senza problemi.
  
  
• Quando è il momento di inoltrare la chiamata al fax, lo switch-over viene avviato dal lato del fornitore non appena viene rilevato il preambolo V.21.
  

  Nota: Non è sempre obbligatorio per il dispositivo chiamato per avviare la commutazione. Diversi server fax sono in grado di avviare la commutazione, anche se sono il terminale da cui ha origine la chiamata. Ciò viene fatto tramite l'incapsulamento del segnale di chiamata (CNG) nei pacchetti dell'indicatore T.30.

• Il re-invito per lo switch-over ha due linee multimediali (m=) in modo che la linea m=image si trovi sopra la linea m=audio, nel qual caso si verifica il difetto descritto in Cisco bug ID CSCue70469 e il CUBE disconnette la chiamata.

Attualmente non è disponibile una risoluzione per questo problema nel CUBO, ma è possibile modificare i fattori esterni per risolvere il problema:

• Utilizzare una sola m-line per il passaggio voce-fax.
  
  
• Utilizza pass-through basato su protocollo
  
  
• Fare in modo che il provider inserisca la linea m=audio sopra la linea m=immagine.
  
  
• Utilizzare il server fax per avviare la commutazione con l'uso di GNC in un pacchetto indicatore T.30.

CUBE versione 10.0 sfrutta una nuova funzionalità per i profili SIP in entrata, in cui i profili SIP vengono applicati a un messaggio SIP in entrata prima di essere presentati allo stack SIP ed elaborati. L'idea alla base dell'uso dei profili SIP in entrata in questo scenario è quella di rimuovere tutte le linee m=audio in modo che il CUBE possa funzionare con una sola linea m=immagine.

Di seguito è riportato un esempio del messaggio di invito successivo quando il provider desidera inoltrare la chiamata vocale al fax:

Received:
INVITE sip:025027141@192.0.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnm30rd10dofho0fo9011sb0000g00.1
Call-ID: 6B6CB982-B41D11E3-898F851F-F1ADD198@192.0.2.2
From: <sip:026455288@25027100.xyz>;tag=7qapqh6u-CC-36
To: "Administrator" <sip:025027141@25027100.xyz>;tag=85A6C018-2489
CSeq: 1 INVITE
Contact: <sip:192.0.2.1:5060;transport=udp>
Max-Forwards: 69
Content-Length: 431
Content-Type: application/sdp
v=0
o=HuaweiSoftX3000 22157305 22157306 IN IP4 192.0.2.1
s=Sip Call
c=IN IP4 192.0.2.1
t=0 0
m=image 53200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 53190 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
================================

Questa configurazione del profilo SIP può essere applicata per rimuovere la linea m=audio:

voice class sip-profiles 966
request REINVITE sdp-header Audio-Media modify "(.*)" "a=sendrecv"
voice service voip
sip
voice-class sip profiles 966 inbound
or 
dial-peer voice XYZ voip
voice-class sip profiles 966 inbound

Questo profilo SIP modifica la linea m=audio in a=sendrecv, che agisce come una linea nel SDP che non è rilevante. In questo modo il CUBE può inviare un messaggio di invito al server fax e attendere la risposta 200 OK.

Dovete inoltre affrontare un altro aspetto importante: Quando il messaggio 200 OK viene inviato al provider in risposta al nuovo invito ricevuto, deve presentare entrambe le m-line per essere conforme all'RFC e garantire che il messaggio di risposta abbia lo stesso numero di attributi multimediali del messaggio di offerta.

A tale scopo, è possibile utilizzare un profilo SIP in uscita standard applicato al dial-peer che punta al provider:

voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
 "t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"

Ciò garantisce che il re-invito con più linee m sia gestito correttamente e che la risposta al provider sia conforme a RFC in quanto la "ridondanza t38UDPR" è sostituita da:

"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP

In sintesi, utilizzare le soluzioni descritte in questo documento (la maggior parte delle quali sono dipendenti dal fornitore) per risolvere il problema di più linee m. Inoltre, è stato osservato che Xmedius Server può anche avviare lo switch-over, in quanto costringe il server a inviare il messaggio di re-invito T.38 ed evita la presentazione di più m-line.