o guia de troubleshooting para o serviço híbrido do .... ajuste a porta do sorvo tls quando você...

O guia de Troubleshooting para o serviço híbridodo atendimento da faísca de Cisco conecta Índice

IntroduçãoPré-requisitosRequisitosComponentes UtilizadosInformações de ApoioEdições da configuração de chamadaFalhas mútuas do handshake de TLSDicas de Troubleshooting mútuos úteis TLSA edição 1. Expressway-e não confia o Certificate Authority (CA) que assinou o certificado dafaísca de Cisco SoluçãoO nome incorreto da edição 2. para o assunto TLS verifica o nome na zona DNS do híbrido dafaísca de Expressway-e Cisco SoluçãoA edição 3. Expressway-e não envia o certificate chain completo à faísca de CiscoSoluçãoO Firewall da edição 4. termina o handshake de TLS mútuoSoluçãoA edição 5. Expressway-e é assinada por CA público mas Cisco acende o hub do controle temCertificados alternativos carregadosSoluçãoA edição 6. Expressway não está traçando a chamada recebida à zona DNS do híbrido da faíscade CiscoSoluçãoCertificado auto-assinado do padrão dos usos de Expressway-e da edição 7.SoluçãoDe entrada: Cisco acende aos Em-locaisA edição 1. Cisco acende é incapaz de resolver Expressway-e DNS SRV/hostnameSoluçãoSolução alternativaFalha de soquete da edição 2.: A porta 5062 é de entrada obstruído a ExpresswaySoluçãoFalha de soquete da edição 3.: Expressway-e não está escutando na porta 5062SoluçãoA edição 4. Expressway-e ou o C não apoiam encabeçamentos Preloaded da rota do SORVOSoluçãoA edição 5. Cisco acende o app está recebendo duas notificações do atendimento (os brindes)SoluçãoDe partida: Em-locais à faísca de Cisco

A edição 1. Expressway é incapaz de resolver o endereço de callservice.ciscospark.comSoluçãoA porta 5062 da edição 2. é de partida obstruído à faísca de CiscoSoluçãoMisconfiguration da regra de busca de Expressway da edição 3.SoluçãoMisconfiguration COMPLETO de Expressway da edição 4.SoluçãoBidirecional: Cisco acende aos Em-locais ou aos Em-locais à faísca de Cisco O valor-limite do telefone IP/Colaboração da edição 1. está oferecendo um codec de áudiodiferentes de G.711, de G.722, de AAC-LD, ou de opusSoluçãoA edição 2. unificou o tamanho máximo do mensagem recebida CM excedidoSoluçãoApêndice 1: Ferramentas de Troubleshooting de ExpresswayVerifique a utilidade do teste padrãoEncontre a utilidadeRegistro diagnósticoReferências

Introdução

Este documento descreve a faísca que de Cisco o serviço híbrido do atendimento conecta asolução que permite que sua infraestrutura existente do Controle de chamadas de Cisco conecteà nuvem da colaboração do Cisco de modo que possam trabalhar junto.

Pré-requisitos

Requisitos

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

Conhecimento da oferta da faísca de Cisco●

Conhecimento da solução de Expressway (B2B)●

Conhecimento do gerente das comunicações unificadas de Cisco (CM unificado) e da suaintegração com Expressway

●

CM unificado 10.5(2) SU5 ou mais tarde.●

Versão X8.7.1 de Expressway (B2B) ou mais tarde (X8.9.1 é recomendado)●

Expressway (host do conector) -- veja o conector de Expressway hospedar atualmente oapoio para serviços híbridos da faísca de Cisco para as versões suportadas

●

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

Gerente das comunicações unificadas de Cisco●

https://collaborationhelp.cisco.com/article/en-us/ruyceab

https://collaborationhelp.cisco.com/article/en-us/ruyceab

Vias expressas●

Cisco acende para Windows●

Cisco acende para o Mac●

Cisco acende para o iOS●

Cisco acende para Android●

Valores-limite da colaboração do Cisco●

Valores-limite da mesa da Colaboração●

Telefones IP●

Clientes de software●

As informações neste documento foram criadas a partir de dispositivos em um ambiente delaboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com umaconfiguração (padrão) inicial. Se sua rede está viva, assegure-se de que você compreenda oimpacto potencial do comando any.

Informações de Apoio

A solução oferece a estes a capacidade:

Use o app da faísca de Cisco como um cliente macio móvel para atendimentos do áudio e dovídeo

●

Use o app para fazer e receber atendimentos de em qualquer lugar, como se estavam noescritório

●

Use a faísca de Cisco, Cisco Jabber, ou seu telefone de mesa para chamar, sem anecessidade de preocupar-se sobre que opção usam

●

Destrave o histórico da chamada em telefones dos em-locais e integre-o que história nafaísca de Cisco

●

O espaço deste guia é cobrir as edições que são originais ao serviço híbrido do atendimentoconectam. Desde que o serviço híbrido do atendimento conecta executa sobre os mesmos paresdo C de Expressway E& que as outras soluções tais como o móbil e o Acesso remoto e chamadainterempresarial, edições com as outras soluções podem afetar o serviço híbrido do atendimentoconectam. Para clientes e Parceiros que distribuem um par de Expressway para o uso comserviço do atendimento conecta, o VCS Expressway de Cisco e o guia de configuração básica docontrole do VCS deve ser provido antes que você tente distribuir o serviço híbrido do atendimentoconectar. Este guia de Troubleshooting cobre considerações Firewall/NAT junto com o projeto deExpressway no apêndice 3 & 4. revê esta documentação completamente. Adicionalmente, estedocumento supõe que o host do conector de Expressway e a ativação híbrida do serviço doatendimento estiveram terminados.

Edições da configuração de chamada

Falhas mútuas do handshake de TLS

O serviço híbrido do atendimento conecta o Transport Layer Security mútuo dos usos (TLSmútuo) para a autenticação entre a faísca de Cisco e Expressway-e. Isto significa queExpressway-e e a faísca de Cisco verificam e inspecionam o certificado que atual. Desde que asedições mútuas TLS são tão predominantes durante disposições novas dos server deExpressway e a habilitação das soluções tais como o serviço híbrido do atendimento conecta,esta seção fornece a informação util e derruba-a para pesquisar defeitos edições baseadas

/content/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-9/Cisco-VCS-Basic-Configuration-Control-with-Expressway-Deployment-Guide-X8-9.pdf


certificado entre as vias expressas e a faísca de Cisco.

Que Expressway-e verifica?

O certificado da faísca de Cisco foi assinado por um público CA que fosse alistado na listaconfiada Expressway-e de CA?

●

Está callservice.ciscospark.com atual no campo de nome alternativo sujeito do certificado dafaísca de Cisco?

●

Que a faísca de Cisco verifica?

O certificado de Expressway-e foi assinado por um do público CA que acende confianças.(Cisco acende a lista confiada de CA)

●

Se Expressway-e não usa publicamente um certificado assinado, o certificado de Expresswayjunto com alguma raiz e Certificados do intermediário foi transferido arquivos pela rede aCisco acende o hub do controle (https://admin.ciscospark.com)?

●

Isto é explicado segundo as indicações da imagem.

Dicas de Troubleshooting mútuos úteis TLS

1. Descodifique o handshake de TLS mútuo

Àrevelia, as marcas de Wireshark SORVEM o tráfego TLS como a porta 5061. O que este osmeios são que em qualquer altura que você quer analisar o handshake de TLS (mútuo) a que osoccurrs sobre a porta 5062, Wireshark não saberão descodificar corretamente o tráfego. Está aquium exemplo do handshake de TLS mútuo que esteja ocorrendo sobre a porta 5062 segundo asindicações da imagem.

https://collaborationhelp.cisco.com/article/en-us/0q4utq

https://admin.ciscospark.com

Como você pode ver, este é como o aperto de mão olha com as configurações padrão emWireshark. O pacote número 175 é o certificado que Expressway envia a Cisco a faísca. Contudo,você não pode determinar que sem o tráfego que está sendo descodificado. Há dois métodos quevocê pode usar a descodificação este tráfego de modo que você possa mais facilmente ver ainformação do certificado e todos os Mensagens de Erro que estarem presente.

1a. Decod o córrego como o SSL

a. Quando você analisa o handshake de TLS mútuo, filtre primeiramente a captação portcp.port==5062. Após isto, clicar com o botão direito o primeiro pacote no córrego e seletodescodifique como… segundo as indicações da imagem.

b. A descodificação como… a opção é selecionada uma vez, você considera uma lista onde vocêpossa selecionar como descodificar o córrego que você selecionou. Da lista, oSSL seleto, clique aplica, e fecha o indicador. Neste momento, o córrego inteiro mostra ocertificado e os Mensagens de Erro trocados na altura do aperto de mão segundo as indicaçõesda imagem.

1b. Ajuste a porta do SORVO TLS

Quando você ajusta a porta do SORVO TLS a 5062 nas preferências de Wireshark, você podeentão ver todos os detalhes que cercam o aperto de mão, que inclui os Certificados. A fim fazeresta mudança:

Abra Wireshark●

Navegue ao Editar > Preferências●

Expanda protocolos e selecione o SORVO●

Ajuste a porta do SORVO TLS a 5062 e o clique aplica-se●

Ajuste o valor de volta a 5061 quando a análise é terminada segundo as indicações daimagem.

●

Se você analisa a mesma captação agora, você vê os pacotes 169 a 175 descodificados. Opacote 175 mostra o certificado de Expressway-e e se você fura para baixo no pacote, você podever todos os detalhes certificados segundo as indicações da imagem.

2. Filtração de Wireshark

Quando você analisa capturas de pacote de informação, é fácil obter perdido na quantidadecompleta de pacotes observados em uma captação dada. É importante compreender que tipo detráfego você está o mais interessado dentro de modo que você possa filtrar Wireshark paraindicar apenas aquele. Estão aqui alguns filtros comuns de Wireshark que podem ser usadospara obter detalhes sobre um handshake de TLS mútuo:

tcp.port==5062●

&&tcp.port==5062 SSL●

&&tcp.port==5062 ssl.handshake.certificate●

3. Certificado do extrato de Pcap

De vez em quando, você pode precisar de obter uma cópia de um certificado (server, raiz, ouintermediário). Se você não sabe onde encontrar o certificado que você está na busca para, vocêpode extrai-la diretamente de uma captura de pacote de informação. Estão aqui as etapas paraque como puxe Cisco acendem o certificado que é apresentado em um handshake de TLSmútuo.

Filtre a captura de pacote de informação com && tcp.port==5062 ssl.handshake.certificate1.Encontre o pacote que é originado do endereço do servidor da faísca e tem o certificadoimpresso na seção de informação.

2.

Nos detalhes de pacote expanda Secure Socket Layer > o certificado > o protocolo dehandshake > os Certificados TLS Note: Certificado inferior/último na corrente é a CA raiz.

3.

Clicar com o botão direito o certificado do interesse e selecione bytes de pacoteselecionados exportação… segundo as indicações da imagem.

4.

5. Salvar o arquivo como .cer.

6. Fazer duplo clique o arquivo salvo para abrir o certificado segundo as indicações da imagem.

4. Ajuste níveis de registro de Expressway

Dois módulos de registro estão disponíveis em Expressway que podem o ajudar melhor acompreender que lógica Expressway executa quando você analisa os Certificados:

developer.ssl●

developer.zone.zonemg●

Àrevelia, estes módulos de registro são ajustados a um nível da INFORMAÇÃO. Quando grupo anível de debug, você pode para começar para ver informação sobre certificado inspeção a queacontece, junto com que tráfego da zona obtém traçou. Both of these funções são relevantes aoserviço híbrido do atendimento.

Exemplo de Expressway-e que conduz uma inspeção SAN do certificado de servidor da faísca deCisco.

2017-09-22T11:11:19.485-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,485"

Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)"

Method="::ttssl_continueHandshake" Thread="0x7f576cbee700": Detail="Handshake in progress"

Reason="want read/write"


Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1960)"

Method="::ttssl_continueHandshake" Thread="0x7f576cbee700": Detail="Handshake succeeded"



Method="::TTSSL_retrieveCommonName" Thread="0x7f576cbee700": Detail="Found common name in peer

certificate" CommonName="l2sip-cfa-01.ciscospark.com"



Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700": Detail="Found DNS alt-name in peer

certificate" AltName="l2sip-cfa-01.ciscospark.com"




certificate" AltName="l2sip-cfa-01.wbx2.com"




certificate" AltName="l2sip-cfa-01-web.wbx2.com"




certificate" AltName="l2sip-cfa-web.wbx2.com"




certificate" AltName="callservice.ciscospark.com"




certificate" AltName="callservice.call.ciscospark.com"

Exemplo de Expressway-e que traça a conexão MTLS à zona DNS do híbrido da faísca de Cisco


Module="developer.zone.zonemgr" Level="DEBUG"

CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1226)"

Method="ZoneManager::getDNSZoneByTLSVerifySubjectName" Thread="0x7f577f0a0700":

this="0x56408ff81220" getDNSZoneByTLSVerifySubjectName classified subject name

callservice.ciscospark.com into DNS zone Hybrid Call Services DNS




Method="ZoneManager::getDNSZoneByTLSVerifySubjectNameList" Thread="0x7f577f0a0700":

this="0x56408ff81220" Detail="Searched for DNS Zones by Subject Name" Found="True"

Candidates="l2sip-cfa-01.ciscospark.coml2sip-cfa-01.ciscospark.coml2sip-cfa-01.wbx2.coml2sip-

cfa-01-web.wbx2.coml2sip-cfa-web.wbx2.comcallservice.ciscospark.com" MatchedZone="Hybrid Call

Services DNS" MatchedIdentity="callservice.ciscospark.com"




Method="ZoneManager::getZoneByIdentities" Thread="0x7f577f0a0700": this="0x56408ff81220"

Detail="getZoneByIdentities, match complete" Identitites="{CN: l2sip-cfa-01.ciscospark.com, Alt-

DNS: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.wbx2.com, Alt-DNS: l2sip-cfa-01-

web.wbx2.com, Alt-DNS: l2sip-cfa-web.wbx2.com, Alt-DNS: callservice.ciscospark.com, Alt-DNS:

callservice.call.ciscospark.com, Alt-DNS: l2sip-a-sparkcall.ciscospark.com, Alt-DNS: l2sip-prod-

11-dfw-public.wbx2.com, Alt-DNS: l2sip-prod-12-dfw-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-

294-riad-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-817-riad-public.wbx2.com, Alt-DNS: l2sip-

l2sip-prod-wpsjc-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.wbx2.com, Alt-DNS:

l2sip-l2sip-prod-wpdfw-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.wbx2.com, Alt-

DNS: l2sip-cfa-02.wbx2.com, Alt-DNS: sparkcmr-wpa.ciscospark.com, Alt-DNS: sparkcmr-

wpb.ciscospark.com, Alt-DNS: sparkcmr-wpc.ciscospark.com, Alt-DNS: l2sip-wpa-01.wbx2.com, Alt-

DNS: l2sip-wpa-02.wbx2.com, Alt-DNS: l2sip-wpb-01.wbx2.com, Alt-DNS: l2sip-wpb-02.wbx2.com, Alt-

DNS: l2sip-wpc-01.wbx2.com, Alt-DNS: l2sip-wpc-02.wbx2.com}" MatchMechanism="DNSZoneMatch"

MatchedZone="Hybrid Call Services DNS"

Está aqui uma lista da maioria de problemas comuns que são relacionados às falhas mútuas TLSentre Expressway-e e a faísca de Cisco.

A edição 1. Expressway-e não confia o Certificate Authority (CA) que assinou o certificado dafaísca de Cisco

Cisco acende o server que está em uma comunicação direta com Expressway-e é chamado umserver L2SIP. Este server L2SIP deve ser assinada por um server intermediário com um CommonName da boca de incêndio SSL ICA G2. O intermediário é assinado por um Certificate Authorityda raiz que tem um Common Name da CA raiz 2 de QuoVadis segundo as indicações daimagem.

Note: Isto podia ser sujeito mudar.

A primeira etapa para analisar este tráfego da perspectiva diagnóstica de Expressway é procurarpela conexão TCP. Depois que você procura o TCP que conecta, você procurará o valor Dst-port=5062. Uma vez que você identifica a área nos logs onde esta conexão esteve tentada eestabelecida, você pode então procurar o handshake de TLS que é denotado geralmente pelasentradas de registro que indica o aperto de mão em andamento.



Method="::ttssl_continueHandshake" Thread="0x7f29ddefa700": Detail="Handshake in progress"


Se Expressway-e não confia que Cisco acende certificados assinados, você pode esperar queExpressway-e pode rejeitar o certificado imediatamente depois que o aperto de mão termina. Istopode ser manchado em Expressway-e que registra por estas entradas de registro:

2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error"

Service="SIP" Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2" Dst-port="5062"

Detail="self signed certificate in certificate chain" Protocol="TLS" Level="1" UTCTime="2017-09-

20 14:49:18,724"


Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)"

Method="::TTSSLErrorOutput" Thread="0x7f29ddefa700": TTSSL_continueHandshake: Failed to

establish SSL connection iResult="-1" error="1" bServer="true"

localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.73:58531']"

ssl_error_reason="error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify

failed"


Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.73" Src-port="58531" Dst-ip="172.16.2.2"

Dst-port="5062" Detail="TCP Connection Closed" Reason="self signed certificate in certificate

chain"

O Mensagem de Erro de Expressway pode levemente enganar-se porque refere um certificadoassinado do auto no certificate chain. Wireshark permite que você olhe um olhar mais atento atroca. De uma perspectiva da análise da captura de pacote de informação do wireshark, vocêpode claramente ver que quando o ambiente da faísca apresenta é certificado então Expresswaygerencie ao redor e rejeições com o certificado com um erro desconhecido de CA segundo asindicações da imagem.

Solução

A fim resolver esta situação, você deve assegurar-se de que Expressway-e confie as autoridadesde certificação da faísca de Cisco. Quando você poderia simplesmente extrair estes Certificadosde um traço do wireshark e os transferir arquivos pela rede à loja do certificado de CA confiadoem Expressway, Expressway oferece um método mais simples:

Log em Expressway-e●

Navegue toApplications > gerenciamento certificado da nuvem●

Seleto obtenha a opção dos Certificados segundo as indicações da imagem.●

Neste momento, Cisco acende autoridades de certificação é transferido arquivos pela rede aExpressway-e confiou a loja de CA (> segurança da manutenção > certificado de CA confiado).

O nome incorreto da edição 2. para o assunto TLS verifica o nome na zona DNS do híbrido dafaísca de Expressway-e Cisco

Como parte do handshake de TLS mútuo, o serviço híbrido do atendimento conecta a verificaçãodos usos TLS. Isto significa que além do que a confiança de Cisco acenda certificados de CA,Expressway verifica que o certificado verificando o campo sujeito do nome alternativo (SAN) docertificado que é apresentado para assegurar ele tem um valor tal comocallservice.ciscospark.com atual. Se este valor não está atual, a chamada recebida falha.

Neste cenário particular, Cisco acende o presente do server seu certificado a Expressway-e. Ocertificado tem realmente 25 diferentes sem. Considere o caso onde Expressway-e verifica ocertificado para ver se há callservice.ciscospark.com SAN mas não encontre isso. Quando estacircunstância é estada conforme, você pode ver um erro similar a este dentro do registro dodiagnóstico:



Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1"

UTCTime="2017-09-20 15:17:42,700"



Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was

unacceptable"

Se você usa o wireshark para analisar este aperto de mão do certificado, você pode encontrarque depois que Cisco acende presentes seu certificado, Expressway RST a conexão shortly aftersegundo as indicações da imagem.

A fim confirmar a configuração deste valor, você pode ir à zona DNS híbrida da faísca que foiconfigurada para a solução. Se você tem o xConfiguration de Expressway-e, você pode procurar

a seção de configuração da zona para determinar como o TLS verifica que o nome do sujeitoesteve configurado. Para o xConfiguration, note que as zonas estão pedidas com a zona 1 que éas primeiras. Está aqui um xConfiguration do ambiente problemático analisado acima.

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "calllservice.spark.com"

Como você pode ver no exemplo acima o TLS verifique que o nome do sujeito está ajustado acalllservice.spark.com em vez de callservice.ciscospark.com.

Solução

A fim resolver esta edição, o TLS verifica que o nome do sujeito deve ser alterado:

Log em Expressway-e●

Navegue à configuração > às zonas > às zonas●

Selecione a zona DNS dos serviços do híbrido da faísca●

Ajuste o TLS verificam o nome do sujeito a callservice.ciscospark.com●

Selecione a salvaguarda●

Note: Veja o comportamento de registro da linha de base do thefor. Esta seção mostraExpressway que executa a verificação de certificado e o mapeamento à zona DNS dohíbrido da faísca.

A edição 3. Expressway-e não envia o certificate chain completo à faísca de Cisco

Como parte do handshake de TLS mútuo, Cisco acende deve confiar o certificado deExpressway-e. Cisco acende tem uma lista completa do público CA que confie. Tipicamente, umhandshake de TLS é bem sucedido quando seu certificado de Expressway-e é assinado por CApúblico que Cisco acende apoios. Pelo projeto, Expressway-e envia somente seu certificadodurante um handshake de TLS apesar da assinatura por um público CA a fim enviar a correntecompleta dos Certificados (raiz e intermediário), aqueles Certificados deve ser adicionado a lojaem Expressway-e própria do certificado de CA confiado.

Se esta circunstância não é estada conforme, Cisco acende rejeições o certificado deExpressway-e. Quando você pesquisa defeitos uma circunstância que combine este problema,você pode usar os log de diagnóstico e o tcpdump de Expressway-e. Quando você analisa os logde diagnóstico de Expressway-e, você verá um erro similar àquele aqui:



Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-19

15:12:09,721"



Method="::TTSSLErrorOutput" Thread="0x7fc67c6ec700": TTSSL_continueHandshake: Failed to

establish SSL connection iResult="0" error="1" bServer="true"


ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"



Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Se você analisa este de uma perspectiva de Wireshark, você vê que Expressway-e apresenta seucertificado. Se você expande o pacote, você pode ver que somente o certificado de servidor estáenviado. Cisco acende rejeita então este handshake de TLS com um Mensagem de Errodesconhecido de CA segundo as indicações da imagem.

Solução

A fim endereçar a edição nesta encenação, você deve transferir arquivos pela rede ointermediário e a raiz CA que são envolvidos na assinatura do certificado de Expressway-e à lojado certificado de CA confiado:

Etapa 1. Log em Expressway-e.Etapa 2. Navegue ao > segurança da manutenção > certificado de CA confiado.Etapa 3. Seleto escolha o arquivo sob o menu da transferência de arquivo pela rede perto daparte inferior do UI.Etapa 4. Escolha o certificado de CA que foi envolvido na assinatura de Expressway-e.Etapa 5. Seleto adicione o certificado de CA.Etapa 6. Repita etapas para todos os certificados de CA envolvidos na assinatura do certificadode Expressway-e (intermediário, raiz).Etapa 7. Seleto adicione o certificado de CA.

Uma vez que este processo é terminado, você vê que a corrente completa dos Certificadosenvolvidos em assinar o certificado de servidor de Expressway-e incluído nas trocas de chave.Está aqui uma amostra do que você veria se você que analisa uma captura de pacote deinformação com Wireshark.

O Firewall da edição 4. termina o handshake de TLS mútuo

De Expressway da solução os intefaces tipicamente com um Firewall. Muitas vezes, o Firewallinline para a solução é executa algum tipo de inspeção da camada de aplicativo. Frequentementecom a solução de Expressway, quando o Firewall executa a inspeção da camada de aplicativo, osadministradores veem resultados indesejados. Esta questão particular ajuda-o a identificarquando a inspeção da camada de aplicativo de um Firewall rasgou abruptamente para baixo aconexão.

Com o uso dos log de diagnóstico de Expressway, você pode procurar o handshake de TLSmútuo tentado. Este aperto de mão, como mencionado mais cedo, deve vir shortly after aconexão de TCP é estabelecida sobre a porta 5062. Nesta encenação, quando o Firewallrasga para baixo a conexão, você vê estes erros dentro do registro diagnóstico.

Thread="0x7f6496669700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-

1" error="5" bServer="false" localAddress="['IPv4''TCP''172.17.31.10:28351']"

2017-06-13T13:31:38.760-05:00 vcse tvcs: Event="Outbound TLS Negotiation Error" Service="SIP"

Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="No SSL

error available, probably remote disconnect" Protocol="TLS" Common-

name="callservice.ciscospark.com" Level="1" UTCTime="2017-06-13 18:31:38,758"

2017-06-13T13:31:38.760-05:00 vcse tvcs: UTCTime="2017-06-13 18:31:38,758" Module="network.tcp"

Level="DEBUG": Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062"

Detail="TCP Connection Closed" Reason="Got EOF on socket"

De uma perspectiva da captura de pacote de informação, você verá que Expressway-e apresentaseu certicate à faísca de Cisco. Você vê um TCP RST vir dentro do sentido da faísca de Ciscosegundo as indicações da imagem.

Àprimeira vista, você pode pensar que algo é errado com o certificado de Expressway-e. A fimpesquisar defeitos esta edição, você primeiramente tem que determinar respostas a estasperguntas:

Expressway-e é assinado por CA público que Cisco acende confianças?●

O certificado de Expressway-e e algum Certificados são envolvidos na assinatura docertificado de Expressway-e transferido arquivos pela rede manualmente ao hub do controleda faísca de Cisco (https://admin.ciscospark.com)?

●

Nestas condições particulares, a solução não era usar Cisco acende o hub do controle paracontrolar os Certificados de Expressway-e. Este meio o certificado de Expressway-e deve serassinado por CA público que Cisco acende confianças. Selecionando no pacote do certificado nacaptação de Wireshark (como ilustrado acima), você pode ver que o certificado esteve assinadopor CA público e que a corrente completa esteve enviada à faísca de Cisco. Consequentemente,


a edição não deve ser relacionada ao certificado de Expressway-e.

Neste momento, se um isolamento mais adicional é exigido, você poderia tomar uma captura depacote de informação fora da interface externa do Firewall. Contudo, a falta do erro SSL no log dediagnóstico é um ponto de dados importante. Se você recorda acima (edição 3.), se Cisco acendenão confia o certificado de Expressway-e, você deve ver algum tipo de motivo de desconexãoSSL. Nesta circunstância, não havia nenhum erro SSL disponível.

Note: Se você devia obter uma captura de pacote de informação fora da interface externado Firewall você não veria um TCP RST vir dentro do ambiente da faísca de Cisco.

Solução

Para esta solução particular, você como um sócio ou o cliente devem confiar em seu equipe desegurança. A equipe deve investigar se usam meio a inspeção da camada de aplicativo para asolução de Expressway e se são, isto devem ser desabilitados. O apêndice 4 do controle do VCSe do guia de distribuição de Expressway explica porque é clientes recomendados desliga estafuncionalidade.

A edição 5. Expressway-e é assinada por CA público mas Cisco acende o hub do controle temCertificados alternativos carregados

Esta condição particular pode frequentemente ocorrer quando você distribuiu a solução deExpressway a partir do zero e você não tem o certificado de Expressway-e assinado inicialmentepor CA público. O que acontece nesta encenação é que você transfere arquivos pela rede ocertificado de servidor de Expressway-e (que foi assinado internamente) ao hub do controle dafaísca de Cisco de modo que você possa terminar a negociação mútua TLS com sucesso. Maistarde, você termina acima a obtenção do certificado de Expressway-e assinado por CA público,porém você esquece remover o certificado de servidor do hub do controle da faísca de Cisco. Éimportante saber que quando um certificado é transferido arquivos pela rede ao hub do controleda faísca de Cisco, esse certificado toma a prioridade sobre que certificado e acorrente ospresentes de Expressway durante o handshake de TLS.

De uma perspectiva de registro diagnóstica de Expressway-e, esta edição pode olhar similar àassinatura de registro que é encontrada quando Cisco acende não confia o certificado deExpressway-e -- por exemplo, o exemplo de Expressway-e que não envia sua corrente completaou o certificado de Expressway-e que não está sendo assinado por CA público que Cisco acendeconfianças. Está abaixo uma amostra do que você pode esperar em Expressway-e que registradurante o handshake de TLS:




14:22:13,668"



Method="::TTSSLErrorOutput" Thread="0x7f4a2c16f700": TTSSL_continueHandshake: Failed to








Olhe este da perspectiva que de Wireshark você pode ver aqui que Expressway-e apresenta seucertificado no item de linha 175. Alguns itens de linha mais tarde, Cisco acendem o ambienterejeitam o certificado com um erro desconhecido do certificado segundo as indicações daimagem.

Se você seleciona o pacote do certificado que Expressway-e envia, você pode expandir ainformação do certificado para determinar se Expressway-e

1. é assinado por CA público que Cisco acende confianças, e

2. está incluindo sua corrente completa envolvida na assinatura.

Nesta situação, both of these circunstâncias são estadas conformes. Isto sugere que não hajanada erradamente com o certificado de Expressway-e.

Solução

Etapa 1. Log no hub do controle da faísca de Cisco.Etapa 2. Selecione serviços do painel esquerdo.

Etapa 3. Escolha ajustes sob o cartão de atendimento híbrido.

Etapa 4. O rolo ao serviço do atendimento conecta a seção e o olhar sob os Certificados para oSORVO cifrado chama para considerar se os Certificados indesejados estão listados. Em casoafirmativo, clique o ícone do balde do lixo ao lado do certificado.

etapa 5. Seleto remova.

Note: É importante que a análise está conduzida e se determina que o cliente não estáusando os Certificados transferidos arquivos pela rede ao hub do controle da faísca antesdos remover.

Para obter mais informações sobre de transferir arquivos pela rede seu certificado deExpressway-e no hub do controle da faísca de Cisco, verifique esta seção do guia de distribuiçãohíbrido do atendimento.


https://admin.ciscospark.com/#/login

/content/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide/cmgt_b_ciscospark-hybrid-call-service-config-guide_chapter_01001.html#reference_48C1397691BF52CE705EA4BDAC105133

/content/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide/cmgt_b_ciscospark-hybrid-call-service-config-guide_chapter_01001.html#reference_48C1397691BF52CE705EA4BDAC105133

A edição 6. Expressway não está traçando a chamada recebida à zona DNS do híbrido da faíscade Cisco

Os trabalhos de entrada da característica do mapeamento TLS conjuntamente com o TLSverificam o nome do sujeito, ambo são configurados na zona DNS híbrida do atendimento. Acaracterística divide em um processo de etapa de três:

Expressway-e aceita o certificado da faísca de Cisco.1.Expressway-e inspeciona o certificado da faísca de Cisco para determinar se há um nomealternativo sujeito que combine o TLS verifique o nome do sujeito:callservice.ciscospark.com.

2.

Expressway-e traça a conexão de entrada através da zona DNS do híbrido da faísca deCisco.

3.

Se a autenticação não é bem sucedida, esta significa que a validação certificada falhou. Oatendimento participa na zona padrão e está distribuído de acordo com as regras de buscafornecidas para encenações interempresariais, se o business-to-business é configurado emExpressway-e.

Como as outras encenações, você deve usar ambo o registro e capturas de pacote de informaçãodiagnósticos para determinar o que esta falha olha como, a seguir usa a captura de pacote deinformação para ver que lado está enviando o RST. Está aqui uma amostra da conexão de TCPque está sendo tentada, estabelecendo então.



Dst-port="5062" Detail="TCP Connecting"



Dst-port="5062" Detail="TCP Connection Established"

Agora que a conexão de TCP estabeleceu, o handshake de TLS pode seguir. Você pode vershortly after o aperto de mão começa, ele rapidamente erros para fora.



Method="::ttssl_continueHandshake" Thread="0x7f044e7cc700": Detail="Handshake in progress"




Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1"

UTCTime="2017-09-22 14:09:57,123"



Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was

unacceptable"

Olhe esta situação de uma perspectiva do pcap, você pode obter um sentido melhor de

quem está enviando o RST, e●

que Certificados estão sendo passados para determinar se estão corretos.●

Quando você analisa esta captação particular, você pode ver que Expressway-e envia o RST.Quando você olha o certificado da faísca de Cisco que está passado, você pode ver que envia acorrente completa. Adicionalmente, você pode concluir que baseado fora do Mensagem de Errono log de diagnóstico, você pode ordenar para fora a encenação onde Expressway-e não confia

que Cisco acende o público CA. Se não, você veria um erro como do “o certificado assinado autono certificate chain”. Você pode escavar nos detalhes de pacote segundo as indicações daimagem.

Pelo clique o certificado de servidor da faísca e expansão dele para ver os nomes alternativossujeitos (dnsName) que você pode verificar para se assegurar de que tenhacallservice.ciscospark.com aliste.

Navegue a Wireshark: Certificado > extensão > nomes gerais > GeneralName > dNSName:callservice.ciscospark.com

Isto confirma inteiramente que o certificado da faísca olha apenas fino.

Você pode agora confirmar que o TLS verifica que o nome do sujeito está correto. Comomencionado, se você tem o xConfiguration você pode procurar a seção de configuração da zonapara determinar como o TLS verifica que o nome do sujeito esteve configurado. Uma coisa anotar sobre o xConfiguration é que as zonas estão pedidas com zona 1 são criadosprimeiramente. Está aqui um xConfiguration do ambiente problemático analisado acima. É claroque nada é errado com o TLS verifica o nome do sujeito.


*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"

A coisa seguinte que deve ser investigada é o TLS verifica o mapeamento de entrada. Istoconfirma se você está traçando corretamente a conexão TLS à zona DNS do híbrido da faísca. OxConfiguration pode ser leveraged para analisar também isto. No xConfiguration o TLS verificaque o mapeamento de entrada está chamado o FECHO DE CORRER TLS DNS verificaInboundClassification. Como você pode ver neste exemplo o valor é ajustado a fora.

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "Off"

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

Dado que este valor está ajustado a fora, o que este os meios são que o VCS está impedido datentativa traçar conexões TLS de entrada a esta zona. O atendimento participa assim na zonapadrão e está verificado e distribuído de acordo com as regras de busca fornecidas paraencenações interempresariais, se o business-to-business é configurado em Expressway-e.

Solução

A fim endereçar isto que você precisa de ajustar o TLS verifica o mapeamento de entrada nazona DNS híbrida do atendimento a sobre. Estão aqui as etapas para terminar isso.

Log em Expressway-e1.Navegue à configuração > às zonas > às zonas2.Selecione a zona DNS híbrida do atendimento3.Para o TLS verifique o mapeamento de entrada, escolhem sobre4.Selecione a salvaguarda5.

Note: Veja para o comportamento de registro da linha de base. Esta seção mostraExpressway que executa a verificação de certificado e o mapeamento à zona DNS dohíbrido da faísca.

Os usos de Expressway-e da edição 7. optam pelo certificado auto-assinado

Em algumas disposições novas de atendimento híbrido preste serviços de manutenção conectam,a assinatura do certificado de Expressway-e é negligenciada ou acreditou que o certificado deservidor do padrão pode ser usado. Alguns povos pensam que este é possível porque Ciscoacende o hub do controle o deixa carregar um certificado feito sob encomenda no portal.(Serviços > ajustes (sob o cartão de atendimento híbrido) > transferência de arquivo pela rede(sob Certificados para atendimentos cifrados))

Se você paga a toda atenção ao fraseio sobre os Certificados por atendimentos cifrados doSORVO, você vê este: “Use os Certificados fornecidos da lista da confiança do padrão dacolaboração do Cisco ou transfira arquivos pela rede seus próprios. Se você usa seus próprios,assegure-se de que os nomes de host estejam em um domínio verificado.” A parte chave a essaindicação é “certifica-se que os nomes de host estão em um domínio verificado.”

Quando você pesquisa defeitos uma edição que combine esta circunstância, mantenha na menteque o sintoma está indo ser dependente do sentido do atendimento. Se o atendimento originadopelo em-locais telefona, você pode esperar que Cisco acende o app não soaria. Também, sevocê tentou seguir o atendimento da história da busca das vias expressas, você encontraria que oatendimento a faria a Expressway-e e a pararia lá. Se o atendimento originado de um app dafaísca de Cisco e era destinado para os locais, os em-locais que o telefone não soa. Nesseexemplo, a história de Expressway-e e de Expressway-C Seach não mostraria qualquer coisa.

Neste cenário particular, o atendimento originou de um telefone dos em-locais. Usando a históriada busca de Expressway-e, você pode determinar que o atendimento a fez ao server. Nestemomento, você pode mergulhar no registro diagnóstico para determinar o que aconteceu. Paracomeçar esta análise, primeiro olhar ver se uma conexão de TCP foi tentada e estabelecida sobrea porta 5062. Procurando os log de diagnóstico de Expressway-e pelo “TCP que conecta” e queprocura o item de linha com a etiqueta "Dst-port=5062", você pode determinar se a conexãoestabelece.






Dst-port="5062" Detail="TCP Connection Established"

Agora que você confirmou a conexão de TCP estabelecida, você pode analisar o handshake deTLS mútuo de que acontece imediatamente depois. Como você pode ver no snippet aqui, o

aperto de mão falha e o certificado é desconhecido (desconhecido alerta do certificadoDetail="sslv3”)



Method="::ttssl_continueHandshake" Thread="0x7f930adab700": Detail="Handshake in progress"





12:18:08,455"



Method="::ttssl_continueHandshake" Thread="0x7f930adab700": Detail="Handshake Failed"

Reason="want error ssl"



Method="::TTSSLErrorOutput" Thread="0x7f930adab700": TTSSL_continueHandshake: Failed to







Olhe um olhar mais atento a captura de pacote de informação fornecida com o registrodiagnóstico de Expressway-e, você pode ver que o erro desconhecido do certificado está obtendooriginado do sentido da faísca de Cisco segundo as indicações da imagem.

Se você inspeciona o certificado de servidor do padrão de Expressway-e, você pode ver que o“Common Name” e “os nomes alternativos sujeitos” não contêm “o domínioverificado” (rtp.ciscotac.net). Você tem então a evidência sobre o que causa esta edição segundoas indicações da imagem.

Neste momento, você determinou que o certificado de servidor de Expressway-e precisa de serassinado por CA público ou por CA interno.

Solução

A fim resolver esta edição, você tem duas opções:

Tenha o certificado de Expressway-e assinado por CA público que Cisco acende confianças.Log em Expressway.Navegue ao > segurança > ao certificado de servidor damanutenção.Seleto gerencia o CSR.Incorpore a informação exigida do certificado eassegure-se de que o campo de nomes alternativo adicional contenha o domínio verificadoalistado no hub do controle da faísca.O clique gerencie o CSR.Forneça o CSR a uma 3ªparte CA público assinando.Em cima do retorno do certificado, navegue ao > segurança >aos certificados de servidor da manutenção.Na seção nova do certificado da transferênciade arquivo pela rede ao lado de seleto o arquivo de certificado de servidor, seleto escolhe oarquivo e seleciona o certificado assinado.Selecione dados do certificado de servidor datransferência de arquivo pela rede.Navegue ao > segurança da manutenção > certificado deCA confiado.Na seção da transferência de arquivo pela rede ao lado seleta do arquivo quecontém os certificados de CA confiados seletos escolha o arquivo.Selecione quaisquercertificados de CA da raiz e do intermediário fornecidos por CA público.Seleto adicione ocertificado de CA.Reinicie Expressway-e.

1.

Mande o certificado de Expressway-e ser assinado por CA interno e transferir arquivos pelarede então CA interno e Expressway-e ao hub do controle da faísca de Cisco.Log em ExpresswayNavegue ao > segurança > ao certificado de servidor damanutenção.Seleto gerencia o CSRIncorpore a informação exigida do certificadoassegurando-se de que o campo de nomes alternativo adicional contenha o domínioverificado alistado no hub do controle da faíscaO clique gerencie o CSRForneça o CSR auma 3ª parte CA público assinandoEm cima do retorno do certificado, navegue ao >segurança > aos certificados de servidor da manutençãoNa seção nova do certificado datransferência de arquivo pela rede ao lado de seleto o arquivo de certificado de servidor,

2.


seleto escolhe o arquivo e seleciona o certificado assinadoSelecione dados do certificado deservidor da transferência de arquivo pela redeNavegue ao > segurança da manutenção >certificado de CA confiadoNa seção da transferência de arquivo pela rede ao lado seleta doarquivo que contém os certificados de CA confiados seletos escolha o arquivo.Selecionequaisquer certificados de CA da raiz e do intermediário fornecidos por CA público.Seletoadicione o certificado de CA.Reinicie Expressway-e.

2a. Transfira arquivos pela rede CA e o certificado internos de Expressway-e ao hub do controleda faísca de Cisco 1. Log no hub do controle da faísca de Cisco como um administrador. 2. Selecione serviços. 3. Selecione ajustes sob o cartão híbrido do serviço do atendimento. 4. Nos Certificados para a seção cifrada dos atendimentos do SORVO selecione atransferência de arquivo pela rede. 5. Escolha CA e os Certificados internos de Expressway-e.

De entrada: Cisco acende aos Em-locais

Quase cada Cisco de entrada acende aos resultados da falha dos em-locais no mesmo sintomarelatado: “Quando eu chamo de meu app da faísca de Cisco ao app de um outro colega, os anéisdo app do colega mas o telefone dos em-locais não fazem.” A fim pesquisar defeitos estaencenação, você encontrará útil compreender o fluxo de chamadas e a lógica que ocorre quandoeste tipo de atendimento está sendo colocado.

Fluxo de nível elevado da lógica

Cisco acende a chamada originada do app inicia o atendimento1.Anéis do app do número chamado2.O atendimento é bifurcado ao ambiente da faísca de Cisco3.Cisco acende o ambiente deve executar uma pesquisa de DNS baseada no destinoconfigurado do SORVO do cliente no hub do controle da faísca de Cisco

4.

Cisco acende tentativas do ambiente de conectar a Expressway sobre a porta 50625.Cisco acende tentativas do ambiente de executar um handshake de TLS mútuo6.Cisco acende o ambiente envia um SORVO CONVIDA a Expressway que seja passado parabaixo ao telefone da Colaboração endpoint/IP dos em-locais

7.

Cisco acende e a empresa termina a negociação do SORVO8.Cisco acende e a empresa começa a enviar e receber media.9.

Fluxo de chamada

Navegue ao app > ao Cisco da faísca de Cisco acendem o ambiente > o Expressway-e > oExpressway-C > o telefone da Colaboração Endpoint/IP dos Em-locais segundo as indicações daimagem.

https://admin.ciscospark.com/#/login

Estão aqui alguns dos problemas comuns observados com chamadas recebidas da faísca àinfraestrutura dos em-locais.

A edição 1. Cisco acende é incapaz de resolver Expressway-e DNS SRV/hostname

Ao pensar sobre a faísca de Cisco ao fluxo de chamadas dos em-locais, passo lógico da faíscade Cisco o primeiro é como contactar os em-locais Expressway. Como notável acima, Ciscoacende tentará conectar aos em-locais Expressway executando uma consulta SRV baseada nodestino configurado do SORVO que é alistado na página híbrida dos ajustes do serviço doatendimento no hub do controle da faísca de Cisco.

Se você tenta pesquisar defeitos esta situação de uma perspectiva do log de diagnóstico deExpressway-e, você não vê nenhum tráfego da faísca de Cisco. Se você tenta procurar pelo TCPque conecta, você não veria o Dst-port=5062, nem você veria todo o aperto de mão subsequenteou SORVO MTLS convidar da faísca de Cisco.

Se esta é a situação, você deve verificar como o destino do SORVO foi configurado no hub docontrole da faísca de Cisco. Você pode igualmente usar a ferramenta de teste de conectividadehíbrida para ajudar no Troubleshooting. A ferramenta de teste de conectividade híbrida verifica sehá um endereço dos DN válidos, se Cisco acende pode conectar à porta retornada na consultaSRV, e se os em-locais Expressway têm um certificado válido que Cisco acende confianças.

Log no hub do controle da faísca do theCisco1.SelectServices2.Selecione o theSettingslink no cartão de atendimento do theHybrid.3.



No atendimento preste serviços de manutenção conectam a seção verificam o domíniousado para o theSIP público Destinationfield do addressin do SORVO SRV.

4.

Se o registro esteve correto entrado, clique o teste para ver se o registro é válido.5.Como representado abaixo, você pode claramente ver que o public domain não tem umregistro correspondente do SORVO SRV associado a ele segundo as indicações daimagem.

6.

os resultados de teste seletos e você da vista podem considerar mais detalhe sobre o que falhousegundo as indicações da imagem.

Como uma outra aproximação, você pode igualmente olhar acima o registro SRV usando onslookup. Estão aqui os comandos que você pode executar para verificar se o destino do SORVOexiste.

C:\Users\pstojano>nslookup

> server 8.8.8.8

Default Server: google-public-dns-a.google.com

Address: 8.8.8.8

> set type=SRV

> _sips._tcp.mtls.rtp.ciscotac.net

Server: google-public-dns-a.google.com

Address: 8.8.8.8

DNS request timed out.

timeout was 2 seconds.

DNS request timed out.

timeout was 2 seconds.

*** Request to google-public-dns-a.google.com timed-out

Como você pode ver no bloco do código acima, o comando nslookup foi iniciado então o server éajustado a 8.8.8.8 que é um servidor DNS público de Google. Ultimamente, você está ajustandoos tipos de registro à consulta aos registros SRV. Nesse ponto, você pode então emitir o registroque completo SRV você quer olhar acima. O resultado de rede é que os pedidos cronometramfinalmente para fora.

Solução

Configurar um endereço público do SORVO SRV para Expressway-e no local que se usampara hospedar nomes do public domain.

1.

Configurar um hostname que resolva ao endereço IP público de Expressway-e2.

Configurar o destino do SORVO para alistar o domínio usado para o endereço do SORVOSRV criado em etapa 1. Log no hub do controle da faísca de CiscoSelecioneserviçosSelecione o link dos ajustes no cartão de atendimento híbridoNo atendimento presteserviços de manutenção conectam a seção incorporam o domínio usado para o endereçopúblico do SORVO SRV ao campo de destino do SORVO. Selecione a salvaguarda

3.

Note: Se o registro que do SORVO SRV você gostaria de se usar já está sendo leveragedpara comunicações interempresariais, nós recomendamos especificar um subdomínio dodomínio corporativo como o endereço da descoberta do SORVO no hub do controle dafaísca de Cisco, e consequentemente um registro do público DNS SRV, como segue:

Serviço e protocolo: _sips. _tcp.mtls.example.comPrioridade: 1Peso: 10Número de porta: 5062Alvo: us-expe1.example.com

A recomendação acima foi puxada diretamente do Guia de Design do híbrido da faísca de Cisco.

Solução alternativa

Se o cliente não tem um presente do registro do SORVO SRV (e não planeia criar um), podemalternativamente alistar o endereço IP público de Expressway suffixed por ":5062". Fazendo isso,o ambiente da faísca não tentará uma consulta SRV mas conectá-la-á um pouco diretamente ao%Expressway_Pub_IP%:5062. (Exemplo: 64.102.241.236:5062)

Configurar o destino do SORVO a ser formatado como%Expressway_Pub_IP%:5062. (Exemplo: 64.102.241.236:5062) Log no hub do controle dafaísca de CiscoSelecione serviçosSelecione o link dos ajustes no cartão de atendimentohíbridoNo atendimento preste serviços de manutenção conectam a seção incorporam o%Expressway_Pub_IP%:5062 ao campo de destino do SORVO. Selecione a salvaguarda

1.

Para obter mais informações sobre do endereço de destino do SORVO e/ou do SRV grave quedevem ser setup. Consulte a possibilidade que o serviço híbrido do atendimento conecta para suaseção da organização do guia híbrido da distribuição de serviço do atendimento da faísca deCisco ou Cisco acende o Guia de Design híbrido.

Falha de soquete da edição 2.: A porta 5062 é de entrada obstruído a Expressway

Depois que a resolução de DNS termina, Cisco acende o ambiente para tentar estabelecer umaconexão de TCP sobre a porta 5062 ao endereço IP de Um ou Mais Servidores Cisco ICM NTque foi retornado durante a pesquisa de DNS. Este endereço IP de Um ou Mais Servidores CiscoICM NT está indo ser o endereço IP público dos em-locais Expressway-e. Se Cisco acende oambiente é incapaz de estabelecer esta conexão de TCP, o atendimento de entrada aos locais ésubseqüentemente falha. O sintoma para esta condição particular é o mesmo que quase cadaoutro Cisco acende a falha da chamada recebida: o telefone dos em-locais não soa.

Se você está pesquisando defeitos esta edição usando os log de diagnóstico de Expressway,você não verá nenhum tráfego da faísca de Cisco. Se você tenta procurar pelo TCP que conecta,você não veria nenhuma tentativas de conexão para o Dst-port=5062, nem você veria todo oaperto de mão subsequente ou SORVO MTLS convidar da faísca de Cisco. Desde que o registro


/content/en/us/td/docs/solutions/PA/maroon/spark/hybdsrvs.html



/content/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide/cmgt_b_ciscospark-hybrid-call-service-config-guide_chapter_0110.html#task_67E3DD9B30843F3A802A0E548877CD55

/content/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide/cmgt_b_ciscospark-hybrid-call-service-config-guide_chapter_0110.html#task_67E3DD9B30843F3A802A0E548877CD55


diagnóstico de Expressway-e é inútil nesta situação, você tem alguns métodos possíveis para averificação:

Obtenha uma captura de pacote de informação fora da interface externa do Firewall1.Leverage uma porta que verifica a utilidade2.Use a ferramenta de teste de conectividade híbrida3.

Desde que a ferramenta de teste de conectividade híbrida é construída certo no hub do controleda faísca de Cisco e simula o ambiente da faísca de Cisco que tenta conectar aos em-locaisExpressway, é o método de verificação o mais ideal disponível. Para testar a Conectividade TCPna organização:

Log no hub do controle da faísca do theCisco1.SelectServices2.Selecione o theSettingslink no cartão de atendimento do theHybrid3.No atendimento preste serviços de manutenção conectam a seção asseguram-se de que ovalor incorporado ao destino do SORVO esteja correto

4.

Clique o teste segundo as indicações da imagem.5.

6. Desde que o teste falhou você pode clicar o link dos resultados de teste da vista para verificaros detalhes segundo as indicações da imagem.

Como observado na imagem acima, você pode ver que o teste do soquete falhou ao tentarconectar a 64.102.241.236:5062. Tendo estes dados além do que os log de diagnóstico/pcaps deExpressway não mostre todas as tentativas de conexão, você têm agora bastante evidênciainvestigar a configuração do Firewall ACL/NAT/Routing.

Solução


Desde que esta questão particular não é causada pelo ambiente da faísca de Cisco ou peloequipamento da Colaboração dos em-locais, você precisa de centrar-se sobre a configuração defirewall. Desde que você não pode necessariamente prever o tipo de Firewall que você estaráconectando com, você precisa de confiar em alguém com familiaridade com o dispositivo. Épossível que a edição poderia ser relacionada a um Firewall ACL, NAT, ou misconfiguration doroteamento.

Falha de soquete da edição 3.: Expressway-e não está escutando na porta 5062

Esta condição particular é diagnosticada frequentemente incorretamente. Muitas vezes, supõe-seque o Firewall é a causa para porque o tráfego sobre a porta 5062 está obtendo obstruído. Parapesquisar defeitos esta condição particular, você pode usar as técnicas a “porta 5062 é deentrada obstruído na encenação a Expressway” acima. Você encontrará que a ferramenta deteste de conectividade híbrida e toda a outra ferramenta usadas para verificar a conectividade deporta falharão. A primeira suposição é que o Firewall está obstruindo o tráfego. A maioria depovos verificarão novamente então o registro diagnóstico de Expressway-e para determinar sepodem ver a conexão de TCP tentar estabelecer. General procurarão um artigo de linha deregistro tal como esta segundo as indicações da imagem.




Nesta circunstância, a entrada de registro particular acima não existirá. Consequentemente,muitos povos diagnosticarão mal a circunstância e supo-la é o Firewall.

Se uma captura de pacote de informação é incluída com o registro diagnóstico, você podeverificar que o Firewall não é a causa. Está abaixo uma amostra da captura de pacote deinformação do thescenario onde Expressway-e não estava escutando sobre a porta 5062. Estacaptação filtrada usando tcp.port==5062 como o filtro aplicado segundo as indicações daimagem.

Como você pode ver na captura de pacote de informação que foi obtida de Expressway-e, otráfego sobre a porta 5062 tcp não está sendo obstruído pelo Firewall mas de fato está chegando.No pacote número 56, você pode ver que Expressway-e está enviando o RST imediatamentedepois que o pacote SYN de TCP inicial chegou. Com esta informação, você pode concluir que aedição está isolada a Expressway-e que recebe o pacote; você deve pesquisar defeitos a ediçãoda perspectiva de Expressway-e. Dado a evidência, considere razões possíveis para porqueExpressway-e RST o pacote. Duas possibilidades que poderiam atribuir a este comportamentosão:

1. Expressway-e tem algum tipo de regras do Firewall estabelecidas que poderiam obstruir otráfego

2. Expressway-e não está escutando o tráfego mútuo TLS e/ou não está escutando o tráfegosobre a porta 5062.

A funcionalidade de firewall do Expressway-e existe sob o sistema > a proteção > o Firewallordena > configuração. Quando isto foi verificado dentro este ambiente, não havia nenhumpresente da configuração de firewall.

Há diversas maneiras de verificar se Expressway-e está escutando o tráfego mútuo TLS sobre aporta 5062. Você pode fazer o este com a interface da WEB ou o CLI como um usuário de raiz.

Da raiz de Expressway, se você emite o netstat - an | o grep ':5062', você deve obter algumasaída similar ao que você vê abaixo.

~ # netstat -an | grep ':5062'

tcp 0 0 172.16.2.2:5062 0.0.0.0:* LISTEN <-- Outside

Interface

tcp 0 0 192.168.1.6:5062 0.0.0.0:* LISTEN <-- Inside Interface

tcp 0 0 127.0.0.1:5062 0.0.0.0:* LISTEN

tcp 0 0 ::1:5062 :::* LISTEN

Esta informação pode igualmente ser capturada através da interface da WEB de Expressway-e.Veja as etapas abaixo para recolher esta informação

1. Log em Expressway-e

2. Navegue à manutenção utiliza ferramentas > uso da porta > portas de entrada locais

3. Procure pelo tipo SORVO e pela porta 5062 IP. (destacado no vermelho segundo as indicaçõesda imagem)

Agora que você conhece o que você deve ver, você pode comparar aquele ao ambiente atual. Daperspectiva CLI, quando você executar o netstat - an | o grep ':5062', a saída olha como este:

~ # netstat -an | grep ':5062'

tcp 0 0 172.16.2.2:5062 0.0.0.0:* LISTEN <-- Outside

Interface

tcp 0 0 192.168.1.6:5062 0.0.0.0:* LISTEN <-- Inside Interface

tcp 0 0 127.0.0.1:5062 0.0.0.0:* LISTEN

tcp 0 0 ::1:5062 :::* LISTEN

Adicionalmente, a Web UU não mostra a porta mútua TLS alistada sob portas de entrada locais

Com estes dados, você pode concluir que Expressway-e não está escutando o tráfego mútuoTLS.

Solução

A fim resolver este problema, você deve assegurar-se de que o modo mútuo TLS esteja permitidoe que a porta mútua TLS está ajustada a 5062 em Expressway-e:

Log em Expressway-e1.Navegue à configuração > aos protocolos > ao SORVO2.Assegure-se de que o modo mútuo TLS esteja ajustado a sobre3.Assegure-se de que a porta mútua TLS esteja ajustada a 50624.Clique a salvaguarda segundo as indicações da imagem.5.

A edição 4. Expressway-e ou o C não apoiam encabeçamentos Preloaded da rota do SORVO

Com atendimento híbrido preste serviços de manutenção conectam, o roteamento de chamada éfeito com base no encabeçamento da rota. O encabeçamento da rota é povoado baseou nainformação que a parcela ciente do serviço do atendimento (conector de Expressway) da soluçãoentrega a Cisco a faísca. O host do conector de Expressway pergunta o CM unificado para osusuários que são permitidos para o serviço do atendimento e puxam seu diretório URI e o FQDNdo conjunto de seu conjunto unificado da HOME CM. Veja este o exemplo, usando Alice e Bob:

Diretório URI Encabeçamento da rota do [email protected] [email protected] us-cucm.example.com

Se Alice ou Bob fazem um atendimento, o atendimento está distribuído a seu CM unificado em-locais de modo que possa ser ancorado a seu Cisco SparkRD antes de distribuir para fora aousuário chamado.

Se Alice devia chamar Bob, o atendimento distribuiria a FQDN unificado do conjunto da HOMECM de Alice (us-cucm.example.com). Se você analzye que o SORVO CONVIDA que Ciscoacende envia de entrada a Expressway-e, você encontraria a informação seguinte dentro doencabeçamento do SORVO

Pedido URI sorvo: [email protected]çamento da rota sorvo: us-cucm.example.com; LR

Da perspectiva de Expressway, as regras de busca são configuradas para distribuir oatendimento não pelo pedido URI mas um pouco pelo encabeçamento da rota (us-cucm.example.com) -- no conjunto unificado da HOME CM desta Alice do casem.

Com este grupo da fundação, você pode compreender pesquisa defeitos as situações onde asvias expressas são desconfiguradas, que faz com que a lógica acima não trabalhe. Porque quasecada outro serviço híbrido de entrada do atendimento conecta a falha na configuração dechamada, o sintoma é que o telefone dos em-locais não soa.

Antes que você analise o diagnóstico entra Expressway, considera como identificar esteatendimento:

O pedido URI do SORVO será o diretório URI do número chamado.1.O SORVO do campo será formatado com a chamada originada alistada como do “o <sip dosobrenome nome”: [email protected] >

2.

Com esta informação, você pode procurar os log de diagnóstico pelo diretório URI do númerochamado, nome e sobrenome da chamada originada, ou Cisco acende o endereço do SORVO dachamada originada. Se você não tem alguma desta informação, você pode procurar em“CONVIDA O SORVO: ” que localiza todo o SORVO chama o corredor sobre Expressway. Umavez que você identificou o SORVO CONVIDE para a chamada recebida, você pode entãoencontrar e copiar a identidade da chamada do SORVO. Depois que você tem este valor, vocêpode simplesmente procurar os log de diagnóstico baseados na identidade da chamada para vertodas as mensagens que correlacionam a este trecho de chamada.

Uma outra coisa a ajudar a isolar o problema de roteamento é determinar como distante oatendimento entra na empresa. Você pode tentar procurar pela informação notável acima emExpressway-C para ver se o atendimento foi distribuído que distante. Em caso afirmativo, vocêquererá provavelmente começar lá sua investigação.

Nesta encenação, você pode ver que Expressway-C recebeu o CONVITE de Expressway-e.

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830"

Module="network.sip" Level="DEBUG": Action="Received" Local-ip="192.168.1.5" Local-port="26847"

Src-ip="192.168.1.6" Src-port="7003" Msg-Hash="11449260850208794722"

SIPMSG:

|INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/TLS 192.168.1.6:7003;egress-

zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-

id=a82052ef-6fd7-4506-8173-e73af6655b5d;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-

local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone


zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c769

6bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS

192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35

464;ingress-zone=HybridCallServicesDNS

Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-

8f0d64025c04d23b6d5e1d5142db46ec;rport=52706

Call-ID: [email protected]

CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared

From: "pstojano test" <sip:[email protected]>;tag=872524918

To: <sip:[email protected]>

Max-Forwards: 15

Route: <sip:cucm.rtp.ciscotac.net;lr>

Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-

[email protected]:7003;transport=tls;lr>

Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-


O importante é que o encabeçamento da rota (FQDN do conjunto) é ainda intacto. Contudo, nãohá nenhuma lógica da busca que está sendo executada baseada no encabeçamento da rota(FQDN) do conjunto cucm.rtp.ciscotac.net. Um pouco, você vê a mensagem obter rejeitadaimediatamente com uns 404 não encontrados.

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Attempted" Service="SIP"

Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-

[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]"

Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-

ddde83b49fd0" Protocol="TLS" Auth="NO" Level="1" UTCTime="2017-09-19 18:16:15,832"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP"

Src-alias-type="SIP" Src-alias="[email protected]" Dst-alias-type="SIP"

Dst-alias="sip:[email protected]" Call-serial-number="a3e44231-f62a-4e95-a70e-

253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="searchtype:INVITE" Level="1"

UTCTime="2017-09-19 18:16:15,834"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Completed" Reason="Not

Found" Service="SIP" Src-alias-type="SIP" Src-alias="[email protected]"

Dst-alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-number="a3e44231-f62a-

4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="found:false,

searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-19 18:16:15,835"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Rejected" Service="SIP"

Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-

[email protected]" Dst-alias-type="SIP" Dst-alias="sip:[email protected]"

Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-

ddde83b49fd0" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2017-09-

19 18:16:15,835"


Module="network.sip" Level="INFO": Action="Received" Local-ip="192.168.1.5" Local-port="26847"

Src-ip="192.168.1.6" Src-port="7003" Detail="Receive Request Method=INVITE, CSeq=1, Request-

URI=sip:[email protected], [email protected], From-

Tag=872524918, To-Tag=, Msg-Hash=11449260850208794722, Local-

SessionID=daf7c278732bb5a557fb57925dffcbf7, Remote-SessionID=00000000000000000000000000000000"


Module="network.sip" Level="INFO": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-

ip="192.168.1.6" Dst-port="7003" Detail="Sending Response Code=404, Method=INVITE, CSeq=1,

To=sip:[email protected], [email protected], From-

Tag=872524918, To-Tag=96b9a0eaf669a590, Msg-Hash=254718822158415175, Local-

SessionID=00000000000000000000000000000000, Remote-SessionID=daf7c278732bb5a557fb57925dffcbf7"


Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-

ip="192.168.1.6" Dst-port="7003" Msg-Hash="254718822158415175"

SIPMSG:

|SIP/2.0 404 Not Found


zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-

id=a82052ef-6fd7-4506-8173-e73af6655b5d;received=192.168.1.6;rport=7003;ingress-

zone=HybridCallServiceTraversal

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-



zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c769

6bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS

192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35



8f0d64025c04d23b6d5e1d5142db46ec;rport=52706


CSeq: 1 INVITE


To: <sip:[email protected]>;tag=96b9a0eaf669a590

Server: TANDBERG/4135 (X8.10.2)

Warning: 399 192.168.1.5:5061 "Policy Response"

Session-ID: 00000000000000000000000000000000;remote=daf7c278732bb5a557fb57925dffcbf7

Content-Length: 0

Comparado a uma encenação de trabalho, você veria que na encenação de trabalho o a lógica dabusca está sendo executada baseada no encabeçamento do roteador (o FQDN do conjunto)

2017-09-22T13:56:02.215-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP"

Src-alias-type="SIP" Src-alias="[email protected]" Dst-alias-type="SIP"

Dst-alias="sip:[email protected]" Call-serial-number="17aa8dc7-422c-42ef-bdd9-

b9750fbd0edf" Tag="8bd936da-f2ab-4412-96df-d64558f7597b" Detail="searchtype:INVITE" Level="1"

UTCTime="2017-09-22 17:56:02,215"


Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL:

<routed> "



<location clear="yes" url="sip:cucm.rtp.ciscotac.net;lr" diversion="" dest-url-for-

message="sip:[email protected]" sip-route-set="" dest-service=""> added

sip:cucm.rtp.ciscotac.net;lr to location set "



<proxy stop-on-busy="no" timeout="0"/> "


Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound MS to CMS' did not match

destination alias 'cucm.rtp.ciscotac.net;lr'"


Module="network.search" Level="DEBUG": Detail="Search rule 'multiway' did not match destination

alias 'cucm.rtp.ciscotac.net;lr'"


Module="network.search" Level="DEBUG": Detail="Search rule 'WebEx Search Rule' did not match



Module="network.search" Level="DEBUG": Detail="Search rule 'ISDN Inbound' ignored due to source

filtering"


Module="network.search" Level="DEBUG": Detail="Search rule 'recalls into CMS' did not match



Module="network.search" Level="DEBUG": Detail="Search rule 'CEtcp-rtp12-tpdmz-118-ucmpub' did

not match destination alias 'cucm.rtp.ciscotac.net;lr'"


Module="network.search" Level="DEBUG": Detail="Search rule 'Conference Factory' did not match



Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound B2B Calling' did not match



Module="network.search" Level="DEBUG": Detail="Search rule 'Calls to Cisco Spark' did not match



Module="network.search" Level="DEBUG": Detail="Considering search rule 'as is local' towards

target 'LocalZone' at priority '1' with alias 'cucm.rtp.ciscotac.net;lr'"


Module="network.search" Level="DEBUG": Detail="Considering search rule 'Hybrid Call Service

Inbound Routing' towards target 'CUCM11' at priority '2' with alias 'cucm.rtp.ciscotac.net;lr'"

Você pode então ver que Expressway-C corretamente para a frente chamar ao CM unificado(192.168.1.21).




SIPMSG:


Via: SIP/2.0/TCP 192.168.1.5:5060;egress-

zone=CUCM11;branch=z9hG4bK251d6daf044e635607cc13d244b9ea45138220.69ccb8de20a0e853c1313782077f77b

5;proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf;rport


zone=HybridCallServiceTraversal;branch=z9hG4bKba323da436b2bc288200d56d11f02d4d272;proxy-call-

id=32c76cef-e73c-4911-98d0-e2d2bb6fec77;received=192.168.1.6;rport=7003;ingress-

zone=HybridCallServiceTraversal

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK06cde3f662d53a210b5b4b11b85500c19;x-cisco-local-

service=nettle;received=192.168.1.6;rport=42533;ingress-zone=DefaultZone


zone=DefaultZone;branch=z9hG4bK297799f31d0785ff7449e1d7dbe3595b271.2ed90cbed5b79c6cffad9ecd84cc8

337;proxy-call-id=3be87d96-d2e6-4489-b936-8f9cb5ccaa5f;received=172.16.2.2;rport=25005

Via: SIP/2.0/TLS

192.168.4.146:5062;branch=z9hG4bK043ca6360f253c6abed9b23fbeff9819;received=148.62.40.64;rport=36



8c648a16c2c5d7b85fa5c759d59aa190;rport=47732


CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared



Max-Forwards: 14


Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-

[email protected]:5060;transport=tcp;lr>

Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-


Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-


Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-


Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY

User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

Analisando o registro diagnóstico que isolou o problema a Expressway-C e um erro específico(404 não encontrados), você pode focalizar no que causaria este tipo de comportamento.Algumas coisas a considerar são as seguintes:

Os atendimentos são movidos dentro e fora das zonas em Expressway por regras de busca.1.A lógica do uso das vias expressas chamada Preloaded o apoio das rotas do SORVO que oSORVO dos processos CONVIDA os pedidos que contêm o encabeçamento do roteador.Este valor pode ser girado de ligar/desligar nas zonas (server de Traversal, cliente deTraversal, vizinho) em Expressway-C e em Expressway-e.

2.

Você pode agora usar o xConfiguration para ver a configuração no server de Expressway-eTraversal e as zonas do cliente de Expressway-C, especificamente aqueles que se estabelecem

para o serviço híbrido do atendimento conectam. Além do que a configuração da zona, você podeanalisar as regras de busca que são configuradas para passar completamente este atendimentode uma zona a outra. Você igualmente sabe que Expressway-e passou o atendimento aExpressway-C assim que a configuração da zona do server de Traversal lá é mais provávelestabelecida corretamente.

Para quebrar para baixo isto, o xConfig abaixo diz-nos que o nome desta zona está chamadoserviço Traversal de Híbrido Chamada. É do tipo da zona de TraversalServer. Comunica-se aExpressway-C sobre a porta TCP 7003 do SORVO.

A parte chave para o serviço híbrido do atendimento é que deve ter preloaded o apoio das rotasdo SORVO sobre. A interface da WEB de Expressway chama este apoio Preloaded valor dasrotas do SORVO visto que o xConfiguration o indicará como o SORVO PreloadedSipRoutesaceita

Expressway-E

*c xConfiguration Zones Zone 7 Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Zone 7 TraversalServer Authentication Mode: "DoNotCheckCredentials"

*c xConfiguration Zones Zone 7 TraversalServer Authentication UserName: "hybridauth"

*c xConfiguration Zones Zone 7 TraversalServer Collaboration Edge: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 H46019 Demultiplexing Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer H323 Port: "6007"

*c xConfiguration Zones Zone 7 TraversalServer H323 Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer Registrations: "Allow"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media Encryption Mode: "Auto"

*c xConfiguration Zones Zone 7 TraversalServer SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Multistream Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 7 TraversalServer SIP Port: "7003"

*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP Protocol: "Assent"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 7 TraversalServer SIP TLS Verify Subject Name: "rtp12-tpdmz-118-

VCSC.rtp.ciscotac.net"

*c xConfiguration Zones Zone 7 TraversalServer SIP Transport: "TLS"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer TCPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe KeepAliveInterval: "20"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryCount: "5"

*c xConfiguration Zones Zone 7 TraversalServer UDPProbe RetryInterval: "2"

*c xConfiguration Zones Zone 7 Type: "TraversalServer"

Você pode igualmente determinar que esta zona tem a regra de busca 3 (híbrido da faísca)amarrada a ela. Essencialmente a regra de busca está enviando um “algum” aliás que entrar coma zona DNS dos serviços híbridos do atendimento e da passagem dela à zona acima, serviçohíbrido Traversal do atendimento. Como esperado, a regra de busca e a zona do server deTraversal em Expressway-e são configuradas corretamente.

*c xConfiguration Zones Policy SearchRules Rule 3 Authentication: "No"

*c xConfiguration Zones Policy SearchRules Rule 3 Description: "Calls to VCS-C"

*c xConfiguration Zones Policy SearchRules Rule 3 Mode: "AnyAlias"

*c xConfiguration Zones Policy SearchRules Rule 3 Name: "Spark Hybrid"

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Behavior: "Strip"

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Replace:

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern String:

*c xConfiguration Zones Policy SearchRules Rule 3 Pattern Type: "Prefix"

*c xConfiguration Zones Policy SearchRules Rule 3 Priority: "15"

*c xConfiguration Zones Policy SearchRules Rule 3 Progress: "Stop"

*c xConfiguration Zones Policy SearchRules Rule 3 Protocol: "SIP"

*c xConfiguration Zones Policy SearchRules Rule 3 SIPTrafficType: "Any"

*c xConfiguration Zones Policy SearchRules Rule 3 Source Mode: "Named"

*c xConfiguration Zones Policy SearchRules Rule 3 Source Name: "Hybrid Call Services DNS"

*c xConfiguration Zones Policy SearchRules Rule 3 State: "Enabled"

*c xConfiguration Zones Policy SearchRules Rule 3 SystemGenerated: "No"

*c xConfiguration Zones Policy SearchRules Rule 3 Target Name: "Hybrid Call Service Traversal"

*c xConfiguration Zones Policy SearchRules Rule 3 Target SIPVariant: "Any"

*c xConfiguration Zones Policy SearchRules Rule 3 Target Type: "Zone"

Se você focaliza no xConfiguration de Expressway-C, você pode começar procurando a zona docliente de Traversal para o híbrido da faísca. Uma maneira fácil encontrá-lo é procurar no númerode porta que você aprendeu do xConfiguration de Expressway-e (porta do SORVO: "7003"). Istoajuda-o rapidamente a identificar a zona correta no xConfiguration.

Como antes, você pode aprender o nome de zona (serviço híbrido Traversal do atendimento), otipo (cliente de Traversal), e o que foi configurado para o SORVO PreloadedSipRoutes aceita(Preloaded o apoio das rotas do SORVO). Como você pode ver deste xConfiguration, este valor éajustado a fora. Baseado no guia de distribuição para serviços híbridos do atendimento da faíscade Cisco, este valor deve ser ajustado a sobre.

Adicionalmente, se nós verificamos a definição do apoio Preloaded das rotas do SORVO nóspodemos ver claramente que Expressway-C deve REJEITAR uma mensagem se este valor estáajustado a fora E o convite contém um encabeçamento da rota: “Desligue o apoio Preloaded dasrotas do SORVO se você quer a zona rejeitar o SORVO CONVIDA os pedidos que contêm esteencabeçamento.”

Expressway-C


*c xConfiguration Zones Zone 6 TraversalClient Accept Delegated Credential Checks: "Off"

*c xConfiguration Zones Zone 6 TraversalClient Authentication Mode: "DoNotCheckCredentials"

*c xConfiguration Zones Zone 6 TraversalClient Authentication Password:

"{cipher}qeh8eq+fuVY1GHGgRLder/1lYDd76O/6KrHGA7g8bJs="

*c xConfiguration Zones Zone 6 TraversalClient Authentication UserName: "hybridauth"

*c xConfiguration Zones Zone 6 TraversalClient Collaboration Edge: "Off"

*c xConfiguration Zones Zone 6 TraversalClient H323 Port: "1719"

*c xConfiguration Zones Zone 6 TraversalClient H323 Protocol: "Assent"

*c xConfiguration Zones Zone 6 TraversalClient Peer 1 Address: "amer-expressway01.ciscotac.net"

*c xConfiguration Zones Zone 6 TraversalClient Peer 2 Address:





*c xConfiguration Zones Zone 6 TraversalClient Registrations: "Allow"

*c xConfiguration Zones Zone 6 TraversalClient RetryInterval: "120"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media Encryption Mode: "Auto"

*c xConfiguration Zones Zone 6 TraversalClient SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Multistream Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP ParameterPreservation Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Port: "7003"

*c xConfiguration Zones Zone 6 TraversalClient SIP PreloadedSipRoutes Accept: "Off"

*c xConfiguration Zones Zone 6 TraversalClient SIP Protocol: "Assent"

*c xConfiguration Zones Zone 6 TraversalClient SIP TLS Verify Mode: "On"

*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Address:

*c xConfiguration Zones Zone 6 TraversalClient SIP TURN Server Port:

*c xConfiguration Zones Zone 6 TraversalClient SIP Transport: "TLS"

*c xConfiguration Zones Zone 6 Type: "TraversalClient"

Neste momento, você isolou o problema a um misconfiguration da configuração da zona docliente de Expressway-C Traversal. Você deve comutar o apoio Preloaded das rotas do SORVO asobre.

Solução

Para ajustar corretamente o apoio Preloaded das rotas do SORVO:

Log em Expressway-C1.Navegue à configuração > às zonas > às zonas2.Selecione a zona híbrida do cliente de Traversal do serviço do atendimento (nomear variaráo cliente ao cliente)

3.

Ajuste o apoio Preloaded das rotas do SORVO a sobre4.Selecione a salvaguarda5.

Note: Quando esta encenação demonstrou a falha em Expressway-C, os mesmos erros deregistro diagnósticos poderiam ser observados em Expressway-e se o apoio Preloaded dasrotas do SORVO estava fora na zona híbrida do server de Traversal do atendimento dafaísca. Nesse evento você nunca veria que o alcance do atendimento Expressway-C eExpressway-e seria responsável para rejeitar o atendimento e enviar os 404 nãoencontrados.

A edição 5. Cisco acende o app está recebendo duas notificações do atendimento (os brindes)

Esta questão particular acontece ser a única encenação da chamada de entrada que não conduza deixar cair do atendimento. Para esta edição, a pessoa que recebe o atendimento (númerochamado) está recebendo duas notificações (brindes) no app da faísca de Cisco da pessoa quetinha colocado o atendimento (chamada originada). A primeira notificação é gerada da faísca deCisco e a segunda notificação vem da infraestrutura dos em-locais. Estão abaixo as amostras dasduas notificações que são recebidas segundo as indicações da imagem.

A primeira notificação (brinde) é da pessoa que está iniciando o atendimento (chamada originada)do lado da faísca de Cisco. A chamada ID é nesta instância o nome do indicador do usuário queinicia esse atendimento. A segunda notificação (brinde) está vindo do estabelece como premissasobre o CTI ou o Cisco acende o RD que é atribuído ao usuário que está fazendo o atendimento.No início, este comportamento parece peculiar. Contudo, se você revê o diagrama da chamadade entrada (do Guia de Design híbrido do atendimento da faísca de Cisco), o comportamento fazmais sentido segundo as indicações da imagem.

Da ilustração, você pode ver que a Alice está chamando Bob de seu app da faísca de Cisco e queo atendimento está sendo bifurcado para baixo aos locais. Este atendimento deve combinar odiretório URI que é atribuído ao telefone de Bob. O problema é aquele com este projeto, odiretório URI é atribuído igualmente a seu CTI-RD ou a Cisco acende o RD. Consequentemente,quando o atendimento é oferecido ao CTI-RD ou a Cisco acende o RD, o atendimento é enviadopara trás para fora à faísca de Cisco porque o dispositivo tem um destino remoto configuradopara [email protected]. A maneira Cisco acende os punhos que esta situação éque cancela o trecho de chamada particular.

Para que a faísca de Cisco cancele corretamente o trecho de chamada, Cisco acende necessárioinicialmente pôr um parâmetro no encabeçamento do SORVO que procuraria para cancelar essepé dado. O parâmetro Cisco acende inserções no SORVO CONVIDA é chamado “call-type=squared” e este valor é incorporado no encabeçamento do contato. Se este valor édescascado da mensagem, Cisco acende não compreende como cancelar o atendimento.

Com esta informação, você pode revisitar a encenação apresentada mais cedo onde Cisco dousuário acende o app recebia duas notificações (brindes) quando Cisco acende o usuário queJonathan Robb fazia um atendimento. Para pesquisar defeitos este tipo de problema, você estáindo sempre precisar de recolher o diagnóstico que termina Expressway-C e Expressway-e.Como um ponto de início, você pode rever os logs de Expressway-e para determinar que oSORVO CONVIDA manda de fato o valor call-type=squared atual no encabeçamento do contatoda faísca de Cisco da inicial CONVIDAR de entrada enviado. Isto assegurar-se-á de que oFirewall não esteja manipulando a mensagem em nenhuma maneira. Está abaixo um snippet daamostra da vinda do CONVITE de entrada a Expressway-e desta encenação.




SIPMSG:


Via: SIP/2.0/TLS 192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71,SIP/2.0/TLS

127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306


CSeq: 1 INVITE

Contact: "l2sip-UA" <sip:[email protected]:5062;transport=tls>;call-type=squared

<-- Spark inserted value

From: "Jonathan Robb" <sip:[email protected]>;tag=540300020


Max-Forwards: 70

Route: <sip:[email protected]:5062;transport=tls;lr>,<sip:cucm.rtp.ciscotac.net;lr>

O encabeçamento do contato tem o presente call-type=squared do valor. Neste momento, oatendimento deve distribuir com Expressway e ser enviado fora da zona híbrida do server deTraversal da faísca. Nós podemos procurar os logs de Expressway-e para determinar como oatendimento foi enviado fora de Expressway-e. Isto dar-nos-á uma ideia se Expressway-e estámanipulando o CONVITE em qualquer maneira.




SIPMSG:

INVITE sip:[email protected] SIP/2.0


zone=HybridCallServiceTraversal;branch=z9hG4bKec916b02b6d469abad0a30b93753f4b0859;proxy-call-

id=d7372034-85d1-41f8-af84-dffed6d1a9a9;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKd91699370129b4c10d09e269525de00c2;x-cisco-local-



zone=DefaultZone;branch=z9hG4bK52aac9a181192566e01b98ae0280bdff858.0e65cdfe078cabb269eecb6bce132

8be;proxy-call-id=ec51e8da-e1a3-4210-95c9-494d12debcd8;received=172.16.2.2;rport=25016

Via: SIP/2.0/TLS

192.168.5.164:5062;branch=z9hG4bK564cd36d87f3417513c9b559dc666f71;received=146.20.193.73;rport=4


Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306


CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls> <-- Spark inserted value is now missing

From: "Jonathan Robb" <sip:[email protected]>;tag=540300020


Max-Forwards: 15


Ao rever este SORVO CONVIDE que está sendo enviado de Expressway-e a Expressway-C,notam que o encabeçamento do contato está faltando call-type=squared. Outra uma coisa aindicar é aquela no item de linha 4, você pode considerar que a saída-zona é igual aHybridCallServiceTraversal. Você pode agora concluir que a razão que Cisco acende o app estáobtendo uma segunda notificação (brinde) quando discado é devido a Expressway-e descascar aetiqueta call-type=squared do SORVO CONVIDA o encabeçamento do contato. A pergunta aresponder é o que poderia causar este encabeçamento descascado.

O atendimento deve distribuir com o serviço híbrido Traversal que do atendimento você seestabelece em Expressway, de modo que fosse um bom lugar para começar a investigação. Sevocê tem o xConfiguration, você pode ver como esta zona foi configurada. Para identificar a zonano xConfiguration, você pode simplesmente usar o nome gravado no através da linha que obtémimpressa nos logs. Você pode ver acima dela foi chamado egress-

zone=HybridCallServiceTraversal. Quando este nome é imprimido no através da linha doencabeçamento do SORVO, os espaços estão removidos. O nome de zona real da perspectivado xConfiguration teria espaços e é formatado no serviço híbrido Traversal do atendimento.












*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "Off" <--

Possible Suspect Value



*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On" <--














Com os ajustes identificados para o serviço híbrido Traversal do atendimento, você pode procuraros ajustes potenciais que estão para fora, como:

O SORVO PreloadedSIPRoutes aceita: Ligado●

Modo de ParameterPreservatoin do SORVO: Desligado●

Usando a interface da WEB de todo o Expressway, você pode ver o que a definição destesvalores é e o que fazem.

Apoio Preloaded das rotas do SORVO

O apoio Preloaded interruptor das rotas do SORVO sobre para permitir esta zona de processar oSORVO CONVIDA os pedidos que contêm o encabeçamento da rota.

Desligue o apoio Preloaded das rotas do SORVO se você quer a zona rejeitar o SORVOCONVIDA os pedidos que contêm este encabeçamento.

SORVA a preservação do parâmetro

Determina se o B2BUA de Expressway preserva ou reescreve os parâmetros nos pedidos doSORVO distribuídos através desta zona.

Onpreserves os parâmetros do pedido URI e do contato do SORVO dos pedidos que distribuementre esta zona e o B2BUA.

Offallows o B2BUA para reescrever o pedido URI do SORVO e para contactar parâmetros dospedidos que distribuem entre esta zona e o B2BUA, caso necessário.Baseado fora destas definições, o xConfiguration, e aquele o valor call-type=squared sãocolocados no encabeçamento do “contato” do SORVO CONVIDAM, você pode concluir aqueleque tem o valor da preservação do parâmetro do SORVO fora na zona híbrida de Traversal doserviço do atendimento é a razão que a etiqueta está obtendo descascada e Cisco acende o appestá obtendo notificações do anel dobro.

Solução

Para preservar o valor call-type=squared no encabeçamento do contato do SORVO CONVIDE,você deve assegurar-se de que toda a preservação do parâmetro do SORVO do apoio das viasexpressas para divida involvido em segurar o atendimento:

Log em Expressway-e1.Navegue à configuração > às zonas > às zonas2.Selecione a zona que está sendo usada para o server híbrido de Traversal3.Ajuste o valor da preservação do parâmetro do SORVO a sobre4.Salvar os ajustes.5.

###############################################Nota: Neste exemplo de cenário era a zona híbrida do server de Traversal da faísca emExpressway-e que foi desconfigurada. Mantenha na mente que é inteiramente possível para ovalor da preservação do parâmetro do SORVO ser ajustado a fora nas zonas híbridas do clientede Traversal da faísca ou do vizinho CUCM. Both of these configurações seriam feitas emExpressway-C. Se aquele era o caso você poderia esperar que Expressway-e enviaria o valorcall-type=squared a Expressway-C e seria Expressway-C que descasca o.

De partida: Em-locais à faísca de Cisco

Quase cada falha de chamada que envolve em-locais de partida aos resultados da faísca deCisco no mesmo sintoma relatado: “Quando eu chamo de meu telefone CM-registrado unificado aum outro usuário que esteja permitido para o serviço do atendimento conecte, seus anéis dotelefone dos em-locais mas seu Cisco acende o app não faz.” Para pesquisar defeitos estaencenação, é importante compreender o fluxo de chamadas e a lógica que estão ocorrendoquando este tipo de atendimento está sendo colocado.

Fluxo de nível elevado da lógica

O usuário A faz um atendimento do seu -premses no telefone ao diretório URI do usuário B1.Os em-locais do usuário b telefonam e CTI-RD/Spark-RD aceitam o atendimento2.O telefone dos em-locais do usuário b começa aos anéis3.CTI-RD/Spark-RD do usuário b bifurca-se isto chama ao destino [email protected]

4.

O CM unificado passa este atendimento a Expressway-C5.Expressway-C envia o atendimento a Expressway-e6.Expressway-e executa uma pesquisa de DNS no domínio de callservice.ciscospark.com7.As tentativas de Expressway-e de conectar a Cisco acendem o ambiente sobre a porta5062.

8.

Expressway-e e o ambiente da faísca de Cisco começam um aperto de mão mútuo9.Cisco acende o ambiente passa o atendimento no app disponível da faísca de Cisco dousuário b

10.

O usuário que Cisco disponível do b acende o app começa a soar.11.Fluxo de chamada

Navegue ao usuário B -prem no telefone > unificado CM > CTI-RD/Spark-RD > Expressway-C >Expressway-e > Cisco acendem o ambiente > o Cisco acendem o app segundo as indicações daimagem.

Nota: A imagem foi puxada do Guia de Design do híbrido da faísca de Cisco.

Pontas da análise do log

Se você pesquisava defeitos uma situação onde os atendimentos bifurcados de partida à faíscade Cisco falhassem, você quereria recolher os logs unificados CM, de Expressway-C, e deExpressway-e. Tendo estes grupos de logs, você pode ver como o atendimento está passandoatravés do ambiente. Uma outra maneira rápida compreender como distante o atendimento estáobtendo dentro de seu ambiente de em-locais é usar Expressway da “história busca”. A históriada busca de Expressway permitirá rapidamente que você considere se bifurcados chamam aCisco a faísca estão obtendo a Expressway-C ou ao E.

Para usar a história da busca você pode executar estes:

Log em Expressway-eColoque uma chamada de testeNavegue à história do estado > da buscaVerifique se você vê um atendimento que tenha um endereço de destino do SORVO URI dafaísca que deve ser chamado ([email protected])Se a história da busca não mostra o atendimento que bate a repetição da história da busca

1.


de Expressway-e este processo em Expressway-CAntes que você analise o diagnóstico entra Expressway, considera como identificar esteatendimento:

O pedido URI do SORVO será Cisco acende o endereço do SORVO do usuário1.O SORVO do campo será formatado para ter a chamada originada alistada como do “o <sipdo sobrenome nome”: Alias@Domain >

2.

Com esta informação você pode procurar os log de diagnóstico pelo diretório URI da chamadaoriginada, nome e sobrenome da chamada originada, ou Cisco acende o endereço do SORVO donúmero chamado. Se você não tem alguma desta informação, você pode fazer uma busca em“CONVIDA O SORVO: ” que localizará todo o SORVO chama o corredor sobre Expressway. Umavez que você identificou o SORVO CONVIDE para a chamada externa, você pode entãoencontrar e copiar a identidade da chamada do SORVO. Depois que você tem este você podesimplesmente procurar os log de diagnóstico baseados na identidade da chamada para ver todasas mensagens que correlacionam a este trecho de chamada.

Estão aqui alguns da maioria de problemas comuns observados com chamadas externas dotelefone CM-registrado unificado ao ambiente da faísca de Cisco quando o atendimento é feito aum usuário que esteja permitido para o serviço do atendimento conecte.

A edição 1. Expressway é incapaz de resolver o endereço de callservice.ciscospark.com

O procedimento de operação padrão para uma zona DNS de Expressway é executar aspesquisas de DNS baseadas no domínio que aparece no lado direito de um pedido URI. Paraexplicar isto, considere um exemplo. Se a zona DNS era receber um atendimento que tivesse umpedido URI de [email protected], uma zona DNS típica de Expresswayexecutaria a lógica da consulta DNS SRV em dmzlab.call.ciscospark.com que é o lado direito dopedido URI. Se Expressway era fazer isto você poderia esperar que a seguintes consulta eresposta ocorreriam.












*c xConfiguration Zones Zone 7 TraversalServer SIP ParameterPreservation Mode: "Off" <--




*c xConfiguration Zones Zone 7 TraversalServer SIP PreloadedSipRoutes Accept: "On" <--














Se você olha proximamente, você vê que a resposta do registro SRV está fornecendo umendereço do servidor e uma porta 5061, não 5062.

Isto significa que o handshake de TLS mútuo que ocorre sobre a porta 5062 não acontecerá euma porta separada é usada sinalizando entre Expressway e a faísca de Cisco. O desafio comeste é que o guia de distribuição para serviços híbridos do atendimento da faísca de Cisco nãochama explicitamente o uso da porta 5061 porque alguns ambientes não permitem a chamadainterempresarial.

A maneira de trabalhar após esta lógica padrão da consulta da zona DNS SRV em Expressway éconfigurar Expressway de modo que faça as buscas explícitas baseadas em um valor que vocêforneça.

Agora ao analisar este atendimento particular, você pode focalizar em Expressway-e porque vocêdeterminou (usando a história da busca) que o atendimento fez lhe este distante. O começo como primeiro SORVO CONVIDA que entra Expressway-e para ver que zona entrou sobre, que asregras de busca estão sendo usadas, que divide o atendimento sai, e se enviado corretamente àzona DNS, que lógica da pesquisa de DNS ocorre.




SIPMSG:



zone=HybridCallServiceTraversal;branch=z9hG4bK6d734eaf7a6d733bd1e79705b7445ebb46175.1d33be65c99c

56898f85df813f1db3a7;proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK13187594dd412;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP

Remote-Party-ID: "Jonathan Robb"

<sip:[email protected]>;party=calling;screen=yes;privacy=off

Contact: <sip:[email protected]:5065;transport=tcp>;video;audio

From: "Jonathan Robb" <sip:[email protected]>;tag=332677~c9cc7ddc-9592-49e8-a13c-

79e26f48eebc-30106860


Max-Forwards: 15

Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-


Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-


Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY

User-Agent: Cisco-CUCM11.5

Expires: 180

Date: Tue, 19 Sep 2017 17:18:50 GMT

Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,X-cisco-original-called

Session-Expires: 1800

Min-SE: 1800

Allow-Events: presence

X-TAATag: 2272025a-ce36-49d0-8d93-cb6a5e90ffe0

Session-ID: 75957d4fb66a13e835c10737aa332675;remote=00000000000000000000000000000000

Cisco-Guid: 2568978048-0000065536-0000000148-0352430272

Content-Type: application/sdp

Content-Length: 714

<SDP Omitted>

Neste SORVO CONVIDE, você pode recolher acima o pedido URI ([email protected]), a identidade da chamada (991f7e80-9c11517a-130ac-1501a8c0), de (“Jonathan Robb” <sip:[email protected]>), a (sorvo: [email protected]), e agente de usuário (Cisco-CUCM11.5). Depois que istoCONVIDA está recebido, Expressway deve agora fazer decisões de lógica para determinar sepode distribuir o atendimento a uma outra zona. Expressway fará este baseado em regras debusca.


Module="network.search" Level="DEBUG": Detail="Search rule 'B2B calls to VCS-C' did not match

destination alias '[email protected]'"


Module="network.search" Level="DEBUG": Detail="Search rule 'Spark Hybrid' ignored due to source

filtering"


Module="network.search" Level="DEBUG": Detail="Search rule 'Calls to Webex' did not match



Module="network.search" Level="DEBUG": Detail="Considering search rule 'Spark Hybrid - to Spark

Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-

[email protected]'"

Baseado no snippet do log acima, você pode ver que Expressway-e analisado gramaticalmentecom quatro regras de busca, porém somente uma (híbrido da faísca - para acender a nuvem) foiconsiderado. A regra de busca teve uma prioridade de 90 e foi visada para ir à zona DNS híbridados serviços do atendimento. Agora que o atendimento está sendo enviado a uma zona DNS,você pode rever as consultas DNS SRV que estão ocorrendo em Expressway-e


Module="network.dns" Level="DEBUG": Detail="Sending DNS query"

Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"



Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"


Module="network.dns" Level="DEBUG": Detail="Resolved hostname to:

['IPv4''TCP''146.20.193.64:5061'] (A/AAAA) Hostname:'l2sip-cfa-01.wbx2.com' Port:'5061'

Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 2"

No snippet acima, você pode ver que Expressway-e executou a consulta SRV baseada no ladodireito no pedido URI (_sips. _tcp.dmzlab.call.ciscospark.com) e resolveu a um hostname de l2sip-cfa-01.wbx2.com e da porta 5061. As resoluções de l2sip-cfa-01.wbx2.com do hostname a146.20.193.64. Com esta informação, o passo lógico que seguinte Expressway tomará é enviarum pacote SYN de TCP a 146.20.193.64 assim que pode tentar setup o atendimento. DeExpressway-e que registra, você pode rever para ver se este está acontecendo.





Module="network.tcp" Level="ERROR": Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64"

Dst-port="5061" Detail="TCP Connection Failed"

No snippet de registro diagnóstico acima de Expressway-e, você pode ver que Expressway-e estátentando conectar ao IP 146.20.193.64 que era previamente a porta TCP excedente resolved5061 contudo que esta conexão é failing imediato. O mesmos podem ser vistos da captura depacote de informação que foi recolhida.

Baseado nestes resultados, é claro que o tráfego sobre a porta 5061 não está sucedendo.Contudo, o serviço híbrido Connect do atendimento pretendeu usar a porta TCP 5062, não 5061.Consequentemente, você precisa de pensar sobre porque não é Expressway-e que resolve umregistro SRV que retorne a porta 5062. Para tentar responder a essa pergunta, você podeprocurar edições da possível configuração na zona DNS do híbrido da faísca de Expressway-e.

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

*c xConfiguration Zones Zone 6 DNS SIP Authentication Trust Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Default Transport: "TLS"

*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Name: "ciscospark.com"

*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Override: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Media AesGcm Support: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Media Encryption Mode: "On"

*c xConfiguration Zones Zone 6 DNS SIP Media ICE Support: "Off"

*c xConfiguration Zones Zone 6 DNS SIP ParameterPreservation Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP Poison Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP PreloadedSipRoutes Accept: "On"

*c xConfiguration Zones Zone 6 DNS SIP Record Route Address Type: "IP"

*c xConfiguration Zones Zone 6 DNS SIP SearchAutoResponse: "Off"

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "On"


*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"

*c xConfiguration Zones Zone 6 DNS SIP UDP BFCP Filter Mode: "Off"

*c xConfiguration Zones Zone 6 DNS SIP UDP IX Filter Mode: "Off"

No xConfiguration de Expressway-e, você pode ver que há dois valores particulares do interesseque se relacionam às pesquisas de DNS: Nome de DNSOverride e ultrapassagem deDNSOverride. Baseado fora deste xConfiguration a ultrapassagem de DNSOverride é ajustada afora, consequentemente o nome de DNSOverride não tomaria o efeito. Para compreender melhoro que estes valores fazem, você pode usar a Web UI de Expressway para olhar acima a definiçãodos valores.

Altere o pedido DNS (traduz à ultrapassagem de DnsOverride no xConfig)

Atendimentos de partida do SORVO das rotas desta zona a um domínio manualmenteespecificado do SORVO em vez do domínio no destino discado. Esta opção é pretendidaprimeiramente para o uso com serviço do atendimento da faísca de Cisco. Vejawww.cisco.com/go/hybrid-services.

Domínio a procurar por (traduz ao nome de DnsOverride no xConfig)

http://www.cisco.com/go/hybrid-services

Incorpore um FQDN para encontrar no DNS em vez da pesquisa pelo domínio no SORVO departida URI. O SORVO original URI não é afetado.

Agora que você tem estas definições, é claro que estes valores se ajustado corretamente seriaminteiramente relevantes para nossa lógica da pesquisa de DNS. Se você acopla este com asindicações do guia de distribuição para serviços híbridos do atendimento da faísca de Cisco, vocêencontraria que o pedido da alteração DNS deve ser ajustado a sobre e o domínio a procurar pelodeve ser ajustado a callservice.ciscospark.com. Se você devia mudar estes valores paraespecificar a informação correta, a lógica da consulta DNS SRV seria totalmente diferente. Estáabaixo um snippet do que você poderia esperar da perspectiva de registro diagnóstica deExpressway-e



Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"



['IPv4''TCP''146.20.193.70:5062'] (A/AAAA) ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)

Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)

Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of

relevant records retrieved: 4"

Solução

Log em Expressway-e1.Navegue à configuração divide > zonas2.Selecione a zona DNS híbrida da faísca que foi configurada3.Ajuste o pedido da alteração DNS a sobre4.Ajuste o domínio para procurar pelo valor a callservice.ciscospark.com5.Salvar as mudanças6.

Note: Se há somente uma zona DNS que está sendo usada em Expressway, uma zonaDNS separada deve ser configurada para ser usado com serviço híbrido do atendimentoque pode se aproveitar destes valores.

A porta 5062 da edição 2. é de partida obstruído à faísca de Cisco

Uma coisa que é original sobre as falhas bifurcadas da chamada externa à faísca de Cisco é queCisco do número chamado acende o app apresentará um botão da junta em seu app embora ocliente nunca soe. Como a encenação acima, porque esta edição que você precisará outra vez deusar as mesmas ferramentas e registrando ao melhor compreenda onde a falha existe. Parapontas em isolar edições do atendimento e em analisar logs, veja a seção deste artigo segundoas indicações da imagem.

Ilustração do botão da junta que está sendo apresentado

Como a edição #1 da chamada externa, você pode começar a análise no registro diagnóstico deExpressway-e, porque você usou a história da busca em Expressway para determinar que oatendimento está obtendo aquele distante. Como antes, comece com a inicial CONVIDAR queentra Expressway-e de Expressway-C. Recorde que as coisas que você quer procurar são:

Se Expressway-e recebe o CONVITE1.Se a lógica da regra de busca passa o atendimento à zona DNS híbrida2.Se a zona DNS executa a pesquisa de DNS e no domínio correto3.Se o sistema tentou e corretamente estabeleceu um cumprimento de TCP para a porta 50624.Se o handshake de TLS mútuo sucedeu5.




SIPMSG:



zone=HybridCallServiceTraversal;branch=z9hG4bK57d8d5c823824bcddfd62f6ff7e09f9939482.899441b6d60c

444e4ed58951d07b5224;proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12d4b77c97a64;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE






79e26f48eebc-30106829


Max-Forwards: 15

Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-


Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-




Expires: 180

Date: Tue, 19 Sep 2017 14:18:34 GMT



Min-SE: 1800


X-TAATag: b2967a3b-93fb-4ca4-b0d7-131f75335684


Cisco-Guid: 1783160448-0000065536-0000000126-0352430272


Content-Length: 714

<SDP Omitted>

Como você pode ver no CONVITE acima, o CONVITE é recebido como o normal. Esta é umaação “recebida” e está vindo do endereço IP de Um ou Mais Servidores Cisco ICM NT deExpressway-C. Você pode agora mover-se na lógica da regra de busca






filtering"





Module="network.search" Level="DEBUG": Detail="Considering search rule 'Spark Hybrid - to Spark

Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-

[email protected]'"

Baseado no snippet do log acima, você pode ver que Expressway-e analisado gramaticalmentecom quatro regras de busca contudo somente uma (híbrido da faísca - para acender anuvem) esteve considerado. A regra de busca teve uma prioridade de 90 e foi visada para ir àzona DNS híbrida dos serviços do atendimento. Agora que o atendimento está sendo enviado auma zona DNS, você pode rever as consultas DNS SRV que estão ocorrendo em Expressway-e.Toda a esta é inteiramente normal. Agora você pode centrar-se sobre a lógica da pesquisa deDNS










Você pode claramente ver aquele nesta instância, o registro de callservice.ciscospark.com SRV éresolved. A resposta é quatro registros válidos diferentes que usam a porta 5062. Este é umcomportamento normal. Neste momento, você pode agora analisar o cumprimento de TCP quedeve vir em seguida. Como mencionado mais cedo no documento, você pode procurar os log dediagnóstico pelo “TCP que conecta” e procurar o item de linha que alista o Dst-port="5062". Estáabaixo uma amostra do que você verá nesta encenação:










Você pode igualmente usar o tcpdump que foi incluído com o pacote de registro diagnóstico paraobter um pouco mais de informação detalhada sobre o cumprimento de TCP segundo asindicações da imagem.

Neste momento, você pode concluir que Expressway-e está distribuindo o atendimentocorretamente. O desafio nesta encenação é que uma conexão de TCP não pode ser estabelecidacom o ambiente da faísca. Isto poderia acontecer porque o ambiente da faísca não estárespondendo ao pacote SYN de TCP contudo que seria improvável considerando o server quesegura a conexão é compartilhado entre muitos clientes. Mais causa provável nesta encenação éalgum tipo do dispositivo intermediário (Firewall, IPS, etc.) não está permitindo o tráfego parafora.

Solução

Porque a edição foi isolada, estes dados devem ser fornecidos ao administrador de rede docliente. Adicionalmente, se precisam mais informação, você pode tomar uma captação fora dainterface externa do dispositivo de ponta e/ou do Firewall para uma prova mais adicional. Daperspectiva de Expressway, não há nenhuma ação mais adicional a executar desde que a ediçãonão reside nesse dispositivo.

Misconfiguration da regra de busca de Expressway da edição 3.

O misconfiguration da regra de busca é um dos problemas relacionados os maiores daconfiguração nas vias expressas. Os problemas de configuração da regra de busca podem serbidirecionais, porque você precisa regras de busca para chamadas recebidas e você precisaregras de busca para chamadas externas. Porque você anda através desta edição, vocêdescobrirá que quando as edições do regex forem bastante comuns em Expressway, não sãosempre a causa de uma edição da regra de busca. Neste segmento particular, você andará comuma chamada externa que esteja falhando. Como todos nossos outros cenários de chamadabifurcados de partida, os sintomas permanecem os mesmos:

Cisco do usuário chamado acende o app apresentado junta-se ao botão●

O telefone de chamada jogava um anel para trás●

O telefone dos em-locais do usuário chamado estava soando●

Cisco do usuário chamado acende o app nunca soou●

Como todas as outras encenações, você igualmente quererá leverage traços CUCM SDL juntocom log de diagnóstico de Expressway-C e E. Como antes, você deve prover para a história epontas leveraging da busca para identificar um atendimento nos log de diagnóstico. Como antes,era determinado usando a história da busca de Expressway-e que este atendimento fazia à lá e afalha. Está abaixo o começo da análise para que nós olhamos o SORVO inicial CONVIDAMOS a

entrada de Expressway-e de Expressway-C.




SIPMSG:



zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e38

63ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE






79e26f48eebc-30106972


Max-Forwards: 15

Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-


Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-




Expires: 180

Date: Mon, 25 Sep 2017 15:26:02 GMT



Min-SE: 1800


X-TAATag: 8e8c014d-5d01-4581-8108-5cb096778fc5


Cisco-Guid: 3582928512-0000065536-0000000240-0352430272


Content-Length: 714

<SDP Omitted>

Usando a identidade da chamada (d58f2680-9c91200a-1c7ba-1501a8c0) do encabeçamento doSORVO, você pode rapidamente procurar abaixo de todas as mensagens associadas a estediálogo. Ao olhar a terceira batida nos logs para a identidade da chamada, você pode ver queExpressway-e envia imediatamente uns 404 não encontrados a Expressway-C.




SIPMSG:

|SIP/2.0 404 Not Found


zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e38

63ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-

911bf0150bfe;received=192.168.1.5;rport=25675;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE


79e26f48eebc-30106972

To: <sip:[email protected]>;tag=10d2cfbc45e4373f



Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa505813

Content-Length: 0

Estes dados dizem-lhe duas coisas:

Expressway-e nunca tentou enviar o CONVITE à faísca de Cisco1.Expressway-e era o partido responsável para fazer a decisão de lógica para rejeitar oatendimento com um erro 404 não encontrado.

2.

Um erro 404 não encontrado significa geralmente que Expressway não pode encontrar oendereço de destino. Desde que as regras de busca do uso das vias expressas para distribuiratendimentos entre se e aos ambientes diferentes, começam focalizando no xConfiguration deExpressway-e. Dentro deste xConfiguration, você pode procurar a regra de busca que devepassar chamar à zona DNS do híbrido da faísca. Para encontrar as regras de busca configuradasem Expressway da perspectiva do xConfiguration, você pode procurar do “pela regra deSearchRules da política das zonas xConfiguration” fazendo isso, você verá uma lista deconfiguração da regra de busca para cada regra de busca criada em Expressway. O número quevem depois que a “regra” aumentará baseado na regra de busca que era primeira criados queestá sendo marcada 1. Se você está tendo o problema que encontra a regra de busca. você podeusar valores de nomeação de uso geral tais como a “faísca” para encontrar melhor a regra debusca. Uma outra maneira de identificar a regra está encontrando o valor de série do teste padrãoa que é ajustado “. *@.* \ .ciscospark \ .com”. Aquela é a corda do teste padrão que é supõe paraser configurada. (Supondo a corda do teste padrão é configurado corretamente)

Após ter revisto o xConfiguration desta encenação, você pode ver que a regra de busca 6 é aregra correta para passar chamar à faísca de Cisco.


*c xConfiguration Zones Policy SearchRules Rule 6 Description: "Outbound calls to Spark"

*c xConfiguration Zones Policy SearchRules Rule 6 Mode: "AliasPatternMatch"

*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Spark Hybrid - to Spark Cloud"

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Behavior: "Leave"


*c xConfiguration Zones Policy SearchRules Rule 6 Pattern String: ".*@.*\.ciscospark\.com"

*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Type: "Regex"



*c xConfiguration Zones Policy SearchRules Rule 6 Protocol: "SIP"


*c xConfiguration Zones Policy SearchRules Rule 6 Source Mode: "Named"

*c xConfiguration Zones Policy SearchRules Rule 6 Source Name: "Hybrid Call Service Traversal"



*c xConfiguration Zones Policy SearchRules Rule 6 Target Name: "Hybrid Call Services DNS"



Para testar este teste padrão, nós podemos usar a função de teste padrão da verificaçãodescrita no. O importantes chamam são aqui que nós quereremos os seguintes valoresconfigurados:

Teste padrão da manutenção > das ferramentas > da verificação

Aliás: %Request URI no INVITE% inicial (ex: [email protected])●

Tipo do teste padrão: Regex●

Corda do teste padrão. *@.* \ .ciscospark \ .com●

Comportamento do teste padrão: Sair●

Se o Regex para a regra está correto estabelecido, você deve ver o resultado deste teste padrãoda verificação suceder. Está abaixo uma ilustração que demonstra esta segundo as indicações daimagem:

Agora que você pode confirmar a regra de busca esta presente e configurou corretamente, vocêpode olhar mais perto na lógica da busca que Expressway está executando para determinar seestá afetando Expressway-e que está enviando os 404 não encontrados. Está abaixo umaamostra da lógica da regra de busca que Expressway executava.






filtering"





Module="network.search" Level="DEBUG": Detail="Considering search rule 'to DNS' towards target

'DNS' at priority '100' with alias '[email protected]'"


Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com"

Type="NAPTR (IPv4 and IPv6)"


Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"



Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"

Nesta amostra, você pode ver que Expressway processou quatro regras de busca. Os primeiros 3não foram considerados devido às várias razões, porém os 4ns foram considerados. A parteinteressante de dados é aquela imediatamente depois da consideração que Expressway salta emlinha reta à lógica da pesquisa de DNS. Se você recorda o que nós tínhamos visto noxConfiguration a regra de busca configurada para o híbrido da faísca foi nomeado híbrido da

faísca - para acendê-la a nuvem e nem sequer esteve considerado nesta lógica da regra debusca acima. Neste momento, vale a vista em como a regra de busca considerada (ao DNS) foiexecutada de modo que você possa melhor compreender se está impactando o uso da regra debusca híbrida da faísca. Para fazer isso, você pode revisitar o xConfig esta vez que procura aregra de busca nomeada “ao DNS”


*c xConfiguration Zones Policy SearchRules Rule 1 Description:

*c xConfiguration Zones Policy SearchRules Rule 1 Mode: "AliasPatternMatch"

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Behavior: "Leave"


*c xConfiguration Zones Policy SearchRules Rule 1 Pattern String: "(?!.*@%localdomains%.*$).*"

*c xConfiguration Zones Policy SearchRules Rule 1 Pattern Type: "Regex"



*c xConfiguration Zones Policy SearchRules Rule 1 Protocol: "Any"


*c xConfiguration Zones Policy SearchRules Rule 1 Source Mode: "Any"

*c xConfiguration Zones Policy SearchRules Rule 1 Source Name: "Please Select"



*c xConfiguration Zones Policy SearchRules Rule 1 Target Name: "DNS"



Após a revisão desta regra de busca, você pode concluir o seguinte:

A corda do teste padrão combinaria Cisco acende o pedido URI●

A prioridade é ajustada a 100●

O progresso (comportamento do teste padrão) é ajustado para parar.●

O que esta informação nos diz é que Cisco acende o pedido URI que está sendo chamadocombinaria esta regra e se a regra foi combinada Expressway pararia de procurar (consideração)outras regras de busca. Com esta compreensão, a prioridade da regra transforma-se um fatorachave. A maneira que os trabalhos da prioridade da regra de busca de Expressway são a regrada mais baixa prioridade é tentada primeiramente. A seguir, está um exemplo.

Regra de busca: Local

Comportamento do teste padrão: Continuar

Prioridade 1

Regra de busca: Vizinho

Comportamento do teste padrão: Continuar

Prioridade 10

Regra de busca: DNS

Comportamento do teste padrão: Pare

50 pés da prioridade

Neste exemplo, a regra de busca nomeada Local (1) seria tentada primeiramente e se um fósforofoi encontrado mover-se-ia para o vizinho da regra de busca (10) devido ao comportamento doteste padrão que está sendo ajustado para continuar. Se o vizinho da regra de busca não foicombinado, ainda continuará à regra de busca DNS (50 pés) e considerará aquela última. Se aregra de busca DNS foi combinada, a busca pararia apesar de se havia uma outra regra de buscacom uma prioridade mais alta do que 50 pés, porque o comportamento do teste padrão foiajustado para parar.

Com esta compreensão, você pode olhar as prioridades da regra de busca entre “ao DNS”e “acenda o híbrido - para acender as regras da nuvem”.

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"



*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Spark Hybrid - to Spark Cloud"



Aqui, você pode ver que “a regra DNS” tem uma baixa prioridade do que da “o híbrido faísca -para acender a nuvem” ordene -- consequentemente, “a regra DNS” será tentada primeiramente.Dado que o comportamento do teste padrão (progresso) está ajustado para parar, Expressway-enunca considera o híbrido da faísca - acender a regra da nuvem e o atendimento falhafinalmente.

Solução

Este tipo de problema é cada vez mais comum com serviço híbrido do atendimento conecta.Muitas vezes quando a solução é distribuída, os povos criam uma regra prioritária para usar-separa as buscas da faísca de Cisco. Muitas vezes esta regra que é criada não está obtendoinvocada devido às regras existentes da baixa prioridade está sendo combinada e conduzem auma falha. Esta edição acontece em ambas as chamadas de entrada e de saída à faísca deCisco. Para resolver isto, você precisará de seguir estas etapas:

Log em Expressway-e1.Navegue às regras da configuração > do Plano de discagem > de busca2.Encontre a regra de busca híbrida da faísca e clique-a (ex: Nome: Híbrido da faísca - paraacender a nuvem)

3.

Ajuste o valor de prioridade a algo mais baixo do que outras regras de busca, contudoaltamente bastante de modo que não impacte outro. (Ex: Prioridade: 99)

4.

O princípio básico geral com regras de busca é mais específica a corda do teste padrão, maisbaixo pode ser colocada na lista de prioridades da regra de busca. Uma zona DNS é configuradageralmente com uma corda do teste padrão que esteja indo travar qualquer coisa que não é umdomínio local e o enviar ao Internet. Devido a isto, nós recomendamos que você se ajusta que otipo de regra de busca a uma alta prioridade assim que a ele invocou por último.

Misconfiguration COMPLETO de Expressway da edição 4.

A solução de Expressway permite a mitigação da fraude na tarifa de ligações usando a lógica(COMPLETA) da língua do Processamento de chamadas disponível no server. Se a solução deExpressway que está sendo distribuída está sendo usada somente para o serviço híbrido do

atendimento da faísca de Cisco e o móbil & o Acesso remoto, nós recomendamos fortemente quea política e as regras COMPLETAS estão permitidas e executadas. Quando a configuraçãoCOMPLETA em Expressway para o híbrido da faísca de Cisco for relativamente simples, sedesconfigurado pode facilmente obstruir tentativas de chamada do acontecimento. Asencenações abaixo da mostra você como usar o registro diagnóstico para identificar ummisconfiguration COMPLETO.

Como todos outros cenários de chamada bifurcados de partida, os sintomas permaneceram osmesmos:

Cisco do usuário chamado acende o app apresentou um botão da junta●

O telefone de chamada jogava um anel para trás●

O telefone dos em-locais do usuário chamado estava soando●

O app do usuário chamado nunca soou●

Como todas as outras encenações, você pode usar os traços CUCM SDL junto com log dediagnóstico de Expressway-C e E. Como antes, você deve prover para usar a história e as pontasda busca para identificar um atendimento nos log de diagnóstico. Como antes, era determinadousando a história da busca de Expressway-e que este atendimento estava chegando lá e falhar.Está abaixo o começo da análise em que você pode olhar o SORVO inicial CONVIDA a entradade Expressway-e de Expressway-C.




SIPMSG:



zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0d

e36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE






79e26f48eebc-30107000


Max-Forwards: 15

Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-


Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-




Expires: 180

Date: Mon, 25 Sep 2017 20:54:43 GMT



Min-SE: 1800


X-TAATag: 4fffefed-0512-4067-ac8c-35828f0a1150


Cisco-Guid: 3224432896-0000065536-0000000264-0352430272


Content-Length: 714

<SDP Omitted>

Usando a identidade da chamada (c030f100-9c916d13-1cdcb-1501a8c0) do encabeçamento doSORVO, você procura rapidamente abaixo de todas as mensagens associadas a este diálogo. Aoolhar a terceira batida nos logs para a identidade da chamada, você pode ver que Expressway-eenvia imediatamente uns 403 proibidos a Expressway-C.




SIPMSG:

|SIP/2.0 403 Forbidden


zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0d

e36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-

5ea7e82f8aac;received=192.168.1.5;rport=26404;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE


79e26f48eebc-30107000

To: <sip:[email protected]>;tag=64fe7f9eab37029d



Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa512577

Content-Length: 0

Para compreender porque Expressway-e negou este atendimento e enviou um erro proibido 403a Expressway-C, você quer analisar as entradas de registro entre os 403 proibidos e o SORVOoriginal CONVIDA aquele entrado em Expressway. Analisando estas entradas de registro, vocêpode tipicamente ver todas as decisões de lógica que estão sendo feitas. Note que você não vênenhuma regras de busca que estão sendo invocadas mas vê a lógica (COMPLETA) da língua doprocesso do atendimento que está sendo invocada. Está abaixo um snippet daquele.



<routed> "



<rule-switch> "



<rule unauthenticated-origin=".*" destination=".*@dmzlab\.call\.ciscospark\.com.*" message-

regex=""> matched "



<reject/> "

Baseado na análise do log acima. você pode fazer a determinação que o COMPLETO estárejeitando o atendimento.

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Search Completed"

Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="[email protected]" Dst-

alias-type="SIP" Dst-alias="sip:[email protected]" Call-serial-

number="48c80582-ec79-4d89-82e2-e5546f35703c" Tag="4fffefed-0512-4067-ac8c-35828f0a1150"

Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-25

20:54:43,726"

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Call Rejected" Service="SIP" Src-

ip="192.168.1.5" Src-port="26404" Src-alias-type="SIP"

Nota: Nesta situação você não verá as regras de busca que estão sendo invocadas porque CPLs,FindMe, e Transforms todos são processados antes de uma regra de busca

Na maioria de circunstâncias, você pode leverage o xConfig de Expressway para compreendermelhor as circunstâncias. Contudo, para CPLs, você não pode ver as regras que são definidas,simplesmente se a política é permitida. Está abaixo a parcela do xConfig que nos mostra que esteExpressway-e está usando a lógica COMPLETA local.

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

Para compreender melhor a configuração da regra, você precisa de entrar a Expressway-e e denavegar à configuração > à política > às regras do atendimento segundo as indicações daimagem.

Ao rever esta configuração, você pode ver o seguinte está configurado

Fonte: . *

Destino:. *@dmzlab \ .call \ .ciscospark \ .com.*

Ação: Reject

Comparado ao que é documentado no guia híbrido da distribuição de serviço do atendimento dafaísca de Cisco, você pode ver que a fonte e o destino estiveram configurados para trás.

Solução

Para resolver esta edição, você precisa de reajustar a configuração COMPLETA da regra demodo que a fonte seja ajustada a. *@%spark_subdomain% \ .call \ .ciscospark \ .com.* e o padrãode destino é. *

Log em Expressway-e1.Navegue à configuração > à política > às regras do atendimento2.Selecione a regra que setup para o serviço híbrido do atendimento da faísca de Cisco3.Incorpore o teste padrão da fonte como. *@%spark_subdomain% \ .call \ .ciscospark \ .com.*4.

/content/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/callservices/cmgt_b_ciscospark-hybrid-call-service-config-guide/cmgt_b_ciscospark-hybrid-call-service-config-guide_chapter_0110.html


(ex:. *@dmzlab \ .call \ .ciscospark \ .com.*)Incorpore o padrão de destino como. *5.Selecione a salvaguarda6.

Para obter mais informações sobre da aplicação COMPLETA para o híbrido da faísca refira oGuia de Design do híbrido da faísca de Cisco.

Bidirecional: Cisco acende aos Em-locais ou aos Em-locais à faísca de Cisco

O valor-limite do telefone IP/Colaboração da edição 1. está oferecendo um codec de áudiodiferentes de G.711, de G.722, de AAC-LD, ou de opus

O serviço híbrido do atendimento conecta apoios quatro Codecs de áudio diferentes: G.711,G.722, AAC-LD, e opus. Para estabelecer com sucesso um atendimento com o ambiente dafaísca de Cisco, um deste Codecs de áudio deve ser usado. O ambiente de em-locais pode sersetup para usar muitos tipos de Codecs de áudio mas ao mesmo tempo pode ser setup pararestringi-lo. Isto pode acontecer intencionalmente ou involuntariamente pelo uso do costume e/ouoptar por ajustes da região no CM unificado. Para este comportamento particular, os testespadrões de registro podem diferir baseado no sentido do atendimento e se o CM unificado esteveconfigurado para se usar cedo ou oferta atrasada. Estão abaixo os exemplos de algumassituações diferentes onde este comportamento poderia se apresentar:

Cisco acende envia um de entrada CONVIDA com o SDP que oferece G.711, G.722, AAC-LD, e opus. Expressway-C envia esta mensagem CM unificado mas o CM unificado éconfigurado para permitir somente G.729 para este atendimento. Assim, o CM unificadorejeitará o atendimento devido a nenhum codec disponível.

1.

O CM unificado tenta a chamada externa porque a oferta adiantada à faísca de Cisco quesignifica que a inicial CONVIDA enviado a Expressway-C conterá o SDP que apoiaSOMENTE o áudio de G.729. Cisco acende envia então a uma APROVAÇÃO 200 com oSDP esse zero para fora o áudio (m=audio 0 RTP/SAVP) porque não apoia G.729. Uma vezque Expressway-C passa este CONVIDE ao CM unificado, o CM unificado termina oatendimento porque não há um codec disponível.

2.

O CM unificado tenta a chamada externa porque a oferta atrasada à faísca de Cisco quesignifica que a inicial CONVIDA enviado a Expressway-C não conterá o SDP. Cisco acendeenvia então uma APROVAÇÃO 200 com o SDP que contém todos os apoios apoiados dafaísca de Cisco do Codecs de áudio. Expressway-C envia esta 200 APROVAÇÃO CMunificado mas o CM unificado é configurado somente para permitir somente G.729 para esteatendimento. Assim, o CM unificado rejeitará o atendimento devido a nenhum codecdisponível.

3.

Se você está tentando identificar um serviço híbrido do atendimento conecte a falha de chamadaque combina esta edição, você deve obter Expressway entra traços unificados da adição CMSDL. A situação abaixo #2 do fósforo dos snippet do log do exemplo onde o CM unificado estátentando a chamada externa como cedo oferece. Porque nós sabemos que o atendimento estásaindo à faísca de Cisco, a análise do log começa em Expressway-e.

Está abaixo um snippet da inicial CONVIDA para fora à faísca de Cisco. Você pode ver que ocodec de áudio preferido está ajustado a G.729 (payload 18). Os 101 é para o DTMF e para estecenário particular não é relevante.





SIPMSG:

INVITE sip:[email protected] SIP/2.0


zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-

id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport

Via: SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-



zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47d

bf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025


zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd

66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-

c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 101 INVITE

Remote-Party-ID: "Jonathan Robb" <sip:[email protected]>;privacy=off;screen=no;party=calling

Contact: <sip:172.16.2.2:5073;transport=tls>;video;audio


79e26f48eebc-30106833


Max-Forwards: 14

Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-


Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-


Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY

User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

Supported: X-cisco-srtp-fallback,replaces,timer

Session-Expires: 1800;refresher=uac

Min-SE: 500

X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725



Content-Length: 1407

v=0

o=tandberg 0 1 IN IP4 64.102.241.236

s=-

c=IN IP4 64.102.241.236

b=AS:384

t=0 0

m=audio 52668 RTP/SAVP 18 101 <-- CUCM is only supporting G.729 for this call

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................


UNENCRYPTED_SRTCP



UNENCRYPTED_SRTCP

a=sendrecv

a=rtcp:52669 IN IP4 64.102.241.236

m=video 52670 RTP/SAVP 126 97

b=TIAS:384000

a=rtpmap:126 H264/90000

a=fmtp:126 profile-level-id=42801e;packetization-mode=1;level-asymmetry-allowed=1

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42801e;packetization-mode=0;level-asymmetry-allowed=1

a=rtcp-fb:* nack pli



UNENCRYPTED_SRTCP



UNENCRYPTED_SRTCP

a=sendrecv

a=content:main

a=label:11

a=rtcp:52671 IN IP4 64.102.241.236

Em resposta a esta inicial CONVIDE, Cisco acendem responde com uma mensagem de 200APROVAÇÕES. Se você olha um olhar mais atento esta mensagem, você pode ver que o codecde áudio esteve zerado para fora. Isto é problemático porque sem uma porta audio atribuída, oatendimento não poderá negociar esse córrego.




SIPMSG:

SIP/2.0 200 OK


zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-

id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport=38245;received=192.168.5.26,SIP/2.0/TLS

172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-

service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone,SIP/2.0/TLS

192.168.1.6:5061;egress-

zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47d

bf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-

14872e007efb;received=192.168.1.6;rport=25025,SIP/2.0/TLS 192.168.1.5:5061;egress-

zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd

66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-

c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-

zone=HybridCallServiceTraversal,SIP/2.0/TCP

192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11


CSeq: 101 INVITE

Contact: "l2sip-UA" <sip:[email protected]:5062;transport=tls>


79e26f48eebc-30106833

To: <sip:[email protected]>;tag=1311451760

Record-Route: <sip:l2sip-cfa-01.wbx2.com:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-

[email protected]:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-


Allow: INVITE,ACK,CANCEL,BYE,REFER,INFO,OPTIONS,NOTIFY,SUBSCRIBE

User-Agent: Cisco-L2SIP

Supported: replaces

Accept: application/sdp

Allow-Events: kpml

Session-ID: ed35426ed3ade6fdc3b058792333df2b;remote=75957d4fb66a13e835c10737aa329445

Locus: 4711a33f-9d49-11e7-9bf6-dea12d0f2127

Locus-Type: CALL


Content-Length: 503

v=0

o=linus 0 1 IN IP4 146.20.193.109

s=-

c=IN IP4 146.20.193.109

b=TIAS:384000

t=0 0

m=audio 0 RTP/SAVP * <-- Spark is zeroing this port out

m=video 33512 RTP/SAVP 108

c=IN IP4 146.20.193.109

b=TIAS:384000

a=content:main

a=sendrecv

a=rtpmap:108 H264/90000

a=fmtp:108 profile-level-id=42001E;packetization-mode=1;max-mbps=40500;max-fs=1620;max-

fps=3000;max-br=10000;max-dpb=3037;level-asymmetry-allowed=1

a=rtcp-fb:* nack pli

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:........................................

a=label:200

Você pode agora usar TranslatorX para rever o restante do diálogo. Você pode ver que o diálogopróprio termina com um ACK. O problema é imediatamente depois que o diálogo termina lá é umADEUS que venha do sentido de Expressway-C segundo as indicações da imagem.

Está abaixo uma amostra detalhada da mensagem do ADEUS. Você pode claramente ver que oagente de usuário é Cisco-CUCM11.5 que significa que a mensagem esteve gerada pelo CMunificado. Uma outra coisa a indicar é que o código de motivo está ajustado a cause=47. Atradução comum para esta não é nenhum recurso disponível.




SIPMSG:

BYE sip:192.168.1.6:5071;transport=tls SIP/2.0


zone=HybridCallServiceTraversal;branch=z9hG4bK90a666b3461356f8cd605cec91e4538240575.494a140082bd

66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;rport

Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12ddd10269d39;received=192.168.1.21;ingress-

zone=CUCM11


CSeq: 102 BYE


79e26f48eebc-30106833

To: <sip:[email protected]>;tag=f3734601fb0eb541

Max-Forwards: 69

Route: <sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-

[email protected]:7003;transport=tls;lr>,<sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-



Date: Tue, 19 Sep 2017 14:46:09 GMT

X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725

Reason: Q.850 ;cause=47

Session-ID: 75957d4fb66a13e835c10737aa329445;remote=ed35426ed3ade6fdc3b058792333df2b

Content-Length: 0

Porque Cisco acende o componente zerou para fora os codec de áudio para esta amostra doatendimento, o foco deve estar ligada

a) a inicial CONVIDA que foi enviada à faísca de Cisco e

b) o que era a faísca de Cisco da lógica usada a zero para fora que move.

Agora olhando o que é original sobre a inicial CONVIDE o que pode ser observado é ele contémsomente G.729. Conhecendo isto, reveja o guia híbrido da distribuição de serviço do atendimentoda faísca de Cisco e reveja especificamente a preparação seu capítulo do ambiente onde a etapa5 do completo as condições prévias para o serviço híbrido do atendimento conecta aseção chama os codecs específicos que são apoiados. Lá nós veríamos este:

Cisco acende apoia os seguintes codecs:

Audio — G.711, G.722, AAC-LD●

Vídeo — H.264●

Com esta informação à mão, você pode concluir que o CM unificado está enviando um codec deáudio unsupported que seja a razão que a faísca de Cisco está zerando para fora a porta.

Solução

Para endereçar esta situação particular, você pode precisar de rever a configuração de regiãoentre a faísca RD de Cisco que está ancorando os em-locais do atendimento e o tronco doSORVO para Expressway-C. Para fazer assim, determine que pool de dispositivos aquelesdois elementos estão. O pool de dispositivos contém os mapeamentos às regiões.

Para determinar o pool de dispositivos do tronco do SORVO de Expressway-C:

Log no CM unificado1.Navegue ao dispositivo > ao tronco2.Procure pelo nome do tronco ou clique o achado3.Selecione o tronco de Expressway-C4.Grave o nome do pool de dispositivos5.

Para determinar o pool de dispositivos do CTI-RD ou de Cisco Faísca-RD que ancoraram oatendimento



Navegue ao dispositivo > ao telefone1.Quando o procurar pode selecionar o tipo de dispositivo contém a faísca ou o dispositivoremoto CTI (segundo o que o cliente se está usando.

2.

Grave o nome do pool de dispositivos3.Determine a região anexada a cada pool de dispositivos

Navegue ao sistema > ao pool de dispositivos1.Procure pelo pool de dispositivos usado para o tronco do SORVO de Expressway-C2.Clique sobre o pool de dispositivos3.Grave o nome da região4.Procure pelo pool de dispositivos usado para o Faísca-RD ou o CTI-RD5.Clique sobre o pool de dispositivos6.Grave o nome da região7.

Determine o relacionamento da região do ithe

Navegue à informação do sistema > da região > à região1.Procure em uma das regiões identificadas acima2.Determine se sua é uma relação da região entre ambas as regiões que esteja usando G.7293.

Neste momento, se você identifica o relacionamento que está usando G.729, você precisará deajustar o relacionamento para apoiar do Codecs de áudio apoiado que Cisco acende usos ou usaum pool de dispositivos diferente que tenha uma região que apoie esta. Na encenaçãodocumentada acima, o seguinte era determinado:

Região do tronco de Expressway-C: ReservingBandwidth

Região Faísca-RD: RTP-dispositivos

Está abaixo uma ilustração gráfica do relacionamento entre as regiões dos RTP-dispositivos e doReservingBandwidth segundo as indicações da imagem.

Mudando o pool de dispositivos o tronco de Expressway-C estava dentro, você muda orelacionamento da região. O pool de dispositivos novo teve uma região ajustada à RTP-infraestrutura, consequentemente o relacionamento novo da região entre o tronco de CiscoFaísca-RD e de Expressway-C era RTP-dispositivos e RTP-infraestrutura. Como representadoacima, você pode ver os apoios AAC-LD deste relacionamento que é um do Codecs de áudioapoiado para a faísca de Cisco e assim que o atendimento estabelecer-se-&z corretamente.

A edição 2. unificou o tamanho máximo do mensagem recebida CM excedido

Porque o vídeo se tornou mais predominante dentro da empresa, o tamanho das mensagens doSORVO que contêm o SDP cresceu substancialmente. Os server que processam estasmensagens devem ser configurados dentro como a maneira que podem aceitar um grandepacote. Em muitos server do Controle de chamadas, os valores padrão são muito bem. Com o

gerente das comunicações unificadas de Cisco (CM unificado), os valores padrão para seguraruma grande mensagem do SORVO que contém liberações do passado SDP dentro não estavam.Em umas liberações mais atrasadas do CM que unificado o tamanho do valor permitido umamensagem do SORVO foi aumentado contudo este valor é ajustado somente em novo instala nãoelevações. Com este todo o disse, os clientes que estão promovendo suas liberações mais velhasdo CM unificado para apoiar o serviço híbrido Connect do atendimento puderam ser afetados pelotamanho máximo do mensagem recebida no CM unificado que é demasiado baixo.

Se você está tentando identificar um serviço híbrido do atendimento conecte a falha de chamadaque combina esta edição, você deve obter Expressway entra traços unificados da adição CMSDL. Para identificar a falha, compreenda primeiramente o que acontece e então os tipos deencenações em que a falha pode ocorrer.

Para responder à pergunta do que acontece, você deve saber que uma vez que o CM unificadorecebe uma mensagem do SORVO que seja demasiado grande, fecha simplesmente o soqueteTCP e não responde a Expressway-C.

Com isto disse, há muitas situações e as maneiras isto poderiam ocorrer:

Cisco acende envia um de entrada CONVIDA com o SDP que é demasiado grande.Expressway-C passa este no CM unificado e unificou o CM fecha o soquete TCP então queo diálogo do SORVO cronometrará para fora.

1.

O CM unificado tenta a chamada externa como adiantado oferece acender que significa quea inicial CONVIDA enviado a Expressway-C conterá o SDP. Cisco acende envia então umaAPROVAÇÃO 200 com o SDP na resposta e na resposta de 200 APROVAÇÕES quandopassado de Expressway-C ao CM unificado é demasiado grande. O CM unificado fecha osoquete TCP então que o diálogo do SORVO cronometrará para fora.

2.

O CM unificado tenta a chamada externa porque a oferta atrasada a acender que significaque a inicial convida enviado a Expressway-C não conterá o SDP. Cisco acende envia entãouma APROVAÇÃO 200 com o SDP e a oferta 200 APROVADA quando passado deExpressway-C ao CM unificado é demasiado grande. O CM unificado fecha o soquete TCPentão que o diálogo do SORVO cronometrará para fora.

3.

Olhar através dos logs de Expressway-C para esta condição particular ajuda-o a compreender ofluxo de mensagem. Se você devia usar um programa como TranslatorX, você poderia ver queEE que Expressway-C está passando Cisco acenda a APROVAÇÃO 200 com SDP CM unificado.O desafio é que o CM unificado nunca responde para trás com um SORVO ACK segundo asindicações da imagem.

http://translatorx.org/

Desde o CMis unificado o partido responsável para não responder, vale revendo os traços SDLpara ver como o CM unificado está segurando esta circunstância. O que você encontraria nestaencenação é que o CM unificado ignora a grande mensagem de Expressway-C. Um artigo delinha de registro tal como esse seria imprimido abaixo.

CUCM Traces

53138762.000 |09:05:19.762 |AppInfo |SIPSocketProtocol(5,100,14,707326)::handleReadComplete

send SdlReadRsp: size 5000

53138763.000 |09:05:19.762 |SdlSig |SdlReadRsp |wait

|SIPTcp(5,100,71,1) |SdlTCPConnection(5,100,14,707326)

|5,100,14,707326.4^10.36.100.140^* |*TraceFlagOverrode

53138763.001 |09:05:19.762 |AppInfo |SIPTcp - SdlRead bufferLen=5000

53138763.002 |09:05:19.762 |AppInfo |//SIP/Stack/Error/0x0/httpish_cache_header_val: DROPPING

unregistered header Locus: c904ecb1-d286-11e6-bfdf-b60ed914549d

53138763.003 |09:05:19.762 |AppInfo |//SIP/Stack/Info/0x0/httpish_msg_process_network_msg:

Content Length 4068, Bytes Remaining 3804

53138763.004 |09:05:19.762 |AppInfo |//SIP/Stack/Info/0x0/ccsip_process_network_message:

process_network_msg: not complete

53138763.005 |09:05:19.762 |AppInfo |SIPTcp - Ignoring large message from %Expressway-

C_IP%:[5060]. Only allow up to 5000 bytes. Resetting connection.

Depois que o diálogo do SORVO cronometra para fora, Cisco acende enviará uma mensagem deentrada da diminuição do SORVO 603 a Expressway-e como referido na amostra do log abaixo.

Expressway-E Traces

2017-01-04T09:05:40.645-05:00 vcs-expressway tvcs: UTCTime="2017-01-04 14:05:40,645"

Module="network.sip" Level="DEBUG": Action="Received" Local-ip="%Exp-E%" Local-port="25150" Src-

ip="%Spark_IP%" Src-port="5062" Msg-Hash="2483073756671246315" SIPMSG: SIP/2.0 603 Decline

Como mencionado, há três encenações diferentes em que você poderia ver este comportamento.

Para maior clareza, as amostras do log fornecidas nesta ilustração combinaram a situação 3 ondeo atendimento foi enviado a de partida à faísca de Cisco enquanto oferta atrasada.

Solução

Log no CM unificado 1.Navegue ao sistema > aos parâmetros de serviço2.Selecione o server que está executando o serviço do gerenciador de chamada3.Escolha o serviço do Cisco Call Manager quando alertado para uma seleção do serviço4.Selecione a opção avançada5.Sob os parâmetros Clusterwide (dispositivo - Os ajustes do SORVO) mudam o tamanhomáximo do mensagem recebida do SORVO a 18000.

6.

Selecione a salvaguarda7.Repita este processo para cada nó unificado CM que está executando o serviço do CiscoCall Manager.

8.

Note: Para que um valor-limite do telefone IP, da Colaboração, e/ou o tronco do SORVOleverage este ajuste deve ser reiniciada. Estes dispositivos podem ser reiniciadosindividualmente para minimizar o impacto ao environment.DO não restaurados cadadispositivo no CUCM a menos que você souber que é absolutamente aceitável fazer assim.

Apêndice 1: Ferramentas de Troubleshooting de Expressway

Verifique a utilidade do teste padrão

Expressway tem um teste padrão que verifica a utilidade que é útil quando você quer testar secompatibilidades de padrão um pseudônimo particular e é transformado na maneira prevista. Autilidade pode ser encontrada em Expressway sob opção de menu do teste padrão damanutenção > das ferramentas > da verificação. O mais geralmente, isto é usado se você quer oteste se seu regex da regra de busca está indo combinar corretamente um pseudônimo a umacorda do teste padrão e executar então opcionalmente a manipulação bem sucedida da corda.Para o atendimento híbrido preste serviços de manutenção conectam, você pode igualmentetestar que o FQDN unificado do conjunto CM está indo combinar a corda do teste padrão essavocê se estabelece para o FQDN unificado do conjunto CM. Ao usar esta utilidade, recorde que oatendimento distribuirá baseado no parâmetro unificado FQDN do conjunto CM alistado noencabeçamento da rota, não o destino URI. Por exemplo se, os seguintes convidam entraramExpressway, testam a funcionalidade do teste padrão da verificação contra cucm.rtp.ciscotac.net,não [email protected].

SIPMSG:



zone=HybridCallServiceTraversal;branch=z9hG4bKcac6d95278590991a2b516cf57e75827371;proxy-call-

id=abcba873-eaae-4d64-83b4-c4541d4e620c;rport

Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK837b03f2cd91b6b19be4fc58edb251bf12;x-cisco-



zone=DefaultZone;branch=z9hG4bK524f89592d00ffc45b7b53000271676c370.88b5177ac4d7cfcae1eb8f8be78da

055;proxy-call-id=2db939b2-a49b-4307-8d96-23716a2c090b;received=172.16.2.2;rport=25010

Via: SIP/2.0/TLS

192.168.4.150:5062;branch=z9hG4bK92f9ef952712e6610c3e6b72770c1230;received=148.62.40.63;rport=39



3d27a6f914badee6420287903c9c6a45;rport=45939


CSeq: 1 INVITE

Contact: <sip:192.168.1.6:5073;transport=tls>



Max-Forwards: 15


Para usar o teste padrão da verificação para testar o atendimento híbrido preste serviços demanutenção conectam o roteamento da regra de busca do encabeçamento da rota, seguem estasetapas:

Navegue ao teste padrão da manutenção > das ferramentas > da verificação1.Para o pseudônimo, incorpore o FQDN unificado do conjunto CM2.Ajuste o tipo do teste padrão para prefixar3.Ajuste o FQDN unificado do conjunto da corda CM do teste padrão4.Ajuste o comportamento do teste padrão para sair5.Selecione o teste padrão da verificação6.

Se as regras de busca em Expressway são configuradas corretamente, você pode esperar ver oretorno dos resultados uma mensagem sucedida.

Está abaixo um exemplo de um teste bem sucedido do teste padrão da verificação segundo asindicações da imagem.

A razão que esta é bem sucedida é porque este pseudônimo (cucm.rtp.ciscotac.net) combina acorda do teste padrão do prefixo de (cucm.rtp.ciscotac.net). Para compreender como umatendimento é distribuído baseou fora destes resultados, você pode usar Expressway encontra autilidade descrita abaixo.

Encontre a utilidade

Expressway encontra a utilidade é útil se você quer testar se Expressway pode distribuir umatendimento a uma zona específica baseada no dado aliás. Todo o isto pode ser terminado semter que colocar um atendimento real. A utilidade da localização pode ser encontrada em

Expressway sob a manutenção > as ferramentas > encontra o menu. Abaixo fornece algumainstrução em como você poderia usar a funcionalidade da localização em Expressway-C paradeterminar se o server poderia distribuir um atendimento baseado no FQDN unificado do conjuntoCM encontrado no encabeçamento da rota do SORVO.

Navegue à manutenção > às ferramentas > localizam1.Incorpore o FQDN unificado do conjunto CM ao campo do pseudônimo2.Selecione o SORVO como o protocolo3.Selecione sua zona híbrida do cliente de Traversal da faísca de Cisco para a fonte4.Seleto localize5.

Na parte inferior da relação, você verá agora os resultados da busca. Está abaixo um exemplo doteste de amostra que foi executado com os resultados de harmonização segundo as indicaçõesda imagem.

Estão abaixo os resultados da localização (acima). Negritos são os valores do interesse mostradestes resultados o seguinte

O fato de que o pseudônimo poderia ser distribuído (verdadeiro)●

Informação de origem (nome de zona/tipo)●

Informação de destino (aliás sendo distribuído)●

Regra de busca que está sendo combinada (roteamento de entrada do serviço híbrido doatendimento)

●

Divida que o atendimento estaria enviado a (CUCM11)●

Search (1)

State: Completed

Found: True

Type: SIP (OPTIONS)

SIPVariant: Standards-based

CallRouted: True

CallSerial Number: ae73fb64-c305-457a-b7b3-59ea9688c630

Tag: 473a5b19-9a37-40bf-bbee-6f7bc94e7c77

Source (1)

Authenticated: True

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: xcom-locate

Zone (1)

Name: Hybrid Call Service Traversal

Type: TraversalClient

Path (1)

Hop (1)

Address: 127.0.0.1

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:cucm.rtp.ciscotac.net

StartTime: 2017-09-24 09:51:18

Duration: 0.01

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: cucm.rtp.ciscotac.net

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown


SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown


SubSearch (1)

Type: Search Rules

SearchRule (1)

Name: as is local

Zone (1)

Name: LocalZone

Type: Local

Protocol: SIP

Found: False

Reason: Not Found

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.5:0

Alias (1)

Type: Url

Origin: Unknown


Zone (2)

Name: LocalZone

Type: Local

Protocol: H323

Found: False

Reason: Not Found

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.5:0

Alias (1)

Type: Url

Origin: Unknown


SearchRule (2)

Name: Hybrid Call Service Inbound Routing

Zone (1)

Name: CUCM11

Type: Neighbor

Protocol: SIP

Found: True

StartTime: 2017-09-24 09:51:18

Duration: 0

Gatekeeper (1)

Address: 192.168.1.21:5065

Alias (1)

Type: Url

Origin: Unknown


Registro diagnóstico

Quando você está pesquisando defeitos uma chamada ou os media emitem para um atendimentoque atravesse a solução de Expressway, você deve usar o registro diagnóstico. Esta capacidadede Expressway dá a um coordenador Ao grande detalhe de informação para todas as decisõesque de lógica Expressway está indo completamente enquanto o atendimento passa. Você podever o corpo completo SORVER mensagens, como as passagens de Expressway que chamamcompletamente, e como os grupos de Expressway - acima dos media canaliza. O registro dodiagnóstico tem um número de módulos diferentes que alimentam nele. Os níveis de registropodem ser ajustados para mostrar FATAL, ERRO, ADVERTEM, INFORMAÇÃO, DEBUGAM,SEGUEM. Tudo é ajustado à revelia à INFORMAÇÃO que captura quase tudo que você precisade diagnosticar um problema. De vez em quando, você pode precisar de ajustar um nível deregistro de um módulo específico da INFORMAÇÃO PARA DEBUGAR para obter umacompreensão melhor do que está acontecendo. As etapas abaixo ilustram como você podeajustar os níveis de registro do módulo developer.ssl que é responsável para fornecer ainformação para apertos de mão (mútuos) TLS.

Registre em Expressway o server (deve ser feito em Expressway-e e em C)1.Navegue ao >Diagnostics da manutenção > avançou > configuração do log do apoio2.Rolo ao módulo que você gostaria de ajustar, nesta instância a developer.ssl e para clicá-lo.3.Ao lado do parâmetro nivelado, escolha DEBUGAM do menu4.Clique a salvaguarda5.

Neste momento, você é preparado para capturar o registro do diagnóstico:

Registre em Expressway o server (deve ser feito em Expressway-e e em C)1.Navegue ao >Diagnostics da manutenção > registro diagnóstico2.Clique o log novo do começo (nota: Assegure-se de que você verifique a opção do tcpdump)3.Reproduza a edição4.Clique o registro da parada5.Clique o log da transferência6.

Para o registro diagnóstico de Expressway, mantenha na mente que você começaria o registro deExpressway-C e de Expressway-e paralelamente: primeiramente comece a abertura deExpressway-e, a seguir vá a Expressway-C e comece-o. Nesse ponto, você pode entãoreproduzir o problema.

Note: Atualmente o pacote do log de diagnóstico Expressway/VCS não contém ainformação sobre o certificado de servidor de Expressway ou a lista confiada de CA. Sevocê tem um caso onde ter esta funcionalidade seja benéfico, anexe por favor sua caixa aeste defeito.

https://tools.cisco.com/bugsearch/bug/CSCvc70955

Referências

Guia de distribuição para serviços híbridos do atendimento da faísca de Cisco●

Cisco acende o Guia de Design híbrido●

Guia do administrador de Cisco Expressway●

Suporte Técnico e Documentação - Cisco Systems●

https://www.cisco.com/go/hybrid-services-call


https://www.cisco.com/c/pt_br/support/unified-communications/expressway-series/products-maintenance-guides-list.html

https://www.cisco.com/c/pt_br/support/index.html

o guia de troubleshooting para o serviço híbrido do .... ajuste a porta do sorvo tls quando você...

Documents