El guía de Troubleshooting para el servicio híbrido de la llamada de la chispa de Cisco conecta

Introducción

Este documento describe la chispa de Cisco que el servicio híbrido de la llamada conecta la solución que permite que su infraestructura existente del Control de llamadas de Cisco conecte con la nube de la colaboración de Cisco de modo que puedan trabajar juntas.

Prerequisites

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento de la oferta de la chispa de Cisco
• Conocimiento de la solución de Expressway (B2B)
• Conocimiento del administrador de las Comunicaciones unificadas de Cisco (CM unificado) y de su integración con Expressway
• CM unificado 10.5(2) SU5 o más adelante.
• Versión X8.7.1 de Expressway (B2B) o más adelante (se recomienda X8.9.1)
• Expressway (host del conector) -- vea el conector de Expressway recibir el soporte para los servicios híbridos de la chispa de Cisco para actualmente las versiones admitidas

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Administrador de las Comunicaciones unificadas de Cisco
• Autopistas
• Chispa de Cisco para Windows
• Chispa de Cisco para el mac
• Chispa de Cisco para el IOS
• Chispa de Cisco para Android
• Puntos finales de la colaboración de Cisco
• Puntos finales del escritorio de la Colaboración
• Teléfonos IP
• Softwares cliente

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si su red está viva, asegúrese de que usted entienda el impacto potencial del comando any.

Antecedentes

La solución ofrece a éstos la capacidad:

• Utilice el app de la chispa de Cisco como cliente suave móvil para las llamadas del audio y del vídeo
• Utilice el app para hacer y para recibir las llamadas de dondequiera, como si estuvieran en la oficina
• Utilice la chispa de Cisco, el Jabber de Cisco, o su teléfono de escritorio para llamar, sin la necesidad de preocuparse de qué opción utilizan
• Desbloquee el historial de llamadas en los teléfonos de la en-premisa e integre que historial en la chispa de Cisco

El alcance de esta guía es cubrir los problemas que son únicos al servicio híbrido de la llamada conectan. Puesto que el servicio híbrido de la llamada conecta funciona con encima los mismos pares del C de Expressway E& que las otras soluciones tales como móvil y Acceso Remoto y llamada interempresarial, los problemas con las otras soluciones pueden afectar al servicio híbrido de la llamada conectan. Para los clientes y los Partners que despliegan un par de Expressway para el uso con el servicio de la llamada conecta, el VCS Expressway de Cisco y la guía de configuración básica del control del VCS debe ser referida antes de que usted intente desplegar el servicio híbrido de la llamada conecte. Este guía de Troubleshooting cubre las consideraciones Firewall/NAT junto con el diseño de Expressway en el apéndice 3 y 4. revisa esta documentación a conciencia. Además, este documento asume que el host del conector de Expressway y la activación híbrida del servicio de la llamada fueron completados. 

Problemas de la configuración de la llamada

Errores mutuos de la entrada en contacto TLS

El servicio híbrido de la llamada conecta el Transport Layer Security mutuo de las aplicaciones (TLS mutuo) para la autenticación entre la chispa de Cisco y Expressway-e. Esto significa que Expressway-e y la chispa de Cisco marcan y examinan el certificado que presente. Puesto que los problemas mutuos de TLS son tan frecuentes durante las nuevas implementaciones de los servidores de Expressway y la habilitación de las soluciones tales como servicio híbrido de la llamada conecta, esta sección proporciona la información útil e inclina para resolver problemas los problemas basados certificado entre las autopistas y la chispa de Cisco.

¿Qué Expressway-e marca?

• ¿El certificado de la chispa de Cisco fue firmado por un público CA que se enumera en la lista confiada en Expressway-e de CA?
• ¿Está callservice.ciscospark.com presente en el campo de nombre alterno sujeto del certificado de la chispa de Cisco?

¿Qué la chispa de Cisco marca?

• El certificado de Expressway-e ha sido firmado por uno del público CA que chispea las confianzas. (Lista de confianza de CA de la chispa de Cisco) 
• ¿Si Expressway-e no utiliza público un certificado firmado, el certificado de Expressway junto con raíz y los Certificados del intermedio fue cargado a Cisco chispean el concentrador del control (https://admin.ciscospark.com)?

Esto se explica tal y como se muestra en de la imagen.

Consejos de Troubleshooting mutuos útiles de TLS

1. Decodifique la entrada en contacto TLS mutua

Por abandono, las marcas de Wireshark SORBEN el tráfico de TLS como puerto 5061. Cuál este los medios son que usted quiere en cualquier momento analizar la entrada en contacto TLS (mutua) a que los occurrs sobre el puerto 5062, Wireshark no sabrán decodificar el tráfico correctamente. Aquí está un ejemplo de la entrada en contacto TLS mutua que está ocurriendo sobre el puerto 5062 tal y como se muestra en de la imagen.

Como usted puede ver, éste es cómo el apretón de manos mira con las configuraciones predeterminadas en Wireshark. El paquete número 175 es el certificado que Expressway envía a Cisco la chispa. Sin embargo, usted no puede determinar eso sin el tráfico que es decodificado. Hay dos métodos que usted puede utilizar el decodificar este tráfico de modo que usted pueda ver más fácilmente la información del certificado y cualquier mensaje de error que estén presentes.

1a. Decod la secuencia como SSL

a. Cuando usted analiza la entrada en contacto TLS mutua, primero filtre la captura por tcp.port==5062. Después de esto, haga clic con el botón derecho del ratón el primer paquete en la secuencia y selecto decodifique como… tal y como se muestra en de la imagen.

b. El decodificar como… opción se selecciona una vez, usted considera una lista donde usted puede seleccionar cómo decodificar la secuencia que usted ha seleccionado. De la lista, el SSL selecto, tecleo aplica, y cierra la ventana. En este momento, la secuencia entera muestra el certificado y los mensajes de error intercambiados a la hora del apretón de manos tal y como se muestra en de la imagen.

1b. Ajuste el puerto de TLS del SORBO

Cuando usted ajusta el puerto de TLS del SORBO a 5062 en las preferencias de Wireshark, usted puede entonces ver todos los detalles que rodean el apretón de manos, que incluye los Certificados. Para realizar este cambio:

• Abra Wireshark
• Navegue para editar > las preferencias
• Amplíe los protocolos y seleccione el SORBO
• Fije el puerto de TLS del SORBO a 5062 y el tecleo se aplica
• Fije el valor de nuevo a 5061 cuando el análisis se completa tal y como se muestra en de la imagen.

Si usted ahora analiza la misma captura, usted ve los paquetes 169 a 175 decodificados. El paquete 175 muestra el certificado de Expressway-e y si usted perfora abajo en el paquete, usted puede ver a todos los detalles del certificado tal y como se muestra en de la imagen.

2. Filtración de Wireshark

Cuando usted analiza a las capturas de paquetes, es fácil conseguir perdido en la cantidad escarpada de paquetes observados en una determinada captura. Es importante entender qué tipo de tráfico usted está el más interesado adentro de modo que usted pueda filtrar Wireshark para visualizar apenas eso. Aquí están algunos filtros comunes de Wireshark que se pueden utilizar para conseguir los detalles sobre una entrada en contacto TLS mutua:

• tcp.port==5062
• && tcp.port==5062 SSL
• && tcp.port==5062 ssl.handshake.certificate

3. Certificado del extracto de Pcap

De vez en cuando, usted puede necesitar conseguir una copia de un certificado (servidor, raíz, o intermediario). Si usted no sabe dónde encontrar el certificado que usted está en la búsqueda para, usted puede extraerla directamente de una captura de paquetes. Aquí están los pasos para que cómo tire del certificado de la chispa de Cisco que se presenta en una entrada en contacto TLS mutua.

1. Filtre a la captura de paquetes con el && tcp.port==5062 ssl.handshake.certificate
2. Localice el paquete que es originado de la dirección del servidor de la chispa y tiene certificado impreso en la sección de información.
3. En los detalles del paquete amplíe Secure Socket Layer > el certificado > el protocolo de entrada en contacto > los Certificados de TLS 

   Note: El certificado de la parte inferior/del último en el encadenamiento es raíz CA.

4. Haga clic con el botón derecho del ratón el certificado de interés y seleccione los bytes del paquete seleccionados exportación… tal y como se muestra en de la imagen.

5. Salve el archivo como .cer.

6. Haga doble clic el archivo guardado para abrir el certificado tal y como se muestra en de la imagen.

4. Ajuste los niveles de registro de Expressway

Dos módulos de registro están disponibles en Expressway que pueden ayudarle mejor a entender qué lógica realiza Expressway cuando usted analiza los Certificados:

• developer.ssl
• developer.zone.zonemg

Por abandono, estos módulos de registro se fijan a un nivel de la INFORMACIÓN. Cuando conjunto a nivel de debug, ustedes puede comenzar ver información sobre certificado examen al cual sucede, junto con qué tráfico de la zona consigue asoció. Ambas funciones son relevantes al servicio híbrido de la llamada. 

Ejemplo de Expressway-e que conduce un examen SAN del certificado de servidor de la chispa de Cisco.

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"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1960)" Method="::ttssl_continueHandshake" Thread="0x7f576cbee700":  Detail="Handshake succeeded"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1629)" Method="::TTSSL_retrieveCommonName" Thread="0x7f576cbee700":  Detail="Found common name in peer certificate" CommonName="l2sip-cfa-01.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-01-web.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="l2sip-cfa-web.wbx2.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1654)" Method="::TTSSL_retrieveAltNames" Thread="0x7f576cbee700":  Detail="Found DNS alt-name in peer certificate" AltName="callservice.call.ciscospark.com"

Ejemplo de Expressway-e que asocia la conexión MTLS a la zona de DNS del híbrido de la chispa de Cisco

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" 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
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1183)" 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"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1054)" 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"

Aquí está una lista de la mayoría de los problemas frecuentes que se relacionan con los errores mutuos de TLS entre Expressway-e y la chispa de Cisco. 

El problema 1. Expressway-e no confía en el Certificate Authority (CA) que firmó el certificado de la chispa de Cisco 

El servidor de la chispa de Cisco que está en la comunicación directa con Expressway-e se llama un servidor L2SIP. Este servidor L2SIP debe ser firmado por un servidor intermediario con un Common Name de la boca de riego SSL ICA G2. El intermediario es firmado por un Certificate Authority de la raíz que tiene un Common Name de QuoVadis raíz CA 2 tal y como se muestra en de la imagen.

Note: Esto podía estar conforme al cambio.

El primer paso para analizar este tráfico de la perspectiva de diagnóstico de Expressway es buscar para la conexión TCP. Después de que usted busque el TCP que conecta, usted buscará el valor Dst-port=5062. Una vez que usted identifica el área en los registros donde esta conexión fue intentada y establecida, usted puede entonces buscar la entrada en contacto TLS que es denotada generalmente por las entradas de registro que indica el apretón de manos en curso.

2017-09-20T10:49:18.427-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,426" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f29ddefa700":  Detail="Handshake in progress" Reason="want read/write"

Si Expressway-e no confía en los certificados firmados de la chispa de Cisco, usted puede contar con que Expressway-e pueda rechazar el certificado inmediatamente después que el apretón de manos completa. Esto se puede manchar en 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"
2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: 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"
2017-09-20T10:49:18.724-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:49:18,724" 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"

El mensaje de error de Expressway puede engañarse levemente porque refiere a un certificado firmado del uno mismo en la Cadena de certificados. Wireshark permite que usted heche una ojeada a una mirada más atenta el intercambio. De una perspectiva del análisis de la captura de paquetes del wireshark, usted puede ver claramente que cuando el entorno de la chispa presenta es certificado entonces Expressway da vuelta alrededor y los rechazos con el certificado con un error desconocido de CA tal y como se muestra en de la imagen.

Solución

Para resolver esta situación, usted debe asegurarse de que Expressway-e confía en las autoridades de certificación de la chispa de Cisco. Mientras que usted podría extraer simplemente estos Certificados de un wireshark los localizan y cargan al almacén de confianza del certificado de CA en Expressway, Expressway ofrecen un método más simple:

• Registro en Expressway-e
• Navegue los toApplications > la administración de certificados de la nube
• Selecto consiga la opción de los Certificados tal y como se muestra en de la imagen.

En este momento, las autoridades de certificación de la chispa de Cisco están cargadas a Expressway-e confiaban en el almacén de CA (> Security (Seguridad) del mantenimiento > certificado de CA de confianza).

El nombre incorrecto del problema 2. para el tema de TLS verifica el nombre en la zona de DNS del híbrido de la chispa de Expressway-e Cisco 

Como parte de la entrada en contacto TLS mutua, el servicio híbrido de la llamada conecta la verificación de TLS de las aplicaciones. Esto significa que además de confiar en los Certificados de CA de la chispa de Cisco, Expressway verifica el certificado marcando el campo sujeto del nombre alterno (SAN) del certificado que se presenta para asegurarse que tiene un valor tal como callservice.ciscospark.com presente. Si este valor no está presente, la llamada entrante falla. 

En este escenario particular, el presente del servidor de la chispa de Cisco su certificado a Expressway-e. El certificado tiene realmente 25 diferentes sin. Considere el caso donde Expressway-e marca el certificado para callservice.ciscospark.com SAN pero no encuentra eso. Cuando se cumple esta condición, usted puede ver un error similar a esto dentro del registro de diagnóstico:

2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-20 15:17:42,700"
2017-09-20T11:17:42.701-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 15:17:42,700" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="46049" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

Si usted utiliza el wireshark para analizar este apretón de manos del certificado, usted puede encontrar que después de que la chispa de Cisco presente su certificado, Expressway RST la conexión poco después tal y como se muestra en de la imagen.

Para confirmar la configuración de este valor, usted puede ir a la zona de DNS híbrida de la chispa que fue configurada para la solución. Si usted tiene el xConfiguration de Expressway-e, usted puede buscar la sección de configuración de la zona para determinar cómo el TLS verifica el asunto fue configurado. Para el xConfiguration, observe que las zonas están pedidas con la zona 1 que es las primeras. Aquí está un xConfiguration del entorno problemático analizado arriba.

*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 usted puede ver en el ejemplo anterior TLS verifique el asunto se fija a calllservice.spark.com en vez de callservice.ciscospark.com. 

Solución

Para resolver este problema, TLS verifica el asunto debe ser modificado:

• Registro en Expressway-e
• Navegue a la configuración > a las zonas > a las zonas
• Seleccione la zona de DNS de los servicios del híbrido de la chispa
• Fije TLS verifican el asunto a callservice.ciscospark.com
• Seleccione la salvaguardia

Note: Vea el comportamiento del registro de la línea de fondo del thefor. Esta sección muestra Expressway que realiza la verificación del certificado y la asignación a la zona de DNS del híbrido de la chispa.

El problema 3. Expressway-e no envía la Cadena de certificados llena a la chispa de Cisco

Como parte de la entrada en contacto TLS mutua, la chispa de Cisco debe confiar en el certificado de Expressway-e. La chispa de Cisco tiene una lista completa del público CA que confíe en. Típicamente, una entrada en contacto TLS es acertada cuando su certificado de Expressway-e es firmado por CA público que la chispa de Cisco soporte. Por el diseño, Expressway-e envía solamente su certificado durante una entrada en contacto TLS a pesar de la firma por un público CA para enviar el encadenamiento lleno de los Certificados (raíz e intermedio), esos Certificados se debe agregar el almacén de confianza en Expressway-e sí mismo del certificado de CA.

Si esta condición no se cumple, la chispa de Cisco rechaza el certificado de Expressway-e. Cuando usted resuelve problemas una condición que haga juego este problema, usted puede utilizar los registros de diagnóstico y el tcpdump de Expressway-e. Cuando usted analiza los registros de diagnóstico de Expressway-e, usted verá un error similar a ése aquí:

2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-19 15:12:09,721"
2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7fc67c6ec700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:33441']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"
2017-09-19T11:12:09.721-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 15:12:09,721" Module="network.tcp" Level="DEBUG": Src-ip="146.20.193.45" Src-port="33441" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Si usted analiza esto de una perspectiva de Wireshark, usted ve que Expressway-e presenta su certificado. Si usted amplía el paquete, usted puede ver que solamente el certificado de servidor está enviado. La chispa de Cisco entonces rechaza esta entrada en contacto TLS con un mensaje de error desconocido de CA tal y como se muestra en de la imagen.

Solución

Para abordar el problema en este escenario, usted debe cargar el intermedio y la raíz CA que están implicados en la firma del certificado de Expressway-e al almacén de confianza del certificado de CA:

Paso 1. Registro en Expressway-e.
Paso 2. Navegue al > Security (Seguridad) del mantenimiento > confiaba en el certificado de CA.
Paso 3. Selecto elija el archivo bajo menú de la carga cerca de la parte inferior del UI.
Paso 4. Elija el certificado de CA que estuvo implicado en la firma de Expressway-e.
Paso 5. Selecto añada el certificado de CA al final del fichero.
Paso 6. Relance los pasos para todos los Certificados de CA implicados en la firma del certificado de Expressway-e (intermedio, raíz).
Paso 7. Selecto añada el certificado de CA al final del fichero.

Una vez que se completa este proceso, usted ve que el encadenamiento lleno de los Certificados implicados en la firma del certificado de servidor de Expressway-e incluido en el intercambio de claves. Aquí está una muestra de lo que usted vería si usted que analiza a una captura de paquetes con Wireshark.

El Firewall del problema 4. termina la entrada en contacto TLS mutua

De Expressway de la solución los intefaces típicamente con un Firewall. Muchas veces, el Firewall en línea para la solución está ejecuta algún tipo de examen de la capa de la aplicación. A menudo con la solución de Expressway, cuando el Firewall ejecuta el examen de la capa de la aplicación, los administradores ven los resultados no deseables. Este problema determinado le ayuda a identificar cuando el examen de la capa de la aplicación de un Firewall derribó precipitadamente la conexión.

Con el uso de los registros de diagnóstico de Expressway, usted puede buscar la entrada en contacto TLS mutua frustrada. Este apretón de manos, según lo mencionado anterior, debe venir poco después de que la conexión TCP se establece sobre el puerto 5062. En este escenario, cuando el Firewall derriba la conexión, usted ve estos errores dentro del registro de 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 una perspectiva de la captura de paquetes, usted verá que Expressway-e presenta su certicate a la chispa de Cisco. Usted ve un TCP RST venir adentro de la dirección de la chispa de Cisco tal y como se muestra en de la imagen. 

En el primer vistazo, usted puede pensar que algo es incorrecto con el certificado de Expressway-e. Para resolver problemas este problema, usted primero tiene que determinar las respuestas a estas preguntas:

• ¿Expressway-e es firmado por CA público que la chispa de Cisco confía en?
• ¿El certificado de Expressway-e y Certificados está implicado en la firma del certificado de Expressway-e cargado manualmente al concentrador del control de la chispa de Cisco (https://admin.ciscospark.com)? 

En estas condiciones determinadas, la solución no era utilizar el concentrador del control de la chispa de Cisco para manejar los Certificados de Expressway-e. Este medio el certificado de Expressway-e se debe firmar por CA público que la chispa de Cisco confía en. Seleccionando en el paquete del certificado en la captura de Wireshark (según lo ilustrado arriba), usted puede ver que el certificado fue firmado por CA público y que el encadenamiento lleno fue enviado a la chispa de Cisco. Por lo tanto, el problema no se debe relacionar con el certificado de Expressway-e.

En este momento, si se requiere el aislamiento adicional, usted podría tomar a una captura de paquetes de la interfaz exterior del Firewall. Sin embargo, la falta de error SSL en el registro de diagnóstico es un punto de datos importante. Si usted recuerda arriba (problema 3.), si la chispa de Cisco no confía en el certificado de Expressway-e, usted debe ver algún tipo de motivo de desconexión SSL. En esta condición, no había error SSL disponible.

Note: Si usted consiguiera a una captura de paquetes de la interfaz exterior del Firewall usted no vería un TCP RST el venir adentro del entorno de la chispa de Cisco.

Solución

Para esta solución determinada, usted como partner o el cliente debe confiar en su equipo de seguridad. El equipo debe investigar si él utiliza cualquier clase de examen de la capa de la aplicación para la solución de Expressway y si son, esto deben ser inhabilitados. El apéndice 4 del control del VCS y del Guía de despliegue de Expressway explica porqué es clientes recomendados apaga estas funciones.

El problema 5. Expressway-e es firmado por CA público pero el concentrador del control de la chispa de Cisco tiene Certificados alternos cargados

Esta condición determinada puede ocurrir a menudo cuando usted desplegó la solución de Expressway desde el principio y usted no hace el certificado de Expressway-e firmar por CA público inicialmente. Qué sucede en este escenario es que usted carga el certificado de servidor de Expressway-e (que se ha firmado internamente) al concentrador del control de la chispa de Cisco de modo que usted pueda completar la negociación mutua de TLS con éxito. Luego, usted termina para arriba conseguir el certificado de Expressway-e firmado por CA público, no obstante usted olvida quitar el certificado de servidor del concentrador del control de la chispa de Cisco. Es importante saber que cuando un certificado está cargado al concentrador del control de la chispa de Cisco, ese certificado toma la prioridad sobre qué certificado y encadene los presentes de Expressway durante la entrada en contacto TLS.

De una perspectiva del registro de diagnóstico de Expressway-e, este problema puede parecer similar a la firma del registro se resuelve que cuando la chispa de Cisco no confía en el certificado de Expressway-e -- por ejemplo, el caso de Expressway-e que no envía su encadenamiento lleno o el certificado de Expressway-e que no es firmado por CA público que la chispa de Cisco confía en. Abajo está una muestra de lo que usted puede esperar en Expressway-e que registra durante la entrada en contacto TLS:

2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-20 14:22:13,668"
2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f4a2c16f700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:48520']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"
2017-09-20T10:22:13.669-04:00 amer-expressway01 tvcs: UTCTime="2017-09-20 14:22:13,668" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="48520" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Heche una ojeada esto de la perspectiva de Wireshark que usted puede ver aquí que Expressway-e presenta su certificado en el elemnto de línea 175. Algunos elemntos de línea más adelante, el entorno de la chispa de Cisco rechazan el certificado con un Error desconocido del certificado tal y como se muestra en de la imagen.

Si usted selecciona el paquete del certificado que Expressway-e envía, usted puede ampliar la información del certificado para determinar si Expressway-e

1. es firmado por CA público que las confianzas de la chispa de Cisco, y

2. está incluyendo su encadenamiento lleno implicado en la firma.

En esta situación, se cumplen ambas condiciones. Esto sugiere que no haya nada mal con el certificado de Expressway-e.

Solución

Paso 1. Registro en el concentrador del control de la chispa de Cisco.
Paso 2. Seleccione los servicios del panel izquierdo.

Paso 3. Elija las configuraciones conforme al indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada híbrido.

Paso 4. Navegue al servicio de la llamada conectan la sección y la mirada conforme a los Certificados para el SIP cifrado llama para considerar si los Certificados indeseados son mencionados. Si es así haga clic el icono del bote de basura al lado del certificado.

paso 5. Seleccione Remover.

Note: Es importante que el análisis está conducido y está determinado que el cliente no está utilizando los Certificados cargados al concentrador del control de la chispa antes de quitarlos.

Para más información sobre cargar su certificado de Expressway-e en la chispa de Cisco controle el concentrador, marcan esta sección del Guía de despliegue híbrido de la llamada.

El problema 6. Expressway no está asociando la llamada entrante a la zona de DNS del híbrido de la chispa de Cisco

TLS entrante que asocia los trabajos de la característica conjuntamente con TLS verifica el asunto, que se configuran en la zona de DNS híbrida de la llamada. La característica analiza en un proceso de paso de tres:

1. Expressway-e valida el certificado de la chispa de Cisco.
2. Expressway-e examina el certificado de la chispa de Cisco para determinar si hay un nombre alterno sujeto que corresponde con el TLS verifica el asunto: callservice.ciscospark.com.
3. Expressway-e asocia la conexión hacia adentro a través de la zona de DNS del híbrido de la chispa de Cisco.

Si la autenticación no es acertada, ésta significa que la validación de certificado falló. La llamada ingresa en la zona predeterminada y se rutea según las reglas de búsqueda proporcionadas para los escenarios interempresariales, si es interempresarial se configura en Expressway-e.

Como los otros escenarios, usted debe utilizar la amba la registración y capturas de paquetes de diagnóstico para determinar lo que parece este incidente, después utiliza a la captura de paquetes para ver qué lado está enviando el RST. Aquí está una muestra de la conexión TCP que es intentada, entonces estableciendo. 

2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"
2017-09-22T10:09:56.471-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:56,471" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

Ahora que la conexión TCP ha establecido, la entrada en contacto TLS puede seguir. Usted puede ver poco después de que el apretón de manos comienza, él rápidamente los errores hacia fuera.  

2017-09-22T10:09:57.044-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,044" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f044e7cc700":  Detail="Handshake in progress" Reason="want read/write"
2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="Peer's TLS certificate identity was unacceptable" Protocol="TLS" Level="1" UTCTime="2017-09-22 14:09:57,123"
2017-09-22T10:09:57.123-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 14:09:57,123" Module="network.tcp" Level="DEBUG":  Src-ip="148.62.40.52" Src-port="44205" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Peer's TLS certificate identity was unacceptable"

Mire esta situación de una perspectiva del pcap, usted puede conseguir un mejor sentido de

• quién está enviando el RST, y
• qué Certificados se están pasando para determinar si están correctos.

Cuando usted analiza esta captura determinada, usted puede ver que Expressway-e envía el RST. Cuando usted mira el certificado de la chispa de Cisco se pasa que, usted puede ver que envía el encadenamiento lleno. Además, usted puede concluir que basado del mensaje de error en el registro de diagnóstico, usted puede eliminar el escenario donde Expressway-e no confía en el público CA de la chispa de Cisco. Si no, usted vería un error como el “certificado firmado del uno mismo en la Cadena de certificados”. Usted puede cavar en los detalles del paquete tal y como se muestra en de la imagen.

Por el tecleo el certificado de servidor de la chispa y extensión de él para ver los nombres alternos sujetos (dnsName) que usted puede verificar para asegurarse que tenga callservice.ciscospark.com enumerara.

Navegue a Wireshark: Certificado > extensión > nombres generales > GeneralName > dNSName: callservice.ciscospark.com 

Esto confirma completamente que el certificado de la chispa parece apenas fino.

Usted puede ahora confirmar que TLS verifica el asunto está correcto. Según lo mencionado, si usted tiene el xConfiguration usted puede buscar la sección de configuración de la zona para determinar cómo se ha configurado el TLS verifica el asunto. Una cosa a observar sobre el xConfiguration es que las zonas están pedidas con la zona 1 son primero creados. Aquí está un xConfiguration del entorno problemático analizado arriba. Está claro que nada es incorrecto con TLS verifica el asunto.

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

La cosa siguiente que debe ser investigada es TLS verifica la correspondencia de entrada. Esto confirma si usted está asociando correctamente la conexión TLS a la zona de DNS del híbrido de la chispa. El xConfiguration se puede leveraged para analizar esto también. En el xConfiguration que TLS verifica la correspondencia de entrada se llama CREMALLERA TLS DNS verifican InboundClassification. Como usted puede ver en este ejemplo el valor se fija a apagado.

*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á fijado a apagado, cuál este los medios son que el VCS está prevenido de intentar asociar las conexiones TLS entrantes a esta zona. La llamada ingresa así en la zona predeterminada y se marca y se rutea según las reglas de búsqueda proporcionadas para los escenarios interempresariales, si es interempresarial se configura en Expressway-e.

Solución

Para dirigir esto que usted necesita fijar TLS verifica la correspondencia de entrada en la zona de DNS híbrida de la llamada a encendido. Aquí están los pasos para completar eso.

1. Registro en Expressway-e
2. Navegue a la configuración > a las zonas > a las zonas
3. Seleccione la zona de DNS híbrida de la llamada
4. Para TLS verifique la correspondencia de entrada, eligen encendido
5. Seleccione la salvaguardia

Note: Vea para el comportamiento del registro de la línea de fondo. Esta sección muestra Expressway que realiza la verificación del certificado y la asignación a la zona de DNS del híbrido de la chispa.

Certificado autofirmado predeterminado de las aplicaciones de Expressway-e del problema 7.

En algunas nuevas implementaciones de la llamada híbrida mantenga conectan, la firma del certificado de Expressway-e se pasa por alto o ha creído que el certificado de servidor predeterminado puede ser utilizado. Algunas personas piensan que esto es posible porque el concentrador del control de la chispa de Cisco le deja cargar un certificado de encargo en el portal. (Servicios > configuraciones (conforme al indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada híbrido) > carga (bajo los Certificados para las llamadas cifradas))

Si usted presta la mucha atención a la fraseología sobre los Certificados las llamadas cifradas del SORBO, usted ve esto: “Utilice los Certificados proporcionados de la lista de la confianza del valor por defecto de la colaboración de Cisco o cargue sus los propio. Si usted utiliza sus los propio, asegúrese que los nombres de host estén en un dominio verificado.” El pedazo dominante a esa declaración es “se aseegura los nombres de host está en un dominio verificado.” 

Cuando usted resuelve problemas un problema que haga juego esta condición, tenga presente que el síntoma va a ser dependiente en la dirección de la llamada. Si la llamada originada por las en-premisas llama por teléfono, usted puede contar con que el app de la chispa de Cisco no suene. También, si usted intentara localizar la llamada del historial de la búsqueda de las autopistas, usted encontraría que la llamada lo haría a Expressway-e y pararía allí. Si la llamada originada de un app de la chispa de Cisco y era destinada para las premisas, las en-premisas que el teléfono no suena. En ese caso, el historial de Expressway-e y de Expressway-C Seach no mostraría cualquier cosa.

En este escenario particular, la llamada originó de un teléfono de las en-premisas. Usando el historial de la búsqueda de Expressway-e, usted puede determinar que la llamada lo hizo al servidor. En este momento, usted puede zambullirse en la registración de diagnóstico para determinar qué sucedió. Para comenzar este análisis, primera mirada para ver si una conexión TCP fue intentada y establecida sobre el puerto 5062. Buscando los registros de diagnóstico de Expressway-e para el “TCP que conecta” y que busca el elemnto de línea con la etiqueta el "Dst-port=5062", usted puede determinar si la conexión establece. 

2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"
2017-09-26T08:18:08.428-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,426" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Established"

Ahora que usted confirmó la conexión TCP establecida, usted puede analizar la entrada en contacto TLS mutua inmediatamente después de la cual sucede. Como usted puede ver en el snippet aquí, el apretón de manos falla y el certificado es desconocido (desconocido alerta del certificado Detail="sslv3”)

2017-09-26T08:18:08.441-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,441" Module="developer.ssl" Level="INFO" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1974)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake in progress" Reason="want read/write"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="sslv3 alert certificate unknown" Protocol="TLS" Level="1" UTCTime="2017-09-26 12:18:08,455"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="DEBUG" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(1997)" Method="::ttssl_continueHandshake" Thread="0x7f930adab700":  Detail="Handshake Failed" Reason="want error ssl"
2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(68)" Method="::TTSSLErrorOutput" Thread="0x7f930adab700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="0" error="1" bServer="true" localAddress="['IPv4''TCP''172.16.2.2:5062']" remoteAddress="['IPv4''TCP''146.20.193.45:59720']" ssl_error_reason="error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown"

2017-09-26T08:18:08.455-04:00 amer-expressway01 tvcs: UTCTime="2017-09-26 12:18:08,455" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.45" Src-port="59720" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Heche una ojeada más cercano la captura de paquetes proporcionada la registración de diagnóstico de Expressway-e, usted puede ver que el Error desconocido del certificado está consiguiendo originado de la dirección de la chispa de Cisco tal y como se muestra en de la imagen.

Si usted examina el certificado de servidor predeterminado de Expressway-e, usted puede ver que el “Common Name” y los “nombres alternos sujetos” no contienen el “dominio verificado” (rtp.ciscotac.net). Usted entonces tiene pruebas sobre qué causa este problema tal y como se muestra en de la imagen. 

En este momento, usted determinó que el certificado de servidor de Expressway-e necesita ser firmado por un público CA o un CA interno. 

Solución

Para resolver este problema, usted tiene dos opciones:

1. Haga el certificado de Expressway-e firmar por CA público que la chispa de Cisco confía en.
   
   1. Registro en Expressway.
   2. Navegue al > Security (Seguridad) > al certificado de servidor del mantenimiento.
   3. Selecto genere el CSR.
   4. Ingrese la información requerida del certificado y asegúrese de que el campo de nombres alternativo adicional contenga el dominio verificado enumerado en el concentrador del control de la chispa.
   5. El tecleo genera el CSR.
   6. Proporcione el CSR a las de otras compañías CA público para firmar.
   7. Sobre la vuelta del certificado, navegue al > Security (Seguridad) > a los certificados de servidor del mantenimiento.
   8. En la nueva sección del certificado de la carga al lado de selecto el archivo de certificado de servidor, selecto elige el archivo y selecciona el certificado firmado.
   9. Seleccione los datos del certificado de servidor de la carga.
   10. Navegue al > Security (Seguridad) del mantenimiento > confiaba en el certificado de CA.
   11. En la sección de la carga al lado selecta del archivo que contiene los Certificados de CA de confianza selectos elija el archivo.
   12. Seleccione cualesquiera Certificados de CA de la raíz y del intermedio proporcionados por CA público.
   13. Selecto añada el certificado de CA al final del fichero.
   14. Recomience Expressway-e.
2. Haga que el certificado de Expressway-e sea firmado por CA interno y después cargue CA interno y Expressway-e al concentrador del control de la chispa de Cisco.
   
   1. Registro en Expressway
   2. Navegue al > Security (Seguridad) > al certificado de servidor del mantenimiento.
   3. Selecto genere el CSR
   4. Ingrese la información requerida del certificado asegurándose de que el campo de nombres alternativo adicional contenga el dominio verificado enumerado en el concentrador del control de la chispa
   5. El tecleo genera el CSR
   6. Proporcione el CSR a las de otras compañías CA público para firmar
   7. Sobre la vuelta del certificado, navegue al > Security (Seguridad) > a los certificados de servidor del mantenimiento
   8. En la nueva sección del certificado de la carga al lado de selecto el archivo de certificado de servidor, selecto elige el archivo y selecciona el certificado firmado
   9. Seleccione los datos del certificado de servidor de la carga
   10. Navegue al > Security (Seguridad) del mantenimiento > confiaba en el certificado de CA
   11. En la sección de la carga al lado selecta del archivo que contiene los Certificados de CA de confianza selectos elija el archivo.
   12. Seleccione cualesquiera Certificados de CA de la raíz y del intermedio proporcionados por CA público.
   13. Selecto añada el certificado de CA al final del fichero.
   14. Recomience Expressway-e.

 2a. Cargue CA y el certificado internos de Expressway-e al concentrador del control de la chispa de Cisco
       1. Registro en el concentrador del control de la chispa de Cisco como administrador.
       2. Seleccione los servicios.
       3. Seleccione las configuraciones conforme al indicador luminoso LED amarillo de la placa muestra gravedad menor híbrido del servicio de la llamada.
       4. En los Certificados para la carga selecta cifrada de la sección de las llamadas del SORBO.
       5. Elija CA y los Certificados internos de Expressway-e.

Entrante: Chispa de Cisco a las En-premisas

Casi cada chispa entrante de Cisco a los resultados del error de las en-premisas en el mismo síntoma señalado: “Cuando llamo de mi app de la chispa de Cisco al app de otro colega, los timbres del app del colega sino el teléfono de las en-premisas no hace.” Para resolver problemas este escenario, usted encontrará útil entender el flujo de llamada y la lógica que ocurre cuando están poniendo a este tipo de llamada.

Flujo de alto nivel de la lógica

1. La parte llamadora del app de la chispa de Cisco inicia la llamada
2. Timbres del app de la Parte llamada
3. La llamada se bifurca al entorno de la chispa de Cisco
4. El entorno de la chispa de Cisco debe realizar una búsqueda de DNS basada en el destino configurado del SORBO del cliente en el concentrador del control de la chispa de Cisco
5. El entorno de la chispa de Cisco intenta conectar con Expressway sobre el puerto 5062
6. El entorno de la chispa de Cisco intenta realizar una entrada en contacto TLS mutua
7. El entorno de la chispa de Cisco envía un SORBO INVITA a Expressway que se pase abajo al teléfono de la Colaboración endpoint/IP de las en-premisas
8. La chispa de Cisco y la empresa completan la negociación del SORBO
9. La chispa de Cisco y la empresa comienzan a enviar y a recibir los media.

Flujo de llamada

Navegue al app de la chispa de Cisco > al entorno de la chispa de Cisco > a Expressway-e > a Expressway-C > al teléfono de la Colaboración Endpoint/IP de las En-premisas tal y como se muestra en de la imagen.

Aquí están algunos de los problemas frecuentes observados con las llamadas entrantes de la chispa a la infraestructura de las en-premisas.

La chispa de Cisco del problema 1. no puede resolver Expressway-e DNS SRV/hostname

Al pensar en la chispa de Cisco al flujo de llamada de las en-premisas, paso lógico de la chispa de Cisco el primer es cómo entrar en contacto las en-premisas Expressway. Según lo observado arriba, la chispa de Cisco intentará conectar con las en-premisas Expressway realizando las operaciones de búsqueda SRV basadas en el destino configurado del SORBO que se enumera en la página Configuración híbrida del servicio de la llamada en el concentrador del control de la chispa de Cisco. 

Si usted intenta resolver problemas esta situación de una perspectiva del registro de diagnóstico de Expressway-e, usted no ve ningún tráfico de la chispa de Cisco. Si usted intenta buscar para el TCP que conecta, usted no vería el Dst-port=5062, ni usted vería cualquier apretón de manos subsiguiente o el SORBO MTLS invitar de la chispa de Cisco. 

Si ésta es la situación, usted debe marcar cómo el destino del SORBO fue configurado en el concentrador del control de la chispa de Cisco. Usted puede también utilizar la herramienta de prueba de conectividad híbrida para ayudar en el troubleshooting. La herramienta de prueba de conectividad híbrida marca si hay un direccionamiento de los DN válidos, si la chispa de Cisco puede conectar con el puerto vuelto en las operaciones de búsqueda SRV, y si las en-premisas Expressway tienen un certificado válido que la chispa de Cisco confía en. 

1. Registro en el concentrador del control de la chispa del theCisco
2. SelectServices
3. Seleccione el theSettingslink en el indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada del theHybrid.
4. En la llamada mantenga conectan la sección verifican el dominio usado para el theSIP público Destinationfield del addressin del SORBO SRV. 
5. Si el expediente ha estado correcto ingresado, haga clic la prueba para ver si el expediente es válido.
6. Según lo representado abajo, usted puede ver claramente que el public domain no tiene un asociado de registro correspondiente del SORBO SRV a él tal y como se muestra en de la imagen. 

los resultados de la prueba selectos y usted de la visión pueden considerar más detalle sobre qué falló tal y como se muestra en de la imagen. 

Como otro acercamiento, usted puede también mirar para arriba el expediente SRV usando el nslookup. Aquí están los comandos que usted puede funcionar con para verificar si existe el destino del SORBO.

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 usted puede ver en el bloque de código arriba, iniciaron al comando nslookup entonces el servidor se fija a 8.8.8.8 que es servidor DNS público de Google. Pasado, usted está fijando los tipos de registro a las operaciones de búsqueda a los expedientes SRV. En ese momento, usted puede entonces publicar el expediente completo SRV que usted quiere mirar para arriba. El resultado neto es que las peticiones miden el tiempo en última instancia hacia fuera. 

Solución

1. Configure un direccionamiento público del SORBO SRV para Expressway-e en el sitio que utilizan para recibir los nombres del public domain. 
2. Configure un nombre de host que resuelva al IP Address público de Expressway-e
3. Configure el destino del SORBO para enumerar el dominio usado para el direccionamiento del SORBO SRV creado en el paso 1.
   1. Registro en el concentrador del control de la chispa de Cisco
   2. Seleccione los servicios
   3. Seleccione el link de las configuraciones en el indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada híbrido
   4. En la llamada mantenga conectan la sección ingresan el dominio usado para el direccionamiento del público SIP SRV en el Campo Destination SIP. 
   5. Seleccione la salvaguardia

Note: Si el expediente del SORBO SRV que usted quisiera utilizar está siendo ya apalancado para las comunicaciones interempresariales, recomendamos el especificar de un subdomain del dominio corporativo como el direccionamiento de la detección del SORBO en el concentrador del control de la chispa de Cisco, y por lo tanto un expediente del público DNS SRV, como sigue:

Servicio y protocolo: _sips. _tcp.mtls.example.com
Prioridad: 1
Ponderación: 10
Número del puerto: 5062
Blanco: us-expe1.example.com

La recomendación antedicha fue tirada directamente de la guía de diseño del híbrido de la chispa de Cisco.

Solución alternativa

Si el cliente no tiene un presente de registro del SORBO SRV (y no planea crear uno), pueden alternativamente enumerar al IP Address público de Expressway añadido como sufijo por el ":5062". De esta manera, el entorno de la chispa no intentará las operaciones de búsqueda SRV sino conectará bastante directamente con el %Expressway_Pub_IP%:5062. (Ejemplo: 64.102.241.236:5062)

1. Configure el destino del SORBO que se formatará como %Expressway_Pub_IP%:5062. (Ejemplo: 64.102.241.236:5062)
   1. Registro en el concentrador del control de la chispa de Cisco
   2. Seleccione los servicios
   3. Seleccione el link de las configuraciones en el indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada híbrido
   4. En la llamada mantenga conectan la sección ingresan el %Expressway_Pub_IP%:5062 en el Campo Destination SIP. 
   5. Seleccione la salvaguardia

Para más información sobre la dirección destino del SORBO y/o el expediente SRV que deben ser puestos. Refiera el permiso que el servicio híbrido de la llamada conecta para su sección de la organización de la guía híbrida de la instrumentación del servicio de la llamada de la chispa de Cisco o de la guía de diseño del híbrido de la chispa de Cisco.

Falla del socket del problema 2.: El puerto 5062 es entrante bloqueado a Expressway

Después de que la resolución de DNS complete, el entorno de la chispa de Cisco a intentar establecer una conexión TCP sobre el puerto 5062 a la dirección IP que fue vuelta durante la búsqueda de DNS. Esta dirección IP va a ser el IP Address público de las en-premisas Expressway-e. Si el entorno de la chispa de Cisco no puede establecer esta conexión TCP, la llamada entrante a las premisas es posteriormente fall. El síntoma para esta condición determinada es lo mismo que casi cada otro error de la llamada entrante de la chispa de Cisco: el teléfono de las en-premisas no suena.

Si usted está resolviendo problemas este problema usando los registros de diagnóstico de Expressway, usted no verá ningún tráfico de la chispa de Cisco. Si usted intenta buscar para el TCP que conecta, usted no vería ninguna intentos de conexión para el Dst-port=5062, ni usted vería cualquier apretón de manos subsiguiente o el SORBO MTLS invitar de la chispa de Cisco. Puesto que el registro de diagnóstico de Expressway-e es inútil en esta situación, usted tiene algunos métodos posibles para la verificación:

1. Consiga a una captura de paquetes de la interfaz exterior del Firewall
2. Leverage un puerto que marca la utilidad
3. Utilice la herramienta de prueba de conectividad híbrida

Puesto que la herramienta de prueba de conectividad híbrida se incorpora a la derecha al concentrador del control de la chispa de Cisco y simula el entorno de la chispa de Cisco que intenta conectar con las en-premisas Expressway, es el método de verificación más ideal disponible. Para probar la Conectividad TCP en la organización:

1. Registro en el concentrador del control de la chispa del theCisco
2. SelectServices
3. Seleccione el theSettingslink en el indicador luminoso LED amarillo de la placa muestra gravedad menor de llamada del theHybrid
4. En la llamada mantenga conectan la sección se aseguran que el valor ingresado en el destino SIP está correcto
5. Haga clic la prueba tal y como se muestra en de la imagen.

  6. Puesto que la prueba ha fallado usted puede hacer clic el link de los resultados de la prueba de la visión para marcar los detalles tal y como se muestra en de la imagen.

Según lo observado en la imagen arriba, usted puede ver que la prueba del socket ha fallado al intentar conectar con 64.102.241.236:5062. Teniendo estos datos además de los registros de diagnóstico/de los pcaps de Expressway no muestre cualquier intento de conexión, usted ahora tienen bastantes pruebas para investigar la configuración del Firewall ACL/NAT/Routing. 

Solución

Puesto que este problema determinado no es causado por el entorno de la chispa de Cisco o el equipo de la Colaboración de las en-premisas, usted necesita centrarse en la configuración de escudo de protección. Puesto que usted no puede predecir necesariamente el tipo de Firewall que usted interconectará con, usted necesita confiar en alguien con la familiaridad con el dispositivo. Es posible que el problema se podría relacionar con un Firewall ACL, NAT, o misconfiguration de la encaminamiento. 

Falla del socket del problema 3.: Expressway-e no está escuchando en el puerto 5062

Esta condición determinada se diagnostica a menudo incorrectamente. Muchas veces, se asume que el Firewall es la causa para porqué el tráfico sobre el puerto 5062 está consiguiendo bloqueado. Para resolver problemas esta condición determinada, usted puede utilizar las técnicas en el “puerto 5062 es entrante bloqueado el escenario a Expressway” arriba. Usted encontrará que la herramienta de prueba de conectividad híbrida y cualquier otra herramienta usadas para marcar la conectividad de puerto fallarán. La primera suposición es que el Firewall está bloqueando el tráfico. La mayoría de la gente entonces comprobará la registración con minuciosidad de diagnóstico de Expressway-e a determinar si ella puede ver la conexión TCP el intentar establecer. Ella general buscará un elemento de línea del registro tal como esto tal y como se muestra en de la imagen.

2017-09-19T14:01:46.462-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:46,461" Module="network.tcp" Level="DEBUG":  Src-ip="146.20.193.73" Src-port="40342" Dst-ip="172.16.2.2" Dst-port="5062" Detail="TCP Connecting"

En esta condición, la entrada de registro determinada antedicha no existirá. Por lo tanto, mucha gente diagnosticará la condición y asumirla es el Firewall.

Si incluyen a una captura de paquetes con el registro de diagnóstico, usted puede verificar que el Firewall no sea la causa. Abajo está una muestra de la captura de paquetes del thescenario donde Expressway-e no escuchaba sobre el puerto 5062. Esta captura filtrada usando tcp.port==5062 como el filtro aplicado tal y como se muestra en de la imagen. 

Como usted puede ver en la captura de paquetes que fue obtenida de Expressway-e, el tráfico sobre el puerto 5062 tcp no está siendo bloqueado por el Firewall sino de hecho está llegando. En el paquete número 56, usted puede ver que Expressway-e está enviando el RST inmediatamente después que llegó la inicial paquete TCP Syn. Con esta información, usted puede concluir que el problema está aislado a Expressway-e que recibe el paquete; usted debe resolver problemas el problema de la perspectiva de Expressway-e. Dado las pruebas, considere las razones posibles de porqué Expressway-e RST el paquete. Dos posibilidades que podrían atribuir a este comportamiento son:

1. Expressway-e tiene algún tipo de reglas de firewall configuradas que podrían bloquear el tráfico

2. Expressway-e no está estando atento el tráfico mutuo de TLS y/o no está estando atento el tráfico sobre el puerto 5062.

Las Expressway-e funcionalidad del firewall existen bajo el sistema > la protección > las reglas de firewall > configuración. Cuando esto fue llegada este entorno, no había presente de la configuración de escudo de protección. 

Hay varias maneras de verificar si Expressway-e está estando atento el tráfico mutuo de TLS sobre el puerto 5062. Usted puede hacer este con la interfaz Web o el CLI como usuario raíz. 

De la raíz de Expressway, si usted publica el netstat - an | el grep ':5062', usted debe conseguir una cierta salida similar a lo que usted ve abajo. 

~ # 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 información se puede también capturar a través de la interfaz Web de Expressway-e. Vea los pasos abajo para recopilar esta información

1. Registro en Expressway-e

2. Navegue al uso de las herramientas de mantenimiento > del puerto > los puertos de entrada locales

3. Busque para el puerto 5062 del SORBO y IP del tipo. (resaltado en el rojo tal y como se muestra en de la imagen)

Ahora que usted conoce lo que usted debe ver, usted puede comparar eso al entorno actual. De la perspectiva CLI, cuando usted ejecuta el netstat - an | el grep ':5062', la salida parece esto:

~ # netstat -an | grep ':5062'
tcp        0      0 127.0.0.1:5062          0.0.0.0:*               LISTEN
tcp        0      0 ::1:5062                :::*                    LISTEN
~ #

Además, la red UU no muestra el puerto mutuo de TLS enumerado bajo los puertos de entrada locales

Con estos datos, usted puede concluir que Expressway-e no está estando atento el tráfico mutuo de TLS.

Solución

Para solucionar este problema, usted debe asegurarse de que el modo mutuo de TLS está habilitado y de que el puerto mutuo de TLS está fijado a 5062 en Expressway-e:

1. Registro en Expressway-e
2. Navegue a la configuración > a los protocolos > al SORBO
3. Asegúrese que el modo mutuo de TLS esté fijado a encendido
4. Asegúrese que el puerto mutuo de TLS esté fijado a 5062
5. Haga clic la salvaguardia tal y como se muestra en de la imagen.

El problema 4. Expressway-e o el C no soporta las encabezados cargadas de la ruta del SORBO

Con la llamada híbrida mantenga conectan, el ruteo de llamadas se hace sobre la base de la encabezado de la ruta. Se puebla la encabezado de la ruta basó en la información que la porción enterada del servicio de la llamada (conector de Expressway) de la solución entrega a Cisco la chispa. El host del conector de Expressway pregunta el CM unificado para los usuarios que se habilitan para el servicio de la llamada y tiran ambo de su directorio URI y del cluster FQDN de su cluster unificado del hogar CM. Vea este el ejemplo, usando Alicia y Bob:

Directorio URI	Encabezado de la ruta del destino
bob@example.com	emea-cucm.example.com
alice@example.com	us-cucm.example.com

Si Alicia o Bob hace una llamada, la llamada se rutea a su CM unificado las en-premisas para poderla asegurar a su Cisco SparkRD antes de rutear hacia fuera al usuario llamado.

Si Alicia llamara a Bob, la llamada rutearía al cluster unificado FQDN (us-cucm.example.com) del hogar CM de Alicia. Si usted analzye que el SORBO INVITA que la chispa de Cisco envíe entrante a Expressway-e, usted encontraría la siguiente información dentro de la encabezado del SORBO

Petición URI	sorbo: bob@example.com
Encabezado de la ruta	sorbo: us-cucm.example.com; LR

De la perspectiva de Expressway, las reglas de búsqueda son configuradas para rutear la llamada no por la petición URI pero bastante la encabezado de la ruta (us-cucm.example.com) -- en el cluster unificado del hogar CM de esta Alicia del casem.

Con este conjunto de la fundación, usted puede entender las situaciones del Troubleshooting donde se configuran mal las autopistas, que hace la lógica antedicha no trabajar. Pues casi cada otro servicio híbrido entrante de la llamada conecta la falla de configuración de la llamada, el síntoma es que el teléfono de las en-premisas no suena.

Antes de que usted analice el diagnóstico abre una sesión Expressway, considera cómo identificar esta llamada:

1. La petición URI del SORBO será el directorio URI de la Parte llamada.
2. El SORBO del campo será formatado con la parte llamadora enumerada como “<sip del último nombre del primer nombre”: SparkDisplayName@subdomain.call.ciscospark.com >

Con esta información, usted puede buscar los registros de diagnóstico por el directorio URI de la Parte llamada, del nombre y apellido de la parte llamadora, o del direccionamiento del SORBO de la chispa de Cisco de la parte llamadora. Si usted no tiene ninguna de esta información, usted puede buscar en “INVITA AL SORBO: ” que localiza todo el SORBO llama el funcionamiento sobre Expressway. Una vez que usted ha identificado el SORBO INVITE para la llamada entrante, usted puede después localizar y copiar el ID de llamada del SORBO. Después de que usted tenga este valor, usted puede buscar simplemente los registros de diagnóstico basados en el ID de llamada para ver todos los mensajes que correlacionen a este tramo de llamada.

Otra cosa a ayudar a aislar el problema de ruteo es determinar hasta dónde la llamada entra la empresa. Usted puede intentar buscar para la información conocida arriba en Expressway-C para ver si la llamada fue ruteada que lejos. Si es así usted querrá probablemente comenzar su investigación allí.

En este escenario, usted puede ver que Expressway-C ha recibido la INVITACIÓN 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:jorobb@rtp.ciscotac.net 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
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;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=35464;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706
Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared
From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=872524918
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 15
Route: <sip:cucm.rtp.ciscotac.net;lr>
Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:7003;transport=tls;lr>
Record-Route: <sip:proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d@192.168.1.6:5061;transport=tls;lr>

El asunto importante es que la encabezado de la ruta (cluster FQDN) está todavía intacta. Sin embargo, no hay lógica de la búsqueda que es realizada basada en la encabezado de la ruta (cluster FQDN) cucm.rtp.ciscotac.net. Bastante, usted ve el mensaje el conseguir rechazado inmediatamente con 404 no 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-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" 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="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" 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="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" 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-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" 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"
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="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:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=, Msg-Hash=11449260850208794722, Local-SessionID=daf7c278732bb5a557fb57925dffcbf7, Remote-SessionID=00000000000000000000000000000000"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" 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:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=96b9a0eaf669a590, Msg-Hash=254718822158415175, Local-SessionID=00000000000000000000000000000000, Remote-SessionID=daf7c278732bb5a557fb57925dffcbf7"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" 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
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-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-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;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=35464;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706
Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1
CSeq: 1 INVITE
From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=872524918
To: <sip:jorobb@rtp.ciscotac.net>;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 un escenario de trabajo, usted vería que en el escenario de trabajo el lógica de la búsqueda se está realizando basada en la encabezado del router (cluster el FQDN)

2017-09-22T13:56:02.215-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" 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"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,217" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <routed> "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <location clear="yes" url="sip:cucm.rtp.ciscotac.net;lr" diversion="" dest-url-for-message="sip:jorobb@rtp.ciscotac.net" sip-route-set="" dest-service=""> added sip:cucm.rtp.ciscotac.net;lr to location set "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.cpl" Level="DEBUG": Remote-ip="192.168.1.6" Remote-port="7003" Detail="CPL: <proxy stop-on-busy="no" timeout="0"/> "
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound MS to CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'multiway' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'WebEx Search Rule' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'ISDN Inbound' ignored due to source filtering"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'recalls into CMS' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'CEtcp-rtp12-tpdmz-118-ucmpub' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,218" Module="network.search" Level="DEBUG": Detail="Search rule 'Conference Factory' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Inbound B2B Calling' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" Module="network.search" Level="DEBUG": Detail="Search rule 'Calls to Cisco Spark' did not match destination alias 'cucm.rtp.ciscotac.net;lr'"
2017-09-22T13:56:02.218-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" 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'"
2017-09-22T13:56:02.219-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,219" 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'"

Usted puede entonces ver que Expressway-C correctamente adelante el decir en voz alta al CM unificado (192.168.1.21).

2017-09-22T13:56:02.232-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,232" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="25606" Dst-ip="192.168.1.21" Dst-port="5065" Msg-Hash="866788495063340574"
SIPMSG:
|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TCP 192.168.1.5:5060;egress-zone=CUCM11;branch=z9hG4bK251d6daf044e635607cc13d244b9ea45138220.69ccb8de20a0e853c1313782077f77b5;proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf;rport
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-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
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK297799f31d0785ff7449e1d7dbe3595b271.2ed90cbed5b79c6cffad9ecd84cc8337;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=36149;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-353038-8c648a16c2c5d7b85fa5c759d59aa190;rport=47732
Call-ID: daa1a6fa546ce76591fc464f0a50ee32@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared
From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=567490631
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 14
Route: <sip:cucm.rtp.ciscotac.net;lr>
Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5060;transport=tcp;lr>
Record-Route: <sip:proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf@192.168.1.5:5061;transport=tls;lr>
Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:7003;transport=tls;lr>
Record-Route: <sip:proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77@192.168.1.6:5061;transport=tls;lr>
Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY
User-Agent: TANDBERG/4352 (X8.10.2-b2bua-1.0)

Analizando el registro de diagnóstico que aisló el problema a Expressway-C y un error específico (404 no encontrados), usted puede centrarse en qué causaría este tipo de conducta. Algunas cosas a considerar son las siguientes:

1. Las llamadas se mueven dentro y fuera de las zonas en Expressway por las reglas de búsqueda.
2. La lógica del uso de las autopistas llamada cargó el soporte de las rutas del SORBO que el SORBO de los procesos INVITA a las peticiones que contienen la encabezado del router. Este valor se puede dar vuelta con./desc. en las zonas (servidor del Traversal, cliente del Traversal, vecino) en Expressway-C y Expressway-e.

Usted puede ahora utilizar el xConfiguration para ver la configuración en el servidor del Traversal de Expressway-e y las zonas del cliente de Expressway-C, los que se configuren para el servicio híbrido de la llamada conectan específicamente. Además de la configuración de la zona, usted puede analizar las reglas de búsqueda que se configuran para pasar esta llamada a través a partir de una zona a otra. Usted también sabe que Expressway-e pasó la llamada a Expressway-C así que la configuración de la zona del servidor del Traversal allí es configuración más probable correctamente.

Para romper esto abajo, el xConfig abajo nos dice que el nombre de esta zona está llamado Traversal del servicio de Hybrid Call. Es del tipo de la zona de TraversalServer. Comunica a Expressway-C sobre el puerto TCP 7003 del SORBO.

El pedazo dominante para el servicio híbrido de la llamada es que debe haber cargado el soporte de las rutas del SORBO encendido. La interfaz Web de Expressway llama este soporte cargado valor de las rutas del SORBO mientras que el xConfiguration lo visualizará como el SORBO PreloadedSipRoutes valida

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"

Usted puede también determinar que esta zona tiene regla de búsqueda 3 (híbrido de la chispa) atada a ella. Esencialmente la regla de búsqueda está enviando un “cualquier” alias que venga adentro con la zona de DNS de los servicios híbridos de la llamada y el paso de ella a la zona arriba, Traversal híbrido del servicio de la llamada. Como se esperaba, la regla de búsqueda y la zona del servidor del Traversal en Expressway-e se configuran correctamente.

*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"

Si usted se centra en el xConfiguration de Expressway-C, usted puede comenzar buscando la zona del cliente del Traversal para el híbrido de la chispa. Una forma sencilla de encontrarlo es buscar en el número del puerto que usted aprendió del xConfiguration de Expressway-e (puerto del SORBO: el "7003"). Esto le ayuda rápidamente a identificar la zona correcta en el xConfiguration.

Como antes, usted puede aprender el nombre de zona (Traversal híbrido del servicio de la llamada), el tipo (cliente del Traversal), y qué se ha configurado para el SORBO PreloadedSipRoutes valida (cargó el soporte de las rutas del SORBO). Como usted puede ver de este xConfiguration, este valor se fija a apagado. De acuerdo con el Guía de despliegue para los servicios híbridos de la llamada de la chispa de Cisco, este valor se debe fijar a encendido.

Además, si marcamos la definición del soporte cargado de las rutas del SORBO podemos ver claramente que Expressway-C debe RECHAZAR un mensaje si este valor se fija a apagado Y la invitación contiene una encabezado de la ruta: “Las rutas cargadas Switch del SORBO soportan apagado si usted quisiera que la zona rechazara el SORBO INVITA a las peticiones que contienen esta encabezado.”

Expressway-C
*c xConfiguration Zones Zone 6 Name: "Hybrid Call Service Traversal"
*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 Peer 3 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 4 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 5 Address: 
*c xConfiguration Zones Zone 6 TraversalClient Peer 6 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"

En este momento, usted ha aislado el problema a un misconfiguration de la configuración de la zona del cliente del Traversal de Expressway-C. Usted debe conmutar el soporte cargado de las rutas del SORBO a encendido.

Solución

Para fijar correctamente el soporte cargado de las rutas del SORBO:

1. Registro en Expressway-C
2. Navegue a la configuración > a las zonas > a las zonas
3. Seleccione la zona híbrida del cliente del Traversal del servicio de la llamada (el nombramiento variará al cliente al cliente)
4. Fije el soporte cargado de las rutas del SORBO a encendido
5. Seleccione la salvaguardia

Note: Mientras que este escenario demostró el error en Expressway-C, los mismos errores de registro de diagnóstico se podrían observar en Expressway-e si el soporte cargado de las rutas del SORBO estaba apagado en la zona híbrida del servidor del Traversal de la llamada de la chispa. En ese evento usted nunca habría visto que el alcance de la llamada Expressway-C y Expressway-e habría sido responsable de rechazar la llamada y de enviar los 404 no encontrados.

El app de la chispa de Cisco del problema 5. está recibiendo dos notificaciones de la llamada (las tostadas)

Este problema determinado sucede ser el único escenario de la llamada entrante que no da lugar a la caída de la llamada. Para este problema, la persona que recibe la llamada (Parte llamada) está recibiendo dos notificaciones (tostadas) en el app de la chispa de Cisco de la persona que había puesto la llamada (parte llamadora). La primera notificación se genera de la chispa de Cisco y la segunda notificación viene de la infraestructura de las en-premisas. Abajo están las muestras de las dos notificaciones que se reciben tal y como se muestra en de la imagen.

La primera notificación (tostada) es de la persona que está iniciando la llamada (parte llamadora) del lado de la chispa de Cisco. El en este caso de llamada ID es el nombre de la visualización del usuario que inicia esa llamada. La segunda notificación (tostada) está viniendo del encendido presupone la chispa RD CTI o de Cisco que se asigna al usuario que está haciendo la llamada. Al principio, este comportamiento parece peculiar. Sin embargo, si usted revisa el diagrama de la llamada entrante (de la guía de diseño híbrida de la llamada de la chispa de Cisco), el comportamiento tiene más sentido tal y como se muestra en de la imagen.

Del ejemplo, usted puede ver que la Alicia está llamando a Bob de su app de la chispa de Cisco y que la llamada se está bifurcando abajo a las premisas. Esta llamada debe hacer juego el directorio URI que se asigna al teléfono de Bob. El problema es ése con este diseño, el directorio URI también se asigna a su chispa RD CTI-RD o de Cisco. Por lo tanto, cuando la llamada se ofrece a la chispa RD CTI-RD o de Cisco, se envía la llamada se retira a la chispa de Cisco porque el dispositivo tiene un destino remoto configurado para bob@example.call.ciscospark.com. La manera que la chispa de Cisco maneja esta situación es que cancela el tramo de llamada determinado. 

Para que la chispa de Cisco cancele correctamente el tramo de llamada, la chispa de Cisco necesitó inicialmente poner un parámetro en la encabezado del SORBO que buscaría para cancelar esa pierna dada. Los separadores de millares de la chispa de Cisco del parámetro en el SIP INVITAN se llaman “call-type=squared” y este valor se ingresa en la encabezado del contacto. Si este valor se elimina del mensaje, la chispa de Cisco no entiende cómo cancelar la llamada. 

Con esta información, usted puede revisitar el escenario presentado anterior donde el app de la chispa de Cisco del usuario recibía dos notificaciones (tostadas) cuando el usuario Jonatán Robb de la chispa de Cisco hacía una llamada. Para resolver problemas este tipo de problema, usted va siempre a necesitar recoger el diagnóstico que termina una sesión Expressway-C y Expressway-e. Como punto de partida, usted puede revisar los registros de Expressway-e para determinar que el SIP INVITA de hecho hace que el valor call-type=squared presente en la encabezado del contacto de la chispa de Cisco de la inicial INVITE a entrante enviado. Esto se asegurará de que el Firewall no esté manipulando el mensaje de ninguna manera. Abajo está un snippet de la muestra de venir de la INVITACIÓN entrante a Expressway-e de este escenario.

2017-09-19T14:01:48.140-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,140" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="5062" Src-ip="146.20.193.73" Src-port="40342" Msg-Hash="11658696457333185909"
 SIPMSG:
 |INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0
 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
 Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1
 CSeq: 1 INVITE
 Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>;call-type=squared   <-- Spark inserted value
 From: "Jonathan Robb" <sip:jorobb@dmzlab.call.ciscospark.com>;tag=540300020
 To: <sip:pstojano-test@rtp.ciscotac.net>
 Max-Forwards: 70
 Route: <sip:l2sip@64.102.241.236:5062;transport=tls;lr>,<sip:cucm.rtp.ciscotac.net;lr>

La encabezado del contacto tiene el presente call-type=squared del valor. En este momento, la llamada se debe rutear con Expressway y enviar zona híbrida del servidor del Traversal de la chispa de los. Podemos buscar los registros de Expressway-e para determinar cómo la llamada fue enviada de los Expressway-e. Esto nos dará una idea si Expressway-e está manipulando la INVITACIÓN de cualquier manera. 

2017-09-19T14:01:48.468-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 18:01:48,468" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26686" Msg-Hash="1847271284712495612"
SIPMSG:
INVITE sip:pstojano-test@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-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-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK52aac9a181192566e01b98ae0280bdff858.0e65cdfe078cabb269eecb6bce1328be;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=40342;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-3237-5c5060d07ecc546a0bb861ef52a5f507;rport=43306
Call-ID: 6bc0ca8210c0b48df69f38057ec1e48b@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>     <-- Spark inserted value is now missing
From: "Jonathan Robb" <sip:jorobb@dmzlab.call.ciscospark.com>;tag=540300020
To: <sip:pstojano-test@rtp.ciscotac.net>
Max-Forwards: 15
Route: <sip:cucm.rtp.ciscotac.net;lr>

Al revisar este SORBO INVITE que se esté enviando de Expressway-e a Expressway-C, observan que la encabezado del contacto está faltando call-type=squared. Otra cosa a señalar es ésa en el elemnto de línea 4, usted puede considerar que la salida-zona es igual a HybridCallServiceTraversal. Usted puede ahora concluir que la razón el app de la chispa de Cisco está consiguiendo una segunda notificación (tostada) cuando está marcado está debido a Expressway-e eliminar la etiqueta call-type=squared del SORBO INVITA a la encabezado del contacto. La pregunta a contestar es qué podría causar esta encabezado eliminada.

La llamada debe rutear con el Traversal híbrido del servicio de la llamada que usted configura en Expressway, de modo que sea un lugar bueno para comenzar la investigación. Si usted tiene el xConfiguration, usted puede ver cómo se ha configurado esta zona. Para identificar la zona en el xConfiguration, usted puede utilizar simplemente el nombre registrado en vía la línea que consigue impresa en los registros. Usted puede ver sobre ella fue llamado egress-zone=HybridCallServiceTraversal. Cuando este nombre se imprime en vía la línea de la encabezado del SORBO, se quitan los espacios. El nombre de zona real de la perspectiva del xConfiguration tendría espacios y se formata en el Traversal híbrido del servicio de la llamada. 

*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: "Off" <-- Possible Suspect Value
*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"   <-- Possible Suspect Value
*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 Name: "Hybrid Call Service Traversal"

Con las configuraciones identificadas para el Traversal híbrido del servicio de la llamada, usted puede buscar las configuraciones potenciales que se destacan, por ejemplo:

• El SORBO PreloadedSIPRoutes valida: Encendido
• Modo de ParameterPreservatoin del SORBO: Desactivado

Usando la interfaz Web de cualquier Expressway, usted puede ver cuáles es la definición de estos valores y lo que lo hacen.

Soporte cargado de las rutas del SORBO

El soporte cargado Switch de las rutas del SORBO encendido para permitir a esta zona para procesar el SORBO INVITA a las peticiones que contienen la encabezado de la ruta.

Las rutas cargadas Switch del SORBO soportan apagado si usted quisiera que la zona rechazara el SORBO INVITA a las peticiones que contienen esta encabezado.

Preservación del parámetro del SORBO

Saliente: En-premisas a la chispa de Cisco

Casi cada falla de llamada que implica las en-premisas salientes a los resultados de la chispa de Cisco en el mismo síntoma señalado: “Cuando llamo de mi teléfono CM-registrado unificado a otro usuario que se habilite para el servicio de la llamada conecte, sus timbres del teléfono de las en-premisas pero su app de la chispa de Cisco no hace.” Para resolver problemas este escenario, es importante entender el flujo de llamada y la lógica que están ocurriendo cuando están poniendo a este tipo de llamada.

Flujo de alto nivel de la lógica

1. El usuario A hace una llamada de su en-premses el teléfono al directorio URI del usuario B
2. Las en-premisas del usuario B llaman por teléfono y CTI-RD/Spark-RD validan la llamada
3. El teléfono de las en-premisas del usuario B comienza a los timbres
4. CTI-RD/Spark-RD del usuario B bifurca esto dice en voz alta al destino de UserB@example.call.ciscospark.com
5. El CM unificado pasa esta llamada a Expressway-C
6. Expressway-C envía la llamada a Expressway-e
7. Expressway-e realiza una búsqueda de DNS en el dominio de callservice.ciscospark.com
8. Las tentativas de Expressway-e de conectar con Cisco chispean el entorno sobre el puerto 5062.
9. Expressway-e y el entorno de la chispa de Cisco comienzan un apretón de manos mutuo
10. El entorno de la chispa de Cisco pasa la llamada sobre el app disponible de la chispa de Cisco del usuario B
11. El app disponible de la chispa de Cisco del usuario B comienza a sonar.

Flujo de llamada

Navegue al usuario B en-prem el teléfono > unificado CM > CTI-RD/Spark-RD > Expressway-C > Expressway-e > entorno de la chispa de Cisco > app de la chispa de Cisco tal y como se muestra en de la imagen.

Nota: La imagen se ha tirado de la guía de diseño del híbrido de la chispa de Cisco.

Extremidades del análisis del registro

Si usted resolviera problemas una situación donde las llamadas bifurcadas salientes a la chispa de Cisco fallaban, usted querría recoger los registros unificados CM, de Expressway-C, y de Expressway-e. Teniendo estos conjuntos de los registros, usted puede ver cómo la llamada está pasando a través del entorno. Otro modo rápido de entender hasta dónde la llamada está consiguiendo dentro de su entorno de las en-premisas es utilizar Expressway “historial de la búsqueda”. El historial de la búsqueda de Expressway permitirá rápidamente que usted considere si bifurcados dicen en voz alta a Cisco la chispa están consiguiendo a Expressway-C o al E.

Para utilizar el historial de la búsqueda usted puede realizar éstos:

1. Registro en Expressway-e
   Ponga una llamada de prueba
   Navegue al historial del estatus > de la búsqueda
   Verifique si usted ve una llamada que tenga una dirección destino del SORBO URI de la chispa que debe ser llamado (user@example.call.ciscospark.com)
   Si el historial de la búsqueda no muestra la llamada que golpea la repetición del historial de la búsqueda de Expressway-e este proceso en Expressway-C

Antes de que usted analice el diagnóstico abre una sesión Expressway, considera cómo identificar esta llamada:

1. La petición URI del SORBO será el direccionamiento del SORBO de Cisco del usuario de la chispa
2. El SORBO del campo será formatado para tener la parte llamadora enumerada como “<sip del último nombre del primer nombre”: Alias@Domain >

Con esta información usted puede buscar los registros de diagnóstico por el directorio URI de la parte llamadora, del nombre y apellido de la parte llamadora, o del direccionamiento del SORBO de la chispa de Cisco de la Parte llamada. Si usted no tiene ninguna de esta información, usted puede hacer una búsqueda en “INVITA AL SORBO: ” que localizará todo el SORBO llama el funcionamiento sobre Expressway. Una vez que usted ha identificado el SORBO INVITE para la llamada de salida, usted puede después localizar y copiar el ID de llamada del SORBO. Después de que usted tenga esto usted puede buscar simplemente los registros de diagnóstico basados en el ID de llamada para ver todos los mensajes que correlacionen a este tramo de llamada.

Aquí están algunos de la mayoría de los problemas frecuentes observados con las llamadas de salida del teléfono CM-registrado unificado al entorno de la chispa de Cisco cuando la llamada se hace a un usuario que se habilite para el servicio de la llamada conecte.

El problema 1. Expressway no puede resolver el direccionamiento de callservice.ciscospark.com

El procedimiento de funcionamiento estándar para una zona de DNS de Expressway es realizar las búsquedas de DNS basadas en el dominio que aparece en el Lado derecho de una petición URI. Para explicar esto, considere un ejemplo. Si la zona de DNS fuera recibir una llamada que tenía una petición URI de pstojano-test@dmzlab.call.ciscospark.com, una zona de DNS típica de Expressway realizaría la lógica de las operaciones de búsqueda DNS SRV en dmzlab.call.ciscospark.com que es el Lado derecho de la petición URI. Si Expressway fuera hacer esto usted podría contar con que ocurran las operaciones de búsqueda y la respuesta siguientes.

_sips._tcp.dmzlab.call.ciscospark.com.
Response: 5 10 5061 l2sip-cfa-01.wbx2.com.
l2sip-cfa-01.wbx2.com
Response: 146.20.193.64

Si usted mira de cerca, usted ve que la respuesta del expediente SRV está proporcionando a una dirección del servidor y a un puerto 5061, no 5062.

No sucederá esto significa que la entrada en contacto TLS mutua que ocurre sobre el puerto 5062 y un puerto separado se utiliza para señalar entre Expressway y la chispa de Cisco. El desafío con esto es que el Guía de despliegue para los servicios híbridos de la llamada de la chispa de Cisco no dice en voz alta explícitamente el uso del puerto 5061 porque algunos entornos no permiten la llamada interempresarial.

La manera de trabajar más allá de esta lógica estándar de las operaciones de búsqueda de la zona de DNS SRV en Expressway es configurar Expressway de modo que haga las búsquedas explícitas basadas en un valor que usted proporcione.

  

Ahora al analizar esta llamada determinada, usted puede centrarse en Expressway-e porque usted determinó (usando el historial de la búsqueda) que la llamada ha hecho le esto lejano. El comienzo con el primer SORBO INVITA que entra en Expressway-e para ver qué zona vino adentro encima, que las reglas de búsqueda se están utilizando, que divide en zonas la llamada sale, y si está enviada correctamente a la zona de DNS, ocurre qué lógica de la búsqueda de DNS. 

2017-09-19T13:18:50.562-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,556" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26686" Msg-Hash="4341754241544006348"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK6d734eaf7a6d733bd1e79705b7445ebb46175.1d33be65c99c56898f85df813f1db3a7;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
 Call-ID: 991f7e80-9c11517a-130ac-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=332677~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106860
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=47454c92-2b30-414a-b7fe-aff531296bcf@192.168.1.5:5060;transport=tcp;lr>
 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>

En este SORBO INVITE, usted puede recolectar para arriba la petición URI (pstojano-test@dmzlab.call.ciscospark.com), el ID de llamada (991f7e80-9c11517a-130ac-1501a8c0), de (“Jonatán Robb” <sip:5010@rtp.ciscotac.net>), a (sorbo: pstojano-test@dmzlab.call.ciscospark.com), y agente de usuario (Cisco-CUCM11.5). Después de que se reciba esto INVITE, Expressway deba ahora tomar las decisiones de lógica para determinar si puede rutear la llamada a otra zona. Expressway hará esto basada en las reglas de búsqueda.

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Spark Hybrid' ignored due to source filtering"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" 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-test@dmzlab.call.ciscospark.com'"

De acuerdo con el snippet del registro arriba, usted puede ver que Expressway-e analizado con cuatro reglas de búsqueda, no obstante solamente una (híbrido de la chispa - chispear la nube) era considerado. La regla de búsqueda tenía una prioridad de 90 y fue apuntada para ir a la zona de DNS híbrida de los servicios de la llamada. Ahora que la llamada se está enviando a una zona de DNS, usted puede revisar las operaciones de búsqueda DNS SRV que están ocurriendo en Expressway-e

  

2017-09-19T13:18:50.565-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,565" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"
2017-09-19T13:18:50.718-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,718" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T13:18:50.795-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,795" 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"

En el snippet arriba, usted puede ver que Expressway-e realizó las operaciones de búsqueda SRV basadas en el Lado derecho en la petición URI (_sips. _tcp.dmzlab.call.ciscospark.com) y ha resuelto a un nombre de host de l2sip-cfa-01.wbx2.com y del puerto 5061. Las resoluciones de l2sip-cfa-01.wbx2.com del nombre de host a 146.20.193.64. Con esta información, el paso lógico siguiente que Expressway tomará es enviar a paquete TCP Syn a 146.20.193.64 así que puede intentar poner la llamada. De Expressway-e que registra, usted puede revisar para ver si está sucediendo esto.

2017-09-19T13:18:51.145-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:51,145" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25010" Dst-ip="146.20.193.64" Dst-port="5061" Detail="TCP Connecting"
2017-09-19T13:19:01.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:19:01,289" 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"

En el snippet antedicho del registro de diagnóstico de Expressway-e, usted puede ver que Expressway-e está intentando conectar con el IP 146.20.193.64 que fue resuelto previamente sobre el puerto TCP 5061 sin embargo que esta conexión es fall absoluto. Lo mismo se pueden ver de la captura de paquetes que fue recogida. 

De acuerdo con estos resultados, está claro que el tráfico sobre el puerto 5061 no está teniendo éxito. Sin embargo, el servicio híbrido Connect de la llamada se prepuso utilizar el puerto TCP 5062, no 5061. Por lo tanto, usted necesita pensar en porqué no es Expressway-e que resuelve un expediente SRV que volvería el puerto 5062. Para intentar contestar a esa pregunta, usted puede buscar los problemas de la configuración posible en la zona de DNS del híbrido de la chispa 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 Mode: "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"

En el xConfiguration de Expressway-e, usted puede ver que hay dos valores específicos del interés que se relacionan con las búsquedas de DNS: Nombre de DNSOverride e invalidación de DNSOverride. Basado de este xConfiguration la invalidación de DNSOverride se fija a apagado, por lo tanto el nombre de DNSOverride no tomaría el efecto. Para entender mejor lo que hacen estos valores, usted puede utilizar la red UI de Expressway para mirar para arriba la definición de los valores.

Modifique la petición DNS (traduce a la invalidación de DnsOverride en el xConfig)

Llamadas salientes del SORBO de las rutas de esta zona a un dominio manualmente especificado del SORBO en vez del dominio en el destino marcado. Esta opción se piensa sobre todo para el uso con el servicio de la llamada de la chispa de Cisco. Vea www.cisco.com/go/hybrid-services.

Dominio a buscar para (traduce al nombre de DnsOverride en el xConfig)

Ingrese un FQDN para encontrar en el DNS en vez de la búsqueda para el dominio en el SIP saliente URI. El SORBO original URI no es afectado.

Ahora que usted tiene estas definiciones, está claro que estos valores si estuvieron fijados correctamente serían totalmente relevantes para nuestra lógica de la búsqueda de DNS. Si usted junta esto con las declaraciones del Guía de despliegue para los servicios híbridos de la llamada de la chispa de Cisco, usted encontraría que la petición de la modificación DNS se debe fijar a encendido y el dominio a buscar para se debe fijar a callservice.ciscospark.com. Si usted cambiara estos valores para especificar la información correcta, la lógica de las operaciones de búsqueda DNS SRV sería totalmente diferente. Abajo está un snippet de lo que usted podría esperar de la perspectiva del registro de diagnóstico de Expressway-e

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['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"

Solución

1. Registro en Expressway-e
2. Navegue a la configuración divide en zonas > las zonas
3. Seleccione la zona de DNS híbrida de la chispa se ha configurado que
4. Fije la petición de la modificación DNS a encendido
5. Fije el dominio para buscar para el valor a callservice.ciscospark.com
6. Salve los cambios

Note: Si hay solamente una zona de DNS que es utilizada en Expressway, una zona de DNS separada se debe configurar para ser utilizado con el servicio híbrido de la llamada que puede aprovecharse de estos valores.

El puerto 5062 del problema 2. es saliente bloqueado a la chispa de Cisco

Una cosa que es única sobre los errores bifurcados de la llamada de salida a la chispa de Cisco es que el app de la chispa de Cisco de la Parte llamada presentará un botón del unido en su app aunque el cliente nunca suene. Como el escenario arriba, porque este problema que usted necesitará otra vez utilizar las mismas herramientas y el registro al mejor entiende donde existe el error. Para las extremidades en el aislamiento de los problemas de la llamada y analizar los registros, vea la sección de este artículo tal y como se muestra en de la imagen.

Ejemplo del botón del unido que es presentado

Como el problema #1 de la llamada de salida, usted puede comenzar el análisis en la registración de diagnóstico de Expressway-e, porque usted ha utilizado el historial de la búsqueda en Expressway para determinar que la llamada está consiguiendo eso lejano. Como antes, comience con la inicial INVITAR que entra en Expressway-e de Expressway-C. Recuerde que son las cosas que usted quiere buscar:

1. Si Expressway-e recibe la INVITACIÓN
2. Si la lógica de la regla de búsqueda pasa la llamada a la zona de DNS híbrida
3. Si la zona de DNS realiza la búsqueda de DNS y en el dominio correcto
4. Si el sistema intentó y correctamente estableció una aceptación decontacto con TCP para el puerto 5062
5. Si la entrada en contacto TLS mutua tuvo éxito

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,017" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="3732376649380137405"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK57d8d5c823824bcddfd62f6ff7e09f9939482.899441b6d60c444e4ed58951d07b5224;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
 Call-ID: 6a48de80-9c11273a-12d08-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=328867~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106829
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Tue, 19 Sep 2017 14:18:34 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: b2967a3b-93fb-4ca4-b0d7-131f75335684
 Session-ID: 75957d4fb66a13e835c10737aa328865;remote=00000000000000000000000000000000
 Cisco-Guid: 1783160448-0000065536-0000000126-0352430272
 Content-Type: application/sdp
 Content-Length: 714
<SDP Omitted>

Como usted puede ver en la INVITACIÓN arriba, la INVITACIÓN se recibe como normal. Esto es una acción “recibida” y está viniendo de la dirección IP de Expressway-C. Usted puede ahora moverse sobre la lógica de la regla de búsqueda

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Spark Hybrid' ignored due to source filtering"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" 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-test@dmzlab.call.ciscospark.com'"

De acuerdo con el snippet del registro arriba, usted puede ver que Expressway-e analizado con cuatro reglas de búsqueda sin embargo solamente una (híbrido de la chispa - chispear la nube) era considerado. La regla de búsqueda tenía una prioridad de 90 y fue apuntada para ir a la zona de DNS híbrida de los servicios de la llamada. Ahora que la llamada se está enviando a una zona de DNS, usted puede revisar las operaciones de búsqueda DNS SRV que están ocurriendo en Expressway-e. Todo el esto es totalmente normal. Ahora usted puede centrarse en la lógica de la búsqueda de DNS

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['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"

Usted puede ver claramente ese en este caso, el expediente de callservice.ciscospark.com SRV se resuelve. La respuesta es cuatro diversos expedientes válidos que utilizan el puerto 5062. Esto es normal. En este momento, usted puede ahora analizar la aceptación decontacto con TCP que debe venir después. Según lo mencionado anterior en el documento, usted puede buscar los registros de diagnóstico para el “TCP que conecta” y buscar el elemnto de línea que enumera el Dst-port="5062". Abajo está una muestra de lo que usted verá en este escenario:

2017-09-19T10:18:35.474-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,474" Module="network.tcp" Level="DEBUG":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connecting"
2017-09-19T10:28:35.295-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:28:35,289" Module="network.tcp" Level="ERROR":  Src-ip="172.16.2.2" Src-port="25026" Dst-ip="146.20.193.70" Dst-port="5062" Detail="TCP Connection Failed"

Usted puede también utilizar el tcpdump que fue incluido con el conjunto del registro de diagnóstico para conseguir más información detallada sobre la aceptación decontacto con TCP tal y como se muestra en de la imagen.

En este momento, usted puede concluir que Expressway-e está ruteando la llamada correctamente. El desafío en este escenario es que una conexión TCP no se puede establecer con el entorno de la chispa. Esto podría suceder porque el entorno de la chispa no está respondiendo al paquete TCP Syn sin embargo que sería inverosímil considerando el servidor que maneja la conexión se comparte entre muchos clientes. Más causa probable en este escenario es algún tipo de dispositivo intermediario (Firewall, IPS, etc) no está permitiendo el tráfico hacia fuera. 

Solución

Porque el problema fue aislado, estos datos se deben proporcionar al administrador de la red del cliente. Además, si necesitan más información, usted puede tomar una captura de la interfaz exterior del dispositivo de borde y/o del Firewall para la prueba adicional. De la perspectiva de Expressway, no hay otra acción a realizarse puesto que el problema no reside en ese dispositivo. 

Misconfiguration de la regla de búsqueda de Expressway del problema 3.

El misconfiguration de la regla de búsqueda es uno de los asuntos relacionados más grandes de la configuración en las autopistas. Los problemas de configuración de la regla de búsqueda pueden ser bidireccionales, porque usted necesita las reglas de búsqueda para las llamadas entrantes y usted necesita las reglas de búsqueda para las llamadas de salida. Pues usted recorre a través de este problema, usted descubrirá que mientras que los problemas del regex son muy comunes en Expressway, no son siempre la causa de un problema de la regla de búsqueda. En este segmento en particular, usted recorrerá con una llamada de salida que esté fallando. Como todos nuestros otros escenarios de llamada bifurcados salientes, los síntomas siguen siendo lo mismo:

• El app de la chispa de Cisco del usuario llamado presentado se une al botón
• El teléfono de llamada repetía un timbre
• El teléfono de las en-premisas del usuario llamado sonaba
• El app de la chispa de Cisco del usuario llamado nunca sonó

Como todos los otros escenarios, usted también querrá leverage las trazas CUCM SDL junto con los registros de diagnóstico de Expressway-C y E. Como antes, usted debe referirse al para el historial y las extremidades leveraging de la búsqueda para identificar una llamada a los registros de diagnóstico. Como antes, fue determinada usando el historial de la búsqueda de Expressway-e que esta llamada hacía lo allí y el fallar. Abajo está el principio del análisis para el cual hechamos una ojeada el SORBO inicial INVITAMOS a entrar en Expressway-e de Expressway-C.

2017-09-25T11:26:02.959-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,959" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="25675" Msg-Hash="1536984498381728689"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;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
 Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Mon, 25 Sep 2017 15:26:02 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: 8e8c014d-5d01-4581-8108-5cb096778fc5
 Session-ID: 75957d4fb66a13e835c10737aa505813;remote=00000000000000000000000000000000
 Cisco-Guid: 3582928512-0000065536-0000000240-0352430272
 Content-Type: application/sdp
 Content-Length: 714
 
<SDP Omitted>

Usando el ID de llamada (d58f2680-9c91200a-1c7ba-1501a8c0) de la encabezado del SORBO, usted puede buscar rápidamente abajo de todos los mensajes asociados a este diálogo. Al mirar el tercer golpe en los registros para el ID de llamada, usted puede ver que Expressway-e envía inmediatamente 404 no encontrados a Expressway-C. 

2017-09-25T11:26:13.286-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:13,286" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="25675" Msg-Hash="12372154521012287279"
 SIPMSG:
 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;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
 Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=10d2cfbc45e4373f
 Server: TANDBERG/4135 (X8.10.2)
 Warning: 399 192.168.1.6:7003 "Policy Response"
 Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa505813
 Content-Length: 0

Estos datos le dicen dos cosas:

1. Expressway-e nunca intentó enviar la INVITACIÓN a la chispa de Cisco
2. Expressway-e era el partido responsable para tomar la decisión de lógica para rechazar la llamada con un error no encontrado 404.

Un error no encontrado 404 significa generalmente que Expressway no puede encontrar a la dirección destino. Puesto que las reglas de búsqueda del uso de las autopistas para rutear las llamadas entre ellos mismos y a diversos entornos, comienzan centrándose en el xConfiguration de Expressway-e. Dentro de este xConfiguration, usted puede buscar la regla de búsqueda que debe pasar el decir en voz alta a la zona de DNS del híbrido de la chispa. Para encontrar las reglas de búsqueda configuradas en Expressway de la perspectiva del xConfiguration, usted puede buscar para “la regla de SearchRules de la directiva de las zonas del xConfiguration” de esta manera, usted verá una lista de configuración de la regla de búsqueda para cada regla de búsqueda creada en Expressway. El número que viene después de que la “regla” aumente basado en la regla de búsqueda que era el primer ser creado 1. marcado. Si usted está teniendo problema que encuentra la regla de búsqueda. usted puede utilizar los valores de nombramiento de uso general tales como “chispa” para localizar mejor la regla de búsqueda. Otra manera de identificar la regla está encontrando el valor de la cadena del modelo al cual se fija “. *@.* \ .ciscospark \ .com”. Ésa es la cadena del modelo que es supone para ser configurada. (Si se asume que la cadena del modelo se configura correctamente)

Después de revisar el xConfiguration de este escenario, usted puede ver que la regla de búsqueda 6 es la regla correcta para pasar el decir en voz alta a la chispa de Cisco.

*c xConfiguration Zones Policy SearchRules Rule 6 Authentication: "No"
*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 Replace: 
*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 Priority: "101"
*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 6 Protocol: "SIP"
*c xConfiguration Zones Policy SearchRules Rule 6 SIPTrafficType: "Any"
*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 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 6 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Policy SearchRules Rule 6 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Type: "Zone"

Para probar este modelo, podemos utilizar la función de modelo del control descrita en. El importantes dicen en voz alta aquí son que querremos los valores siguientes configurados:

Modelo del mantenimiento > de las herramientas > del control

• Alias: %Request URI en el INVITE% inicial (ex: pstojano-test@dmzlab.call.ciscospark.com)
• Tipo del modelo: Regex
• Cadena del modelo. *@.* \ .ciscospark \ .com
• Comportamiento del modelo: Salir

Si el Regex para la regla está correcto configurado, usted debe ver el resultado de este modelo del control tener éxito. Abajo está un ejemplo que demuestra esto tal y como se muestra en de la imagen:

Ahora que usted puede confirmar la regla de búsqueda es presente y configurado correctamente, usted puede considerar más cerca la lógica de la búsqueda que Expressway se está realizando para determinar si está afectando a Expressway-e que está enviando los 404 no encontrados. Abajo está una muestra de la lógica de la regla de búsqueda que Expressway realizaba.

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Spark Hybrid' ignored due to source filtering"
2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'Calls to Webex' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-25T11:26:02.967-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,967" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'to DNS' towards target 'DNS' at priority '100' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

2017-09-25T11:26:02.968-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,968" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"
2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Could not resolve hostname"
2017-09-25T11:26:02.982-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,982" Module="network.dns" Level="DEBUG": Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"

En esta muestra, usted puede ver que Expressway procesó cuatro reglas de búsqueda. Los primeros 3 no eran considerados debido a las diversas razones, no obstante los 4tos eran considerados. El pedazo interesante de datos es ése inmediatamente después de consideración que Expressway salta derecho a la lógica de la búsqueda de DNS. Si usted recuerda qué habíamos visto en el xConfiguration la regla de búsqueda configurada para el híbrido de la chispa fue nombrado híbrido de la chispa - para chispear la nube y la ni siquiera era considerado en esta lógica de la regla de búsqueda arriba. En este momento, vale el mirar en cómo la regla de búsqueda considerada (al DNS) fue implementada de modo que usted pueda entender mejor si está afectando el uso de la regla de búsqueda híbrida de la chispa. Para hacer eso, usted puede revisitar el xConfig este vez que busca la regla de búsqueda nombrada “al DNS”

*c xConfiguration Zones Policy SearchRules Rule 1 Authentication: "No"
*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 Replace: 
*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 Priority: "100"
*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 1 Protocol: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 SIPTrafficType: "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 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 1 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 1 Target Name: "DNS"
*c xConfiguration Zones Policy SearchRules Rule 1 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 1 Target Type: "Zone"

Después del estudio de esta regla de búsqueda, usted puede concluir el siguiente:

• La cadena del modelo haría juego la petición URI de la chispa de Cisco
• La prioridad se establece a 100
• El progreso (comportamiento del modelo) se fija para parar.

Qué esta información nos dice es que la petición URI de la chispa de Cisco que es llamado haría juego esta regla y si la regla fuera correspondida con Expressway pararía el buscar (consideración) de otras reglas de búsqueda. Con esta comprensión, la prioridad de la regla se convierte en factor clave. La manera que los trabajos de la prioridad de la regla de búsqueda de Expressway son la regla de la prioridad más baja se intenta primero. Aquí tiene un ejemplo.

Regla de búsqueda: Local

Comportamiento del modelo: Continúe

Prioridad 1

Regla de búsqueda: Vecino

Comportamiento del modelo: Continúe

Prioridad 10

Regla de búsqueda: DNS

Comportamiento del modelo: Pare

Prioridad 50

En este ejemplo, la regla de búsqueda nombrada Local (1) sería intentada primero y si una coincidencia fuera encontrada se movería al vecino de la regla de búsqueda (10) debido al comportamiento del modelo que es fijado para continuar. Si no correspondieron con al vecino de la regla de búsqueda, todavía continuará a la regla de búsqueda DNS (50) y considerará ese último. Si la regla de búsqueda DNS fuera correspondida con, la búsqueda pararía sin importar si había otra regla de búsqueda con una prioridad más alta de 50, porque el comportamiento del modelo fue fijado para parar. 

Con esta comprensión, usted puede hechar una ojeada las prioridades de la regla de búsqueda entre “al DNS” y “chispee el híbrido - para chispear las reglas de la nube”. 

*c xConfiguration Zones Policy SearchRules Rule 1 Name: "to DNS"
*c xConfiguration Zones Policy SearchRules Rule 1 Priority: "100"
*c xConfiguration Zones Policy SearchRules Rule 1 Progress: "Stop"

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

Aquí, usted puede ver que “la regla al DNS” tiene una prioridad baja que el “híbrido de la chispa - para chispear la nube” gobierne -- por lo tanto, “la regla al DNS” será intentada primero. Dado que el comportamiento del modelo (progreso) está fijado para parar, Expressway-e nunca considera el híbrido de la chispa - chispear la regla de la nube y la llamada falla en última instancia. 

Solución

Este tipo de problema es cada vez más común con el servicio híbrido de la llamada conecta. Muchas veces cuando se despliega la solución, la gente crea una regla prioritaria para utilizar para las búsquedas de la chispa de Cisco. Muchas veces esta regla se crea se está correspondiendo con que no está consiguiendo invocada debido a las reglas existentes de la prioridad baja y ella da lugar a un error. Este problema sucede en entrante y las llamadas de salida a la chispa de Cisco. Para resolver esto, usted necesitará seguir los siguientes pasos:

1. Registro en Expressway-e
2. Navegue a las reglas de la configuración > del Plan de marcado > de búsqueda
3. Encuentre la regla de búsqueda híbrida de la chispa y hágala clic (ex: Nombre: Híbrido de la chispa - chispear la nube)
4. Fije el valor de prioridad algo más bajo que otras reglas de búsqueda, con todo arriba bastante de modo que no afecte otras. (Ex: Prioridad: 99)

La regla práctica general con las reglas de búsqueda es cuanto más específica la cadena del modelo, más bajo puede ser colocada en la lista de prioridad de la regla de búsqueda. Una zona de DNS se configura generalmente con una cadena del modelo que vaya a coger cualquier cosa que no es un dominio local y a enviarlo a Internet. Debido a esto, recomendamos que usted fijó ese tipo de regla de búsqueda a un prioritario así que ha invocado el último. 

Misconfiguration COMPLETO de Expressway del problema 4.

La solución de Expressway permite la mitigación del fraude de cargos de llamada usando la lógica (COMPLETA) del lenguaje del Procesamiento de llamadas disponible en el servidor. Si la solución de Expressway que es desplegada se está utilizando solamente para el servicio híbrido de la llamada de la chispa de Cisco y móvil y Acceso Remoto, recomendamos fuertemente que la directiva y las reglas COMPLETAS están habilitadas y implementadas. Mientras que la configuración COMPLETA en Expressway para el híbrido de la chispa de Cisco es bastante directa, si es mal configurado puede bloquear fácilmente los intentos de llamada del suceso. Los escenarios debajo de la demostración usted cómo utilizar el registro de diagnóstico para identificar un misconfiguration COMPLETO.

Como todos otros escenarios de llamada bifurcados salientes, los síntomas seguían siendo lo mismo:

• El app de la chispa de Cisco del usuario llamado presentó un botón del unido
• El teléfono de llamada repetía un timbre
• El teléfono de las en-premisas del usuario llamado sonaba
• El app del usuario llamado nunca sonó

Como todos los otros escenarios, usted puede utilizar las trazas CUCM SDL junto con los registros de diagnóstico de Expressway-C y E. Como antes, usted debe referirse al para usar el historial y las extremidades de la búsqueda para identificar una llamada en los registros de diagnóstico. Como antes, fue determinada usando el historial de la búsqueda de Expressway-e que llegaba esta llamada allí y el fallar. Abajo está el principio del análisis en el cual usted puede hechar una ojeada el SORBO inicial INVITA a entrar en Expressway-e de Expressway-C.

2017-09-25T16:54:43.722-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,722" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26404" Msg-Hash="17204952472509519266"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;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
 Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>
 Max-Forwards: 15
 Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5061;transport=tls;lr>
 Record-Route: <sip:proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac@192.168.1.5:5060;transport=tcp;lr>
 Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
 User-Agent: Cisco-CUCM11.5
 Expires: 180
 Date: Mon, 25 Sep 2017 20:54:43 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: 4fffefed-0512-4067-ac8c-35828f0a1150
 Session-ID: 75957d4fb66a13e835c10737aa512577;remote=00000000000000000000000000000000
 Cisco-Guid: 3224432896-0000065536-0000000264-0352430272
 Content-Type: application/sdp
 Content-Length: 714

<SDP Omitted>

Usando el ID de llamada (c030f100-9c916d13-1cdcb-1501a8c0) de la encabezado del SORBO, usted busca rápidamente abajo de todos los mensajes asociados a este diálogo. Al mirar el tercer golpe en los registros para el ID de llamada, usted puede ver que Expressway-e envía inmediatamente 403 prohibidos a Expressway-C. 

2017-09-25T16:54:43.727-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,727" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="192.168.1.6" Local-port="7003" Dst-ip="192.168.1.5" Dst-port="26404" Msg-Hash="9195436101110134622"
 SIPMSG:
 |SIP/2.0 403 Forbidden
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;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
 Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=64fe7f9eab37029d
 Server: TANDBERG/4135 (X8.10.2)
 Warning: 399 192.168.1.6:7003 "Policy Response"
 Session-ID: 00000000000000000000000000000000;remote=75957d4fb66a13e835c10737aa512577
 Content-Length: 0

Para entender porqué Expressway-e negó esta llamada y envió un error prohibido 403 a Expressway-C, usted quiere analizar las entradas de registro entre los 403 prohibidos y el SIP original INVITA a eso ingresada en Expressway. Analizando estas entradas de registro, usted puede ver típicamente todas las decisiones de lógica se están tomando que. Observe que usted no ve ninguna reglas de búsqueda que son invocada pero vea la lógica (COMPLETA) de proceso del lenguaje de la llamada que es invocada. Abajo está un snippet de ése.

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: <routed> "
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,725" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: <rule-switch>  "
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: <rule unauthenticated-origin=".*" destination=".*@dmzlab\.call\.ciscospark\.com.*" message-regex=""> matched "
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,726" Module="network.cpl" Level="DEBUG":  Remote-ip="192.168.1.5" Remote-port="26404" Detail="CPL: <reject/> "

De acuerdo con el análisis del registro arriba. usted puede hacer la determinación que el COMPLETO está rechazando la llamada. 

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="5010@rtp.ciscotac.net" Dst-alias-type="SIP" Dst-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" 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: En esta situación usted no verá las reglas de búsqueda que son invocadas porque CPLs, FindMe, y Transforms toda se procesan antes de una regla de búsqueda

En la mayoría de los casos, usted puede leverage el xConfig de Expressway para entender mejor las circunstancias. Sin embargo, para CPLs, usted no puede ver las reglas se definen que, sólo si se habilita la directiva. Abajo está la porción del xConfig que nos muestra que este Expressway-e está utilizando la lógica COMPLETA local.

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

Para entender mejor la configuración de la regla, usted necesita iniciar sesión a Expressway-e y navegar a la configuración > a la directiva > a las reglas de la llamada tal y como se muestra en de la imagen.

Al revisar esta configuración, usted puede ver el siguiente se configura

Fuente: . *

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

Acción: Rechazo

Comparado a qué se documenta en la guía híbrida de la instrumentación del servicio de la llamada de la chispa de Cisco, usted puede ver que la fuente y el destino fueron configurados al revés.

Solución

Para resolver este problema, usted necesita reajustar la configuración COMPLETA de la regla para fijar la fuente a. *@%spark_subdomain% \ .call \ .ciscospark \ .com.* y el diagrama de destinos es. *

1. Registro en Expressway-e
2. Navegue a la configuración > a la directiva > a las reglas de la llamada
3. Seleccione la regla que fue puesta para el servicio híbrido de la llamada de la chispa de Cisco
4. Ingrese el modelo de la fuente como. *@%spark_subdomain% \ .call \ .ciscospark \ .com.* (ex:. *@dmzlab \ .call \ .ciscospark \ .com.*)
5. Ingrese el diagrama de destinos como. *
6. Seleccione la salvaguardia

Para más información sobre la implementación COMPLETA para el híbrido de la chispa refiera a la guía de diseño del híbrido de la chispa de Cisco. 

Bidireccional: Chispa de Cisco a las En-premisas o a las En-premisas a la chispa de Cisco 

El teléfono del IP del problema 1./el punto final de la Colaboración está ofreciendo un códec de audio con excepción de G.711, de G.722, de AAC-LD, o del opus

El servicio híbrido de la llamada conecta los soportes cuatro diverso Códecs de audio: G.711, G.722, AAC-LD, y opus. Para establecer con éxito una llamada con el entorno de la chispa de Cisco, uno de este Códecs de audio debe ser utilizado. El entorno de las en-premisas se puede poner para utilizar muchos tipos de Códecs de audio pero al mismo tiempo puede ser puesto para restringirlo. Esto puede suceder intencionalmente o involuntariamente por el uso de las configuraciones de la región de la aduana y/o del valor por defecto en el CM unificado. Para este comportamiento determinado, los modelos del registro pueden diferenciar basado en la dirección de la llamada y si el CM unificado fue configurado para utilizar temprano u oferta retrasada. Abajo están los ejemplos de algunas diversas situaciones donde este comportamiento podría presentarse:

1. La chispa de Cisco envía un entrante INVITA con el SDP que ofrece G.711, G.722, AAC-LD, y el opus. Expressway-C envía este mensaje CM unificado pero el CM unificado se configura para permitir solamente G.729 para esta llamada. Así pues, el CM unificado rechazará la llamada debido a ningún codificador-decodificador disponible.
2. El CM unificado intenta la llamada de salida pues la oferta temprana a la chispa de Cisco que significa que la inicial INVITA enviado a Expressway-C contendrá el SDP que soporta SOLAMENTE el audio de G.729. La chispa de Cisco entonces manda una AUTORIZACIÓN 200 con el SDP ese los ceros el audio (m=audio 0 RTP/SAVP) porque no soporta G.729. Una vez que Expressway-C pasa esto INVITE al CM unificado, el CM unificado termina la llamada porque no hay un codificador-decodificador disponible. 
3. El CM unificado intenta la llamada de salida pues la oferta retrasada a la chispa de Cisco que significa que la inicial INVITA enviado a Expressway-C no contendrá el SDP. La chispa de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP que contiene todos los soportes soportados de la chispa de Cisco del Códecs de audio. Expressway-C envía esta 200 AUTORIZACIÓN CM unificado pero el CM unificado se configura solamente para permitir solamente G.729 para esta llamada. Así pues, el CM unificado rechazará la llamada debido a ningún codificador-decodificador disponible.

Si usted está intentando identificar un servicio híbrido de la llamada conecte la falla de llamada que hace juego este problema, usted debe conseguir Expressway abre una sesión las trazas unificadas de la adición CM SDL. El snippets del registro del ejemplo debajo de la situación #2 de la coincidencia donde el CM unificado está intentando la llamada de salida como temprano ofrece. Porque sabemos que la llamada está saliendo a la chispa de Cisco, el análisis del registro comienza en Expressway-e.

Abajo está un snippet de la inicial INVITA hacia fuera a la chispa de Cisco. Usted puede ver que el códec de audio preferido está fijado a G.729 (payload 18). Los 101 está para el DTMF y para este escenario particular no es relevante. 

2017-09-19T10:46:10.488-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:10,488" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="172.16.2.2" Local-port="25034" Dst-ip="146.20.193.64" Dst-port="5062" Msg-Hash="4309505007645007056"
SIPMSG:
INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
Via: SIP/2.0/TLS 64.102.241.236:5062;egress-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-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;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
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 101 INVITE
Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;privacy=off;screen=no;party=calling
Contact: <sip:172.16.2.2:5073;transport=tls>;video;audio
From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833
To: <sip:pstojano-test@dmzlab.call.ciscospark.com>
Max-Forwards: 14
Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>
Record-Route: <sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>
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
Session-ID: 75957d4fb66a13e835c10737aa329445;remote=00000000000000000000000000000000
Content-Type: application/sdp
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:.............................................
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP
a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................
a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. 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
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:.............................................
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:............................................. UNENCRYPTED_SRTCP
a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:.............................................
a=crypto:4 AES_CM_128_HMAC_SHA1_32 inline:............................................. UNENCRYPTED_SRTCP
a=sendrecv
a=content:main
a=label:11
a=rtcp:52671 IN IP4 64.102.241.236

En respuesta a esta inicial INVITE, chispa de Cisco responde con un mensaje de 200 AUTORIZACIONES. Si usted hecha una ojeada a una mirada más atenta este mensaje, usted puede ver que el códec de audio fue puesto a cero hacia fuera. Esto es problemático porque sin un puerto audio asignado, la llamada no podrá negociar esa secuencia. 

2017-09-19T10:46:27.073-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,072" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="172.16.2.2" Local-port="25034" Src-ip="146.20.193.64" Src-port="5062" Msg-Hash="5236578200712291002"
SIPMSG:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 64.102.241.236:5062;egress-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.a402e3f25603f5a77b60b17ea47dbf72;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.494a140082bd66357134b9eed4335df8;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
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 101 INVITE
Contact: "l2sip-UA" <sip:l2sip-UA@l2sip-cfa-01.wbx2.com:5062;transport=tls>
From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833
To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=1311451760
Record-Route: <sip:l2sip-cfa-01.wbx2.com:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@64.102.241.236:5062;transport=tls;lr>,<sip:proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2@172.16.2.2:5061;transport=tls;lr>
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-Type: application/sdp
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

Usted puede ahora utilizar TranslatorX para revisar el resto del diálogo. Usted puede ver que el diálogo sí mismo completa con un ACK. El problema es inmediatamente después que el diálogo completa allí es un ADIÓS que viene de la dirección de Expressway-C tal y como se muestra en de la imagen. 

Abajo está una muestra detallada del mensaje del ADIÓS. Usted puede ver claramente que el agente de usuario es Cisco-CUCM11.5 que significa que el mensaje fue generado por el CM unificado. Otra cosa a señalar es que el código de motivo está fijado a cause=47. La traducción común para esto no es ningún recurso disponible. 

2017-09-19T10:46:27.175-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,175" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="237943800593485079"
SIPMSG:
BYE sip:192.168.1.6:5071;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK90a666b3461356f8cd605cec91e4538240575.494a140082bd66357134b9eed4335df8;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
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 102 BYE
From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833
To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=f3734601fb0eb541
Max-Forwards: 69
Route: <sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:7003;transport=tls;lr>,<sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:5061;transport=tls;lr>
User-Agent: Cisco-CUCM11.5
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 el componente de la chispa de Cisco puso a cero hacia fuera los códecs de audio para esta muestra de la llamada, el foco debe estar prendido

a) la inicial INVITA que fue enviada a la chispa de Cisco y

b) cuál era la chispa de Cisco de la lógica usada a cero hacia fuera que vira hacia el lado de babor.

Ahora mirando en cuál es único sobre la inicial INVITE a qué puede ser notada es él contiene solamente G.729. Conociendo esto, revise la guía híbrida de la instrumentación del servicio de la llamada de la chispa de Cisco y revise específicamente la preparación su capítulo del entorno donde el paso 5 del completo los requisitos previos para el servicio híbrido de la llamada conecta la sección dice en voz alta el codecs específico se soportan que. Allí veríamos esto:

La chispa de Cisco soporta el codecs siguiente:

• Audio — G.711, G.722, AAC-LD
• Vídeo — H.264

Con esta información a mano, usted puede concluir que el CM unificado está enviando un códec de audio sin apoyo que sea la razón que la chispa de Cisco está poniendo a cero hacia fuera el puerto. 

Solución

Para dirigir esta situación determinada, usted puede necesitar revisar la configuración de región entre la chispa RD de Cisco que está asegurando las en-premisas de la llamada y el trunk del SORBO para Expressway-C. Para hacer así pues, determine en que la agrupación de dispositivos esos dos elementos está. La agrupación de dispositivos contiene las asignaciones a las regiones. 

Para determinar a la agrupación de dispositivos del trunk de Expressway-C SIP:

1. Registro en el CM unificado
2. Navegue al dispositivo > al trunk
3. Busque para el nombre del trunk o haga clic el hallazgo
4. Seleccione el trunk de Expressway-C
5. Registre el nombre de la agrupación de dispositivos

Para determinar a la agrupación de dispositivos del CTI-RD o del Cisco Chispa-RD que aseguraron la llamada 

1. Navegue al Device (Dispositivo) > Phone (Teléfono)
2. Cuando la búsqueda de usted puede seleccionar el tipo de dispositivo contiene la chispa o el dispositivo remoto CTI (dependiendo de lo que está utilizando el cliente. 
3. Registre el nombre de la agrupación de dispositivos

Determine la región asociada a cada agrupación de dispositivos

1. Navegue al sistema > a la agrupación de dispositivos
2. Busque para la agrupación de dispositivos usada para el trunk del SORBO de Expressway-C
3. Haga clic en a la agrupación de dispositivos
4. Registre el nombre de la región
5. Busque para la agrupación de dispositivos usada para el Chispa-RD o el CTI-RD
6. Haga clic en a la agrupación de dispositivos
7. Registre el nombre de la región

Determine la relación de la región del ithe

1. Navegue a la información del sistema > de la región > a la región
2. Busque en una de las regiones identificadas arriba
3. Determine si su es una relación de la región entre ambas regiones que está utilizando G.729

En este momento, si usted identifica la relación que está utilizando G.729, usted necesitará ajustar la relación para soportar del Códecs de audio soportado que la chispa de Cisco utiliza o utiliza a una diversa agrupación de dispositivos que tenga una región que soporte esto. En el escenario documentado arriba, lo que sigue fue determinado:

Región del trunk de Expressway-C: ReservingBandwidth

Región Chispa-RD: RTP-dispositivos

Abajo está una ilustración gráfica de la relación entre las regiones de los RTP-dispositivos y de ReservingBandwidth tal y como se muestra en de la imagen. 

Cambiando a la agrupación de dispositivos el trunk de Expressway-C estaba adentro, usted cambia la relación de la región. La nueva agrupación de dispositivos hizo una región fijar a la RTP-infraestructura, por lo tanto la nueva relación de la región entre el trunk de Cisco Chispa-RD y de Expressway-C era RTP-dispositivos y RTP-infraestructura. Según lo representado arriba, usted puede ver los soportes AAC-LD de esta relación que es uno del Códecs de audio soportado para la chispa de Cisco y así que la llamada configurará correctamente. 

El problema 2. unificó el tamaño máximo del mensaje entrante CM excedido

Porque el vídeo ha llegado a ser más frecuente dentro de la empresa, el tamaño de los mensajes del SORBO que contienen el SDP ha crecido substancialmente. Los servidores que procesan estos mensajes se deben configurar adentro por ejemplo la manera que pueden validar un paquete grande. En muchos servidores del Control de llamadas, los valores predeterminados están muy bien. Con el administrador de las Comunicaciones unificadas de Cisco (CM unificado), los valores predeterminados para manejar un mensaje grande del SORBO que contenía las versiones del pasado SDP adentro no estaban. En versiones posteriores del CM unificado que el tamaño del valor permitido para un mensaje del SORBO se ha aumentado sin embargo este valor se fija solamente en nuevo instala no las actualizaciones. Con este todo el dicho, los clientes que están actualizando sus más viejas versiones del CM unificado para soportar el servicio híbrido Connect de la llamada pudieron ser afectados por el tamaño máximo del mensaje entrante en el CM unificado que era demasiado bajo.

Si usted está intentando identificar un servicio híbrido de la llamada conecte la falla de llamada que hace juego este problema, usted debe conseguir Expressway abre una sesión las trazas unificadas de la adición CM SDL. Para identificar el error, primero entienda qué sucede y entonces los tipos de escenarios en los cuales el error puede ocurrir.

Para contestar a la cuestión de qué sucede, usted debe saber que una vez que el CM unificado recibe un mensaje del SORBO que sea demasiado grande, cierra simplemente el socket TCP y no responde a Expressway-C.

Con esto dijo, hay muchas situaciones y las maneras esto podrían ocurrir:

1. La chispa de Cisco envía un entrante INVITA con el SDP que es demasiado grande. Expressway-C pasa esto sobre el CM unificado y unificó el CM cierra el socket TCP entonces que el diálogo del SORBO medirá el tiempo hacia fuera.
2. El CM unificado intenta la llamada de salida como temprano ofrece chispear que significa que la inicial INVITA enviado a Expressway-C contendrá el SDP. La chispa de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP en la respuesta y la respuesta de 200 AUTORIZACIONES cuando está pasada de Expressway-C al CM unificado es demasiado grande. El CM unificado cierra el socket TCP entonces que el diálogo del SORBO medirá el tiempo hacia fuera.
3. El CM unificado intenta la llamada de salida pues la oferta retrasada a chispear que significa que la inicial invita enviado a Expressway-C no contendrá el SDP. La chispa de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP y la oferta ACEPTABLE 200 cuando está pasada de Expressway-C al CM unificado es demasiado grande. El CM unificado cierra el socket TCP entonces que el diálogo del SORBO medirá el tiempo hacia fuera.

La mirada a través de los registros de Expressway-C para esta condición del detalle le ayuda a entender el flujo de mensajes. Si usted utilizara un programa como TranslatorX, usted podría ver el ee que Expressway-C está pasando la AUTORIZACIÓN de la chispa 200 de Cisco con SDP CM unificado. El desafío es que el CM unificado nunca responde detrás con un SORBO ACK tal y como se muestra en de la imagen.

Puesto que el CMis unificado el partido responsable para no responder, él vale el revisar de las trazas SDL para ver cómo el CM unificado está manejando esta condición. Qué usted encontraría en este escenario es que el CM unificado ignora el mensaje grande de Expressway-C. Un elemento de línea del registro tal como el abajo sería impreso.

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.

 Después de que el diálogo del SORBO mida el tiempo hacia fuera, la chispa de Cisco enviará un mensaje entrante de la disminución del SORBO 603 a Expressway-e como se apunta en la muestra del registro abajo.

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

Según lo mencionado, hay tres diversos escenarios en los cuales usted podría ver este comportamiento. Para mayor clareza, las muestras del registro proporcionadas en este ejemplo correspondieron con la situación 3 donde la llamada fue enviada saliente a la chispa de Cisco mientras que oferta retrasada. 

Solución

1. Registro en el CM unificado 
2. Navegue al sistema > a los parámetros de servicio
3. Seleccione el servidor que está funcionando con el servicio del administrador de llamada
4. Elija el servicio del Cisco Call Manager cuando está indicado para una selección del servicio
5. Seleccione la opción avanzada
6. Bajo parámetros Clusterwide (dispositivo - Las configuraciones del SORBO) cambian el tamaño máximo del mensaje entrante del SORBO a 18000.
7. Seleccione la salvaguardia
8. Relance este proceso para cada nodo unificado CM que esté funcionando con el servicio del Cisco Call Manager.

Note: Para que un punto final del teléfono del IP, de la Colaboración, y/o el trunk del SORBO leverage esta configuración debe ser recomenzada. Estos dispositivos se pueden recomenzar individualmente para minimizar el impacto al environment.DO no reajustados cada dispositivo en el CUCM a menos que usted sepa que es absolutamente aceptable hacer tan.

Apéndice 1: Herramientas de Troubleshooting de Expressway

Utilidad del modelo del control

Expressway tiene un modelo que marca la utilidad que es útil cuando usted quiere probar si las Coincidencias de patrones un alias determinado y se transforma de la manera prevista. La utilidad se puede encontrar en Expressway bajo opción de menú de modelo del mantenimiento > de las herramientas > del control. Lo más comúnmente posible, se utiliza esto si usted quiere la prueba si su regex de la regla de búsqueda va a hacer juego correctamente un alias a una cadena del modelo y después a realizar opcionalmente la manipulación acertada de la cadena. Para la llamada híbrida mantenga conectan, usted puede también probar que el cluster unificado FQDN CM va a hacer juego la cadena del modelo que usted configura para el cluster unificado FQDN CM. Al usar esta utilidad, recuerde que la llamada ruteará basado en el parámetro unificado del cluster FQDN CM enumerado en la encabezado de la ruta, no el destino URI. Por ejemplo si, los siguientes invitan entraron en Expressway, prueban las funciones del modelo del control contra cucm.rtp.ciscotac.net, no jorobb@rtp.ciscotac.net.

 SIPMSG:
 |INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.6:7003;egress-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-local-service=nettle;received=192.168.1.6;rport=41913;ingress-zone=DefaultZone
 Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK524f89592d00ffc45b7b53000271676c370.88b5177ac4d7cfcae1eb8f8be78da055;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=39986;ingress-zone=HybridCallServicesDNS
 Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-313634-3d27a6f914badee6420287903c9c6a45;rport=45939
 Call-ID: 3e613afb185751cdf019b056285eb574@127.0.0.1
 CSeq: 1 INVITE
 Contact: <sip:192.168.1.6:5073;transport=tls>
 From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=145765215
 To: <sip:jorobb@rtp.ciscotac.net>
 Max-Forwards: 15
 Route: <sip:cucm.rtp.ciscotac.net;lr>

Para utilizar el modelo del control para probar la llamada híbrida mantenga conectan la encaminamiento de la regla de búsqueda de la encabezado de la ruta, siguen los siguientes pasos:

1. Navegue al modelo del mantenimiento > de las herramientas > del control
2. Para el alias, ingrese el FQDN unificado del cluster CM
3. Fije el tipo del modelo para prefijar
4. Fije el cluster unificado FQDN de la cadena CM del modelo
5. Fije el comportamiento del modelo para irse
6. Seleccione el modelo del control

Si las reglas de búsqueda en Expressway se configuran correctamente, usted puede esperar ver la vuelta de los resultados un mensaje tenido éxito. 

Abajo está un ejemplo de una prueba acertada del modelo del control tal y como se muestra en de la imagen. 

La razón que ésta es acertada es porque este alias (cucm.rtp.ciscotac.net) hace juego la cadena del modelo del prefijo de (cucm.rtp.ciscotac.net). Para entender cómo se rutea una llamada basó de estos resultados, usted puede utilizar Expressway localiza la utilidad descrita más abajo.

Localice la utilidad

Expressway localiza la utilidad es útil si usted quiere probar si Expressway puede rutear una llamada a una zona particular basada en dado alias. Todo el esto puede ser completada sin tener que poner una llamada real. La utilidad de la situación se puede encontrar en Expressway bajo el mantenimiento > las herramientas > localiza el menú. Debajo proporciona una cierta instrucción en cómo usted podría utilizar las funciones de la situación en Expressway-C para determinar si el servidor podría rutear una llamada basada en el FQDN unificado del cluster CM encontrado en la encabezado de la ruta SIP.

1. Navegue al mantenimiento > a las herramientas > localizan
2. Ingrese el FQDN unificado del cluster CM en el campo del alias
3. Seleccione el SORBO como el protocolo
4. Seleccione su zona híbrida del cliente del Traversal de la chispa de Cisco para la fuente
5. Selecto localice

En la parte inferior de la interfaz, usted ahora verá los resultados de la búsqueda. Abajo está un ejemplo de la prueba de muestra que fue funcionada con con los resultados que correspondían con tal y como se muestra en de la imagen. 

Abajo están los resultados de la situación (arriba). Enes negrita son los valores del interés demostración de estos resultados el siguiente

• El hecho de que el alias podría ser ruteado (verdad)
• Información fuente (nombre de zona/tipo)
• Información de destino (alias siendo ruteado)
• Regla de búsqueda que es correspondida con (encaminamiento entrante del servicio híbrido de la llamada)
• Divida en zonas que la llamada sería enviada 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
Value: cucm.rtp.ciscotac.net
SubSearch (1)
Type: FindMe
Action: Proxy
ResultAlias (1)
Type: Url
Origin: Unknown
Value: cucm.rtp.ciscotac.net
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
Value: cucm.rtp.ciscotac.net
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
Value: cucm.rtp.ciscotac.net
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
Value: cucm.rtp.ciscotac.net

Registro de diagnóstico

Cualquier momento usted está resolviendo problemas una llamada o los media publican para una llamada que atraviese la solución de Expressway, usted debe utilizar el registro de diagnóstico. Esta capacidad de Expressway da a técnico Al gran detalle de la información para todas las decisiones de lógica que va Expressway a través mientras que la llamada pasa. Usted puede ver al cuerpo completo SORBER los mensajes, cómo los pasos de Expressway que llaman a través, y cómo Expressway configura los canales de los media. El registro de diagnóstico tiene varios diversos módulos que alimenten en él. Los niveles de registro se pueden ajustar para mostrar FATAL, ERROR, ADVIERTEN, INFORMACIÓN, DEBUG, TRAZA. Por abandono todo se fija a la INFORMACIÓN que captura casi todo que usted necesita diagnosticar un problema. De vez en cuando, usted puede necesitar ajustar un nivel de registro de un módulo particular de la INFORMACIÓN PARA HACER EL DEBUG DE para conseguir una mejor comprensión de qué está sucediendo. Los pasos abajo ilustran cómo usted puede ajustar los niveles de registro del módulo developer.ssl que es responsable de proporcionar a la información para las entradas en contacto TLS (mutuas).

1. Registre en Expressway el servidor (debe ser hecho en Expressway-e y C)
2. Navegue al >Diagnostics del mantenimiento > avanzó > configuración del registro del soporte
3. Navegue al módulo que usted quisiera ajustar, al en este caso developer.ssl y hacerlo clic.
4. Al lado del parámetro llano, elija el DEBUG del menú
5. Haga clic la salvaguardia

En este momento, le preparan para capturar el registro de diagnóstico:

1. Registre en Expressway el servidor (debe ser hecho en Expressway-e y C)
2. Navegue al >Diagnostics del mantenimiento > registro de diagnóstico
3. Haga clic el nuevo registro del comienzo (nota: Asegúrese que usted marque la opción del tcpdump)
4. Reproduzca el problema
5. Haga clic el registro de la parada
6. Haga clic el registro de la descarga

Para el registro de diagnóstico de Expressway, tenga presente que usted comenzaría el registro de Expressway-C y de Expressway-e paralelamente: primero comience la apertura de sesión de Expressway-e, después vaya a Expressway-C y comiéncelo. En ese momento, usted puede entonces reproducir el problema.

Note: El conjunto del registro de diagnóstico Expressway/VCS no contiene actualmente la información sobre el certificado de servidor de Expressway o la lista de confianza de CA. Si usted tiene un caso donde estaría beneficioso tener estas funciones, asocie por favor su caja a este defecto.

Referencias

• Guía de despliegue para los servicios híbridos de la llamada de la chispa de Cisco
• Guía de diseño del híbrido de la chispa de Cisco
• Guía del administrador de Cisco Expressway
• Soporte Técnico y Documentación - Cisco Systems