Entender a lógica de roteamento de chamadas no Meeting Server

Introduction

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 realizar através dessas tabelas de roteamento de chamadas.

Prerequisites

Requirements

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.

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.

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 chamadas para cada chamada recebida no CMS. Isso é válido para todos os tipos de chamadas: Cisco Meeting App (CMA - thick client ou WebRTC), chamadas do Standard Session Initiation Protocol (SIP) ou chamadas do Microsoft SIP, a menos que especificado de outra forma.

Note: A única exceção seria para as chamadas iniciadas pelo CMS (diretamente para as chamadas de saída programadas do TelePresence Management Suite (TMS) ou para as chamadas de saída do cliente CMA) nas quais 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 chamadas recebidas
3. Tabela de Chamadas de Saída

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

Note: 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 LHS (lado esquerdo) da URI como você tem no Cisco Unified Communications Manager (CUCM) com roteamento DiretoryNumber (Padrões de rota).

Note: Cada tabela é uma lista ordenada definida pelo atributo de prioridade. Prioridade mais alta significa que ele tenta ser correspondido primeiro. Se não corresponder, ele continuará com a próxima regra na lista. Como regra geral, dê a regras mais gerais (como um * que corresponda a qualquer domínio) uma prioridade mais baixa do que as regras mais específicas. Dessa forma, as regras específicas são tratadas primeiro, e você pode ter o recuo potencial 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 ao próprio Cisco Meeting Server e precisaria ser processada posteriormente ou se é uma chamada destinada a um sistema diferente em que o CMS é o agente que interopera a chamada e lida com a mídia e a sinalização (por exemplo, O gateway do Skype chama os endpoints SIP padrão ou vice-versa.)

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

Note: Se você não tiver nenhum domínio correspondente de chamada de entrada configurado, o CMS aceitará todas as URIs de entrada de chamadas SIP ou Lync atendidas no callbridge. Para clientes CMA (WebRTC ou cliente thick), embora aceite a chamada, ainda que não seja roteada para o espaço ou usuário correto automaticamente. Portanto, é importante inserir o 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 Destinos espaços e Destinos para ser breve):

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 visam 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 chamadas recebidas

Se a chamada não atingiu nenhuma das regras na tabela de correspondência de chamada recebida ou se não houve correspondência para a chamada continuar (por exemplo, o usuário discou URI de espaço não existente ou errado), ela passa pela segunda tabela chamada tabela de desvio de chamada. Isso também é baseado em domínio apenas e permite que você bloqueie especificamente as chamadas para determinados domínios ou permita apenas chamadas para determinados domínios. Se você quiser fazer isso, é importante ter regras mais específicas com uma prioridade mais alta, então elas são 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 desvio 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, pois não há nenhuma regra de desvio de chamadas. Na suposição de que o domínio da chamada recebida não corresponde na tabela de correspondência de chamada recebida ou que o domínio corresponde, mas não há correspondência nos espaços, usuários ou RVIs (ou reuniões do Skype), a chamada não é encaminhada com relação à tabela de chamada de saída.

Note: Isso acontece mesmo com clientes CMA (thick clients e WebRTC), pois eles podem fazer chamadas de saída (*O Web App em 3.0 não pode fazer chamadas de saída, mas sim chamadas feitas pelo espaço CMS fora pela Callbridge). Da mesma forma, as chamadas de saída no CMS também funcionam bem quando 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 ou via CMA) não devem seguir a lógica de encaminhamento de chamadas.

No registro de eventos, você pode ver a mensagem de encaminhamento realçada como, por exemplo, quando o CMS atua como um gateway para chamadas SIP e Skype. 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 regra de rejeição, o registro de eventos não mostrará isso explicitamente. Ele apenas informa que a chamada do SIP não corresponde (espaço, usuário, IVR ou reunião do Lync) e que você não tem a regra de encaminhamento (ou ela está definida para rejeitar) para mover 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 de saída do CMS iniciadas por meio de reuniões agendadas do TMS, não há chamada recebida no registro de eventos. A chamada vai imediatamente para a tabela do plano de discagem de saída e não é processada pela tabela de desvio de chamadas.

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

Reescrever domínio

Esta opção permite reescrever o domínio da chamada de entrada para outro e altera a parte do domínio da solicitação de URI do SIP, bem como o cabeçalho To da mensagem SIP.

Por exemplo, com a configuração nesta imagem, o registro de eventos (com rastreamento SIP ativado) é mostrado aqui para uma chamada de entrada com domínio any.com, mas sem uma correspondência na tabela de correspondência de chamada 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

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

O uso mais comum dessa reescrita do domínio vem com uma integração do Lync no local com um cluster CMS onde é recomendável definir o cabeçalho do Contato e o cabeçalho De nas regras de saída para o Lync/Skype para os Nomes de Domínio Totalmente Qualificados (FQDNs - Fully Qualified Domain Names) específicos da callbridge. Isso é devido a estas regras de roteamento:

• O Skype envia novas transações em uma caixa de diálogo (como por exemplo, um ACK após um CONVITE - 200 OK) para o cabeçalho do Contato 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 NEGOTIATE SIP contendo um cabeçalho ms-fe no cabeçalho To, que especifica como o cabeçalho do Contato deve ser preenchido nas respostas 200 OK no CONVITE (pois 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 no caso de uma chamada perdida) para o cabeçalho De do CONVITE original

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

ID do chamador

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

Por exemplo, a mesma chamada anterior foi feita, mas agora há uma regra de plano de discagem de saída para newany.com (como após a reescrita 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). De forma apropriada, o Local From Domain (e Local Contact Domain) são preenchidos para apontar para o FQDN da callbridge como indicado anteriormente para chamadas do Lync. Isso reflete a alteração no cabeçalho De e Contato do CONVITE SIP de saída. Como mostrado na imagem, eles são preenchidos com o mesmo valor e podem ser selecionados individualmente de acordo com o seu requisito.

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 definida na passagem, então não haveria nenhuma modificação no cabeçalho De como visto também no exemplo anterior (caso em que a passagem foi definida na regra de encaminhamento). O cabeçalho do contato é sempre adaptado à medida que o CMS inicia um novo callLeg e, portanto, deve adicionar um cabeçalho de contato a si mesmo.

Diferentes combinações de identificador de chamada e domínio de contato local e local de domínio podem ser usadas. O cabeçalho De no CONVITE SIP de saída é construído conforme 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 pelo Cisco Meeting Manager (CMM)) ou de um cliente 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 assume 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 na 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 sentido, se você quiser bloquear chamadas de saída do CMA ou feitas via TMS ou CMM, você pode fazer isso de duas maneiras. Não tem nenhum registro SRV DNS (ou não pode ser resolvido pelo CMS) ou encaminhe essas chamadas para o controle de chamadas (CUCM ou Expressway, por exemplo) e bloqueie as chamadas lá.

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

Com uma regra geral <todos os domínios> no final e a primeira regra para o domínio de steven.lab sem um Proxy SIP para uso preenchido (portanto, ele depende dos registros SRV DNS para ele).

Observe que esta é uma lista ordenada com um valor de prioridade mais alta que é abordado primeiro. Se você corresponder uma regra com o Comportamento definido como Parar, a chamada não passará pelo resto da tabela após essa correspondência e a chamada falhará se o Proxy SIP não tiver roteado 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 de entrada. O tipo de tronco permite especificar que tipo de chamada precisa ser feita, que pode ser SIP padrão, Lync ou Avaya, dependendo do sistema receptor.

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

Um exemplo de saída do arquivo de log de uma chamada para steven.lab (após a reescrita do domínio na tabela de encaminhamento de chamadas recebidas), com rastreamento DNS e rastreamento SIP definido como detalhado, mostra os registros SRV consultados e o mecanismo de fallback no caso da Criptografia ser definida como Auto.

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

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

OutboundDialPlanRule (para US callbridge)

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

OutboundDialPlanRules (para todos os callbridges que não sejam US e que devem permitir fazer essa chamada) (é necessário um por callbridge)

• domain=us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• escopo = callbridge
• callbridge = <não-US-callbridge-ID>

Verificar 

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

Troubleshoot 

Atualmente, não há informações específicas de solução de problemas disponíveis para esta configuração.

Informações Relacionadas

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

---

NOTE: Para obter exemplos de configuração, consulte estes guias:

• Configurar e integrar o Guia Único Combinado do CMS
• Configurar o Cisco Meeting Server e o Guia CUCM