Architecture for Voice, Video and Integrated Data

Cisco Unified Communications

SIP Trunk – VCS para CUCM – SIP Cancel message

Posted by Paulo Souza em 30/10/2012


Olá Pessoal,

Está é a minha primeira postagem no AVVID e gostaria de compartilhar com vocês um problema que encontrei recentemente quando estava estabelecendo um SIP Trunk entre CallManager (versão 8.6) e VCS (Video Communication Server).

Cenário

Antes de começar a falar do problema, deixe-me explicar a necessidade da criação do Trunk entre CallManager e VCS. No mundo de Telepresence da Cisco, a palavra do momento é “interoperabilidade”. Isto significa permitir dispositivos diferentes, que utilizam protocolos diferentes, normalmente de fabricantes diferentes – se comunicarem dentro da mesma estrutura de Telepresença e Vídeo Conferência. A Cisco atualmente ampliou a capacidade de interoperabilidade entre os equipamentos de Telepresença e Video conferência de seu portfólio. Atualmente já é possível integração direta entre VCs e TPs sem a necessidade de qualquer MCU para intermediar o tráfego. Esta nova capacidade foi inserida a partir da versão 8.5.1 do CUCM e foi bastante aprimorada na versão 8.6.2. Falaremos desta compatibilidade em outro tópico.

Considerando este fator de interoperabilidade direta entre Telepresença e Video conferência, é muito comum termos o seguinte deployment:

  • VCS – Vários endpoints de Vídeo Conferência registrados como SIP, tais como c20, c40, MXP 1700, Ex90, MCU Codian, Telepresence Server e etc.
  • CallManager – Várias Telepresences Cisco registradas como SIP, tais como CTS 1300, 3000, 3200, TX 1300, 9000 e etc.
  • SIP Trunk – Neste caso temos um SIP Trunk estabelecido entre VCS e CallManager para permitir o mundo de VC conversar com o mundo de TP.

Bom, dado o cenário, vamos ao problema:     =)

O Problema

Uma Telepresence (registrada no CallManager) efetua uma ligação para o Telepresence Server ou qualquer outra VC (Registrada no VCS). A chamada não funciona. No Log do VCS vemos que o CallManager inesperadamente envia uma mensagen Cancel para o VCS e a chamada encerra antes de ser estabelecida. Vejam a sinalização:

SIP Trunk CUCM to VCS problem. CallManager Sends a cancel message

Olhando no Log do CallManager, notei que o CallManager, após receber as mensagens SIP, estava tentando fazer uma resolução de nome SRV no DNS.  =O

  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: Received
  • SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^*
  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/copyRecordRspToRecordReq: Retry SRV
  • query as an 1 query|0,0,0,0.0^*^*
  • 22:18:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or
  • AAAA query called as SRV query Fail):hostname=videoconf.int,
  • ReqType=1,serversused=0
  • 22:18:54.839 |//SIP/Stack/Transport/0xf1860b0/Sending CANCEL to the
  • transport layer|0,0,0,0.0^*^*

Este domínio videoconf.int é o domínio SIP que estava sendo usado no VCS. Todas as VCs registravam no VCS a SIP URI no formato ramal@videoconf.int. Então nas mensagens SIP das VCs, o campo de contato sempre contém ramal@videoconf.int. O que o CallManager estava fazendo era pegar a porção de domínio da URI do endpoint que recebeu a ligação, no caso, videoconf.int, e fazer uma consulta SRV no DNS para desocobrir quem é o servidor SIP que atende por este domínio. Como a consulta DNS falha, então o CallManager envia uma mensagem de Cancel e encerra a chamada.

Bom, o CallManager não deveria fazer uma consulta SRV no DNS para tentar descobrir qual é o servidor SIP, pois a message SIP recebida continha o campo “Record-route” no cabeçalho, indicando o endereço IP do Servidor SIP para o qual a chamada deve ser roteada, neste caso, o IP do VCS. O CallManager só deveria consultar o DNS via SRV se não houvesse “Record-route” na mensagem SIP.

Este comportamento bizarro do CallManager refere-se ao Bug CSCty07061 encontrado nas versões mais novas do CUCM, são elas:

  • 9.0(1)
  • 8.6(2.21020.1)
  • 8.6(2.21900) – Meu caso
  • 9.0(0.99081.4)
  • 9.0(0.98000.64)

Também é possível encontrar este problema na versão 8.5.1.

Workaround

Há duas formas de resolver temporariamente este problema. As duas formas podem ser bastante trabalhosas dependendo da estrutura do ambiente.

Workaround 1:

Alterar a SIP URI dos endpoints de Video conferência. Ao invés de utilizar o ramal@dominio_sip, pode-se usar ramal@endereço_IP_VCS. Deste modo o campo de contato na mensagem SIP não terá nenhum domínio, assim o CUCM não tentará fazer qualquer resolução. Mas imagine reconfigurar algumas dezenas de endpoints… trabalhoso, não é? Se você tiver o TMS pode facilitar. Mas o principal trabalho vai ser mudar a estrutura de roteamento no VCS, pois o comum é criar as search rules e transforms sempre se baseando na URI com domínio SIP.

Workaround 2:

Configurar o servidor DNS para resolver entradas de serviço (SRV Records) para o protocolo SIP, apontando o endereço IP do VCS e porta de SIP utilizada. Vejam abaixo um exemplo:

Crie um entrada tipo A no servidor DNS com os seguintes parametros:

  • Host: <Hostname VCS>.<dominio>. Exemplo: vcs-control.empresa.local
  • TTL: 86400
  • Type: A
  • Data: Endereço IP do VCS. Exemplo: 10.10.10.10

Agora crie uma entrada tipo SRV para o serviço SIP e associe-a com a entrada tipo criada acima:

  • Service: sip
  • protocol: udp (Pode-se usar tcp, udp ou tls, escolha o mesmo que esta sendo usado no SIP Trunk entre VCS e CUCM. Caso seja TLS ou TCP, então o parâmetro Service acima deve ser “sips”)
  • Host: <_sip._udp>.<Domínio Externo> (troque o udp por tcp ou tls, deve ser o mesmo configurado no parametro protocol. Note que o domínio deve ser o mesmo dominio SIP utilizado no VCS). Exemplo: _sip._udp.videoconf.int
  • Port: 5060 (Coloque 5060 se o protocolo for tcp ou udp, coloque 5061 caso seja tls)
  • Name: <dominio> (Deve ser o mesmo dominio SIP configurado no VCS). Exemplo: videoconf.int
  • TTL: 86400
  • Type: SRV
  • Priority: 10
  • Weight: 10
  • Target: Coloque o FQDN criado anteriormente para o VCS. Por exemplo: vcs-control.empresa.local

Com estas configurações, quando o CallManager consultar uma entrada SRV no DNS procurando o servidor SIP e a porta que devem ser utilizados para o domínio videoconf.int, o resultado da resolução será o endereço IP do VCS Control e a porta 5060. Assim a chamada não será cancelada.

Recomendo ter um especialista em DNS para realizar estas configurações. Pois o procedimento muda de acordo com o servidor DNS que está sendo utilizado.

Workaround 3

A Cisco sugere habilitar o parâmetro Rel1XX dentro do SIP Profile que está sendo usado no SIP Trunk que aponta para VCS Control, no CallManager. Este Workaround pode ou não funcionar. No meu caso, não funcionou.

Resolução definitiva

Não tem jeito. Para resolver o problema definitivamente é necessário fazer o upgrade do CallManager. Este bug foi corrigido nas seguintes versões do CUCM:

  • 9.0(0.98000.15)
  • 9.0(0.98000.19)
  • 9.0(0.99999.2242)
  • 9.0(0.98000.52)
  • 1.9(9.98000.7)
  • 9.0(0.98000.65)
  • 9.0(0.99081.7)
  • 8.6(2.22025.1)
  • 9.0(1.10000.15)
  • 9.0(1.10000.37)
  • 8.6(2.22900.9) – Meu caso

 

Bom pessoal, escolham o que é mais fácil para o ambiente de vocês: Mudar a URI dos endpoints (exige mudar rotas do VCS), criar entrada no DNS ou atualizar o CallManager.

Embora este tópico seja referente à SIP Trunk entre CUCM e VCS envolvendo equipamentos de Telepresence, é possível que o mesmo problema ocorra quando você tiver a mesma versão de CallManager apontando um SIP Trunk para um outro device cujas mensagens SIP também contenham domínio na URI do campo de contato.

 

Espero que seja útil. Até a próxima!

 

Paulo Souza

Anúncios

Uma resposta to “SIP Trunk – VCS para CUCM – SIP Cancel message”

  1. loliveira said

    Boa Paulo, seja bem vindo ao AVVID e obrigado por compartilhar esta informação.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s