O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
A Cisco recomenda que você tenha conhecimento destes tópicos:
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.
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:
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.
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).
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.
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:
À 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.
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.
Esta é a última tabela na lógica de roteamento de chamada que faz a chamada para um servidor diferente como:
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)
OutboundDialPlanRules (para todos os callbridges que não sejam US e que devem permitir fazer essa chamada) (é necessário um por callbridge)
No momento, não há procedimento de verificação disponível para esta configuração.
Atualmente, não há informações específicas de solução de problemas disponíveis para esta configuração.
NOTE: Para obter exemplos de configuração, consulte estes guias:
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
30-Sep-2021 |
Versão inicial |