Voz y Comunicaciones unificadas : Cisco Unified Border Element

Fallas del fax del Troubleshooting debido a las M-líneas múltiples en el CUBO

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe cómo resolver un problema en el Cisco Unified Border Element (CUBO) cuando las fallas del fax salientes ocurren debido a las m-líneas múltiples de un proveedor. El CUBO no entiende las m-líneas múltiples, pero un workaround se puede implementar en el CUBO para resolver el problema con el uso de los perfiles del Session Initiation Protocol (SIP).

Contribuido por Kaustubh Inamdar y Mudit Mathur, ingenieros de Cisco TAC.

Prerrequisitos

Requisitos

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 del fax
  • Administrador de las Comunicaciones unificadas de Cisco (CUCM)
  • CUBO

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

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 de la invitación al CUBO durante un Voz-a-fax Switch-sobre, e incluye un protocolo session description (SDP) que contenga dos m-líneas, el comportamiento original del CUBO era rechazar la llamada con un mensaje no aceptable del SORBO 488 aquí.

Después del Id. de bug Cisco CSCtw96549, este comportamiento ha cambiado. Ahora, si un proveedor envía un SDP con dos m-líneas, la llamada va a través como se esperaba.

Aquí está un ejemplo de una m-línea validada formato:

m=audio
m=image

Sin embargo, si un proveedor envía un SDP con la m-línea formato invertido, el CUBO no la procesa correctamente y envía un SDP malformado al servidor del fax en el mensaje de la invitación. Por lo tanto, todo el fall de las llamadas.

Aquí está un ejemplo de una m-línea inaceptada formato:

m=image
m=audio

Consejo: Para otros detalles, refiera al Id. de bug Cisco CSCue70469.

Solución

Para resolver problemas este problema, hacer una llamada de prueba saliente del fax y recoger los debugs del SORBO (ccsips messages del debug). De la salida de los debugs, estas observaciones pueden ser hechas:

  • La llamada de voz establece sin los problemas.

  • Cuando es hora de extender la llamada para enviar por fax, Switch-sobre es iniciado por el proveedor-lado al detectar el preámbulo V.21.

    Nota: No es siempre obligatorio para el lado Switch-sobre el cual se llama para iniciar. Varios servidores del fax tienen la capacidad para iniciar Switch-sobre, aunque son la terminal de la cual la llamada origina. Esto se hace vía la encapsulación del tono de llamada (CNG) en los paquetes del indicador T.30.

  • La re-invitación para Switch-sobre tiene dos líneas de los media (m=) tales que la línea del m=image está puesta sobre la línea del m=audio, en este caso se presenta el defecto que se describe en el Id. de bug Cisco CSCue70469 y el CUBO desconecta la llamada.

Actualmente, no hay resolución para este problema en el CUBO, pero usted puede alterar la solución alternativa externa de los factores para el problema:

  • Utilice solamente una m-línea para el Voz-a-fax Switch-sobre.

  • Utilice el paso basado en protocolos.

  • Haga que el proveedor ponga la línea del m=audio sobre la línea del m=image.

  • Utilice el servidor del fax para iniciar Switch-sobre con el uso del CNG en un paquete del indicador T.30.

La versión 10.0 del CUBO leverages una nueva función para los perfiles entrantes del SORBO, donde los perfiles del SORBO se aplican en un mensaje entrante del SORBO antes de que se presente al stack del SORBO y se procese. La idea detrás del uso de los perfiles entrantes del SORBO en este escenario es quitar la línea toda del m=audio junta de modo que el CUBO pueda trabajar con solamente una sola línea del m=image.

Aquí está un ejemplo del mensaje de la re-invitación cuando el proveedor desea de extender la llamada de voz para enviar por 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 del SORBO puede ser aplicada para quitar la línea del 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

Modificaciones del perfil de este SORBO la línea del m=audio al a=sendrecv, que actúa como línea en el SDP que no es relevante. Esto permite que el CUBO envíe un mensaje de la re-invitación al lado del servidor del fax y aguarde la respuesta de 200 AUTORIZACIONES.

Usted debe también dirigir un aspecto más importante: Cuando el mensaje de 200 AUTORIZACIONES se envía al proveedor en respuesta al recibido re-invite, debe presentar ambas m-líneas para cumplir con el RFC y asegurarse de que el mensaje de respuesta tiene el mismo número de atributos de los media que el mensaje de la oferta.

Usted puede lograr esto vía un perfil saliente estándar del SORBO que se aplique en el dial-peer esas puntas 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 se asegura de que la re-invitación con las m-líneas múltiples esté manejada correctamente y de que la respuesta al proveedor es en conformidad con RFC porque el "t38UDPReddundancy" se substituye por:

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

En resumen, emplee el uso el soluciones alternativas que se describen en este documento (la mayoría cuyo sea proveedor-dependiente) para la aplicación de la resolución las m-líneas múltiples. También, se ha observado que el servidor de Xmedius puede también iniciar Switch-sobre, pues fuerza el servidor para enviar T.38 re-invite al mensaje y evita la presentación de las m-líneas múltiples.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118939