Voz e comunicações unificadas : Cisco Unified Border Element

Pesquise defeitos as falhas de fax devido às M-linhas múltiplas no CUBO

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como resolver uma edição no Cisco Unified Border Element (CUBO) quando as falhas de fax de partida ocorrem devido às m-linhas múltiplas de um fornecedor. O CUBO não compreende m-linhas múltiplas, mas uma ação alternativa pode ser executada no CUBO a fim resolver a edição com o uso de perfis do Session Initiation Protocol (SIP).

Contribuído por Kaustubh Inamdar e por Mudit Mathur, engenheiros de TAC da Cisco.

Pré-requisitos

Requisitos

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
  • Gerente das comunicações unificadas de Cisco (CUCM)
  • CUBO

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Topologia de rede

O exemplo que é descrito neste documento usa esta topologia de rede:

Problema

Quando um fornecedor envia uma mensagem do convite ao CUBO durante um Voz-à-fax interruptor-sobre, e inclui um protocolo session description (SDP) que contivesse duas m-linhas, o comportamento original do CUBO era rejeitar o atendimento com uma mensagem não aceitável do SORVO 488 aqui.

Após a identificação de bug Cisco CSCtw96549, este comportamento mudou. Agora, se um fornecedor envia um SDP com duas m-linhas, o atendimento vai completamente como esperado.

Está aqui um exemplo de uma m-linha aceitada formato:

m=audio
m=image

Contudo, se um fornecedor envia um SDP com a m-linha formato invertido, o CUBO não a processa corretamente e envia-o um SDP deformado ao servidor de fax na mensagem do convite. Consequentemente, toda a falha dos atendimentos.

Está aqui um exemplo de uma m-linha unaccepted formato:

m=image
m=audio

Dica: Para uns detalhes mais adicionais, refira a identificação de bug Cisco CSCue70469.

Solução

A fim pesquisar defeitos esta edição, para fazer uma chamada de teste de partida do fax e para recolher o SORVO debuga (debugar mensagens de ccsip). Do resultado do debug, estas observações podem ser feitas:

  • A chamada de voz estabelece sem edições.

  • Quando é hora de escalar o atendimento para enviar, interruptor-sobre está iniciado pelo fornecedor-lado após detecção do preâmbulo V.21.

    Nota: Não é sempre imperativo para o lado que é chamado para iniciar interruptor-sobre. Diversos servidores de fax têm a capacidade de iniciar interruptor-sobre, mesmo que sejam o terminal de que o atendimento origina. Isto é feito através do encapsulamento do tom (CNG) de chamada nos pacotes do indicador T.30.

  • O re-convite para interruptor-sobre tem duas linhas dos media (m=) tais que a linha do m=image está colocada acima da linha do m=audio, neste caso o defeito que está descrito na identificação de bug Cisco CSCue70469 elevara e o CUBO desliga o atendimento.

Atualmente, não há nenhuma definição para esta edição no CUBO, mas você pode alterar a ação alternativa externo dos fatores a edição:

  • Use somente uma m-linha para o Voz-à-fax interruptor-sobre.

  • Use com base nos protocolos passagem-através de.

  • Mande o fornecedor colocar a linha do m=audio acima da linha do m=image.

  • Use o servidor de fax a fim iniciar interruptor-sobre com o uso do CNG em um pacote do indicador T.30.

A versão 10.0 do CUBO leverages uns novos recursos para os perfis de entrada do SORVO, onde os perfis do SORVO estão aplicados em uma mensagem de entrada do SORVO antes que esteja apresentada à pilha do SORVO e processada. A ideia atrás do uso dos perfis de entrada do SORVO nesta encenação é remover juntamente toda do m=audio a linha de modo que o CUBO possa trabalhar com somente uma única linha do m=image.

Está aqui um exemplo da mensagem do re-convite quando o fornecedor deseja escalar a chamada de voz para enviar:

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 do SORVO pode ser aplicada a fim remover a linha do 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

Alterações de perfil deste SORVO a linha do m=audio ao a=sendrecv, que atua como uma linha no SDP que não é relevante. Isto permite que o CUBO envie uma mensagem do re-convite ao lado do servidor de fax e espere a resposta de 200 APROVAÇÕES.

Você deve igualmente endereçar um aspecto mais importante: Quando a mensagem de 200 APROVAÇÕES é enviada ao fornecedor em resposta ao recebido re-convide, deve apresentar ambas as m-linhas a fim seguir com o RFC e assegurar-se de que o mensagem de resposta tenha o mesmo número de atributos dos media que a mensagem da oferta.

Você pode realizar este através de um perfil de partida padrão do SORVO que seja aplicado no dial-peer esses pontos ao fornecedor:

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

Isto assegura-se de que o re-convite com m-linhas múltiplas esteja segurado corretamente e que a resposta ao fornecedor é em conformidade com RFC porque o "t38UDPReddundancy" é substituído por:

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

Em resumo, empregue o uso o das ações alternativas que são descritas neste documento (a maioria de que seja fornecedor-dependente) a introdução da resolução de m-linhas múltiplas. Também, observou-se que o server de Xmedius pode igualmente iniciar interruptor-sobre, porque força o server para enviar T.38 re-convide a mensagem e evite a apresentação de m-linhas múltiplas.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118939