Solucione problemas de falhas de fax devido a várias linhas M no CUBE

Introduction

Este documento descreve como resolver um problema no Cisco Unified Border Element (CUBE) quando falhas de fax de saída ocorrem devido a várias linhas m de um provedor. O CUBE não entende várias linhas m, mas uma solução alternativa pode ser implementada no CUBE para resolver o problema com o uso de perfis SIP (Session Initiation Protocol).

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas seguintes versões de hardware e software:

• 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.

Topologia de rede

O exemplo descrito neste documento usa esta topologia de rede:

Problema

Quando um provedor envia uma mensagem de convite para o CUBE durante um comutação de voz para fax e inclui um Session Description Protocol (SDP) que contém duas linhas m, o comportamento original do CUBE era rejeitar a chamada com uma mensagem SIP 488 Not Aceitable Here.

Após o bug da Cisco ID CSCtw96549, esse comportamento mudou. Agora, se um provedor envia um SDP com duas linhas m, a chamada passa conforme esperado.

Aqui está um exemplo de um formato de linha-m aceito:

m=audio
m=imagem

No entanto, se um provedor envia um SDP com o formato de linha m invertido, o CUBE não o processa corretamente e envia um SDP malformado ao servidor de fax na mensagem Convidar. Portanto, todas as chamadas falham.

Aqui está um exemplo de um formato de linha-m não aceito:

m=imagem
m=audio

Tip: Para obter mais detalhes, consulte o bug da Cisco ID CSCue70469.

Solução

Para solucionar esse problema, faça uma chamada de teste de fax de saída e colete as depurações SIP (debug ccsip messages). A partir da saída da depuração, essas observações podem ser feitas:

• A chamada de voz é estabelecida sem problemas.
  
  
• Quando é hora de escalar a chamada para fax, a comutação é iniciada pelo provedor na detecção do preâmbulo V.21.
  

  Note: Nem sempre é obrigatório para o lado que é chamado para iniciar a comutação. Vários servidores de fax têm a capacidade de iniciar a comutação, mesmo que sejam o terminal de onde a chamada se origina. Isso é feito através do encapsulamento do tom de chamada (CNG) nos pacotes do Indicador T.30.

• O novo convite para a comutação tem duas linhas de mídia (m=) de modo que a linha m=image é colocada acima da linha m=audio, caso em que o defeito descrito no bug da Cisco ID CSCue70469 surge e o CUBE desconecta a chamada.

Atualmente, não há resolução para esse problema no CUBE, mas você pode alterar os fatores externos para contornar o problema:

• Use apenas uma linha m para o switch de voz para fax.
  
  
• Usar passagem baseada em protocolo.
  
  
• Peça ao provedor que coloque a linha m=audio acima da linha m=image.
  
  
• Use o servidor de fax para iniciar a comutação com o uso de CNG em um pacote de Indicador T.30.

O CUBE Versão 10.0 aproveita um novo recurso para perfis SIP de entrada, em que os perfis SIP são aplicados em uma mensagem SIP de entrada antes de serem apresentados à pilha SIP e processados. A ideia por trás do uso dos perfis SIP de entrada neste cenário é remover a linha de áudio m=todos juntos para que o CUBE possa funcionar com apenas uma única linha m=image.

Aqui está um exemplo da mensagem de convite novamente quando o provedor deseja encaminhar a chamada de voz para 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 configuração de perfil SIP pode ser aplicada para remover a linha 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 altera a linha de áudio m= para a=sendrecv, que atua como uma linha no SDP que não é relevante. Isso permite que o CUBE envie uma mensagem de convite novamente para o servidor de fax e aguarde a resposta 200 OK.

Você também deve abordar um outro aspecto importante: Quando a mensagem 200 OK é enviada ao provedor em resposta ao reconvite recebido, ele deve apresentar ambas as linhas m para cumprir com o RFC e garantir que a mensagem de resposta tenha o mesmo número de atributos de mídia que a mensagem de oferta.

Você pode fazer isso por meio de um perfil SIP de saída padrão aplicado no peer de discagem que aponta para o provedor:

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

Isso garante que o novo convite com várias linhas m seja tratado corretamente e que a resposta ao provedor seja compatível com RFC porque a "t38UDPReddundancy" é substituída por:

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

Em resumo, utilize as soluções alternativas descritas neste documento (a maioria das quais depende do provedor) para resolver o problema de várias linhas m. Além disso, observou-se que o Servidor Xmedius também pode iniciar a comutação, pois força o servidor a enviar a mensagem de reconvite T.38 e evita a apresentação de várias linhas m.