Solucionar os problemas mais comuns de chamadas Business to Business pelo Expressway

Introduction

Este documento descreve os problemas mais comuns na implantação Business to Business (B2B). Como solucionar problemas de chamadas B2B pelo Expressways.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Expressway-C (Exp-C)
• Expressway-E
• Cisco Unified Computing Manager (CUCM)
• Telepresence Video Communication Server-C (VCS-C)

Componentes Utilizados

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

• Expressway C e E X8.1.1 ou posterior
• Unified Communications Manager (CUCM) 10.0 ou posterior.

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

 Problemas comuns

 1. Erro "//SIP/SIPTcp/wait_SdlReadRsp: Ignorar mensagem grande. Permitir somente até 5000 bytes. Redefinindo conexão."

Chamadas de endpoints do TelePresence registradas no VCS, entrando em um tronco de protocolo de início de sessão (SIP) para o CUCM, falham com "//SIP/SIPTcp/wait_SdlReadRsp: Ignorar mensagem grande. Permitir somente até 5000 bytes. Redefinindo conexão."

O roteamento de chamada no Expressway-C/VCS-C está correto e a chamada é enviada para o CUCM. A mensagem de convite SIP é enviada para o CUCM, mas nos logs SDL não há mensagens SIP. Esse erro pode ser visto nos logs SDL:

"|AppInfo |SIPTcp - Ignorando mensagem grande de xxx.xxx.xxx.xxx:[27469]. Permitir somente até 5000 bytes. Redefinindo conexão."

No CUCM 8.6 e anterior, o valor padrão do tamanho máximo de mensagem de entrada SIP era de 5000, depois que o CUCM 9.X mudou para 11000. No entanto, a atualização do 8 ou abaixo da versão 9 ou 10 vão manter o valor padrão na versão anterior do software (5000). 

Solução

Esse problema está relacionado ao bug CSCts00642

Aumentar o parâmetro de serviço avançado do CUCM Tamanho de máximo de mensagem de entrada SIP do valor padrão de 5000 para um tamanho adequado para esses tipos de chamadas. 11000 parece ser um bom valor para a maioria dos cenários previstos do cliente.

Na página de administração do CUCM, navegue até Parâmetros de serviço e selecione o servidor CUCM e o CallManager Service:

Selecione na opção Avançada e procure por Tamanho máximo da mensagem de entrada SIP:

2. O fluxo de mídia para caso outro servidor de chamada transfere a chamada.

Isso pode acontecer em chamadas B2B e acesso remoto e móvel (MRA).

Pode não ter nenhum som em uma direção ou um zumbido (mesmo ruído de quando você tenta reproduzir uma captura com áudio criptografado) depois que a chamada é transferida. Isso acontece pois um pacote de criptografia é selecionado na configuração da chamada que não é compatível com o endpoint para o qual é transferido. 

Você pode comparar a negociação SIP antes e depois de transferir a chamada. Na primeira negociação dos logs CUCM ou VCS, é possível ver as linhas de criptografia na mensagem 200 OK do VCS:

m=audio 54582 RTP/SAVP 9 96 97 0 8 18 101
a=rtpmap:9 G722/8000
a=rtpmap:96 G7221/16000
a=fmtp:96 bitrate=32000
a=rtpmap:97 G7221/16000
a=fmtp:97 bitrate=24000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ckXijkT3CcVY+xlOf3ozX/TjHPz05OzEdY49rAHA|2^48
a=sendrecv
a=rtcp:54583 IN IP4 10.1.201.7
m=video 54658 RTP/SAVP 96 97
b=TIAS:4000000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42e01e;max-fs=1621;packetization-mode=1;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e;max-fs=1621;packetization-mode=0;level-asymmetry-allowed=1
a=rtcp-fb:* nack pli
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:S8BJvGB/2l6F7XP8izXxId443Xd9f27oUI/4gxSt|2^48

 

Linhas de criptografia são aceitas na primeira chamada, mas na segunda chamada você observa que a mensagem ACK remove as linhas de criptografia:

m=audio 24826 RTP/AVP 0
c=IN IP4 10.1.231.30
a=ptime:20
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 126
c=IN IP4 10.1.98.80
b=TIAS:448000
a=label:11
a=rtpmap:126 H264/90000
a=fmtp:126 profile-level-id=42E01F;packetization-mode=1;max-fs=3601;max-rcmd-nalu-size=32000;level-asymmetry-allowed=1
a=content:main

O VCS tenta usar as linhas de criptografia negociadas no início, mesmo se o endpoint para o qual a chamada é transferida não é compatível com criptografia. 

Solução

Esse problema está relacionado ao bug CSCuv11790

Atualize o VCS/Expressway para o x8.6.1 para corrigir esse problema.

3. O domínio de nível superior não está configurado no CUCM.

Se o domínio de nível superior do parâmetro Enterprise não estiver definido, isso faz com que o CUCM roteie chamadas de entrada para seu próprio domínio e os padrões de rota SIP são usados. Isso poderia causar um loop, pois a chamada provavelmente é enviada de volta para o Exp-C ou também pode falhar com um "erro 404 não encontrado". 

Solução

Na página de administração do CUCM, navegue até Sistema > Parâmetros Enterprise para alterar essa configuração

4. O certificado CUCM deve ter o atributo de autenticação do cliente aplicado.

Quando uma conexão segura é definida entre o Exp-C e o CUCM (verificação TLS ativada), o handshake SSL é iniciado por um servidor de chamada específico que depende da direção da chamada. Isso significa que ambos os servidores devem ter autenticação de cliente e servidor nos certificados. Esse erro é visto nos logs do VCS/Expressway caso o atributo esteja ausente:

Line 190: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,060" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connecting"
Line 239: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,071" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Established"
Line 249: 2015-05-07T07:34:01-04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-05-07 11:34:01,081" Module="network.tcp" Level="DEBUG": Src-ip="10.50.47.16" Src-port="45215" Dst-ip="10.50.47.51" Dst-port="5061" Detail="TCP Connection Closed" Reason="no certificate returned"

Solução

Detalhes sobre como configurar um modelo com atributos de servidor e cliente da Web podem ser encontrados no guia de certificado do VCS

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-7/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-7.pdf

5. Problemas de interoperabilidade.

O VCS/Expressway versão X8.6.x tinha alguns problemas com o processo de interoperabilidade.

Bugs relacionados ao problema:

O defeito CSCuw85626 pode ser detectado se você verificar os logs de diagnóstico do VCS/Expressway para linhas m do vídeo sendo rejeitadas: 

Essa mensagem de erro é mostrada quando as  linhas de mídia na parte TCS do fluxo H323 são negociadas. 

índice de medialine: 1

rejeitado: verdadeiro, direção: SDP_MEDIA_DIR_SENDRECV

digite: vídeo / SDP_MF_AU_VID

O defeito CSCuw85715 é semelhante, mas nesse caso os logs VCS/Expressway vão especificar que a causa é dataTypeNotSupported:

2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="INFO": Action="Sent" Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Detail="Sending H.245 OpenLogicalChannelRejResponse "
2015-10-29T09:49:00+04:00 XXXXXXXXXXXXXXXX tvcs: UTCTime="2015-10-29 05:49:00,197" Module="network.h323" Level="DEBUG": Dst-ip="XXXXXXXXXXXXXXXX" Dst-port="49162"
Sending H.245 PDU:
value MultimediaSystemControlMessage ::= response : openLogicalChannelReject :
{
forwardLogicalChannelNumber 3,
cause dataTypeNotSupported : NULL
}

Solução

Atualize para o X8.7 ou posterior.

  

6. A mensagem ACK recebida do não é enviada para o VCS-E/Expressway-E.

Isso normalmente é visto quando a zona de passagem configurada não aponta para o endereço IP correto do VCS Expressway/Expressway-E.

Em implantações únicas de NIC (no Expressway/Borda), a zona de cliente de passagem no controle/núcleo precisa apontar para o endereço IP público do servidor de passagem.

Nas implantações de NIC duplas, o cliente de passagem precisa apontar para o endereço IP externo (a NIC interna normalmente é LAN1, mas pode ser LAN2) do servidor de passagem. Tenha em mente que esse é o endereço IP interno da LAN interna.

Solução

Consulte o Apêndice 4 da Configuração básica do Cisco VCS Expressway e controle de VCS  para obter mais informações e um diagrama das diferentes implantações de rede. 

7. O CUCM descarta a sessão TCP nas chamadas de entrada

Quando as chamadas são encaminhadas para o controle de VCS/núcleo do Expressway, o CUCM poderá rejeitá-las  descartando a sessão TCP.

 Isso pode acontecer quando a porta entre a zona de vizinho e o perfil de segurança de tronco sip não corresponde ou é configurado para ser 5060/5061.

O MRA usa uma comunicação em linha enquanto chamadas B2B usam uma comunicação de tronco, o CUCM tem uma limitação que não permite que comunicações de tronco e em linha passem pela mesma porta. Como o MRA na maior parte das vezes é configurado automaticamente, as implantações B2B precisam usar uma porta diferente.

Solução

Para fazer isso, a porta de destino configurada na zona de vizinho para o CUCM (no VCS-C/Expressway-C) precisa ser diferente de 5060/5061, normalmente 5065 é usado, mas outros podem ser usados, a porta configurada precisa corresponder à porta configurada no perfil de segurança do tronco sip atribuída ao tronco de sip neste servidor no CUCM.

Na página de administração do CUCM, navegue até  Dispositivo > Tronco.

Perfil de segurança de tronco SIP com a porta 5065. 

A porta de destino do tronco SIP pode ser 5060/5061, como mostrado na imagem.

A porta SIP na zona vizinha do VCS/Expressway precisa corresponder à porta configurada no perfil de segurança do tronco SIP, como mostrado na imagem.

Na página de administração do Expressway, navegue até Configuração > Protocolos > SIP

O VCS não tem essa limitação ou ela não se aplica a esse cenário, isso significa que o tronco SIP em si pode ser configurado com 5060/5061.

8. O VCS não pode resolver FQDNs corretamente ou falha na consulta de registros SRV.

Nas chamadas B2B originadas do CUCM, um problema pode ser apresentado devido à natureza de como o CUCM trata e roteia chamadas.

Quando o CUCM encaminha as chamadas para os servidores VCS, o CUCM tende a adicionar :5060 ou :5061 (dependendo da configuração) no final do URI discado, (por exemplo, test@lab.local >> test@lab.local:5060) quando alcança o expressway e atinge uma regra de pesquisa para a zona DNS, o VCS não consulta o registro SRV, em vez de apenas procurar A ou A Registros AAAA. Você pode confirmar isso nos logs de diagnóstico do VCS/Expressway. 

Solução

Para resolver esse problema, basta criar uma transformação que remove a porta no final (em qualquer servidor, não importa)  antes que chegue à zona DNS.

Na página de administração do Expressway, navegue para Configuração > Plano de discagem > Transformações por configuração > Plano de discagem > Transformar

 Exemplos de transformações: 

Se por alguma razão uma transformação não possa ser criada, isso pode ser feito pelas regras de pesquisa, mas é recomendado fazer isso pelas transformações.

Na página de administração do Expressway, navegue até Configuração > Plano de discagem > Transformações e configuração > Plano de discagem > Regras de pesquisa

Informações Relacionadas

• Cisco VCS Expressway e VCS Control - Configuração básica

• Criação e utilização de certificado Cisco VCS