Resolución de problemas de fallas de fax debido a varias líneas M en el CUBE

Introducción

Este documento describe cómo resolver un problema en Cisco Unified Border Element (CUBE) cuando se producen fallos de fax salientes debido a varias líneas m de un proveedor. El CUBE no comprende varias líneas m, pero se puede implementar una solución alternativa en el CUBE para resolver el problema con el uso de perfiles de protocolo de inicio de sesión (SIP).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software y hardware.

• Servidor de fax
• Cisco Unified Communications Manager (CUCM)
• CUBE

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Topología de red

El ejemplo que se describe en este documento utiliza esta topología de red:

Problema

Cuando un proveedor envía un mensaje Invite al CUBE durante un intercambio de voz a fax e incluye un protocolo de descripción de sesión (SDP) que contiene dos líneas m, el comportamiento original del CUBE era rechazar la llamada con un mensaje SIP 488 Not Acceptable Here.

Después del Id. de bug Cisco CSCtw96549, este comportamiento ha cambiado. Ahora, si un proveedor envía un SDP con dos líneas m, la llamada se realiza según lo esperado.

A continuación se muestra un ejemplo de un formato de línea m aceptado:

m=audio
m=imagen

Sin embargo, si un proveedor envía un SDP con el formato de línea m invertido, el CUBE no lo procesa correctamente y envía un SDP mal formado al servidor de fax en el mensaje Invite. Por lo tanto, todas las llamadas fallan.

A continuación se muestra un ejemplo de un formato de línea m no aceptado:

m=imagen
m=audio

Consejo: Para obtener más detalles, refiérase al ID de bug de Cisco CSCue70469.

Solución

Para resolver este problema, realice una llamada de prueba de fax saliente y recopile los debugs SIP (debug ccsip messages). A partir del resultado de la depuración, se pueden realizar estas observaciones:

• La llamada de voz se establece sin problemas.
  
  
• Cuando es hora de escalar la llamada al fax, el switch se inicia por el lado del proveedor al detectar el preámbulo V.21.
  

  Nota: No siempre es obligatorio para el lado al que se llama para iniciar el switch-over. Varios servidores de fax tienen la capacidad de iniciar el switch-over, aunque sean el terminal desde el que se origina la llamada. Esto se realiza mediante la encapsulación del tono de llamada (CNG) en los paquetes del indicador T.30.

• La re-invitación para el switch-over tiene dos líneas de medios (m=) de manera que la línea m=image se coloca encima de la línea m=audio, en cuyo caso surge el defecto que se describe en el Id. de error de Cisco CSCue70469 y el CUBE desconecta la llamada.

Actualmente, no hay resolución para este problema en el CUBE, pero usted puede alterar los factores externos para solucionar el problema:

• Utilice sólo una línea m para el switch-over de voz a fax.
  
  
• Utilice el paso a través basado en protocolo.
  
  
• Haga que el proveedor coloque la línea m=audio por encima de la línea m=image.
  
  
• Utilice el servidor de fax para iniciar el switch-over con el uso de CNG en un paquete indicador T.30.

La versión 10.0 de CUBE aprovecha una nueva función para los perfiles SIP entrantes, donde los perfiles SIP se aplican en un mensaje SIP entrante antes de que se presente a la pila SIP y se procese. La idea detrás del uso de los perfiles SIP entrantes en este escenario es quitar la línea m=audio para que el CUBE pueda trabajar con una única línea m=image.

A continuación se muestra un ejemplo del mensaje re-Invite cuando el proveedor desea derivar la llamada de voz 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
================================

Esta configuración del perfil SIP se puede aplicar para quitar la línea 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

Este perfil SIP cambia la línea m=audio a a=sendrecv, que actúa como una línea en el SDP que no es relevante. Esto permite al CUBE enviar un mensaje de re-invitación al servidor de fax y esperar la respuesta 200 OK.

También debe abordar un aspecto más importante: Cuando el mensaje 200 OK se envía al proveedor en respuesta a la nueva invitación recibida, debe presentar ambas líneas m para cumplir con RFC y asegurarse de que el mensaje de respuesta tenga el mismo número de atributos de medios que el mensaje de oferta.

Puede lograr esto a través de un perfil SIP saliente estándar que se aplica en el par de marcado que señala al proveedor:

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

Esto asegura que la reinvitación con varias líneas m se maneje correctamente y que la respuesta al proveedor sea compatible con RFC porque la "t38UDPReddundancy" se reemplaza por:

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

En resumen, emplee las soluciones alternativas descritas en este documento (la mayoría de las cuales dependen del proveedor) para resolver el problema de varias líneas m. Además, se ha observado que el servidor Xmedius también puede iniciar el switch-over, ya que obliga al servidor a enviar el mensaje T.38 re-Invite y evita la presentación de varias líneas m.