Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Topologia de rede

Problema

Solução

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.