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

Introducción

Este documento describe el WebEx 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.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento de la oferta del WebEx de Cisco
• Conocimiento de la solución de Expressway (B2B)
• Conocimiento del encargado de las Comunicaciones unificadas de Cisco (unificado cm) 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 la ayuda para los servicios híbridos del WebEx 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.

• Encargado de las Comunicaciones unificadas de Cisco
• Autopistas
• El WebEx de Cisco combina para Windows
• El WebEx de Cisco combina para el mac
• El WebEx de Cisco combina para el IOS
• El WebEx de Cisco combina para Android
• Puntos finales de la colaboración de Cisco
• Puntos finales del escritorio de la Colaboración
• Teléfonos IP
• Clientes del software

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La solución ofrece a éstos la capacidad:

• Utilice el app de los equipos del WebEx 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 los equipos del WebEx 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 el historial en el WebEx de Cisco combina

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 del apretón de manos de TLS

El servicio híbrido de la llamada conecta la Seguridad mutua de la capa de transporte de las aplicaciones (TLS mutuo) para la autenticación entre el WebEx de Cisco y Expressway-e. Esto significa que Expressway-e y el WebEx de Cisco controlan 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 el enablement de las soluciones tales como servicio híbrido de la llamada conecta, esta sección proporciona a la información útil e inclina para resolver problemas los problemas basados certificado entre las autopistas y el WebEx de Cisco.

¿Qué Expressway-e controla?

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

¿Qué el WebEx de Cisco controla?

• El certificado de Expressway-e ha sido firmado por uno del público CAs las confianzas de ese WebEx. (Lista de confianza del WebEx CA 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 por teletratamiento a Cisco el WebEx controlan el concentrador (https://admin.ciscoWebex.com)?

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

Extremidades de troubleshooting mutuas útiles de TLS

1. Decodifique el apretón de manos mutuo de TLS

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 el apretón de manos a TLS (mutuo) que los occurrs sobre el puerto 5062, Wireshark no sabrán decodificar el tráfico correctamente. Aquí está un ejemplo del apretón de manos mutuo de TLS 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 por defecto en Wireshark. El paquete número 175 es el certificado que Expressway envía a Cisco el WebEx. Sin embargo, usted no puede determinar que 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 el apretón de manos mutuo de TLS, primero filtre la captura por tcp.port==5062. Después de esto, haga clic derecho 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. A este punto, 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 corregir > 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 un apretón de manos mutuo de TLS:

• 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 del WebEx de Cisco que se presenta en un apretón de manos mutuo de TLS.

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

   Note: El certificado inferior/pasado en el encadenamiento es raíz CA.

4. Haga clic derecho 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 fichero 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 DEPURACIÓN nivel, 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 del WebEx 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.com"

Ejemplo de Expressway-e que asocia la conexión MTLS a la zona de DNS del híbrido del WebEx 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.ciscoWebex.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.ciscoWebex.coml2sip-cfa-01.ciscoWebex.coml2sip-cfa-01.wbx2.coml2sip-cfa-01-web.wbx2.coml2sip-cfa-web.wbx2.comcallservice.ciscoWebex.com" MatchedZone="Hybrid Call Services DNS" MatchedIdentity="callservice.ciscoWebex.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.ciscoWebex.com, Alt-DNS: l2sip-cfa-01.ciscoWebex.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.ciscoWebex.com, Alt-DNS: callservice.call.ciscoWebex.com, Alt-DNS: l2sip-a-Webexcall.ciscoWebex.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.ciscoWebex.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.ciscoWebex.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.wbx2.com, Alt-DNS: l2sip-cfa-02.wbx2.com, Alt-DNS: Webexcmr-wpa.ciscoWebex.com, Alt-DNS: Webexcmr-wpb.ciscoWebex.com, Alt-DNS: Webexcmr-wpc.ciscoWebex.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 el WebEx de Cisco. 

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

El servidor del WebEx 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 nombre común de la boca de riego SSL ICA G2. El intermediario es firmado por una autoridad de certificación de la raíz que tenga un nombre común 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 el apretón de manos de TLS que es denotado 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 del WebEx 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 del WebEx presenta es certificado entonces Expressway da vuelta alrededor y los rechazos con el certificado con un error desconocido 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 del WebEx de Cisco. Mientras que usted podría extraer simplemente estos Certificados de un wireshark los rastrean y cargan por teletratamiento al almacén de certificados de confianza CA en Expressway, Expressway ofrecen un método más simple:

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

A este punto, cargan por teletratamiento a las autoridades de certificación del WebEx de Cisco a Expressway-e confiaban en el almacén CA (> Security (Seguridad) del mantenimiento > certificado 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 del WebEx de Expressway-e Cisco 

Como parte del apretón de manos mutuo de TLS, 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 CA del WebEx de Cisco, Expressway verifica que el certificado controlando el campo sujeto del nombre alterno (SAN) del certificado que se presenta para asegurar él tiene un valor tal como callservice.ciscoWebex.com presente. Si este valor no está presente, la llamada entrante falla. 

En este escenario particular, el presente del servidor del WebEx de Cisco su certificado a Expressway-e. El certificado tiene realmente 25 diferentes sin. Considere el caso donde Expressway-e controla el certificado para saber si hay callservice.ciscoWebex.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 el WebEx de Cisco presente su certificado, Expressway RSTs 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 del WebEx 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 TLS verifica que el asunto fuera 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.Webex.com"

Como usted puede ver en el ejemplo anterior TLS verifique que el asunto esté fijado a calllservice.Webex.com en vez de callservice.ciscoWebex.com. 

Solución

Para resolver este problema, TLS verifica que 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 del WebEx
• Fije TLS verifican el asunto a callservice.ciscoWebex.com
• Seleccione Save (Guardar).

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 del WebEx.

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

Como parte del apretón de manos mutuo de TLS, el WebEx de Cisco debe confiar en el certificado de Expressway-e. El WebEx de Cisco tiene una lista completa del público CAs que confíe en. Típicamente, un apretón de manos de TLS es acertado cuando su certificado de Expressway-e es firmado por un público CA que el WebEx de Cisco utilice. Por el diseño, Expressway-e envía solamente su certificado durante un apretón de manos de 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 certificados de confianza en Expressway-e sí mismo CA.

Si esta condición no se cumple, el WebEx 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. El WebEx de Cisco entonces rechaza este apretón de manos de TLS con un mensaje de error desconocido CA tal y como se muestra en de la imagen.

Solución

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

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

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 el apretón de manos mutuo frustrado de TLS. 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 decorado, 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.ciscoWebex.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 al WebEx de Cisco. Usted ve un TCP RST venir adentro de la dirección del WebEx 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 un público CA las confianzas de ese WebEx de Cisco?
• ¿El certificado de Expressway-e y Certificados está implicado en la firma del certificado de Expressway-e cargado por teletratamiento manualmente al concentrador del control del WebEx de Cisco (https://admin.ciscoWebex.com)? 

En estas condiciones determinadas, la solución no era utilizar el concentrador del control del WebEx de Cisco para manejar los Certificados de Expressway-e. Este medio el certificado de Expressway-e se debe firmar por un público CA las confianzas de ese WebEx de Cisco. 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 un público CA y que el encadenamiento lleno fue enviado al WebEx de Cisco. Por lo tanto, el problema no se debe relacionar con el certificado de Expressway-e.

A este punto, 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 el WebEx 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 del WebEx 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 el público CA pero el concentrador del control del WebEx de Cisco hace los Certificados alternos cargar

Esta condición determinada puede ocurrir a menudo cuando usted desplegó la solución de Expressway a partir de cero y usted no hace que el certificado de Expressway-e sea firmado por un público CA inicialmente. Qué sucede en este decorado es que usted carga por teletratamiento el certificado de servidor de Expressway-e (que se ha firmado internamente) al concentrador del control del WebEx 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 un público CA, no obstante usted olvida quitar el certificado de servidor del concentrador del control del WebEx de Cisco. Es importante conocer eso cuando un certificado se carga por teletratamiento al concentrador del control del WebEx de Cisco, ese certificado toma la prioridad sobre qué certificado y encadene los presentes de Expressway durante el apretón de manos de 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 el WebEx 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 un ese Cisco WebEx del público CA confía en. Abajo está una muestra de lo que usted puede esperar en Expressway-e que registra durante el apretón de manos de 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 del WebEx 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 un público CA que las confianzas del WebEx 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. Registre en el concentrador del control del WebEx 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. El desplazamiento al servicio de la llamada conecta la sección y la mirada conforme a los Certificados para el SORBO 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. Selecto quite.

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

Para más información sobre cargar por teletratamiento su certificado de Expressway-e en el concentrador del control del WebEx de Cisco, controle 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 del WebEx 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 del WebEx de Cisco.
2. Expressway-e examina el certificado del WebEx de Cisco para determinar si hay un nombre alterno sujeto que hace juego TLS verifica el asunto: callservice.ciscoWebex.com.
3. Expressway-e asocia la conexión hacia adentro a través de la zona de DNS del híbrido del WebEx 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 encamina según las reglas de búsqueda proporcionadas para los decorados interempresariales, si es interempresarial se configura en Expressway-e.

Como los otros decorados, usted debe utilizar el ambo el registro de diagnóstico y capturas de paquetes para determinar lo que parece este error, 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, el apretón de manos de 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 del WebEx 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 decorado donde Expressway-e no confía en el público CAs del WebEx 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 del WebEx y extensión de él para ver los nombres alternos sujetos (dnsName) que usted puede verificar para asegurarse que tenga callservice.ciscoWebex.com enumerara.

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

Esto confirma completamente que el certificado del WebEx parece apenas fino.

Usted puede ahora confirmar que TLS verifica que 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 TLS verifica que se haya configurado 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.ciscoWebex.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 del WebEx. El xConfiguration se puede leveraged para analizar esto también. En el xConfiguration TLS verifica que la correspondencia de entrada esté llamada CREMALLERA TLS DNS verifique 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 controla y se encamina según las reglas de búsqueda proporcionadas para los decorados 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 Save (Guardar).

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 del WebEx.

Las aplicaciones de Expressway-e del problema 7. omiten el certificado autofirmado

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 del valor por defecto puede ser utilizado. Algunas personas piensan que esto es posible porque el concentrador del control del WebEx 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 por teletratamiento (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 por teletratamiento sus los propio. Si usted utiliza sus los propio, asegúrese que los hostname estén en un dominio verificado.” El pedazo dominante a esa declaración es “se asegura de que los hostname están 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 originara por las en-premisas llame por teléfono, usted puede contar con que el app del WebEx de Cisco no suene. También, si usted intentara rastrear 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 del WebEx 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. A este punto, usted puede zambullirse en el registro 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 el apretón de manos mutuo de TLS inmediatamente después del cual sucede. Como usted puede ver en el recorte 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 a una mirada más atenta la captura de paquetes proporcionada el registro de diagnóstico de Expressway-e, usted puede ver que el Error desconocido del certificado está consiguiendo originario de la dirección del WebEx de Cisco tal y como se muestra en de la imagen.

Si usted examina el certificado de servidor del valor por defecto de Expressway-e, usted puede ver que el “nombre común” 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. 

A este punto, 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 que el certificado de Expressway-e sea firmado por un público CA las confianzas de ese WebEx 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 y asegúrese de que el campo de nombres alternativo adicional contenga el dominio verificado enumerado en el concentrador del control del WebEx.
   5. El tecleo genera el CSR.
   6. Proporcione al CSR a un público CA de las de otras compañías 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 por teletratamiento al lado de selecto el fichero de certificado de servidor, selecto elige el fichero y selecciona el certificado firmado.
   9. Seleccione los datos del certificado de servidor de la carga por teletratamiento.
   10. Navegue al > Security (Seguridad) del mantenimiento > confiaba en el certificado CA.
   11. En la sección de la carga por teletratamiento al lado selecta del fichero que contiene los Certificados CA de confianza selectos elija el fichero.
   12. Seleccione cualquier raíz y Certificados CA intermedio proporcionados por el público CA.
   13. Selecto añada el certificado CA al final del fichero.
   14. Recomience Expressway-e.
2. Haga que el certificado de Expressway-e sea firmado por un CA interno y después cargue por teletratamiento el CA interno y Expressway-e al concentrador del control del WebEx 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 del WebEx
   5. El tecleo genera el CSR
   6. Proporcione al CSR a un público CA de las de otras compañías 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 por teletratamiento al lado de selecto el fichero de certificado de servidor, selecto elige el fichero y selecciona el certificado firmado
   9. Seleccione los datos del certificado de servidor de la carga por teletratamiento
   10. Navegue al > Security (Seguridad) del mantenimiento > confiaba en el certificado CA
   11. En la sección de la carga por teletratamiento al lado selecta del fichero que contiene los Certificados CA de confianza selectos elija el fichero.
   12. Seleccione cualquier raíz y Certificados CA intermedio proporcionados por el público CA.
   13. Selecto añada el certificado CA al final del fichero.
   14. Recomience Expressway-e.

 2a. Cargue por teletratamiento el CA y el certificado internos de Expressway-e al concentrador del control del WebEx de Cisco
       1. Registre en el concentrador del control del WebEx 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 sección cifrada de las llamadas del SORBO seleccione la carga por teletratamiento.
       5. Elija los Certificados internos CA y de Expressway-e.

Entrante: WebEx de Cisco a las En-premisas

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

Flujo de alto nivel de la lógica

1. El partido de llamada del app del WebEx de Cisco inicia la llamada
2. Anillos del app de la Parte llamada
3. La llamada se bifurca al entorno del WebEx de Cisco
4. El entorno del WebEx de Cisco debe realizar una búsqueda de DNS basada en el destino configurado del SORBO del cliente en el concentrador del control del WebEx de Cisco
5. El entorno del WebEx de Cisco intenta conectar con Expressway sobre el puerto 5062
6. El entorno del WebEx de Cisco intenta realizar un apretón de manos mutuo de TLS
7. El entorno del WebEx 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. El WebEx de Cisco y la empresa completan la negociación del SORBO
9. El WebEx de Cisco y la empresa comienzan a enviar y a recibir los media.

Flujo de llamada

Navegue al app del WebEx de Cisco > al entorno del WebEx 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 del WebEx a la infraestructura de las en-premisas.

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

Al pensar en el WebEx de Cisco a las en-premisas llame el flujo, paso lógico del WebEx de Cisco el primer es cómo entrar en contacto con las en-premisas Expressway. Según lo observado arriba, el WebEx 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 del WebEx 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 del WebEx 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 del WebEx de Cisco. 

Si ésta es la situación, usted debe controlar cómo el destino del SORBO fue configurado en el concentrador del control del WebEx 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 controla si hay un direccionamiento de los DN válidos, si el WebEx 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 las confianzas de ese WebEx de Cisco. 

1. Registro en el concentrador del control del WebEx 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 un 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 hostname que resuelva a la dirección IP pública 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. Registre en el concentrador del control del WebEx 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 SIP SRV del público en el Campo Destination SIP. 
   5. Seleccione Save (Guardar).

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 del descubrimiento del SORBO en el concentrador del control del WebEx de Cisco, y por lo tanto de 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 del WebEx de Cisco.

Solución alternativa

Si el cliente no tiene un presente de registro del SORBO SRV (y no planea crear uno), pueden enumerar alternativamente la dirección IP pública de Expressway añadida como sufijo por el ":5062". De esta manera, el entorno del WebEx 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. Registre en el concentrador del control del WebEx 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 Save (Guardar).

Para más información sobre el direccionamiento de 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 del WebEx de Cisco o de la guía de diseño del híbrido del WebEx 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 del WebEx 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 la dirección IP pública de las en-premisas Expressway-e. Si el entorno del WebEx 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 del WebEx 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 del WebEx 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 del WebEx 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 controla 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 del WebEx de Cisco y simula el entorno del WebEx 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 del WebEx 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 controlar 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 del WebEx de Cisco o el equipo de la Colaboración de las en-premisas, usted necesita centrarse en la configuración del Firewall. 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 decorado a Expressway” arriba. Usted encontrará que la herramienta de prueba de conectividad híbrida y cualquier otra herramienta usadas para controlar 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á el registro con minuciosidad de diagnóstico de Expressway-e para determinar si ella puede ver la conexión TCP el intentar establecer. Ella general buscará un item 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 puestas 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 del Firewall. 

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 - | 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 tipo SORBO y el puerto 5062 IP. (destacado 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 - | 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á activado 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 utiliza las encabezados cargadas de la ruta del SORBO

Con la llamada híbrida mantenga conectan, la encaminamiento de la llamada 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 el WebEx. El host del conector de Expressway pregunta el cm unificado para los usuarios que se activan para el servicio de la llamada y tiran de su directorio URI y del racimo FQDN de su racimo 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 encamina a sus en-premisas unificadas cm para poderla asegurar a su Cisco WebexRD antes de encaminar hacia fuera al usuario llamado.

Si Alicia llamara a Bob, la llamada encaminaría al racimo unificado FQDN (us-cucm.example.com) del hogar cm de Alicia. Si usted analzye que el SORBO INVITA que el WebEx 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 encaminar la llamada no por la petición URI pero bastante la encabezado de la ruta (us-cucm.example.com) -- en el racimo unificado del hogar cm de esta Alicia del casem.

Con este conjunto de la fundación, usted puede entender las situaciones del Troubleshooting donde las autopistas misconfigured, 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 el partido de llamada enumerado como “<sip del último nombre del primer nombre”: WebexDisplayName@subdomain.call.ciscoWebex.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 del partido de llamada, o del direccionamiento del SORBO del WebEx de Cisco del partido de llamada. 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 encaminada que lejos. Si es así usted querrá probablemente comenzar su investigación allí.

En este decorado, 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.ciscoWebex.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 (racimo 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 (racimo 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 decorado de trabajo, usted vería que en el decorado de trabajo el lógica de la búsqueda se está realizando basada en la encabezado del router (racimo 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.ciscoWebex.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 Webex' 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.ciscoWebex.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ó la ayuda 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 pongan 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 disposició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 7003 del SORBO TCP.

El pedazo dominante para el servicio híbrido de la llamada es que debe haber cargado la ayuda de las rutas del SORBO encendido. La interfaz Web de Expressway llama esta ayuda cargada valor de las rutas del SORBO mientras que el xConfiguration la 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 del WebEx) 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: "Webex 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 del WebEx. 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ó la ayuda 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 del WebEx de Cisco, este valor se debe fijar a encendido.

Además, si controlamos la definición de la ayuda cargada 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: “Apague la ayuda cargada de las rutas del SORBO 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"

A este punto, usted ha aislado el problema a un misconfiguration de la configuración de la zona del cliente del Traversal de Expressway-C. Usted debe cambiar la ayuda cargada de las rutas del SORBO a encendido.

Solución

Para fijar correctamente la ayuda cargada 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 la ayuda cargada de las rutas del SORBO a encendido
5. Seleccione Save (Guardar).

Note: Mientras que este decorado demostró el error en Expressway-C, los mismos errores de registro de diagnóstico se podrían observar en Expressway-e si la ayuda cargada de las rutas del SORBO estaba apagado en la zona híbrida del servidor del Traversal de la llamada del WebEx. 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 del WebEx de Cisco del problema 5. está recibiendo dos notificaciones de la llamada (las tostadas)

Este problema determinado sucede ser el único decorado 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 del WebEx de Cisco de la persona que había puesto la llamada (partido de llamada). La primera notificación se genera del WebEx 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 (partido de llamada) del lado del WebEx de Cisco. El en este caso identificación de llamada es el nombre de la visualización del usuario que inicia esa llamada. La segunda notificación (tostada) está viniendo del encendido presupone el WebEx 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 del WebEx 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 del WebEx 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 CTI-RD o WebEx RD de Cisco. Por lo tanto, cuando la llamada se ofrece al CTI-RD o al WebEx RD de Cisco, se envía la llamada se retira al WebEx de Cisco porque el dispositivo tiene un destino remoto configurado para bob@example.call.ciscoWebex.com. La manera que el WebEx de Cisco maneja esta situación es que cancela el tramo de llamada determinado. 

Para que el WebEx de Cisco cancele correctamente el tramo de llamada, el WebEx 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 del WebEx 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, el WebEx de Cisco no entiende cómo cancelar la llamada. 

Con esta información, usted puede revisitar el decorado presentado anterior donde el app del WebEx de Cisco del usuario recibía dos notificaciones (tostadas) cuando el usuario Jonatán Robb del WebEx 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 SORBO INVITA de hecho hace que el valor call-type=squared presente en la encabezado del contacto del WebEx 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 recorte de la muestra de venir de la INVITACIÓN entrante a Expressway-e de este decorado.

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   <-- Webex inserted value
 From: "Jonathan Robb" <sip:jorobb@dmzlab.call.ciscoWebex.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. A este punto, la llamada se debe encaminar con Expressway y enviar fuera de la zona híbrida del servidor del Traversal del WebEx. Podemos buscar los registros de Expressway-e para determinar cómo la llamada fue enviada de 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>     <-- Webex inserted value is now missing
From: "Jonathan Robb" <sip:jorobb@dmzlab.call.ciscoWebex.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 del WebEx 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 encaminar con el Traversal híbrido del servicio de la llamada que usted pone 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: En
• Modo de ParameterPreservatoin del SORBO: De

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

Ayuda cargada de las rutas del SORBO

La ayuda cargada conmutador de las rutas del SORBO encendido para permitir a esta zona procesar el SORBO INVITA a las peticiones que contienen la encabezado de la ruta.

Apague la ayuda cargada de las rutas del SORBO si usted quisiera que la zona rechazara el SORBO INVITA a las peticiones que contienen esta encabezado.

SORBA la preservación del parámetro

Saliente: En-premisas al WebEx de Cisco

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

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/Webex-RD validan la llamada
3. El teléfono de las en-premisas del usuario B comienza a los anillos
4. CTI-RD/Webex-RD del usuario B bifurca esto dice en voz alta al destino de UserB@example.call.ciscoWebex.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.ciscoWebex.com
8. Expressway-e intenta conectar con el entorno del WebEx de Cisco sobre el puerto 5062.
9. Expressway-e y el entorno del WebEx de Cisco comienzan un apretón de manos mutuo
10. El entorno del WebEx de Cisco pasa la llamada sobre el app disponible del WebEx de Cisco del usuario B
11. El app disponible del WebEx de Cisco del usuario B comienza a sonar.

Flujo de llamada

Navegue al usuario B en-prem el teléfono > unificado cm > CTI-RD/Webex-RD > Expressway-C > Expressway-e > entorno del WebEx de Cisco > app del WebEx 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 del WebEx de Cisco.

Extremidades del análisis del registro

Si usted resolviera problemas una situación donde las llamadas bifurcadas salientes al WebEx 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 el WebEx 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 un direccionamiento de destino del SORBO URI del WebEx que debe ser llamado (user@example.call.ciscoWebex.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 del WebEx
2. El SORBO del campo será formatado para tener el partido de llamada enumerado 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 del partido de llamada, el nombre y apellido del partido de llamada, o el direccionamiento del SORBO del WebEx 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 del WebEx de Cisco cuando la llamada se hace a un usuario que se active para el servicio de la llamada conecte.

El problema 1. Expressway no puede resolver el direccionamiento de callservice.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 el apretón de manos mutuo de TLS que ocurre sobre el puerto 5062 y un puerto separado se utiliza para señalar entre Expressway y el WebEx de Cisco. El desafío con esto es que el Guía de despliegue para los servicios híbridos de la llamada del WebEx 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 a 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.com), el ID de llamada (991f7e80-9c11517a-130ac-1501a8c0), de (“Jonatán Robb” <sip:5010@rtp.ciscotac.net>), a (sorbo: pstojano-test@dmzlab.call.ciscoWebex.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 encaminar 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.ciscoWebex.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 'Webex 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.ciscoWebex.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 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscoWebex.com'"

De acuerdo con el recorte del registro arriba, usted puede ver que Expressway-e analizado con cuatro reglas de búsqueda, no obstante solamente una (híbrido del WebEx - a la nube del WebEx) 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.ciscoWebex.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.ciscoWebex.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 recorte 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.ciscoWebex.com) y ha resuelto a un hostname de l2sip-cfa-01.wbx2.com y del puerto 5061. Las resoluciones de l2sip-cfa-01.wbx2.com del hostname 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 recorte 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 5061 TCP 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 5062 TCP, 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 del WebEx 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: "ciscoWebex.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.ciscoWebex.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 del WebEx 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 URI saliente SIP. 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 del WebEx 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.ciscoWebex.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 recorte 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.ciscoWebex.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 del WebEx 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.ciscoWebex.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 al WebEx de Cisco

Una cosa que es única sobre los errores bifurcados de la llamada de salida al WebEx de Cisco es que el app del WebEx de Cisco de la Parte llamada presentará un botón del unido en su app aunque el cliente nunca suene. Como el decorado 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 el registro 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 el apretón de manos mutuo de TLS 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 'Webex 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.ciscoWebex.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 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscoWebex.com'"

De acuerdo con el recorte del registro arriba, usted puede ver que Expressway-e analizado con cuatro reglas de búsqueda sin embargo solamente una (híbrido del WebEx - a la nube del WebEx) 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.ciscoWebex.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.ciscoWebex.com SRV se resuelve. La respuesta es cuatro diversos expedientes válidos que utilizan el puerto 5062. Esto es normal. A este punto, 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 decorado:

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 manojo 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.

A este punto, usted puede concluir que Expressway-e está encaminando la llamada correctamente. El desafío en este decorado es que una conexión TCP no se puede establecer con el entorno del WebEx. Esto podría suceder porque el entorno del WebEx 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 decorado 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 temas relacionados más grandes de la configuración en las autopistas. Los problemas de la 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 del WebEx de Cisco del usuario llamado presentado se une al botón
• El teléfono de llamada repetía un anillo
• El teléfono de las en-premisas del usuario llamado sonaba
• El app del WebEx de Cisco del usuario llamado nunca sonó

Como todos los otros decorados, usted también querrá leverage los rastros 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, era resuelta 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 al WebEx 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 el direccionamiento de destino. Puesto que las reglas de búsqueda del uso de las autopistas para encaminar 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 del WebEx. 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 primera creada que era marcada 1. Si usted está teniendo problema que encuentra la regla de búsqueda. usted puede utilizar los valores de nombramiento de uso general tales como “WebEx” 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 “. *@.* \ .ciscoWebex \ .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 decorado, usted puede ver que la regla de búsqueda 6 es la regla correcta para pasar el decir en voz alta al WebEx de Cisco.

*c xConfiguration Zones Policy SearchRules Rule 6 Authentication: "No"
*c xConfiguration Zones Policy SearchRules Rule 6 Description: "Outbound calls to Webex"
*c xConfiguration Zones Policy SearchRules Rule 6 Mode: "AliasPatternMatch"
*c xConfiguration Zones Policy SearchRules Rule 6 Name: "Webex Hybrid - to Webex 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: ".*@.*\.ciscoWebex\.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.ciscoWebex.com)
• Tipo del modelo: Regex
• Cadena del modelo. *@.* \ .ciscoWebex \ .com
• Comportamiento del modelo: Salir

Si el Regex para la regla está correcto puesto, 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.ciscoWebex.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 'Webex 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 del WebEx fue nombrado Webex Hybrid - a la nube y a ella del WebEx ni siquiera era considerado en esta lógica de la regla de búsqueda arriba. A este punto, vale el mirar en cómo la regla considerada de búsqueda (al DNS) fue aplicada de modo que usted pueda entender mejor si está afectando el uso de la regla de búsqueda híbrida del WebEx. 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 del WebEx 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 del WebEx 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. Abajo está 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á eso pasado. 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 al “híbrido del WebEx - las reglas a la nube del WebEx”. 

*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: "Webex Hybrid - to Webex 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 “híbrido del WebEx - la regla a la nube del WebEx” -- 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 del WebEx - a la regla de la nube del WebEx y a 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 del WebEx 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 él da lugar a un error. Este problema sucede en entrante y las llamadas de salida al WebEx 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 del WebEx y hágala clic (ex: Nombre: Híbrido del WebEx - a la nube del WebEx)
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 fija que el tipo de regla de búsqueda a un prioritario él ha invocado tan por ú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 del WebEx de Cisco y móvil y Acceso Remoto, recomendamos fuertemente que la directiva y las reglas COMPLETAS están activadas y aplicadas. Mientras que la configuración COMPLETA en Expressway para el híbrido del WebEx de Cisco es bastante directa, si está misconfigured le puede bloquear fácilmente los intentos de llamada del suceso. Los decorados 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 del WebEx de Cisco del usuario llamado presentó un botón del unido
• El teléfono de llamada repetía un anillo
• El teléfono de las en-premisas del usuario llamado sonaba
• El app del usuario llamado nunca sonó

Como todos los otros decorados, usted puede utilizar los rastros 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, era resuelta 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.ciscoWebex.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.ciscoWebex.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.ciscoWebex.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 recorte 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\.ciscoWebex\.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.ciscoWebex.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 activa 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 abrirse una 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 \ .ciscoWebex \ .com.*

Acción: Rechazo

Comparado a qué se documenta en la guía híbrida de la instrumentación del servicio de la llamada del WebEx 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. *@%Webex_subdomain% \ .call \ .ciscoWebex \ .com.* y el modelo del destino 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 del WebEx de Cisco
4. Ingrese el modelo de la fuente como. *@%Webex_subdomain% \ .call \ .ciscoWebex \ .com.* (ex:. *@dmzlab \ .call \ .ciscoWebex \ .com.*)
5. Ingrese el modelo del destino como. *
6. Seleccione Save (Guardar).

Para más información sobre la puesta en práctica COMPLETA para el híbrido del WebEx refiera a la guía de diseño del híbrido del WebEx de Cisco. 

Bidireccional: WebEx de Cisco a las En-premisas o a las En-premisas al WebEx de Cisco 

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

El servicio híbrido de la llamada conecta las ayudas tres diverso Códecs de audio: G.711, G.722, y AAC-LD. Para establecer con éxito una llamada con el entorno del WebEx 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 la aduana y/o omitir las configuraciones de la región 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. El WebEx de Cisco envía un entrante INVITA con el SDP que ofrece G.711, G.722, o AAC-LD. Expressway-C envía este mensaje cm unificado pero el cm unificado se configura para permitir solamente G.729 para esta llamada. Así pues, unificado cm rechazará la llamada debido a ningún codificador-decodificador disponible.
2. El cm unificado intenta la llamada de salida como temprano ofrece a Cisco el WebEx que significa que la inicial INVITA enviado a Expressway-C contendrá el SDP que utiliza SOLAMENTE el audio de G.729. El WebEx de Cisco entonces manda una AUTORIZACIÓN 200 con el SDP ese los ceros el audio (m=audio 0 RTP/SAVP) porque no utiliza 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 al WebEx de Cisco que significa que la inicial INVITA enviado a Expressway-C no contendrá el SDP. El WebEx de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP que contiene todas las ayudas utilizadas del WebEx de Cisco del Códecs de audio. Expressway-C envía esto 200 la AUTORIZACIÓN cm unificado pero el cm unificado se configura solamente para permitir solamente G.729 para esta llamada. Así pues, unificado cm rechazará la llamada debido a ningún codificador-decodificador disponible.

Si usted está intentando identificar un servicio híbrido de la llamada conecte el error de la llamada que hace juego este problema, usted debe conseguir Expressway abre una sesión los rastros unificados cm SDL de la adición. Los recortes 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 ofrecen. Porque sabemos que la llamada está saliendo al WebEx de Cisco, el análisis del registro comienza en Expressway-e.

Abajo está un recorte de la inicial INVITA hacia fuera al WebEx de Cisco. Usted puede ver que el códec de audio preferido está fijado a G.729 (payload 18). Los 101 está para 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.ciscoWebex.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.ciscoWebex.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, WebEx 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.ciscoWebex.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 *      <-- Webex 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.ciscoWebex.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 del WebEx 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 al WebEx de Cisco y

b) cuál era el WebEx de Cisco de la lógica usado 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 del WebEx 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 los codificadores-decodificador específicos se utilizan que. Allí veríamos esto:

El WebEx de Cisco utiliza los codificadores-decodificador siguientes:

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

Nota: El opus no se utiliza en encendido la pierna de la premisa de la llamada para la llamada híbrida del WebEx de Cisco. 

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 el WebEx 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 la región entre el WebEx RD de Cisco que está asegurando las en-premisas de la llamada y el tronco del SORBO para Expressway-C. Para hacer así pues, determine en qué agrupación de dispositivos están esos dos elementos. La agrupación de dispositivos contiene las asignaciones a las regiones. 

Para determinar a la agrupación de dispositivos del tronco del SORBO de Expressway-C:

1. Registro en el cm unificado
2. Vaya a Device >Trunk (Dispositivo > Enlace troncal)
3. Busque para el nombre del tronco o haga clic el hallazgo
4. Seleccione el tronco 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 de Cisco WebEx-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 el WebEx 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 tronco 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 WebEx-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

A este punto, si usted identifica la relación que está utilizando G.729, usted necesitará ajustar la relación para utilizar del Códecs de audio utilizado que el WebEx de Cisco utiliza o utiliza a una diversa agrupación de dispositivos que tenga una región que utilice esto. En el decorado documentado arriba, lo que sigue era resuelto:

Región del tronco de Expressway-C: ReservingBandwidth

Región WebEx-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 tronco 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 tronco de Cisco WebEx-RD y de Expressway-C era RTP-dispositivos y RTP-infraestructura. Según lo representado arriba, usted puede ver las ayudas AAC-LD de esta relación que es uno del Códecs de audio utilizado para el WebEx de Cisco y así que la llamada pondrá 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 encargado de las Comunicaciones unificadas de Cisco (unificado cm), 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 mejoras. Con este todo el dijo, los clientes que están actualizando sus más viejas versiones del cm unificado para utilizar 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 es demasiado bajo.

Si usted está intentando identificar un servicio híbrido de la llamada conecte el error de la llamada que hace juego este problema, usted debe conseguir Expressway abre una sesión los rastros unificados cm SDL de la adición. Para identificar el error, primero entienda qué sucede y entonces los tipos de decorados 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. El WebEx 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 al WebEx que significa que la inicial INVITA enviado a Expressway-C contendrá el SDP. El WebEx de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP en la respuesta y la respuesta de 200 AUTORIZACIONES cuando está pasado 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 al WebEx que significa que la inicial invita enviado a Expressway-C no contendrá el SDP. El WebEx de Cisco entonces envía una AUTORIZACIÓN 200 con el SDP y la oferta ACEPTABLE 200 cuando está pasado 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 determinada le ayuda a entender el flujo del mensaje. Si usted utilizara un programa como TranslatorX, usted podría ver a EE que Expressway-C está pasando la AUTORIZACIÓN del WebEx 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 los rastros SDL para ver cómo el cm unificado está manejando esta condición. Qué usted encontraría en este decorado es que el cm unificado ignora el mensaje grande de Expressway-C. Un item 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, el WebEx 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="%Webex_IP%" Src-port="5062" Msg-Hash="2483073756671246315"
SIPMSG:
SIP/2.0 603 Decline

Según lo mencionado, hay tres diversos decorados 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 al WebEx 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 encargado de llamada
4. Elija el servicio del encargado de llamada de Cisco cuando está incitado 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 Save (Guardar).
8. Relance este proceso para cada nodo unificado cm que esté funcionando con el servicio del encargado de llamada de Cisco.

Note: Para que una punto final del teléfono, de la Colaboración IP, y/o el tronco 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: Expressway que resuelve problemas las herramientas

Controle la utilidad del modelo

Expressway tiene un modelo que controla 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 racimo unificado FQDN cm va a hacer juego la cadena del modelo esa usted puso para el racimo unificado FQDN cm. Al usar esta utilidad, recuerde que la llamada encaminará basado en el parámetro unificado del racimo 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.ciscoWebex.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 racimo cm
3. Fije el tipo del modelo para prefijar
4. Fije el racimo unificado FQDN cm de la cadena 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 encamina 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 encaminar 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 a 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 encaminar una llamada basada en el racimo unificado FQDN cm encontrado en la encabezado de la ruta del SORBO.

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

En la parte inferior del interfaz, usted ahora verá los resultados de 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 encaminado (verdad)
• Información fuente (nombre de zona/tipo)
• Información de destino (alias siendo encaminado)
• 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 pone 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, DEPURACIÓN, RASTRO. 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 PONER A PUNTO 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 los apretones de manos (mutuos) de TLS.

1. Registre en Expressway el servidor (debe ser hecho en Expressway-e y C)
2. Navegue al mantenimiento > a los diagnósticos > avanzó > configuración del registro de la ayuda
3. Desplazamiento al módulo que usted quisiera ajustar, al en este caso developer.ssl y hacerlo clic.
4. Al lado del parámetro llano, elija la DEPURACIÓN del menú
5. Haga clic en Save (Guardar).

A este punto, 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 mantenimiento > a los diagnósticos > registro de diagnóstico
3. Haga clic el nuevo registro del comienzo (nota: Asegúrese que usted controle la opción del tcpdump)
4. Reproduzca el problema
5. Haga clic el registro de la parada
6. Haga clic el registro de la transferencia directa

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 manojo 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 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 del WebEx de Cisco
• Guía de diseño del híbrido del WebEx de Cisco
• Guía de administrador de Cisco Expressway
• Soporte Técnico y Documentación - Cisco Systems