Voz e comunicações unificadas : Cisco TelePresence Video Communication Server (VCS)

Atendimentos de CUCM à zona DNS na via expressa VC enviada ao endereço IP errado

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

Introdução

Nas disposições onde os valores-limite são registrados no gerente das comunicações unificadas de Cisco (CUCM) e os atendimentos são distribuídos através de um server de comunicação de vídeo (VC), os atendimentos intercompany ou os atendimentos a um domínio diferente não puderam ser distribuídos corretamente.

Este documento descreve como o problema de enviar chamar a um endereço de destino errado pode ocorrer, assim como como o problema pode ser resolved se você descasca a porta do convite.

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

  • Gerente das comunicações unificadas de Cisco
  • Zona do Domain Name System (DNS)

Contribuído por Kristof Van Coillie, engenheiro de TAC da Cisco.

Problema

Neste exemplo, o fluxo de chamadas é uma chamada feita de um valor-limite registrado em um conjunto CUCM a uma zona DNS na via expressa VC:

116729-trouble-cucm-dns-vcs-01.png

Há uma zona vizinha configurada entre o controle VC e o conjunto CUCM, e uma zona do traversal configurada entre o controle VC e a via expressa VC. Quando o CUCM envia chamar sobre um tronco do Session Initiation Protocol (SIP), adiciona o número de porta ao identificador de recurso uniforme (URI):

Module="network.sip" Level="DEBUG":  Src-ip="10.48.79.189"  Src-port="25018"
 SIPMSG:
 |INVITE sip:user@company.com:5060 SIP/2.0

O controle VC tem uma regra de busca que envie o atendimento à via expressa VC. A via expressa VC é configurada assim que a regra de busca envia este atendimento a uma zona DNS. Se não há nenhuma alteração no URI, a via expressa VC faz uma consulta do Um-registro:

Module="network.dns" Level="DEBUG":  Detail="Sending DNS query"
Name="company.com" Type="A and AAAA"
Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:
['IPv4''TCP''10.10.10.10'] (A/AAAA) Number of relevant records
retrieved: 1"

A via expressa VC igualmente faz uma consulta do servidor DNS (SRV) para o domínio:

Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" 
Name="_sips._tcp.company.com" Type="SRV (IPv4 and IPv6)"
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to:
['IPv4''TCP''10.10.10.10:5061'] (A/AAAA) Number of relevant records
retrieved: 1"

Quando o convite é enviado, o resultado da consulta do Um-registro está usado:

Event="Request Sent" Service="SIP" Src-ip="10.48.79.123" Src-port="5060"
Dst-ip="10.10.10.10" Dst-port="5060"
Call-serial-number="617a2b3a-407b-11e3-882a-000c291377f3"
Tag="617331f4-407b-11e3-b012-000c29f5e10e" Protocol="UDP"
Method="INVITE" Request-URI="sip:user@company.com:5060"
To="sip:user@10.48.79.189" Level="2" UTCTime="2013-10-29 09:20:41,210"

Este não é o comportamento desejado, porque o endereço não é aquele da via expressa VC, mas do servidor de Web que está hospedando www.company.com.

Solução

O uso transforma regras nos VC controla ou a via expressa VC a fim descascar a porta do convite. Isto permite que a via expressa VC use a nomeação do ponteiro da autoridade (NAPTR) e das consultas SRV.

Para um exemplo de como descascar a porta, veja “permitindo os valores-limite registrados no CM unificado para chamar valores-limite registrados a seção VC” na página 24 do gerente das comunicações unificadas de Cisco do Cisco TelePresence com o guia de distribuição de Cisco VC (tronco do SORVO).

Uma vez que a porta é descascada, a via expressa VC faz uma consulta NAPTR e SRV:

Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" 
Name="company.com" Type="NAPTR (IPv4 and IPv6)"
Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"
Module="network.dns" Level="DEBUG": Detail="Sending DNS query"
Name="_sips._tcp.company.com" Type="SRV (IPv4 and IPv6)"
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to:
['IPv4''TCP''10.10.10.20:5061'] (A/AAAA) Number of relevant records
retrieved: 1"
Module="network.dns" Level="DEBUG": Detail="Sending DNS query"
Name="_sip._tcp.company.com" Type="SRV (IPv4 and IPv6)"
Module="network.dns" Level="DEBUG": Detail="Resolved hostname to:
['IPv4''TCP''10.10.10.20:5060'] (A/AAAA) Number of relevant records
retrieved: 1"
Module="network.dns" Level="DEBUG": Detail="Sending DNS query"
Name="_sip._udp.company.com" Type="SRV (IPv4 and IPv6)"
Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"

A via expressa VC usa o resultado do SRV (um pouco do que a consulta do Um-registro) a fim estabelecer o atendimento. Este é o comportamento desejado, e o atendimento sucede:

Module="network.tcp" Level="DEBUG":  Src-ip="10.48.79.123" Src-port="25005" 
Dst-ip="10.10.10.20" Dst-port="5061" Detail="TCP Connecting"

Informações Relacionadas



Document ID: 116729