Entender a Lógica de Roteamento de Chamadas no Servidor de Reunião

Introdução

Este documento descreve a lógica de roteamento de chamadas do Cisco Meeting Server (CMS) (antigo produto Acano), que é dividida em várias tabelas de roteamento de chamadas. Este documento aborda os diferentes estágios e cenários que as chamadas podem seguir por meio dessas tabelas de roteamento de chamadas.

Pré-requisitos

Requisitos

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

• Componente Call Bridge do Cisco Meeting Server.

Componentes Utilizados

As informações neste documento são baseadas no Cisco Meeting Server na versão 2.3.x.

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

Qual é a lógica de roteamento de chamadas do Cisco Meeting Server (CMS)?

O roteamento de chamadas no CMS envolve algumas tabelas diferentes de roteamento de chamadas. Com o fluxograma que pode ser baixado , você pode seguir a lógica de roteamento de chamada para cada chamada que chega no CMS. Isso é válido para todos os tipos de chamadas: Cisco Meeting App (CMA - cliente thick ou WebRTC), chamadas Standard Session Initiation Protocol (SIP) ou chamadas Microsoft SIP, a menos que especificado de outra forma.

Observação: a única exceção seria para chamadas iniciadas pelo CMS (diretamente para chamadas de saída agendadas do TelePresence Management Suite (TMS) ou chamadas de saída do cliente CMA) em que a tabela de encaminhamento de chamadas é ignorada.

Esta é a ordem do processo de rota de chamada no CMS: 

1. Tabela de correspondência de chamada recebida
2. Tabela de encaminhamento de chamada recebida
3. Tabela de chamadas de saída

Cada tabela é explicada com mais detalhes posteriormente no documento, que inclui as imagens que mostram apenas a parte relevante do .

Observação: o CMS executa somente o roteamento de chamadas com base no roteamento de domínio, portanto, com base no lado direito (RHS) do Uniform Resource Identifier (URI). Não há nenhuma funcionalidade de roteamento de chamadas com base no lado esquerdo (LHS) do URI, como você tem no Cisco Unified Communications Manager (CUCM) com roteamento DiretoryNumber (padrões de rota).

Observação: Cada tabela é uma lista ordenada definida pelo atributo priority. Prioridade mais alta significa que ele tenta ser correspondido primeiro. Se não coincidir, prossegue com a próxima regra na lista. Como regra geral, dê às regras mais gerais (como um * que corresponda a qualquer domínio) uma prioridade mais baixa do que às regras mais específicas. Dessa forma, as regras específicas são tratadas primeiro e você tem o retorno potencialmente para as regras mais gerais.

Etapa 1. Tabela de correspondência de chamada recebida

Essa é a primeira etapa no processo em que o CMS determina se a chamada de entrada é destinada para o próprio Cisco Meeting Server e precisaria ser processada posteriormente ou se é uma chamada destinada a um sistema diferente no qual o CMS é o agente que interfunciona a chamada e lida com a mídia e a sinalização (por exemplo, chamadas de gateway do Skype para endpoints SIP Padrão ou vice-versa).

Verifica se a parte de domínio do URI de entrada corresponde ou não à tabela de correspondência de entrada. Se houver correspondência, ele poderá rotear a chamada para espaço, usuário, IVR ou fazer uma pesquisa de conferência do Lync (no local ou fora do local) de acordo com sua configuração para esta regra de plano de discagem. A tabela não permite domínios curinga, ela requer uma correspondência completa.

Observação: se você não tiver domínios de correspondência de chamada de entrada configurados, o CMS aceitará todos os URIs de entrada de chamadas SIP ou Lync que chegam na callbridge. Para clientes CMA (WebRTC ou cliente thick), embora aceite a chamada, ainda não é roteada para o espaço correto ou o usuário automaticamente. Portanto, é importante digitar no domínio correto quando você usa o cliente CMA para discar para espaços ou usuários nesse caso.

Por exemplo, uma tabela de correspondência de chamadas é mostrada na imagem (ela mostra apenas a opção Espaços de destino e Usuários de destino para abreviar):

Aqui o domínio é configurado como acano.steven.lab, que os clientes normalmente discam. No entanto, ele também permite chamadas ad-hoc ou padrões de rota SIP específicos do CUCM (ou regras de pesquisa do Expressway) que têm como destino apenas uma callbridge específica (no caso de um cluster) pela primeira e segunda regra de fallback na tabela que correspondem ao endereço IP da callbridge (10.48.54.160 neste caso) ou ao Nome de domínio totalmente qualificado (FQDN) da callbridge (acano1.acano.steven.lab neste caso).

Etapa 2. Tabela de encaminhamento de chamada recebida

Se a chamada não atingiu nenhuma das regras na tabela de correspondência de chamadas de entrada ou não houve correspondência para a chamada continuar (por exemplo, o usuário discou um URI inexistente ou de espaço errado), ela passa pela segunda tabela chamada tabela de encaminhamento de chamadas. Isso também é somente baseado em domínio e permite que você bloqueie chamadas especificamente para determinados domínios ou permita chamadas especificamente para determinados domínios. Se você quiser fazer isso, é importante ter regras mais específicas com uma prioridade mais alta, para que elas sejam verificadas primeiro.

Este exemplo mostra que as chamadas para dummy.com são rejeitadas, enquanto as chamadas para tplab.local são encaminhadas:

Quando você deixa a tabela de encaminhamento de chamadas em branco, isso resulta em um estado em que o CMS não está atuando como um gateway entre os participantes do Skype e do SIP, por exemplo, já que não há nenhuma regra de encaminhamento de chamadas. Supondo que o domínio da chamada recebida não corresponda à tabela de correspondência de chamadas recebidas ou que o domínio corresponda, mas não haja correspondência nos espaços, usuários ou RVIs (ou reuniões do Skype), a chamada não será encaminhada com relação à tabela de chamadas de saída.

Observação: isso acontece com clientes CMA (thick clients e WebRTC), pois eles podem fazer chamadas de saída (*Web App no 3.0 não pode fazer chamadas de saída, mas sim chamadas feitas pelo espaço CMS fora do Callbridge). Da mesma forma, as chamadas de saída no CMS também funcionam bem quando são feitas via API, por exemplo (no caso de conferências agendadas do TMS). Em geral, as chamadas iniciadas a partir do próprio CMS (diretamente CMS ou via CMA) não devem seguir a lógica de encaminhamento de chamadas.

No registro de eventos, você pode ver a mensagem realçada forwarding, por exemplo, quando o CMS atua como um gateway para chamadas SIP e Skype. Um pouco antes disso, você pode ver a chamada recebida e a chamada de saída depois.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

Se a tabela de encaminhamento não tiver nenhuma regra ou uma regra de rejeição, o log de eventos não mostrará isso explicitamente. Ele apenas informa que a chamada SIP não correspondeu (nenhum espaço, usuário, IVR ou reunião do Lync) e que você perdeu a regra de encaminhamento (ou está definida para rejeitar) para ir para a seção de regras de saída.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

Para chamadas de clientes CMA ou chamadas de saída do CMS iniciadas por meio de reuniões agendadas do TMS, nenhuma chamada de entrada é vista no log de eventos. A chamada vai imediatamente para a tabela de plano de discagem de saída e não é processada pela tabela de encaminhamento de chamadas.

Na tabela de encaminhamento de chamadas, há duas outras opções de configuração: Reescrever domínio e ID do chamador.

Reescrever Domínio

Esta opção permite que você reescreva o domínio da chamada de entrada para um diferente e altera a parte do domínio do URI de solicitação SIP, bem como o cabeçalho Para da mensagem SIP.

Por exemplo, com a configuração nesta imagem, o log de eventos (com rastreamento SIP habilitado) é mostrado aqui para uma chamada de entrada com o domínio any.com, mas sem uma correspondência na tabela de correspondência de chamadas de entrada (em espaços, usuários, IVR ou conferências do Skype):

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

Nessa linha de chamada de encaminhamento, ele mostra a modificação que ocorreu. Caso você não tenha o rastreamento SIP habilitado, ele ainda mostrará a modificação de any.com para newany.com.

O uso mais comum dessa regravação do domínio vem com uma integração do Lync no local com um cluster CMS, onde é recomendável definir o cabeçalho de Contato e o cabeçalho De nas regras de saída para Lync/Skype para os Nomes de Domínio Totalmente Qualificados (FQDNs) específicos do callbridge. Isso se deve às seguintes regras de roteamento:

• O Skype envia novas transações dentro de uma caixa de diálogo (como por exemplo um ACK após um INVITE - 200 OK) para o cabeçalho Contact especificado no 200 OK que ele recebeu do CMS. Para conexões de entrada do Skype para o CMS, o Skype envia primeiro uma mensagem SIP NEGOTIATE contendo um cabeçalho ms-fe no cabeçalho To que especifica como o cabeçalho Contact deve ser preenchido nas respostas 200 OK no INVITE (já que ele usa o mesmo canal TCP)
• O Skype envia novos diálogos (como compartilhamento de conteúdo, pois é uma chamada separada, ou um retorno de chamada em caso de chamada perdida) para o cabeçalho De do CONVITE original

À medida que ele regrava o domínio, é relevante para o retorno de chamada das chamadas do Lync. O cabeçalho De do CONVITE perdido, aponta para a callbridge específica de onde a chamada vem. Em seguida, o Lync envia uma nova solicitação (INVITE) com URI de solicitação SIP que corresponde ao FQDN da callbridge. Em seguida, ele é convertido para o domínio SIP por meio dessas regras de regravação. Depois que a chamada é encaminhada, ela usa as regras de saída para o CUCM ou Expressway-C onde o ponto final SIP está registrado.

ID do chamador

Há duas opções aqui que podem ser definidas nas regras de encaminhamento. Ele está definido para passagem e, em seguida, nenhuma modificação é feita no cabeçalho De dos INVITEs de saída ou está definido para usar plano de discagem, o que permite que o sistema modifique o cabeçalho De de acordo com as regras de saída. Essa configuração é independente do fato de você ter ou não uma regravação do domínio, pois isso apenas diz respeito ao URI de solicitação SIP, bem como ao cabeçalho Para do CONVITE de saída.

Por exemplo, a mesma chamada de antes foi feita, mas agora há uma regra de plano de discagem de saída para newany.com (como após a regravação na tabela de encaminhamento de chamadas de entrada) configurada como uma chamada do tipo Lync (Ms-Conversation-ID como cabeçalho SIP extra, por exemplo). Apropriadamente, o Domínio de origem local (e o Domínio de contato local) são preenchidos para apontar para o FQDN callbridge como indicado anteriormente para chamadas do Lync. Isso reflete a alteração no cabeçalho From e Contact do SIP INVITE de saída. Como mostrado na imagem, eles são preenchidos com o mesmo valor e podem ser selecionados individualmente de acordo com sua necessidade.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

Caso a regra de encaminhamento fosse apenas definida como pass through, não haveria nenhuma modificação no cabeçalho De, como visto também no exemplo anterior (caso em que pass through foi definido na regra de encaminhamento). O cabeçalho Contato é sempre adaptado à medida que o CMS inicia um novo callLeg e, portanto, deve adicionar um cabeçalho Contato a ele mesmo.

Diferentes combinações de Identificador de Chamada e Domínio de Contato Local e Domínio Local de Origem podem ser usadas. O cabeçalho De no CONVITE SIP de saída é construído como mostrado na tabela em que a chamada de entrada entra no CMS com um cabeçalho De de usera@from.com.

Etapa 3. Tabela de chamadas de saída

Esta é a última tabela na lógica de roteamento de chamada que faz a chamada para um servidor diferente como:

• A chamada recebida não é tratada localmente (no domínio correspondente da chamada recebida).
• É uma chamada de saída de um espaço do CMS (via CMA ou via API no caso de reuniões agendadas do TMS, por exemplo, ou chamada de saída instruída do Cisco Meeting Manager (CMM)) ou de um cliente do CMA.

A partir da imagem, você pode ver que a lógica é relativamente fácil. Se não houver nenhuma entrada na tabela, ela ainda permitirá chamadas de saída, mas assumirá que o servidor CMS é capaz de resolver em registros SRV SIP (_sips._tcp / _sip._tcp / _sip._udp) para esse domínio específico, conforme mencionado no URI de solicitação SIP. Se a tabela não estiver vazia, mas não houver correspondência para o domínio discado, a mesma lógica de pesquisa de DNS será executada. Se houver uma correspondência no domínio, ela seguirá a lógica dessa regra específica. Nesse aspecto, se você quiser bloquear chamadas de saída do CMA ou como feitas via TMS ou CMM, poderá fazer isso de duas maneiras. Não tenha nenhum registro SRV de DNS (ou não possa ser resolvido pelo CMS) ou encaminhe essas chamadas para seu controle de chamadas (CUCM ou Expressway, por exemplo) e bloqueie as chamadas lá.

A imagem mostra um exemplo de tabela de chamadas de saída:

Com uma regra geral <match all domains> no final e a primeira regra para o domínio de steven.lab sem um Proxy SIP a ser usado preenchida (então ela depende de registros SRV DNS para isso).

Observe que esta é uma lista ordenada com um valor de prioridade mais alto que é abordado primeiro. Caso você corresponda a uma regra com o Comportamento definido como Parar, a chamada não passará pelo restante da tabela após essa correspondência e a chamada falhará se o Proxy SIP não conseguir rotear a chamada, por exemplo. Quando essa configuração for definida como Continuar, você poderá permitir um fallback para uma rota diferente ou nó diferente no cluster. Por exemplo, você pode especificar um proxy SIP diferente para cada regra para o mesmo domínio. 

As configurações de Local Contact Domain e Local From Domain são abordadas na seção anterior da tabela de encaminhamento de chamadas recebidas. O Tipo de tronco permite especificar que tipo de chamada precisa ser feita, que pode ser SIP padrão, Lync ou Avaya, que depende do sistema receptor.

O campo Encryption determina se a sinalização da chamada deve ser descriptografada ou criptografada. No entanto, observe que isso não implica qualquer criptografia de mídia, pois ela está definida na configuração de criptografia de mídia SIP, conforme encontrado no menu Configuração > Configurações da chamada. Nessa configuração, você também tem a opção de selecionar Automático, que tenta fazer a chamada primeiro com uma sinalização criptografada com um possível fallback para uma sinalização não criptografada. Se você souber antecipadamente que o outro lado está criptografado ou não, é altamente recomendável defini-lo de acordo para evitar atrasos na configuração da chamada devido ao processo de fallback.

Um exemplo de saída do arquivo de registro de uma chamada para steven.lab (após a regravação do domínio na tabela de encaminhamento de chamadas recebidas), com rastreamento DNS e rastreamento SIP definidos como detalhados, mostra os registros SRV que são consultados e o mecanismo de fallback caso a Criptografia esteja definida como Automática.

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

Observação: no caso de um ambiente em cluster com várias callbridges, você pode configurar regras de plano de discagem de saída por callbridge ao configurá-lo via API e especificar no objeto API uma ID de callbridge (ou ID de callbridgeGroup). Suponha, por exemplo, que você deseja que todas as chamadas saiam de um callbridge específico para um domínio específico (por exemplo, quando você disca para us.example.com, gostaria que ele saísse de seus servidores baseados nos EUA). Em seguida, assegure-se de que você tenha uma configuração de API para outboundDialPlanRules, de modo que cada callbridge que não a baseada em US possa rotear a chamada para callbridge de US (no caso deste exemplo).

OutboundDialPlanRule (para callbridge dos EUA)

• domain=us.example.com
• sipProxy = <vazio ao usar SRV/IP ou FQDN DNS se definido manualmente>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (para todas as callbridges não-EUA que devem permitir fazer essa chamada) (precisa de uma por callbridge)

• domain=us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• scope = callbridge
• callbridge = <non-US-callbridge-ID>

Verificar 

No momento, não há procedimento de verificação disponível para esta configuração.

Troubleshooting 

No momento, não há nenhuma informação específica de solução de problemas disponível para esta configuração.

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems
• Ferramenta Collaboration Solutions Analyzer 
• documentação de CMS

---

OBSERVAÇÃO: para obter exemplos de configuração, consulte estes guias:

• Guia único combinado de configuração e integração do CMS
• Configurar o Cisco Meeting Server e o Guia do CUCM