Guide de dépannage pour Hybrid Call Service Connect de Cisco Webex

Introduction

Ce document décrit la solution Cisco Webex Hybride Call Service Connect, qui permet à votre infrastructure actuelle de contrôle des appels de Cisco de se connecter au nuage Cisco Collaboration Cloud de façon à ce qu’ils puissent fonctionner ensemble.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Connaissance de l’offre Cisco Webex
• Connaissance de la solution Expressway (B2B)
• Connaissance de Cisco Unified Communications Manager (Unified CM) et de son intégration dans Expressway
• Unified CM 10.5 (2) SU5 ou versions ultérieures.
• Expressway (B2B) version X8.7.1 ou ultérieure (la version X8.9.1 est recommandée)
• Expressway (Connector Host) — Voir Prise en charge des hôtes de connecteur Expressway pour les services hybrides Cisco Webex pour les versions actuellement prises en charge

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Solutions Cisco Unified Communications Manager
• Expressways
• Webex pour Windows
• Webexfor Mac
• Webexfor iOS
• Webex pour Android
• Terminaux de collaboration de Cisco
• Terminaux de collaboration de bureau
• Téléphones IP
• Clients logiciels
  
  

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

La solution offre les fonctionnalités suivantes :

• Utiliser l'application Webex comme client logiciel mobile pour les appels audio et vidéo
• Utiliser l’application pour passer et recevoir des appels n’importe où, comme au bureau
• Utiliser Webex, Cisco Jabber ou leur téléphone de bureau pour appeler, sans avoir à se soucier de l'option qu'ils utilisent
• Déverrouiller l'historique des appels sur les téléphones sur site et intégrer cet historique dans Webex

Ce guide porte sur les problèmes qui sont uniques à la solution Hybride Call Service Connect. Étant donné que Hybrid Call Service Connect fonctionne sur la même paire Expressway E & C que d’autres solutions telles que Mobile and Remote Access et Business to Business, les problèmes avec les autres solutions peuvent affecter Hybrid Call Service Connect. Pour les clients et partenaires qui déploient une paire Expressway pour une utilisation avec Call Service Connect, le guide de configuration de base de Cisco VCS Expressway et VCS Controldoit être consulté avant toute tentative de déploiement de Hybrid Call Service Connect. Ce guide de dépannage couvre les considérations relatives au pare-feu/NAT ainsi que la conception d’Expressway dans les annexes 3 et 4. Examinez attentivement cette documentation. En outre, ce document se fonde sur la supposition que l’activation de l’hôte connecteur Expressway et des services hybrides Hybrid Call Service a été effectuée. 

Problèmes de configuration des appels

Échecs du protocole de prise de contact mutuelle TLS

Hybrid Call Service Connect fait appel à des mesures de sécurité de couches de transport (TLS mutuelle) pour les démarches d’authentification entre Cisco Webex et Expressway-E. Cela signifie qu’Expressway-E et Cisco Webex vérifient et examinent le certificat présenté par l’autre. Étant donné que les problèmes de TLS mutuels sont très répandus lors des nouveaux déploiements des serveurs Expressway et de l’activation de solutions telles que Hybrid Call Service Connect, cette section fournit des informations et des conseils utiles pour le dépannage des problèmes basés sur des certificats entre les Expressways et Cisco Webex.

Que vérifie Expressway-E?

• Est-ce que le certificat Cisco Webex a été signé par une CA publique qui est répertoriée dans la liste de CA de confiance d’Expressway-E?
• Est-ce que callservice.ciscospark.com apparaît dans le champ de l’autre nom du sujet du certificat Cisco Webex?

Que vérifie Cisco Webex?

• Est-ce que le certificat d’Expressway-E a été signé par l’une des CA publiques réputées fiables par Webex? (Liste des CA de confiance de Cisco Webex)
• Si l’Expressway-E n’utilise pas un certificat signé de façon publique, est-ce que le certificat d’Expressway et les éventuels certificats racines et intermédiaires ont été téléchargés vers le concentrateur Cisco Webex Control Hub (https://admin.ciscospark.com)?

Cela s’explique comme l’illustre l’image.

Conseils utiles de dépannage pour la prise de contact mutuelle TLS

1. Décoder la prise de contact mutuelle TLS

Par défaut, Wireshark marque le trafic TLS de SIP comme le port 5061. Cela signifie que chaque fois que vous voulez analyser une connexion TLS (mutuelle) qui se produit sur le port 5062, Wireshark ne saura pas comment décoder correctement le trafic. Voici un exemple de processus de prise de contact mutuelle sur le port 5062, comme l’illustre l’image.

Vous pourrez observer de quelle façon une prise de contact mutuelle se présente dans Wireshark. Le paquet numéro 175 est le certificat qu’Expressway envoie à Cisco Webex. Cependant, vous ne pouvez pas le déterminer sans que le trafic soit décodé. Il y a deux méthodes possibles pour décoder ce trafic afin que vous puissiez plus facilement visualiser l’information des certificats et les messages d’erreur susceptibles de se présenter.

1 bis. Décoder le flux en tant que SSL

a. Lorsque vous analysez la prise de contact mutuelle de TLS, dans un premier temps, filtrez la capture par tcp.port==5062. Après cela, cliquez avec le bouton droit sur le premier paquet du flux et sélectionnez Décoder sous... comme le montre l'image.

b. Une fois le Decode As... est sélectionnée, vous voyez une liste dans laquelle vous pouvez sélectionner comment décoder le flux que vous avez sélectionné. Dans la liste, sélectionnez SSL, cliquez sur Apply et fermez la fenêtre. À ce stade, l’ensemble du flux montre le certificat et les messages d’erreur échangés au moment de la prise de contact, comme l’illustre l’image.

1 ter. Modifier le port TLS de SIP

Lorsque vous modifiez le port SIP de TLS pour qu’il porte le numéro 5062 dans les préférences de Wireshark, vous pouvez ensuite consulter tous les détails de la prise de contact, y compris les certificats. Afin de faire cette modification :

• Ouvrez Wireshark
• Naviguez jusqu’à Edit > Preferences
• Dans les protocoles, choisissez SIP
• Définissez le port TLS de SIP comme 5062, puis cliquez sur Appliquer
• Remplacez la valeur par 5061 lorsque l'analyse est terminée, comme le montre l'image.

Si vous analysez maintenant la même capture, vous verrez que les paquets 169 à 175 sont décodés. Le paquet 175 montre le certificat d’Expressway-E. Si vous analysez le paquet, vous pouvez voir tous les détails de certificat, comme l’indique l’image.

2. Filtre Wireshark

Lorsque vous analysez les captures de paquets, il est facile de se perdre parmi les nombreux paquets observés dans une capture donnée. Il est important de comprendre quel type de trafic vous intéresse le plus, afin que vous puissiez appliquer un filtre Wireshark pour qu’il affiche seulement ce que vous souhaitez consulter. Voici certains des filtres Wireshark courants qui peuvent vous permettre d’obtenir de plus amples renseignements sur une prise de contact mutuelle de TLS :

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

3. Extrayez le certificat de Pcap

De temps à autre, vous devrez peut-être obtenir une copie d'un certificat (serveur, racine ou intermédiaire). Si vous ne connaissez pas où trouver le certificat que vous êtes dans recherchez, vous pouvez le extraire directement à partir de une saisie de paquets. Voici les étapes à suivre pour obtenir le certificat de Cisco Webex qui est présenté lors d’une prise de contact mutuelle de TLS.

1. Filtrer la capture de paquets avec ssl.handshake.certificate & & tcp.port==5062
2. Repérez le paquet qui provient de l’adresse de serveur de Webex. Le certificat apparaît dans la section de l’information.
3. Dans les détails du paquet, développez Secure Socket Layer > TLS Certificate > Handshake Protocol > Certificates.

   Note: Le dernier certificat (en bas) de la chaîne de certificats provient de l’autorité de certification racine.

4. Cliquez avec le bouton droit sur le certificat d'intérêt et sélectionnez Exporter les octets de paquets sélectionnés... comme le montre l'image.

5. Enregistrez le fichier sous le format .cer.

6. Cliquez deux fois sur le fichier enregistré pour ouvrir le certificat, comme l’indique l’image.

4. Réglez les niveaux de journalisation d’Expressway

Deux modules de journalisation sont disponibles sur Expressway. Ils peuvent vous aider à mieux comprendre la logique qu’applique Expressway lorsque vous analysez les certificats :

• developer.ssl
• developer.zone.zonemg
  
  

Par défaut, ces modules de journalisation sont réglés à un niveau d’information (INFO). Lorsque les modules sont définis selon un niveau de débogage (DEBUG), vous pouvez consulter les renseignements concernant l’inspection de certificat qui se déroule, de même que de l’information sur le trafic de zone cartographié. Ces deux fonctions sont pertinentes pour Hybrid Call Service. 

Un exemple de l’Expressway-E qui effectue une inspection SAN du certificat de serveur de Cisco Webex.

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

Exemple d’Expressway-E mappant la connexion MTLS à la zone DNS hybride Cisco Webex :

2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1226)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectName" Thread="0x7f577f0a0700":  this="0x56408ff81220" getDNSZoneByTLSVerifySubjectName classified subject name callservice.ciscospark.com into DNS zone Hybrid Call Services DNS
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1183)" Method="ZoneManager::getDNSZoneByTLSVerifySubjectNameList" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="Searched for DNS Zones by Subject Name" Found="True" Candidates="l2sip-cfa-01.ciscospark.coml2sip-cfa-01.ciscospark.coml2sip-cfa-01.wbx2.coml2sip-cfa-01-web.wbx2.coml2sip-cfa-web.wbx2.comcallservice.ciscospark.com" MatchedZone="Hybrid Call Services DNS" MatchedIdentity="callservice.ciscospark.com"
2017-09-22T11:11:19.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-22 15:11:19,564" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(1054)" Method="ZoneManager::getZoneByIdentities" Thread="0x7f577f0a0700":  this="0x56408ff81220"  Detail="getZoneByIdentities, match complete" Identitites="{CN: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.ciscospark.com, Alt-DNS: l2sip-cfa-01.wbx2.com, Alt-DNS: l2sip-cfa-01-web.wbx2.com, Alt-DNS: l2sip-cfa-web.wbx2.com, Alt-DNS: callservice.ciscospark.com, Alt-DNS: callservice.call.ciscospark.com, Alt-DNS: l2sip-a-Webexcall.ciscospark.com, Alt-DNS: l2sip-prod-11-dfw-public.wbx2.com, Alt-DNS: l2sip-prod-12-dfw-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-294-riad-public.wbx2.com, Alt-DNS: l2sip-l2sipproda1-817-riad-public.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpsjc-web.wbx2.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.ciscospark.com, Alt-DNS: l2sip-l2sip-prod-wpdfw-web.wbx2.com, Alt-DNS: l2sip-cfa-02.wbx2.com, Alt-DNS: Webexcmr-wpa.ciscospark.com, Alt-DNS: Webexcmr-wpb.ciscospark.com, Alt-DNS: Webexcmr-wpc.ciscospark.com, Alt-DNS: l2sip-wpa-01.wbx2.com, Alt-DNS: l2sip-wpa-02.wbx2.com, Alt-DNS: l2sip-wpb-01.wbx2.com, Alt-DNS: l2sip-wpb-02.wbx2.com, Alt-DNS: l2sip-wpc-01.wbx2.com, Alt-DNS: l2sip-wpc-02.wbx2.com}" MatchMechanism="DNSZoneMatch" MatchedZone="Hybrid Call Services DNS"

Voici une liste des problèmes les plus courants liés aux défaillances de TLS lors des processus mutuels entre l’Expressway-E et Cisco Webex. 

Problème 1. Expressway-E ne fait pas confiance à l’autorité de certification qui a signé le certificat Cisco Webex

Le serveur de Cisco Webex qui est en communication directe avec l’Expressway-E est appelé serveur L2SIP. Ce serveur L2SIP doit faire l’objet d’une signature d’autorisation par un serveur intermédiaire portant le nom courant de Hydrant SSL ICA G2. Le serveur intermédiaire doit faire l’objet d’une signature d’autorisation par une autorité de certification racine portant le nom courant de QuoVadis Root CA 2, comme l’indique l’image.

Note: Cela pourrait faire l’objet de modifications.

La première étape pour analyser ce trafic sous l’angle d’un diagnostic Expressway consiste à faire des recherches portant sur les connexions TCP : TCP Connecting. Une fois que vous aurez repéré TCP Connecting, cherchez la valeur Dst-port=5062 . Une fois que vous aurez cerné dans les journaux la zone où cette connexion a été tentée et établie, vous pourrez chercher à repérer la prise de contact mutuelle de TLS, qui apparaît généralement dans les entrées de journal qui indiquent que le processus est en cours (Handshake in progress).

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 l’Expressway-E ne tient pas les certificats de Cisco Webex signés pour des certificats fiables, il est fort probable que l’Expressway-E rejette le certificat tout de suite après l’achèvement du processus de prise de contact. Vous pourrez trouvé des traces de ces actions ans les journaux d’Expressway-E, en particulier dans ces entrées de journal : 

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"

Le message d’erreur d’Expressway peut induire légèrement en erreur car il fait référence à un certificat auto-signé dans la chaîne de certificats. Wireshark vous permet de regarder de plus près l'échange. Du point de vue de l’analyse de capture de paquets Wireshark, vous pouvez clairement voir que lorsque l’environnement Webex présente son certificat, Expressway se retourne et rejette avec un certificat avec une erreur de CA inconnue, comme le montre l’image.

Solution :

Afin de résoudre cette situation, vous devez vérifier que l’Expressway-E tient pour fiables les autorités de certification de Cisco Webex. Tandis que vous pourriez simplement extraire ces certificats d’une trace Wireshark et les télécharger dans le centre de certificats des autorités de certification de confiance (Trusted CA) de l’Expressway, l’Expressway offre une méthode plus simple :

• Ouvrez une session dans l'Expressway-E
• Accédez à Applications > Gestion des certificats cloud
• Sélectionnez Get Certificates, comme l’indique l’image.

À ce stade-là, les autorités de certification de Cisco Webex sont téléversés dans le centre Trusted CA d’Expressway-E(Maintenance > Security > Trusted CA certificate).

Problème 2. Nom incorrect pour la vérification du sujet TLS sur Expressway-E Cisco Webex Hybrid DNS Zone 

Dans le cadre de la prise de contact mutuelle de TLS, Hybrid Call Service Connect fait appel à la vérification de TLS. Cela signifie qu’en plus de se fier aux certificats de CA de Cisco Webex, l’Expressway vérifie le certificat en contrôlant le champ SAN (Subject Alternate Name, autres noms de sujet) du certificat présenté pour vérifier qu’il a une valeur, comme celle de callservice.ciscospark.com . Si cette valeur n’est pas présente, il y aura un échec de l’appel entrant. 

Dans ce scénario particulier, le serveur Cisco Webex présente son certificat à l’Expressway-E. Dans les faits, le certificat a 25 noms de sujets (SAN) différents. Envisagez un cas où l’Expressway-E vérifierait le certificat pour le SAN callservice.ciscospark.com sans trouver ce nom de sujet. Dans un tel cas, vous pourrez voir une erreur semblable à celle-ci dans les journaux de diagnostic :

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 vous utilisez Wireshark pour analyser la prise de contact pour ce certificat, vous pourrez constater qu’après la présentation par Cisco Webex d’un certificat, l’Expressway ne tarde pas à mettre fin à la connexion (arrêt RST), comme l’indique l’image.

Afin de confirmer la configuration de cette valeur, vous pouvez accéder à la zone DNS de Webex Hybrid qui a été configurée pour la solution. Si vous avez la xConfiguration Expressway-E, vous pouvez consulter la section de configuration de la zone pour déterminer comment le nom de sujet de vérification de TLS a été configuré. Pour xConfiguration, notez que les zones sont présentées en ordre, la Zone 1 en premier. Voici une xConfiguration provenant de l'environnement problématique analysé ci-dessus.

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

Comme vous pouvez le voir dans l'exemple, le nom du sujet de vérification TLS est défini sur calllservice.ciscospark.com au lieu de callservice.ciscospark.com. (notez le « l » supplémentaire).

Solution :

Afin de résoudre ce problème, le nom de sujet de vérification de TLS doit être modifié comme suit :

• Ouvrez une session dans l'Expressway-E
• Naviguez jusqu'à Configuration > Zones > Zones
• Sélectionnez Webex Hybrid Services DNS Zone
• Définissez le nom de sujet de vérification (TLS verify subject name) comme suit : callservice.ciscospark.com
• Sélectionnez Save (enregistrer)

Note: Par la suite, consultez le comportement de journalisation de référence. Cette section présente la vérification du certificat s’exécutant sur Expressway, de même que la mise en correspondance des données de la zone DNS de Webex Hybrid.

Note: Depuis le code Expressway x12.5 et les versions ultérieures, une nouvelle zone « Webex » est sortie. Cette zone Webex préremplit la configuration de la zone requise pour la communication vers Webex. Cela signifie que vous n'avez plus besoin de définir le mode de vérification de l'objet TLS et le nom de l'objet de vérification TLS. Pour simplifier la configuration, il est recommandé d’utiliser la zone Webex si vous utilisez x12.5 ou une version ultérieure du code Expressway. 

Problème 3. Expressway-E n’envoie pas la chaîne de certificats complète à Cisco Webex

Dans le cadre de la prise de contact mutuelle de TLS, Cisco Webex doit se fier au certificat d’Expressway-E. Cisco Webex a une liste complète de ses CA publiques de confiance. En général, une prise de contact mutuelle de TLS est menée à bien lorsque votre certificat d’Expressway-E est signé par une autorité de certification publique que prend en charge Cisco Webex. Par conception, l’Expressway-E n’envoie son certificat qu’au cours d’une connexion TLS, bien qu’il ait été signé par une autorité de certification publique. Afin d’envoyer la chaîne complète de certificats (racine et intermédiaire), ces certificats doivent être ajoutés au magasin de certificats CA de confiance sur l’Expressway-E lui-même.

Si cette condition n’est respectée, Cisco Webex rejette le certificat d’Expressway-E. Lorsque vous faites du dépannage dans une situation qui correspond à ce problème, vous pouvez utiliser les journaux de diagnostic et tcpdump dans l’Expressway-E. Lorsque vous analysez les journaux de diagnostic d’Expressway-E, vous observerez une erreur semblable à celle-ci :

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 vous analysez cela sous la perspective de Wireshark, vous verrez que l’Expressway-E présente son certificat. Si vous approfondissez votre étude du paquet, vous pourrez voir qu’uniquement le certificat du serveur est envoyé. Cisco Webex rejette ensuite cette prise de contact mutuelle de TLS en émettant un message d’erreur indiquant que l’autorité de certification est inconnue (Unknown CA) , comme l’indique l’image.

Solution :

Afin de régler le problème dans ce cas, vous devez télécharger les CAS intermédiaires et racines qui sont engagées dans la signature du certificat d’Expressway-E dans le centre des certificats de CA de confiance (Trusted CA) :

Étape 1. Ouvrez une session dans l'Expressway-E.
Étape 2. Naviguez jusqu'à Maintenance > Security > Trusted CA certificate.
Étape 3. Sélectionnez Choose File dans le menu Upload (Télécharger) situé en bas de l'interface utilisateur.
Étape 4. Choisissez le certificat CA qui a été impliqué dans la signature de l’Expressway-E.
Étape 5. Sélectionnez Append CA Certificate (ajouter le certificat de la CA).
Étape 6. Répétez les étapes pour tous les certificats CA impliqués dans la signature du certificat Expressway-E (intermédiaire, racine).
Étape 7. Sélectionnez Append CA Certificate (ajouter le certificat de la CA).

Une fois ce processus terminé, vous verrez que la chaîne entière de certificats faisant partie du processus de signature du certificat de serveur de l’Expressway-E est incluse dans l’échange de clés. Voici un exemple de ce que vous constaterez en analysant une capture de paquet au moyen de Wireshark.

Problème 4. Le pare-feu met fin à la prise de contact mutuelle de TLS

En règle générale, la solution Expressway s’interface avec un pare-feu. Dans bien des cas, le pare-feu en ligne lié à la solution exécute une sorte d’inspection de couche de l’application. Souvent avec la solution Expressway, lorsque le pare-feu exécute l’inspection de la couche application, les administrateurs voient des résultats indésirables. Ce problème particulier vous permet de repérer les cas où une inspection de couche de l’application met fin abruptement à la connexion.

Au moyen des journaux de diagnostic de l’Expressway, vous pouvez chercher à consulter les tentatives de prises de contact mutuelles de TLS. Tel que nous l’avons signalé précédemment, ce processus de prise de contact devrait survenir peu de temps après l’établissement de la connexion TCP sur le port 5062. Dans ce cas, lorsque le pare-feu rompt la connexion, vous verrez ces erreurs dans les journaux de diagnostic.

Thread="0x7f6496669700": TTSSL_continueHandshake: Failed to establish SSL connection iResult="-1" error="5" bServer="false" localAddress="['IPv4''TCP''172.17.31.10:28351']"
2017-06-13T13:31:38.760-05:00 vcse tvcs: Event="Outbound TLS Negotiation Error" Service="SIP" Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Common-name="callservice.ciscospark.com" Level="1" UTCTime="2017-06-13 18:31:38,758"
2017-06-13T13:31:38.760-05:00 vcse tvcs: UTCTime="2017-06-13 18:31:38,758" Module="network.tcp" Level="DEBUG":  Src-ip="172.17.31.10" Src-port="28351" Dst-ip="198.101.251.5" Dst-port="5062" Detail="TCP Connection Closed" Reason="Got EOF on socket"

Sous la perspective de capture de paquets, vous verrez que l’Expressway-E présente son certicate à Cisco Webex. Vous voyez un RST de TCP provenant de Cisco Webex, comme l’illustre l’image. 

Dans un premier temps, vous pourriez penser que quelque chose ne va pas avec le certificat d’Expressway-E. Afin de résoudre ce problème, vous devez tout d’abord déterminer les réponses à ces questions :

• Est-ce que l’Expressway-E porte la signature d’une autorité de certification publique réputée digne de confiance par Cisco Webex?
• Est-ce que le certificat Expressway-E et les éventuels autres certificats prenant part au processus de signature de l’Expressway-E ont été téléchargés manuellement dans le Cisco Webex Control Hub (https://admin.ciscospark.com)? 

Dans cette situation en particulier, la solution ne consistait pas à utiliser Cisco Webex Control Hub pour gérer les certificats Expressway-E. Cela signifie que le certificat e l’Expressway-E doit porter la signature d’une autorité de certification publique réputée digne de confiance par Cisco Webex. En cliquant sur le paquet du Certificat dans la capture de Wireshark (comme le montre l’illustration ci-dessous), vous pouvez voir que le certificat a bien été signé par une autorité de certification publique et que la chaîne entière de certificats a été envoyée à Cisco Webex. Par conséquent, le problème n’est probablement pas relié au certificat d’Expressway-E.

À ce stade, s’il est nécessaire d’isoler plus précisément la problématique, vous pourriez faire une capture de paquet de l’interface externe du pare-feu. Cependant, l’absence d’erreur de SSL dans le journal de diagnostic constitue un important point de données. Tel que nous l’avons abordé ci-dessus (Problème 3.) , si Cisco Webex ne tient pas pour fiable le certificat d’Expressway-E, vous devriez voir un certain motif de déconnexion SSL. Dans ce cas-ci, il n’y avait pas d’erreur SSL disponible.

Note: Si vous deviez obtenir une capture de paquets de l’interface externe du pare-feu, vous n’observeriez pas de RST de TCP provenant de l’environnement de Cisco Webex.

Solution

Pour cette solution en particulier, vous, en tant que partenaire ou client, devrez vous fier à votre équipe de sécurité. L’équipe devra vérifier si elle utilise une forme d’inspection de couche de l’application pour la solution Expressway et si c’est le cas, elle devra la désactiver. L’Annexe 4 du guide de déploiement de VCS Control et Expressway explique pourquoi il est recommandé que les clients désactivent cette fonctionnalité.

Problème 5. L’Expressway-E est signé par une autorité de certification publique, mais le concentrateur de contrôle Cisco Webex a d’autres certificats chargés

Cette situation en particulier se produit souvent lorsque vous avez déployé la solution d’Expressway en partant de rien et que vous n’avez pas au départ de certificat d’Expressway-E signé par une autorité de certification publique. Dans ce scénario, vous téléchargez le certificat du serveur Expressway-E (qui a été signé à l’interne) vers le Cisco Webex Control Hub afin que vous puissiez effectuer la prise de contact mutuelle avec succès. Par la suite, vous obtenez le certificat d’Expressway-E signé par une autorité de certification publique, toutefois vous oubliez de retirer le certificat du serveur du Cisco Webex Control Hub. Il est important de savoir que lorsqu’un certificat est téléchargé vers le Cisco Webex Control Hub, ce certificat l’emportera en priorité sur tout certificat ou toute chaîne que présente l’Expressway au cours de la prise de contact mutuelle de TLS.

Du point de vue de la journalisation de diagnostic d’Expressway-E, ce problème peut ressembler à la signature de journalisation qui est rencontrée lorsque Cisco Webex ne fait pas confiance au certificat Expressway-E, par exemple dans le cas où l’Expressway-E n’envoie pas sa chaîne complète ou le certificat Expressway-E n’est pas signé par une autorité de certification publique de confiance de Cisco Webex. Ci-dessous, un exemple de ce vous pouvez constater dans la journalisation d’Expressway-E s’attachant à la prise de contact mutuelle 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"

En y jetant un œil du point de vue de Wireshark, vous pourrez constater qu’Expressway-E présente son certificat dans l’élément de la ligne 175. Quelques lignes plus bas, l’environnement de Cisco Webex rejette le certificat en émettant une erreur de certificat inconnu (Certificate Unknown error), comme l’indique l’image.

Si vous sélectionnez le paquet de certificat envoyé par l’Expressway-E, vous pouvez développer les renseignements sur le certificat pour déterminer si l’Expressway-E

1. porte la signature d’une autorité de certification publique que Cisco Webex tient pour fiable

2. et s’il inclut la chaîne complète de certificats dans la signature.

Dans cette situation, les deux critères sont satisfaits. Cela fait penser qu’il n’y a aucun problème avec le certificat d’Expressway-E.

Solution

Étape 1. Connectez-vous au Cisco Webex Control Hub.
Étape 2. Sélectionnez Services dans le volet gauche.

Étape 3. Sélectionnez Paramètres sous la carte d'appel hybride.

Étape 4. Faites défiler jusqu'à la section Call Service Connect et recherchez les certificats pour les appels SIP chiffrés pour voir si des certificats indésirables sont répertoriés. Dans un tel cas, cliquez sur l’icône de poubelle à côté du certificat.

étape 5. Sélectionnez Supprimer.

Note: Il est important que l’analyse soit effectuée et il est déterminé que le client n’utilise pas les certificats téléchargés dans Webex Control Hub avant de les retirer.

Pour plus de renseignements à propos du téléchargement de votre certificat Expressway-E dans le Cisco Webex Control Hub, vérifiez la section du guide de déploiement Hybrid Call.

Problème 6. Expressway ne mappe pas l’appel entrant à la zone DNS hybride Cisco Webex

La fonctionnalité de mise en correspondance de TLS d’appels entrants fonctionne en conjonction avec le nom de sujet de vérification (Verify Subject Name) de TLS. Ces deux éléments sont configurés dans la zone DNS d’Hybrid Call. Ce scénario présente les problèmes et les défis observés avec l’Expressway avant x12.5. Dans x12 et les versions ultérieures, un nouveau type de zone a été mis en oeuvre appelé la zone « Webex ». Cette zone préremplit toutes les configurations requises pour l'intégration avec Webex. Si vous exécutez x12.5 et déployez Webex Hybrid Call, il est recommandé d'utiliser le type de zone Webex afin que le domaine des services d'appel hybrides (callservice.webex.com) soit configuré automatiquement pour vous. Cette valeur correspond au nom secondaire du sujet du certificat Webex qui est présenté lors de la connexion mutuelle TLS et permet à la connexion et au mappage entrant vers l’Expressway de réussir. 

Si vous utilisez une version de code sous x12.5 ou si vous n’utilisez pas la zone Webex, vous voudrez poursuivre avec l’explication ci-dessous qui montre comment identifier et corriger les problèmes où l’Expressway ne mappe pas l’appel entrant vers la zone DNS hybride Webex. 

La fonctionnalité conduit à un processus en trois étapes :

1. Expressway-E accepte le certificat de Cisco Webex.
2. Expressway-E examine le certificat de Cisco Webex pour déterminer s’il y a un autre nom de sujet (Subject Alternate Name) qui correspond au nom de sujet de vérification de TLS : callservice.ciscospark.com.
3. Expressway-E met en correspondance la connexion entrante au moyen de la zone DNS de Cisco Webex Hybrid.

Si l’authentification n’a pas réussi, cela signifie que la validation du certificat a échoué. L’appel entre dans la zone par défaut et est acheminé selon les règles de recherche précisées pour les scénarios d’une entreprise à l’autre (business-to-business), si l’option business-to-business est configurée sur Expressway-E.

Comme dans les autres scénarios, vous devez utiliser la journalisation de diagnostic et les captures de paquets pour déterminer l’aspect que prend l’échec, puis utiliser la capture de paquets pour déterminer quel côté envoie le RST. Voici un exemple de la connexion de TCP qui fait l’objet de tentatives avant d’être établie. 

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"

Maintenant que la connexion de TCP est établie, la prise de contact mutuelle de TLS peut suivre. Vous pouvez observer que peu de temps après la mise en application de la prise de contact mutuelle, le processus est rapidement interrompu pour cause d’erreur.  

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"

Examinez cette situation sous l’angle de pcap, et vous pourrez vous faire une meilleure idée de

• qui émet le RST
• et quels sont les certificats transmis, pour vérifier s’ils sont corrects.

Lorsque vous analysez cette capture en particulier, vous pouvez voir que l’Expressway-E envoie le RST. Lorsque vous consultez le certificat de Cisco Webex qui est transmis, vous observez aussi que la chaîne complète est envoyée. De plus, selon le message d’erreur dans le journal de diagnostic, vous pouvez conclure que le scénario selon lequel l’Expressway-E ne tient pas pour fiables les CA publiques de Cisco Webex n’est pas en cause. Sinon, vous auriez vu une erreur comme la suivante « self signed certificate in certificate chain » (signalant le certificat autosigné dans la chaine de certificats). Vous pouvez approfondir votre examen des détails de paquets, comme l’indique l’image.

Si vous cliquez sur le certificat du serveur Webex et faites afficher de plus amples renseignements pour voir les autres noms du sujet, c.-à-d. les Subject Alternate Names (dnsName), vous pouvez vérifier que callservice.ciscospark.com est indiqué.

Naviguez jusqu’à Wireshark : Certificate > Extension > General Names > GeneralName > dNSName : callservice.ciscospark.com 

Cela confirme entièrement que le certificat de Webex semble parfaitement correct.

Vous pouvez maintenant confirmer que le nom de sujet de vérification de TLS (TLS Verify Subject Name) est correct. Tel que signalé précédemment, si vous avez xConfiguration, vous pouvez consulter la section de configuration de la zone pour déterminer comment le nom de sujet de vérification de TLS a été configuré. Pour xConfiguration, il convient de signaler que les zones sont présentées en ordre, la Zone 1 en premier. Voici une xConfiguration provenant de l'environnement problématique analysé ci-dessus. De toute évidence, le nom de sujet de vérification de TLS ne pose pas de problème.

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

La prochaine chose à examiner est la mise en correspondance des données entrantes de vérification de TLS (TLS verify inbound mapping). Cela vous permet de confirmer que votre mise en correspondance de la connexion TLS dans la zone DNS de Webex Hybrid est correcte. Il est aussi possible de tirer part de xConfiguration pour analyser cela. Dans la xConfiguration, la mise en correspondance des données entrantes de vérification de TLS TLS verify inbound mapping s’appelle DNS ZIP TLS Verify InboundClassification. Comme vous pouvez le voir dans cet exemple, la valeur est réglée à « Off » (arrêt).

*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "Off"
*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"

Étant donné que la valeur est réglée à « Off » (arrêt), cela signifie que le VCS ne peut pas tenter de mettre en correspondance des données entrantes de connexion de TLS dans cette zone. L’appel entre donc dans la zone par défaut et vérifié est acheminé selon les règles de recherche précisées pour les scénarios d’une entreprise à l’autre (business-to-business), si l’option business-to-business est configurée sur Expressway-E.

Solution

Afin d’aborder cette situation, vous devez définir la mise en correspondance de données entrantes de vérification de TLS en sélectionnant « On » (mise en marche) pour la zone DNS d’Hybrid Call. Voici les étapes à suivre pour le faire.

1. Ouvrez une session dans l'Expressway-E
2. Naviguez jusqu'à Configuration > Zones > Zones
3. Sélectionnez Hybrid Call DNS Zone
4. Pour TLS verify inbound mapping, choisissez On
5. Sélectionnez Save (enregistrer)

Note: Reportez-vous à la pour connaître le comportement de journalisation de base. Cette section présente la vérification du certificat s’exécutant sur Expressway, de même que la mise en correspondance des données de la zone DNS de Webex Hybrid.

Problème 7. Expressway-E utilise un certificat auto-signé par défaut

Dans certains nouveaux déploiements de Hybrid Call Service Connect, la signature du certificat Expressway-E est oubliée, ou encore, on pense que le certificat de serveur par défaut peut être utilisé. Certaines personnes pensent que c’est possible parce que Cisco Webex Control Hub vous permet de charger un certificat personnalisé sur le portail. (Services > Settings (sous Hybrid Call card) > Upload (sous Certificates for Encrypted Calls))

Si vous portez attention aux énoncés au sujet des Certificates for Encrypted SIP Calls, vous observerez la directive suivante : « Use certificates provided from the Cisco Collaboration default trust list or upload your own. If you use your own, ensure the hostnames are on a verified domain ». Cela signifie : utilisez des certificats provenant de la liste de confiance par défaut de Cisco Collaboration ou encore, téléchargez les vôtres. Si vous utilisez les vôtres, assurez-vous que les noms d’hôte proviennent d’un domaine vérifié. L’élément clé de la directive est le suivant : « assurez-vous que les noms d’hôte proviennent d’un domaine vérifié. » 

Lorsque vous faites du dépannage pour un problème qui correspond à cette situation, n’oubliez pas que les symptômes dépendront de l’orientation de l’appel. Si l’appel provient d’un téléphone sur place, vous pouvez vous attendre à ce que l’application Cisco Webex ne sonne pas. De même, si vous essayez de retracer l’appel à partir de l’historique de recherche Expressways, vous constaterez que l’appel s’est rendu sur l’Expressway-E et s’est arrêté là. Si l’appel provient d’une application de Cisco Webex et était destiné à un site sur place, le téléphone sur place ne sonne pas. Dans un tel cas, l’historique de recherche d’Expressway-E et d’Expressway-C ne révélera rien.

Dans ce scénario en particulier, l’appel provenait d’un téléphone sur place. Au moyen de l’historique de recherche d’Expressway-E, vous pouvez déterminer que l’appel s’est rendu au serveur. À ce stade, vous pouvez examiner de plus près la journalisation de diagnostic pour déterminer ce qui est arrivé. Pour commencer cette analyse, dans un premier temps, vérifiez si une connexion de TCP a été tentée et établie sur le port 5062. Au moyen d’une recherche dans les journaux de diagnostic d’Expressway-E pour les traces de la connexion TCP (« TCP Connecting »), en particulier une recherche pour les lignes portant la balise « Dst-port=5062 », vous pouvez déterminer si la connexion a été établie. 

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"

Maintenant que vous avez confirmé que la connexion de TCP est établie, vous pouvez analyser la prise de contact mutuelle de TLS qui s’est produite immédiatement après. Comme vous pouvez le voir dans l’extrait ici, la prise de contact mutuelle échoue et le certificat est inconnu (« sslv3 alertcertificate unknown »)

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"

À l’examen de la capture de paquets découlant de la journalisation de diagnostic Expressway-E, vous pouvez voir que l’erreur de certificat inconnu proviendrait de Cisco Webex, comme l’indique l’image.

Si vous inspectez le certificat du serveur par défaut (Default Server certificate) de l’Expressway-E, vous pouvez voir que le « Common Name » (nom courant) et les « Subject Alternate Names » (autres noms de sujet) ne comprend pas de domaine vérifié (« Verified Domain ») (rtp.ciscotac.net). Vous avez ensuite des données probantes sur ce qui cause ce problème, comme l’indique l’image. 

À ce stade, vous avez déterminé que le certificat du serveur Expressway-E doit être signé par une autorité de certification (CA) publique ou une autorité de certification (CA) interne. 

Solution

Afin de résoudre ce problème, vous avez deux options :

1. Veiller à ce que le certificat de l’Expressway-E porte la signature d’une CA publique réputée digne de confiance par Cisco Webex.
   
   1. Ouvrez une session dans l’Expressway.
   2. Naviguez jusqu’à Maintenance > Security > Server certificate.
   3. Sélectionnez Generate CSR (produire CSR).
   4. Saisissez les informations de certificat requis et vous assurer que le Supplémentaires noms autre champ contient le Vérifié Domaine décrites dans le Concentrateur de Contrôle Webex.
   5. Cliquez sur Generate CSR.
   6. Fournir le CSR à la tierce autorité de certification publique pour signature.
   7. Lorsque le certificat sera de retour, naviguez jusqu’à Maintenance > Security > Server certificates.
   8. Dans la section Upload New Certificate (télécharger le nouveau certificat) à côté de Select the server certificate file (sélectionner le fichier de certificat du serveur), sélectionnez Choose File (choisir un fichier) puis sélectionnez signed certificate (certificat signé).
   9. Sélectionnez Upload server certificate data (télécharger les données de certificat de serveur).
   10. Naviguez jusqu'à Maintenance > Security > Trusted CA certificate.
   11. Dans la section Upload (télécharger) à côté de Select the file containing trusted CA certificates (sélectionner le fichier qui renferme les certificats de CA de confiance), sélectionnez Choose File (choisir un fichier).
   12. Sélectionnez n'importe quel des certificats racines et intermédiaires provenant de l'autorité de certification publique.
   13. Sélectionnez Append CA Certificate (ajouter le certificat de la CA).
   14. Redémarrez l'Expressway-E.
2. Veillez à ce que le certificat d’Expressway-E soit signé par une autorité de certification (CA) interne, puis téléversez l’Expressway-E et l’autorité de certification (CA) interne dans Cisco Webex Control Hub.
   
   1. Ouvrez une session dans l’Expressway.
   2. Naviguez jusqu’à Maintenance > Security > Server certificate.
   3. Sélectionnez Generate CSR (produire CSR).
   4. Saisissez les renseignements de certificat requis et vérifiez que le Additional alternative names field comprend le domaine vérifié (Verified Domain ) décrit dans le Webex Control Hub
   5. Cliquez sur Generate CSR.
   6. Fournir le CSR à la tierce autorité de certification publique pour signature.
   7. Au retour du certificat, Accédez à Maintenance > Sécurité > certificats Serveur
   8. Dans la section Upload New Certificate (télécharger le nouveau certificat) à côté de Select the server certificate file (sélectionner le fichier de certificat du serveur), sélectionnez Choose File (choisir un fichier) puis sélectionnez signed certificat (certificat signé).
   9. Sélectionnez Upload server certificate data (télécharger les données de certificat de serveur).
   10. Naviguez jusqu’à Maintenance > Security > Trusted CA certificate.
   11. Dans la section Upload (télécharger) à côté de Select the file containing trusted CA certificates (sélectionner le fichier qui renferme les certificats de CA de confiance), sélectionnez Choose File (choisir un fichier).
   12. Sélectionnez n'importe quel des certificats racines et intermédiaires provenant de l'autorité de certification publique.
   13. Sélectionnez Append CA Certificate (ajouter le certificat de la CA).
   14. Redémarrez l'Expressway-E.

 2a. Téléversez le certificat de l’autorité de certification interne et d’Expressway-E dans Cisco Webex Control Hub.
       1. Connectez-vous au Cisco Webex Control Hub en tant qu'administrateur.
       2. Sélectionnez Services.
       3. Sélectionnez Paramètres sous la carte Hybrid Call Service.
       4. Dans la section des certificats des appels SIP chiffrés (Certificates for Encrypted SIP Calls section) sélectionnez Upload (télécharger).
       5. Sélectionnez les certificats CA interne et Expressway-E.

Entrant : Cisco Webex vers le site

Presque tous les échecs d’une communication de Cisco Webex vers un site entraînent les mêmes symptômes déclarés : « Lorsque j’appelle de l’application de mon Cisco Webex à l’application d’un collègue, son application sonne, mais le téléphone sur le site ne sonne pas. » Afin de résoudre ce genre de problématique, vous trouverez utile de comprendre les flux d’appels et la logique s’appliquant lorsque ce genre d’appel s’effectue.

Flux logique de haut niveau

1. L’appelant de l’application de Cisco Webex lance l’appel.
2. L’application de l’appelé sonne.
3. L’appel est acheminé par l’environnement de Cisco Webex
4. L’environnement de Cisco Webex doit effectuer une recherche de DNS en fonction de la destination SIP configurée du client dans le Cisco Webex Control Hub
5. L’environnement de Cisco Webex tente de se connecter à l’Expressway sur le port 5062
6. L’environnement de Cisco Webex tente d’effectuer une prise de contact mutuelle de TLS
7. L’environnement de Cisco Webex envoie une invitation (INVITE) SIP à Expressway. L’invitation est transmise au point terminal de collaboration/téléphone IP sur place.
8. Cisco Webex et l’entreprise complètent la négociation de SIP
9. Cisco Webex et l’entreprise commencent à envoyer et recevoir des communications.

Flux d’appels

Naviguez jusqu’à Cisco Webex app > Cisco Webex environment > Expressway-E > Expressway-C > On-PremisesCollaboration Endpoint/IP Phone, comme l’indique l’image.

Voici quelques-uns des problèmes courants observés dans l’infrastructure sur place au sujet des appels entrants provenant de Webex.

Problème 1. Cisco Webex ne peut pas résoudre le SRV/nom d’hôte DNS de l’Expressway-E

Lorsque l’on examine le flux d’appels de Cisco Webex vers les sites sur place, la première étape logique que franchit Cisco Webex consiste à vérifier comment communiquer avec l’Expressway sur place. Comme il en est question ci-haut, Cisco Webex va tenter de se connecter à l’Expressway sur place en effectuant une recherche de SRV fondée sur la configuration de la destination SIP qui est affichée dans la page de paramètres Hybrid Call Service Settings dans le Cisco Webex Control Hub. 

Si vous tentez de faire un dépannage dans cette situation sous une perspective de journal de diagnostic Expressway-E, vous ne verrez pas le trafic en provenance de Cisco Webex. Si vous tentez de faire des recherches de connexion TCP, vous n’observerez pas Dst-port=5062 ou les processus subséquents de prise de contact mutuelle de MTLS ou d’invitation SIP provenant de Cisco Webex. 

S’il s’agit de votre situation, vous devrez vérifier comment la SIP Destination a été configurée dans Cisco Webex Control Hub. Vous pouvez également utiliser l’outil Hybrid Connectivity Test Tool pour vérifier la connectivité dans le cadre de vos efforts de dépannage. Cet outil (Hybrid Connectivity Test Tool) vérifie s’il y a une adresse DNS valide, si Cisco Webex peut se connecter au port renvoyé dans la recherche de SRV et si l’Expressway sur place a un certificat valide auquel Cisco Webex peut se fier. 

1. Ouvrez une session dans le Cisco Webex Control Hub
2. Sélectionnez les Services
3. Sélectionnez le lien conduisant aux paramètres (Settings) dans la carte Call card d’Hybrid.
4. Dans la section Call Service Connect, vérifiez le domaine utilisé pour l’adresse publique de SRV de SIP le champ Destination du SIP. 
5. Si l’enregistrement est saisi correctement, cliquez sur Test pour voir si l’enregistrement est valide.
6. Comme le montre l’illustration ci-dessous, vous pouvez voir clairement que le domaine public n’a pas un enregistrement SRV de SIP correspondant connexe, tel que l’indique l’image. 

Sélectionnez View test results (afficher les résultats de test) pour consulter de plus amples renseignements au sujet de ce qui a échoué, comme l’illustre l’image. 

Vous pouvez aussi recourir à une autre approche, qui consiste à faire une recherche d’enregistrement SRV en utilisant nslookup. Voici les commandes que vous pouvez exécuter pour vérifier si la destination SIP existe.

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

Comme vous pouvez le constater dans le bloc de codes ci-dessus, la commande nslookup a été lancée, puis le serveur s’est réglé à 8.8.8.8, ce qui correspond à un serveur DNS public de Google. En dernier lieu, vous définissez les types d’enregistrement pour faire une recherche d’enregistrements SRV. À ce stade-ci, vous pourrez ensuite émettre l’enregistrement SRV complet que vous souhaitez consulter. En fin de compte, il y aura un arrêt automatique s’appliquant aux demandes. 

Solution

1. Configurez une adresse SRV de SIP publique pour l’Expressway-E sur le site utilisé pour héberger les noms de domaine public. 
2. Configurez un nom d’hôte qui permettra de remédier aux problèmes d’adresse IP de l’Expressway-E
3. Configurez la destination SIP pour afficher le domaine utilisé pour l’ adresse SRV de SIP créée à l’Étape 1.
   1. Ouvrez une session dans le Cisco Webex Control Hub
   2. Sélectionner des services
   3. Sélectionnez le lien conduisant aux paramètres (Settings ) dans la carte Hybrid Call card
   4. Dans la section Call Service Connect, saisissez le domaine utilisé pour l’adresse publique SRV de SIP dans le champ SIP Destination. 
   5. Sélectionnez Save (enregistrer)

Note: Si l’enregistrement SRV du SIP que vous souhaitez utiliser est déjà utilisé pour les communications « business-to-business », nous vous recommandons de préciser un sous-domaine du domaine d’entreprise comme adresse de découverte SIP de Cisco Webex Control Hub et par conséquent, un enregistrement public SRV de DNS, comme suit :

Service and protocol (service et protocole) : _sips._tcp.mtls.example.com
Priorité : 1
Weight (poids) : 10
Port number (numéro de port) : 5062
Target (cible) : us-expe1.example.com

La recommandation ci-dessus provient directement du guide de conception de Cisco Webex Hybrid Design.

Solution de rechange

Si le client n’a pas un enregistrement SIP de SRV (et ne prévoit pas en créer un), il peut aussi afficher l’adresse IP publique d’Expressway portant le suffixe : « : 5062 ». À la suite de cette action, l’environnement de Webex ne tentera pas une recherche de SRV, mais se connectera plutôt à %Expressway_Pub_IP%:5062. (Par exemple : 64.102.241.236:5062)

1. Configurez la destination SIP pour qu’elle soit formatée comme suit %Expressway_Pub_IP%:5062. (Exemple : 64.102.241.236:5062)
   1. Ouvrez une session dans le Cisco Webex Control Hub
   2. Sélectionner des services
   3. Sélectionnez le lien conduisant aux paramètres (Settings ) dans la carte Hybrid Call card
   4. Dans la section Call Service Connect, saisissez %Expressway_Pub_IP%:5062 dans le champ SIP Destination. 
   5. Sélectionnez Save (enregistrer)

Pour en savoir plus sur l’adresse de la destination du SIP ou sur l’enregistrement SRV à configurer. Consultez la section Enable Hybrid Call Service Connect for Your Organization du guide de déploiement des services Hybrid Call de Cisco Webex ou encore, le guide de conception de Cisco Webex Hybrid Design.

Problème 2. Échec du socket : Port 5062 est bloqué à l'entrée d'Expressway

Après la résolution DNS, l’environnement de Cisco Webex tentera d’établir une connexion TCP sur le port 5062 à l’ adresse IP qui a été retournée au cours de la recherche de DNS. Cette adresse IP est l’adresse IP publique provenant de l’Expressway-E sur place. Si l’environnement de Cisco Webex est incapable d’établir cette connexion TCP, l’appel entrant sur place échouera ensuite. Le symptôme révélant ce problème en particulier est le même que presque tous les autres échecs liés à un appel entrant de Cisco Webex : le téléphone sur place ne sonne pas.

Si vous faites un dépannage pour ce problème au moyen des journaux de diagnostic Expressway, vous ne verrez pas de trafic provenant de Cisco Webex. Si vous tentez de faire des recherches de connexion TCP, vous n’observerez aucune tentative de connexion pour Dst-port=5062 ou de processus subséquents de prise de contact mutuelle de MTLS ou d’invitation SIP provenant de Cisco Webex. Puisque la journalisation de diagnostic d’Expressway-E n’est d’aucun secours dans cette situation, vous disposez de quelques méthodes possibles pour la vérification :

1. Obtenez une saisie de paquets de l’interface externe du pare-feu
2. Tirez parti d’une fonctionnalité de vérification de port
3. Utilisez l’outil de test de connectivité d’Hybrid

Puisque l’outil de test de connectivité d’Hybrid est intégré au Cisco Webex Control Hub et simule l’environnement de Cisco Webex dans ses tentatives de connexion à l’Expressway sur les lieux, parmi les solutions offertes, c’est la méthode de vérification idéale. Pour mettre à l’essai la connectivité TCP dans l’organisation :

1. Ouvrez une session dans le Cisco Webex Control Hub
2. Sélectionnez les Services
3. Sélectionnez le lien conduisant aux paramètres (Settings) dans la carte Call card d’Hybrid.
4. Dans la section Call Service Connect, vérifiez que la valeur saisie dans le champ SIP Destination est correcte
5. Cliquez sur Test, comme l’indique l’image.

  6. Puisque l’essai a échoué, vous pouvez cliquer sur le lien d’affichage des résultats de test (View test results ) pour consulter les détails, comme l’indique l’image.

Comme l’illustre l’image ci-dessus, vous pouvez voir que le test de l’interface de connexion a échoué lors de la tentative de connexion au 64.102.241.236:5062. Grâce à ces données, en plus des journaux de diagnostic et pcaps Expressway qui n’affichent pas de tentatives de connexion, vous avez désormais assez de données probantes pour examiner la configuration du pare-feu ACL/NAT/routage. 

Solution

Étant donné que ce problème en particulier n’est pas causé par l’environnement de Cisco Webex ou par l’équipement de collaboration sur les lieux, vous devez axer vos efforts sur la configuration du pare-feu. Puisque vous ne pouvez pas nécessairement prévoir le type de pare-feu avec lequel vous serez en contact, vous devrez vous fier à quelqu’un qui connaît le périphérique. Il est possible que le problème soit lié à une erreur de configuration de pare-feu ACL, de NAT ou de routage. 

Problème 3. Échec du socket : Expressway-E n'est pas à l'écoute sur le port 5062

Il arrive souvent que ce problème en particulier ne soit pas correctement diagnostiqué. Souvent, il est supposé que le pare-feu est la cause du blocage du trafic sur le port 5062. Pour résoudre ce problème en particulier, vous pouvez utiliser les techniques décrites dans la mise en situation « Le port 5062 est bloqué à l’entrée d’Expressway » ci-dessus. Vous constaterez que l’outil de test de connectivité Hybrid échouera, comme tout autre outil pour vérifier la connectivité de port. Selon une première hypothèse, c’est le pare-feu qui bloquerait le trafic. La plupart des gens vérfieraient de nouveau la journalisation de diagnostic de l’Expressway-E pour déterminer s’ils peuvent repérer la connexion TCP qui tente de s’établir. De façon générale, ils chercheront à repérer une ligne de journal comme celle qui se trouve dans l’image.

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"

Dans un cas comme celui-ci, l’entrée de journal ci-dessus n’apparaîtra pas. Par conséquent, plusieurs personnes établissent un diagnostic erroné en supposant que le problème vient du pare-feu.

Si une capture de paquets est incluse dans la journalisation de diagnostic, vous pouvez vérifier que le pare-feu n’est pas la cause du problème. Voici un exemple de capture de paquets provenant du scénario dans lequel l’Expressway-E n’était pas à l’écoute sur le port 5062. Cette capture est filtrée avec le filtre tcp.port==5062 , comme le révèle l’image. 

Comme vous pouvez le voir dans la capture de paquets obtenue à partir de l’Expressway-E, le trafic sur le port TCP 5062 n’est pas bloqué par le pare-feu. Au contraire, il est en train d’arriver. Dans le paquet numéro 56, vous pouvez voir que l’Expressway-E envoie le RST tout de suite après l’arrivée du premier paquet SYN. Compte tenu de cette information, vous pouvez conclure que le problème se limite à l’Expressway-E recevant le paquet; vous devez résoudre le problème sous l’angle de l’Expressway-E. Compte tenu des données probantes, envisagez les raisons possibles pour lesquelles l’Expressway-E appliquerait un RST au paquet. Voici deux scénarios possibles susceptibles de s’attribuer à ce comportement :

1. Dans l’Expressway-E, certains paramètres de pare-feu pourraient bloquer le trafic.

2. L’Expressway-E n’est pas à l’écoute du trafic de TLS mutuel ou du trafic sur le port 5062.

Les fonctionnalités de pare-feu de l’Expressway-E se trouvent sous System > Protection > Firewall rules > Configuration. Lorsque cela a été vérifié dans cet environnement, il n’y avait pas de configuration de pare-feu. 

Il y a plusieurs façons de vérifier si l’Expressway-E est à l’écoute du trafic de TLS mutuel sur le port 5062. Vous pouvez le faire sur l’Interface Web ou la CLI en tant que superutilisateur. 

Des racines de l’Expressway, si vous émetteznetstat -an | grep ' : 5062' , vous devriez obtenir une sortie similaire à celle que vous voyez ci-dessous. 

~ # 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

Cette information peut aussi être saisie sur l’interface web de l’Expressway-E. Voir les étapes ci-dessous pour recueillir ces renseignements

1. Ouvrez une session dans l'Expressway-E

2. Naviguez jusqu’à Maintenance Tools > Port usage > Local inbound ports

3. Faites une recherche selon le Type SIP ou le port IP (IP port 5062). (en surbrillance en rouge, comme l’illustre l’image)

Maintenant que vous savez ce que vous devriez voir, vous pouvez faire une comparaison avec l’environnement actuel. Dans la perspective de la CLI, lorsque vous exécutez netstat -an | grep ' : 5062' , la sortie ressemble à ceci :

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

En outre, l’UU web ne montre pas le port de TLS mutuel sous les ports entrants locaux

Compte tenu de ces données, vous pouvez conclure que l’Expressway-E n’est pas à l’écoute du trafic de TLS mutuel.

Solution

Afin de résoudre ce problème, vous devez veiller à ce que le mode de TLS mutuel (Mutual TLS mode) soit activé et à ce que le port de TLS mutuel () soit réglé à 5062 sur l’Expressway-E :

1. Ouvrez une session dans l'Expressway-E
2. Naviguez jusqu’à Configuration > Protocols > SIP
3. Vérifiez que le mode de prise de contact mutuelle de TLS (Mutual TLS mode) est activé (On)
4. Vérifiez que le port de prise de contact mutuelle de TLS (Mutual TLS port) est établi à 5062
5. Cliquez sur Save (enregistrer), comme l’indique l’image.

Problème 4. Expressway-E ou C ne prend pas en charge les en-têtes de route SIP préchargés

Dans le contexte d’Hybrid Call Service Connect, l’appel de routage s’effectue en fonction l’en-tête de routage. L’en-tête de routage s’établit en fonction de l’information que fournit la partie Call Service Aware (connecteur Expressway) de la solution à Cisco Webex. L’hôte de connecteur Expressway interroge Unified CM pour les utilisateurs qui sont activés pour le service d’appel et extrait l’URI de l’annuaire et le FQDN de groupe de leur grappe d’accueil Unified CM. Voici des exemples mettant en vedette Alice et Bob :

Si Alice ou Bob passe un appel, l’appel est acheminé vers l’Unified CM sur le site. Cela permet de relier l’appel au Cisco WebexRD avant de l’acheminer à l’utilisateur appelé.

Si Alice ont été appeler Bob, l’ appel serait acheminer vers Alice de Unified CM à la Maison Cluster FQDN (é.-cucm.example.com). Si vous analysez l’invitation (SIP INVITE) entrante que Cisco Webex envoie à l’Expressway-E, vous trouverez l’information suivante dans l’en-tête SIP.

Du point de vue d’Expressway, les règles de recherche sont configurées pour acheminer l’appel non pas par l’URI de la demande, mais plutôt par l’en-tête de route (us-cucm.example.com) — dans ce cas, le cluster d’accueil Unified CM d’Alice.

Maintenant que les bases sont jetées, vous pouvez comprendre les situations de dépannage dans lesquelles l’Expressways fait l’objet d’une mauvaise configuration, qui entraîne le mauvais déroulement de la séquence logique décrite ci-dessus. Un peu comme on le constate pour presque tous les autres échecs de configuration d’Hybrid Call Service Connect, le symptôme est le suivant : le téléphone sur les lieux ne sonne pas.

Avant d’analyser les journaux de diagnostic sur l’Expressway, songez aux façons de cerner cet appel :

1. L’URI de demande de SIP sera l’URI de l’annuaire de la partie appelée.
2. Le champ SIP FROM sera formaté avec l'appelant indiqué comme « Prénom » <sip:WebexDisplayName@subdomain.call.ciscospark.com>

Compte tenu de cette information, vous pouvez faire une recherche dans les journaux de diagnostic en fonction des paramètres suivants : URI de l’Annuaire de la partie appelée, prénom et nom de la personne qui appelle ou adresse de SIP de Cisco Webex de la personne qui appelle. Si vous n’avez aucune de ces informations, vous pouvez effectuer une recherche sur "INVITE SIP :" qui localise tous les appels SIP exécutés sur l’Expressway. Une fois que vous avez trouvé l’invitation de SIP de l’appel entrant, vous pouvez repérer et copier l’identifiant de l’appel SIP. Une fois que vous avez cette valeur, vous pouvez simplement faire une recherche dans les journaux de diagnostic en fonction de l’identifiant de l’appel pour voir tous les messages s’attachant à ce segment d’appel.

Une autre façon de contribuer à isoler le problème de routage consiste à déterminer quelle distance l’appel parvient à franchir dans l’entreprise. Vous pouvez essayer d’effectuer des recherches ayant pour objet les renseignements précisés ci-dessus sur l’Expressway-C pour voir si l’appel a été acheminé jusque-là. Si c’est le cas, c’est probablement là que vous voudrez lancer votre étude.

Dans ce scénario, vous pouvez voir que l’Expressway-C a reçu l’invitation (INVITE) de l’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" 
     
     ;tag=872524918
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 15
Route: 
     
     
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>

La partie importante : l’en-tête de routage (FQDN de grappe) demeure intacte. Toutefois, il n’y a aucune logique de recherche s’exécutant en fonction de l’en-tête de routage (FQDN de grappe) cucm.rtp.ciscotac.net. Vous constatez plutôt que le message est rejeté immédiatement et fait l’objet d’un message d’erreur 404 Not Found.

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Attempted" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Protocol="TLS" Auth="NO" Level="1" UTCTime="2017-09-19 18:16:15,832"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="searchtype:INVITE" Level="1" UTCTime="2017-09-19 18:16:15,834"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Search Completed" Reason="Not Found" Service="SIP" Src-alias-type="SIP" Src-alias="pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-19 18:16:15,835"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.6" Src-port="7003" Src-alias-type="SIP" Src-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Dst-alias-type="SIP" Dst-alias="sip:jorobb@rtp.ciscotac.net" Call-serial-number="a3e44231-f62a-4e95-a70e-253701a89515" Tag="73c276e2-3917-4a0c-9fc5-ddde83b49fd0" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2017-09-19 18:16:15,835"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,830" Module="network.sip" Level="INFO": Action="Received" Local-ip="192.168.1.5" Local-port="26847" Src-ip="192.168.1.6" Src-port="7003" Detail="Receive Request Method=INVITE, CSeq=1, Request-URI=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=, Msg-Hash=11449260850208794722, Local-SessionID=daf7c278732bb5a557fb57925dffcbf7, Remote-SessionID=00000000000000000000000000000000"
2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="INFO": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Detail="Sending Response Code=404, Method=INVITE, CSeq=1, To=sip:jorobb@rtp.ciscotac.net, Call-ID=9062bca7eca2afe71b4a225048ed5101@127.0.0.1, From-Tag=872524918, To-Tag=96b9a0eaf669a590, Msg-Hash=254718822158415175, Local-SessionID=00000000000000000000000000000000, Remote-SessionID=daf7c278732bb5a557fb57925dffcbf7"

2017-09-19T14:16:15.836-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-19 18:16:15,836" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="26847" Dst-ip="192.168.1.6" Dst-port="7003" Msg-Hash="254718822158415175"
SIPMSG:
|SIP/2.0 404 Not Found
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKc81c6c4dddef7ed6be5bdce9868fb019913;proxy-call-id=a82052ef-6fd7-4506-8173-e73af6655b5d;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bKb0eba6d700dfdf761a8ad97fff3c240124;x-cisco-local-service=nettle;received=192.168.1.6;rport=43119;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK6fe399bae58fb0d70c9d69b8e37e13e5912.4248943487bff4af6f649b586c7696bb;proxy-call-id=f2d15853-c81f-462f-b3e5-c08124f344a3;received=172.16.2.2;rport=25016
Via: SIP/2.0/TLS 192.168.5.66:5062;branch=z9hG4bK0f455ca79cf1b0af5637333aa5286436;received=146.20.193.45;rport=35464;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-383039-8f0d64025c04d23b6d5e1d5142db46ec;rport=52706
Call-ID: 9062bca7eca2afe71b4a225048ed5101@127.0.0.1
CSeq: 1 INVITE
From: "pstojano test" 
     
     ;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

Si l’on compare avec un scénario de fonctionnement, dans un tel scénario, la logique de recherche s’exécuterait selon l’en-tête de routage (FQDN de grappe)

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

On peut ensuite voir que l’Expressway-C transmet correctement l’appel vers Unified CM (192.168.1.21).

2017-09-22T13:56:02.232-04:00 rtp12-tpdmz-118-VCSC tvcs: UTCTime="2017-09-22 17:56:02,232" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="192.168.1.5" Local-port="25606" Dst-ip="192.168.1.21" Dst-port="5065" Msg-Hash="866788495063340574"
SIPMSG:
|INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
Via: SIP/2.0/TCP 192.168.1.5:5060;egress-zone=CUCM11;branch=z9hG4bK251d6daf044e635607cc13d244b9ea45138220.69ccb8de20a0e853c1313782077f77b5;proxy-call-id=17aa8dc7-422c-42ef-bdd9-b9750fbd0edf;rport
Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKba323da436b2bc288200d56d11f02d4d272;proxy-call-id=32c76cef-e73c-4911-98d0-e2d2bb6fec77;received=192.168.1.6;rport=7003;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK06cde3f662d53a210b5b4b11b85500c19;x-cisco-local-service=nettle;received=192.168.1.6;rport=42533;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK297799f31d0785ff7449e1d7dbe3595b271.2ed90cbed5b79c6cffad9ecd84cc8337;proxy-call-id=3be87d96-d2e6-4489-b936-8f9cb5ccaa5f;received=172.16.2.2;rport=25005
Via: SIP/2.0/TLS 192.168.4.146:5062;branch=z9hG4bK043ca6360f253c6abed9b23fbeff9819;received=148.62.40.64;rport=36149;ingress-zone=HybridCallServicesDNS
Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-353038-8c648a16c2c5d7b85fa5c759d59aa190;rport=47732
Call-ID: daa1a6fa546ce76591fc464f0a50ee32@127.0.0.1
CSeq: 1 INVITE
Contact: <sip:192.168.1.6:5073;transport=tls>;call-type=squared
From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=567490631
To: <sip:jorobb@rtp.ciscotac.net>
Max-Forwards: 14
Route: 
     
     
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)

À la suite de cette analyse de la journalisation de diagnostic, qui a permis de constater que le problème se limite à l’Expressway-C et plus particulièrement, qu’il s’attribue à une erreur précise (404 Not Found), vous pouvez axer vos efforts sur ce qui cause ce type de comportement. Voici certains apsects à envisager :

1. Les appels sont déplacés entre les zones de l’Expressway au moyen de règles de recherche.
2. L’Expressways fait appel à une logique préétablie de prise en charge du routage SIP (Preloaded SIP routes support). Cela permet de traiter les demandes d’invitation de SIP qui contiennent des en-têtes de routage. Il est possible d’activer ou de désactiver cette valeur dans les zones (serveur de traverse, client de traverse, voisin) sur l’Expressway-C et l’Expressway-E.

Vous pouvez désormais utiliser xConfiguration pour afficher la configuration du serveur de traverse Expressway-E et des zones client de l’Expressway-C, surtout lorsque ces configurations sont destinées à Hybrid Call Service Connect. Outre la configuration de la zone, vous pouvez analyser les règles de recherche qui sont configurées pour transmettre cet appel d’une zone à l’autre. Vous savez également que l’Expressway-E a communiqué l’appel vers l’Expressway-C. Ainsi, la configuration de la zone du serveur de traverse est probablement bien effectuée.

Approfondissons cette question. Vous verrez ci-dessous que xConfig indique que cette zone s’appelle Hybrid Call ServiceTraversal (traverse d’Hybrid Call Service). Il s’agit d’un type de zone TraversalServer . Ce type communique avec l’Expressway-C sur le port TCP de SIP 7003.

Pour le l’Hybrid Call Service, l’élément central est que la prise en charge Preloaded SIP routes support doit être activée. Dans l’interface Web d’Expressway, cette valeur s’appelle Preloaded SIP routes support , tandis que xConfiguration l’affichera sous l’appellation SIP PreloadedSipRoutes Accept

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"

Vous pouvez également déterminer que cette zone est reliée à une règle 3 de recherche (Webex Hybrid). Essentiellement, la règle de recherche communique un alias correspondant à « l’un ou l’autre », par l’entremise de la zone DNS. Celui-ci est ensuite transmis à la zone au-dessus, la traverse Hybrid Call Service. Comme l’on pouvait s’y attendre, la règle de recherche et la zone de serveur de traverse sont configurées correctement sur l’Expressway-E.

*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 vous mettez l’accent sur xConfiguration de l’Expressway-c, vous pouvez commencer par examiner la zone client de traverse pour Webex Hybrid. Pour la trouver facilement, faites une recherche sur le numéro de port découvert grâce à xConfiguration sur l’Expressway-E (Port de SIP  : « 7003 »). Cela vous permet de cerner rapidement la zone correcte dans xConfiguration.

Comme il en a été question auparavant, vous pouvez apprendre le nom de zone (Hybrid Call Service Traversal), le type (Traversal Client) et les autres aspects configurés pour la fonction SIP PreloadedSipRoutes Accept (Preloaded SIP routes support). Comme vous pouvez le voir dans xConfiguration, cette valeur est désactivée (« Off »). Selon le guide de déploiement pour Cisco Webex Hybrid Call Services, cette valeur doit être activée (« On »).

En outre, à la lecture de la définition de la fonction Preloaded SIP routes support, on constate qu’il est clairement indiqué que l’Expressway-C doit REFUSER un message si cette valeur est désactivée ET que l’invitation (INVITE) comprend un en-tête de routage : « Preloaded SIP routes support doit être désactivé (« Off ») si vous souhaitez que la zone rejette les demandes d’invitation de SIP avec un en-tête. »

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"

À ce stade, vous avez établi que le problème se limite à une erreur de configuration de la zone client de traverse d’Expressway-C. Vous devez activer la prise en charge Preloaded SIP routes support (« On »)

Solution

Pour configurer correctement la prise en charge Preloaded SIP routes support :

1. Ouvrez une session dans l’Expressway-E
2. Naviguez jusqu'à Configuration > Zones > Zones
3. Sélectionnez la zone de client de traverse d’Hybrid Call Service (le nom variera selon le client)
4. Définir la prise en charge Preloaded SIP routes support pour qu’elle soit activée (« On »)
5. Sélectionnez Save (enregistrer)

Note: Tandis que ce scénario a mis en évidence une défaillance sur l’Expressway-C, les mêmes erreurs de journalisation de diagnostic pourraient s’observer sur l’Expressway-E si la prise en charge Preloaded SIP routes support a été désactivée dans la zone du serveur de traverse Webex Hybrid Call. Si c’était le cas, l’appel n’aurait jamais atteint l’Expressway-C et c’est l’Expressway-E qui aurait été responsable de rejeter l’appel et d’envoyer l’erreur 404 Not Found.

Problème 5. L'application Cisco Webex reçoit deux notifications d'appel (toasts)

Ce problème en particulier est le seul scénario d’appels entrants qui ne conduit pas à une interruption d’appel. Lorsque ce problème survient, la personne recevant l’appel (l’appelé) reçoit deux notifications (ou invites) dans l’application Cisco Webex de la part de la personne qui a fait l’appel (la partie appelante). La première notification provient de Cisco Webex et la deuxième vient de l’infrastructure sur place. Ci-dessous, vous trouverez des échantillons des notifications reçues, comme l’illustre l’image.

La première notification (invite) vient de la personne qui a lancé l’appel (la partie appelante) du côté de Cisco Webex. Dans ce cas-ci, l’ID de l’appelant est le nom d’affichage de l’utilisateur qui a lancé l’appel. La deuxième notification (invite) provient de la CTI sur place ou de Cisco Webex RD qui est affecté à l’utilisateur qui passe l’appel. Au départ, ce comportement semble étrange. Cependant, si vous passez en revue le diagramme des appels entrants (dans le guide de conception de Cisco Webex Hybrid), le comportement semble plus logique, comme le révèle l’image.

L’illustration montre qu’Alice appelle Bob au moyen de son application Cisco Webex. L’appel est transmis vers le site sur place. Cet appel devrait correspondre à l’URI de l’annuaire s’attribuant au téléphone de Bob. Le problème vient de ce que dans cette conception, l’URI de l’annuaire s’attache aussi au CTI-RD ou au Cisco Webex RD de Bob. Par conséquent, lorsque l’appel est communiqué à CTI-RD ou à Cisco Webex RD, l’appel est renvoyé vers Cisco Webex, car la configuration du périphérique prévoit une destination à distance pour bob@example.call.ciscospark.com. Cisco Webex aborde cette situation en annulant ce segment d’appel en particulier. 

Pour Cisco Webex correctement annuler le segment d’ appel, Cisco Webex initialement requises pour a mis un jeu de paramètres dans le SIP en-tête laquelle il serait allure pour les annuler ce segment donné. Le paramètre que Cisco Webex insère dans l’invitation (INVITE) de SIP s’appelle « call-type=squared » et cette valeur est saisie dans l’en-tête de contact. Si cette valeur disparaît du message, Cisco Webex ne comprend pas comment annuler l’appel. 

Compte tenu de cette information, vous pouvez examiner sous un autre angle le scénario présenté plus tôt, dans lequel l’application Cisco Webex de l’utilisateur recevait deux notifications (invites) lorsque Jonathan Robb, l’utilisateur de Cisco Webex, faisait un appel. Pour résoudre ce type de problème, il faut toujours recueillir de l’information de journalisation de diagnostic provenant d’Expressway-C et d’Expressway E. Comme point de départ, vous pouvez consulter les journaux d’Expressway-E. Cela vous permettra de déterminer que l’invitation (INVITE) de SIP comprend la valeur call-type=squared . Cette valeur se trouve dans l’en-tête de la première invitation entrante de Cisco Webex. Cela fera en sorte que le pare-feu ne manipule pas le message de n’importe quelle façon. Ci-dessous est un échantillon de l’invitation (INVITE) arrivant sur l’Expressway-E dans ce scénario.

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" 
     
     ;tag=540300020
 To: 
     
      
      
 Max-Forwards: 70 
      
 Route: 
      
        , 
        
       
     

L’en-tête de contact comprend la valeur call-type=squared. À ce moment-là, l’appel doit s’acheminer sur l’Expressway vers la zone du serveur de traverse Webex Hybrid. Nous pouvons faire des recherches dans les journaux d’Expressway-E pour déterminer de quelle manière l’appel est envoyé de l’Expressway-E. Cela permettra de vérifier si l’Expressway-E manipule l’invitation d’une façon ou d’une autre. 

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" 
     
     ;tag=540300020
To: 
     
     
Max-Forwards: 15
Route: <sip:cucm.rtp.ciscotac.net;lr>

À l’examen de l’invitation (SIP INVITE) qui est en cours d’envoi de l’Expressway-E à l’Expressway-C, vous observerez que l’en-tête ne comprend plus la valeur call-type=squared. Signalons aussi qu’à la ligne 4, comme vous pourrez le voir, vous pouvez voir que la zone de sortie (egress-zone) correspond à HybridCallServiceTraversal. Vous pouvez maintenant conclure que la raison pour laquelle l’application Cisco Webex reçoit une deuxième notification (invite) lorsqu’on l’appelle vient de la disparition, dans l’Expressway-E, de la balisecall-type=squared qui était contenue dans l’en-tête de contact de l’invitation (INVITE) de SIP. Il faut maintenant répondre à la question de savoir ce qui pourrait faire disparaître l’information dans l’en-tête.

L’appel doit s’acheminer par la traverse de Hybrid Call Service qui est configurée dans l’Expressway. C’est donc un bon endroit pour commencer l’examen. Si vous avez xConfiguration, vous pouvez voir comment cette zone est configurée. Pour cerner la zone dans xConfiguration, il suffit d’utiliser le nom enregistré dans la ligne Via qui apparaît dans les journaux. Vous pouvez voir ci-dessus qu’elle s’appelle egress-zone=HybridCallServiceTraversal. Lorsque ce nom est imprimé dans la ligne Via de l’en-tête de SIP, les espaces sont supprimés. Sous l’angle de xConfiguration, le vrai nom comprendrait des espaces et serait formaté à la traverse d’Hybrid Call Service. 

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

Grâce aux paramètres cernés dans la traverse Hybrid Call Service, vous pouvez faire des recherches pour repérer des paramètres se démarquant, par exemple :

• SIP PreloadedSIPRoutes Accept : On (activé)
• SIP ParameterPreservatoin Mode : Off (désactivé)

Dans l’interface Web d’un Expressway, vous pouvez consulter la définition de ces valeurs et leurs fonctions.

Preloaded SIP Routes support (prise en charge préétablie du routage de SIP)

Activez la prise en charge Preloaded SIP routes support (« On ») pour permettre à cette zone de traiter les demandes d’invitation de SIP comprenant un en-tête de routage.

Preloaded SIP routes support doit être désactivé (« Off ») si vous souhaitez que la zone rejette les demandes d’invitation de SIP avec un en-tête.

SIP parameter preservation (préservation des paramètres de SIP)

Sortant : Le site vers Cisco Webex

Presque tous les échecs d’une communication provenant d’un site à destination de Cisco Webex entraînent les mêmes symptômes déclarés : « Lorsque j’appelle un autre utilisateur activé dans Call Service Connect de mon téléphone enregistré auprès de Unified CM, son téléphone sonne, mais pas son application Cisco Webex. » Afin de résoudre ce genre de problématique, il est important de comprendre les flux d’appels et la logique s’appliquant lorsque ce type d’appel s’effectue.

Flux logique de haut niveau

1. L’utilisateur A lance un appel de son téléphone sur les lieux à l’URI de l’annuaire de l’utilisateur B
2. Le téléphone sur place de l’utilisateur B et CTI-RD/Webex-RD acceptent l’appel
3. Le téléphone sur place de l’utilisateur B commence à sonner
4. CTI-RD/Webex-RD de l’utilisateur B achemine cet appel vers la destination de UserB@example.call.ciscospark.com
5. Unified CM transmet cet appel à l’Expressway-C
6. L’Expressway-C envoie l’appel vers l’Expressway-E
7. L’Expressway-E effectue une recherche de DNS dans le domaine callservice.ciscospark.com
8. L’Expressway-E tente de se connecter à l’environnement Cisco Webex sur le port 5062
9. L’Expressway-E et l’environnement de Cisco Webex amorcent une prise de contact mutuelle
10. L’environnement de Cisco Webex parvient à passer l’appel sur l’application Cisco Webex disponible de l’utilisateur B
11. L’application disponible Cisco Webex de l’utilisateur B commence à sonner.

Flux d’appels

Naviguez jusqu’à User B on-prem phone > Unified CM > CTI-RD/Webex-RD > Expressway-C > Expressway-E > Cisco Webex environment > Cisco Webex app , comme l’indique l’image.

Note: L’image est tirée du guide de conception Cisco Webex Hybrid.

Conseils pour l’analyse de journal

Si vos efforts de dépannage ont pour objet une situation dans laquelle des appels sortants acheminés vers Cisco Webex n’ont pas fonctionné correctement, vous souhaiterez recueillir les journaux d’Unified CM, d’Expressway-C et d’Expressway-E. Ces ensembles de journaux vous permettront de vérifier comment l’appel est transmis à l’échelle de l’environnement. Une autre façon rapide de comprendre jusqu’où l’appel se déplace au sein de votre environnement sur place consiste à utiliser la fonction de l’historique de recherche (« Search History »). L’historique de recherche Expressway vous permettra de voir rapidement si l’appel acheminé vers Cisco Webex parvient à joindre l’Expressway-C ou l’Expressway-E.

Pour utiliser l’historique de recherche, vous pouvez suivre les étapes suivantes :

1. Ouvrez une session dans l'Expressway-E
   Faites un appel de test
   Naviguez jusqu’à Status > Search History
   Vérifiez si vous consultez un appel qui a une adresse de destination de l’ Webex uri de TYPE SIP qui devrait être appelé (user@example.call.ciscospark.com)
   Si l’historique de recherche ne révèle pas que l’appel s’est rendu sur l’Expressway-E, répétez la démarche sur l’Expressway-C

Avant d’analyser les journaux de diagnostic sur l’Expressway, songez aux façons de cerner cet appel :

1. L’URI de demande de SIP sera l’adresse SIP de l’utilisateur de Cisco Webex
2. Le champ SIP FROM sera formaté pour que l'appelant soit répertorié comme « Prénom Nom » <sip:Alias@Domain>

Compte tenu de cette information, vous pouvez faire une recherche dans les journaux de diagnostic en fonction des paramètres suivants : URI de l’annuaire de la partie qui appelle, prénom et nom de la personne qui appelle ou adresse de SIP de Cisco Webex de la personne appelée. Si vous n’avez aucune de ces informations, vous pouvez effectuer une recherche sur "INVITE SIP :" qui localisera tous les appels SIP exécutés sur l’Expressway. Une fois que vous avez trouvé l’invitation de SIP de l’appel sortant, vous pouvez repérer et copier l’identifiant de l’appel SIP (SIP Call-ID). Une fois que vous avez cette donnée, vous pouvez simplement faire une recherche dans les journaux de diagnostic en fonction de l’identifiant de l’appel (Call-ID ) pour voir tous les messages s’attachant à ce segment d’appel.

Voici quelques-uns des problèmes les plus courants observés avec des appels sortants d’un téléphone Unified CM à destination de l’environnement de Cisco Webex lorsque l’appel est destiné à un utilisateur qui est activé sur Call Service Connect.

Problème 1. Expressway ne peut pas résoudre l’adresse callservice.ciscospark.com

La procédure de fonctionnement standard pour une zone DNS d’Expressway consiste à effectuer une recherche de DNS de DNS fondée sur le domaine qui s’affiche à la droite de l’URI de demande. Pour expliquer cela, voici un exemple. Si la zone de DNS devait recevoir un appel comprenant l’URI de la demande pstojano-test@dmzlab.call.ciscospark.com, habituellement, la zone de DNS d’Expressway appliquerait la logique de recherche de SRV de DNS sur dmzlab.call.ciscospark.com , qui est à droite de l’URI de la demande. Si l’Expressway le faisait, vous pourriez vous attendre aux recherches et réponses que voici.

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

Un examen attentif permet de constater que la réponse de SRV est une adresse de serveur et le port 5061, plutôt que 5062.

Cela signifie que la prise de contact mutuelle de TLS qui se produit sur le port 5062 ne sera pas complétée et qu’un port distinct est utilisé pour la signalisation entre Expressway et Cisco Webex. Voici le défi lié à cette situation : le guide de déploiement de Cisco Webex Hybrid Call Services n’aborde pas explicitement l’utilisation du port 5061 parce que certains environnements ne permettent pas les appels interentreprises.

Voici comment contourner cette logique de recherche de SRV dans la zone de DNS : il faut configurer l’Expressway de façon à ce qu’aient lieu des recherches explicites selon une valeur que vous précisez.

Maintenant, dans notre analyse de cet appel en particulier, vous pouvez mettre l’accent sur l’Expressway-E, car vous avez déterminé (au moyen de l’historique de recherche) que l’appel s’est rendu jusque-là. Commencez par la première invitation de SIP (SIP INVITE) se présentant dans l’Expressway-E pour vérifier de quelle zone elle provenait et quelles étaient les règles de recherche appliquées, la zone vers laquelle l’appel se dirigeait et (si l’appel s’est correctement acheminé vers la zone DNS) la logique de recherche de DNS mise en œuvre. 

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

Dans cette invitation SIP, vous pouvez rassembler l'URI de demande (pstojano-test@dmzlab.call.ciscospark.com), l'ID d'appel (991f7e80-9c11517a-130ac-1501a8c0), De (« Jonathan Robb » <sip:5010@rtp.ciscotac.net>), To (sip:pstojano-test@dmzlab.call.ciscospark.com) et User-Agent (Cisco-CUCM11.5). Une fois que l’invitation est reçue, l’Expressway doit prendre des décisions logiques pour déterminer s’il est possible d’acheminer l’appel vers une autre zone. L’Expressway le fait selon des règles de recherche.

2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Search rule '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.ciscospark.com'"
2017-09-19T13:18:50.564-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,564" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

Selon l’extrait du registre ci-dessus, vous pouvez voir que l’Expressway-E a parcouru quatre règles de recherche, mais que seule la règle (Webex Hybrid - to Webex Cloud) a été envisagée. La règle de recherche était assortie à une priorité de 90 et ciblait la destination suivante : la zone DNS d’Hybrid Call Services Maintenant que l’appel est envoyé à la zone DNS, vous pouvez passer en revue les recherches SRV de DNS qui se produisent sur l’Expressway-E

2017-09-19T13:18:50.565-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,565" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="dmzlab.call.ciscospark.com" Type="NAPTR (IPv4 and IPv6)"
2017-09-19T13:18:50.718-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,718" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.dmzlab.call.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T13:18:50.795-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 17:18:50,795" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.64:5061'] (A/AAAA)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5061' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 2"

Dans l’extrait ci-dessus, vous pouvez voir que l’Expressway-E a effectué la recherche SRV en se basant sur le côté droit de l’URI de requête (_sips._tcp.dmzlab.call.ciscospark.com) et qu’il s’est résolu en un nom d’hôte de l2sip-cfa-01.wbx2.com et port 500661. Le nom d’hôte l2sip-cfa-01.wbx2.com correspond à 146.20.193.64. Compte tenu de ce qui précède, la prochaine étape logique dans Expressway consiste à envoyer un paquet SYN de TCP pour 146.20.193.64 afin de tenter d’établir l’appel. Dans le journal de l’Expressway-E, vous pouvez vérifier si ça se produit.

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"

Dans l’extrait de journalisation de diagnostic d’Expressway-E, vous pouvez voir que l’Expressway-E tente de se connecter à l’IP146.20.193.64 qui a précédemment été résolue sur le port 5061 de TCP. Toutefois, cette connexion échoue clairement. Il est possible d’observer la même chose dans les captures de paquets recueillies. 

Selon ces résultats, il est évident que le trafic sur le port 5061 n’est pas fructueux. Toutefois, Hybrid Call Service Connect visait l’utilisation du port TCP 5062, plutôt que 5061. Par conséquent, vous devez songer à la question de savoir pourquoi l’Expressway-E ne parvient pas à effectuer un enregistrement de SRV qui devrait s’associer au port 5062. Pour tenter de répondre à cette question, vous pouvez examiner les éventuels problèmes de configuration dans la zone DNS de WebexHybrid sur l’Expressway-E. 

*c xConfiguration Zones Zone 6 Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Zone 6 DNS SIP Authentication Trust Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Default Transport: "TLS"
*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Name: "ciscospark.com"
*c xConfiguration Zones Zone 6 DNS SIP DnsOverride Override: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Media AesGcm Support: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Media Encryption Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP Media ICE Support: "Off"
*c xConfiguration Zones Zone 6 DNS SIP ParameterPreservation Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP Poison Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP PreloadedSipRoutes Accept: "On"
*c xConfiguration Zones Zone 6 DNS SIP Record Route Address Type: "IP"
*c xConfiguration Zones Zone 6 DNS SIP SearchAutoResponse: "Off"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify InboundClassification: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Mode: "On"
*c xConfiguration Zones Zone 6 DNS SIP TLS Verify Subject Name: "callservice.ciscospark.com"
*c xConfiguration Zones Zone 6 DNS SIP UDP BFCP Filter Mode: "Off"
*c xConfiguration Zones Zone 6 DNS SIP UDP IX Filter Mode: "Off"

Dans xConfiguration de l’Expressway-E, vous pouvez voir que deux valeurs particulières se rattachent aux recherches de DNS : DNSOverride Name et DNSOverride Override. Selon xConfiguration, il appert que la fonction de remplacement DNSOverride Override est désactivée (« Off ») et par conséquent, la fonction DNSOverride Name ne peut pas s’appliquer. Pour mieux comprendre les fonctions de ces valeurs, vous pouvez utiliser l’interface Web de l’Expressway pour obtenir la définition de ces valeurs.

Modify DNS request (devient DnsOverride Override dans xConfig)

Permet de diriger les appels sortants SIP provenant de cette zone à un domaine SIP précisé manuellement au lieu du domaine de la destination de composition. Cette option est principalement conçu pour une utilisation avec Cisco Webex Call Service. Consultez la section www.cisco.com/go/hybrid-services.

Domain to search for (devient DnsOverride Name dans xConfig)

Saisissez un FQDN à trouver dans DNS au lieu de chercher le domaine dans l’URI de SIP des appels sortants. Cela n’a pas d’incidence sur l’URI de SIP original.

Maintenant que vous avez accès à ces définitions, il ne fait aucun doute que ces valeurs, si elles sont correctement définies, sont entièrement pertinentes pour notre logique de recerche de DNS. Si vous associez cela aux instructions du Guide de déploiement pour les services d'appel hybrides Cisco Webex, vous constaterez que la demande de modification DNS doit être définie sur On et que le domaine à rechercher doit être défini sur callservice.ciscospark.com. Si vous changiez ces valeurs afin qu’elles précisent la bonne information, la logique de la recherche de SRV de DNS serait complètement différente. Voici un extrait de ce qui pourrait se produire, sous l’angle de la journalisation de diagnostic d’Expressway-E

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

Solution

1. Ouvrez une session dans l'Expressway-E
2. Naviguez jusqu’à Configuration > Zones > Zones
3. Sélectionnez la zone de DNS Webex Hybrid qui a été configurée
4. Activez la demande de modification de DNS (Modify DNS) (en la réglant à « On »)
5. Définissez le domaine dans lequel faire la recherche de valeur (Domain to search for value) à callservice.ciscospark.com
6. Enregistrez les modifications

Note: S’il n’y a qu’une zone de DNS en cours d’utilisation sur l’Expressway, il faudrait configurer une zone DNS distincte pour utilisation avec Hybrid Call Service, afin de tirer parti de ces valeurs.

Problème 2. Le port 5062 est bloqué en sortie vers Cisco Webex

Un aspect unique des échecs des appels sortants acheminés vers Cisco Webex est que l’application Cisco Webex de la partie appelée affichera un bouton Join pour se joindre à l’appel dans son interface même si le client ne sonne jamais. Comme nous l’avons vu dans le scénario ci-dessus, pour ce problème. vous devrez de nouveau utiliser les mêmes outils et rapports de journalisation pour mieux comprendre où la défaillance est survenue. Pour obtenir des conseils sur la façon d’isoler des problèmes liés aux appels et d’analyser les journaux, consultez la section de cet article, tel que le montre l’image.

Illustration du bouton pour se joindre qui apparaît

Un peu comme pour le problème nº 1 des appels sortants, vous pouvez commencer par analyser les journaux de diagnostic de l’Expressway-E, car vous avez utilisé l’historique de recherche de l’Expressway afin de déterminer que l’appel s’est rendu jusque-là. Comme précédemment, commencez par l’invitation initiale qui arrive dans l’Expressway-E à partir de l’Expressway-C. N’oubliez pas que vous devez rechercher les éléments suivants :

1. Est-ce que l’Expressway-E reçoit l’invitation (INVITE)
2. Est-ce que la logique des règles de recherche permet l’acheminement de l’appel dans la zone DNS d’Hybrid
3. Est-ce que la zone de DNS effectue la recherche de DNS dans le bon domaine
4. Est-ce que le système a tenté une prise de contact mutuelle de TCP sur le port 5062 et est-ce qu’il est parvenu à l’établir
5. Est-ce que la prise de contact mutuelle de TLS s’est révélée fructueuse

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,017" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="3732376649380137405"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK57d8d5c823824bcddfd62f6ff7e09f9939482.899441b6d60c444e4ed58951d07b5224;proxy-call-id=696f6f1c-9abe-47f3-96a4-e26f649fb76f;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12d4b77c97a64;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: 6a48de80-9c11273a-12d08-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
     
     ;tag=328867~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106829
 To: 
     
     
 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>

Comme vous pouvez le voir dans l’invitation (INVITE) ci-dessus, l’invitation reçue est normale. Il s’agit d’ une action de réception qui provient de l’adresse IP d’Expressway-C. Vous pouvez désormais passer à la logique des règles de recherche

2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Search rule '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.ciscospark.com'"
2017-09-19T10:18:35.023-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,022" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'Webex Hybrid - to Webex Cloud' towards target 'Hybrid Call Services DNS' at priority '90' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

En vous basant sur l’extrait de journal ci-dessus, vous pouvez voir que l’Expressway-E a analysé quatre règles de recherche, mais une seule (Webex Hybrid - vers Webex Cloud) a été pris en considération. La règle de recherche avait une priorité de 90 et visait à accéder à la Zone DNS Hybrid Call Services. Maintenant que l’appel est envoyé à la zone DNS, vous pouvez passer en revue les recherches SRV de DNS qui se produisent sur l’Expressway-E C’est parfaitement normal. Maintenant, axez votre examen sur la logique de la recherche de DNS

2017-09-19T10:18:35.048-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,048" Module="network.dns" Level="DEBUG":  Detail="Sending DNS query" Name="_sips._tcp.callservice.ciscospark.com" Type="SRV (IPv4 and IPv6)"
2017-09-19T10:18:35.126-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:18:35,126" Module="network.dns" Level="DEBUG":  Detail="Resolved hostname to:  ['IPv4''TCP''146.20.193.70:5062'] (A/AAAA)  ['IPv4''TCP''146.20.193.64:5062'] (A/AAAA)  Hostname:'l2sip-cfa-02.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV)  Hostname:'l2sip-cfa-01.wbx2.com' Port:'5062' Priority:'5' TTL:'300' Weight:'10' (SRV) Number of relevant records retrieved: 4"

Vous pouvez clairement voir que dans ce cas-ci, l’enregistrement SRV callservice.ciscospark.com est envoyé. La réponse a pour objet quatre différents enregistrements valides qui utilisent tous le port 5062. Ceci est un comportement normal. À ce stade-ci, vous pouvez analyser la prise de contact mutuelle de TCP qui devrait suivre ensuite. Comme il en a été question plus tôt, vous pouvez faire dans les journaux de diagnostic des recherches qui ont pour objet la connexion TCP (« TCP Connecting »). Cherchez à repérer la ligne qui comprend Dst-port="5062". Voici un exemple de ce que vous verrez dans ce scénario :

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"

Vous pouvez également utiliser tcpdump qui fait partie du groupe de journalisation de diagnostic afin d’obtenir de plus amples renseignements sur la prise de contact mutuelle de TCP, comme l’indique l’image.

À ce stade, vous pouvez conclure que l’Expressway-E achemine correctement l’appel. Dans ce scénario, le défi vient de ce qu’une connexion TCP ne peut pas être établie dans l’environnement de Webex. Cela pourrait s’attribuer au fait que l’environnement de Webex ne répond pas aux paquets SYN de TCP. Toutefois, c’est peu probable, car le serveur traitant la connexion est partagé entre un grand nombre de clients. Il est plus probable que certains types de périphériques intermédiaires (pare-feu, IPS, etc.) ne permettent pas l’acheminement externe du trafic. 

Solution

Parce que le problème était isolé, ces données doivent être communiquées à l’administrateur réseau du client. De plus, s’il a besoin de plus amples renseignements, vous pouvez prendre une capture de l’interface externe de l’appareil en périphérie ou du pare-feu en guise de preuves supplémentaires. Sous l’angle d’Expressway, il n’y a aucune autre action à effectuer, car le problème ne se situe pas sur ce périphérique. 

Problème 3. Erreur de configuration de la règle de recherche Expressway

Les erreurs de configuration de la règle de rechercheh sont au nombre des problèmes de configuration les plus répandus pour les Expressways. Les problèmes de configuration de la règle de la recherche peuvent être bidirectionnels, car vous avez besoin de règles de recherche pour les appels entrants et pour les appels sortants. Tandis que vous parcourez le problème, vous découvrirez que si les problèmes de Regex sont assez courants sur l’ Expressway, ils ne sont pas toujours la cause d’un problème de règle de recherche. Dans ce segment en particulier, vous examinerez un appel sortant en défaillance. Comme dans tous nos autres scénarios d’appels sortants acheminés, les symptômes demeurent identiques :

• L’application Cisco Webex de l’utilisateur appelé fait apparaître un bouton pour se joindre à l’appel (Join)
• Le téléphone qui fait l’appel émet une tonalité de rappel
• Le téléphone sur les lieux de l’utilisateur appelé sonne
• L’application Cisco Webex de l’utilisateur appelé n’a jamais sonné

Comme dans tous les autres scénarios, vous voudrez tirer parti des traces de SDL de CUCM, de même que des rapports de journalisation de diagnostic de l’Expressway-C et de l’Expressway-E. Comme dans les autres cas, vous devrez faire appel à l’historique de recherche et aux conseils connexes pour repérer l’appel dans les journaux de diagnostic. De nouveau, au moyen de l’historique de recherche de l’Expressway-E, il est déterminé que l’appel était en train de s’y rendre lorsqu’il a défailli. Vous trouverez ci-dessous le début de l’analyse permettant d’examiner l’invitation de SIP arrivant dans l’Expressway-E en provenance de l’Expressway-C.

2017-09-25T11:26:02.959-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,959" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="25675" Msg-Hash="1536984498381728689"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK1c7bf93ff08014ca5e00bb0b5f8b184b272412.a81f2992e3863ac202a000a3dd599763;proxy-call-id=f79b8631-947b-46d4-a888-911bf0150bfe;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1c8c419938648;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: d58f2680-9c91200a-1c7ba-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
     
     
       ; 
     tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: 
     
     
 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>

À l'aide de l'ID d'appel (d58f2680-9c91200a-1c7ba-1501a8c0) à partir de l'en-tête SIP, vous pouvez rapidement rechercher tous les messages associés à cette boîte de dialogue. Lorsque vous consultez la troisième occurrence dans les journaux pour ce Call-ID, vous pouvez voir que l’Expressway-E envoie immédiatement une erreur 04 Not Found à l’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" 
     
     ;tag=505817~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106972
 To: 
     
     
       >;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 
     

*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: ".*@.*\.ciscospark\.com"
*c xConfiguration Zones Policy SearchRules Rule 6 Pattern Type: "Regex"
*c xConfiguration Zones Policy SearchRules Rule 6 Priority: "101"
*c xConfiguration Zones Policy SearchRules Rule 6 Progress: "Stop"
*c xConfiguration Zones Policy SearchRules Rule 6 Protocol: "SIP"
*c xConfiguration Zones Policy SearchRules Rule 6 SIPTrafficType: "Any"
*c xConfiguration Zones Policy SearchRules Rule 6 Source Mode: "Named"
*c xConfiguration Zones Policy SearchRules Rule 6 Source Name: "Hybrid Call Service Traversal"
*c xConfiguration Zones Policy SearchRules Rule 6 State: "Enabled"
*c xConfiguration Zones Policy SearchRules Rule 6 SystemGenerated: "No"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Name: "Hybrid Call Services DNS"
*c xConfiguration Zones Policy SearchRules Rule 6 Target SIPVariant: "Any"
*c xConfiguration Zones Policy SearchRules Rule 6 Target Type: "Zone"

2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule 'B2B calls to VCS-C' did not match destination alias 'pstojano-test@dmzlab.call.ciscospark.com'"
2017-09-25T11:26:02.966-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,966" Module="network.search" Level="DEBUG":  Detail="Search rule '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.ciscospark.com'"
2017-09-25T11:26:02.967-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 15:26:02,967" Module="network.search" Level="DEBUG":  Detail="Considering search rule 'to DNS' towards target 'DNS' at priority '100' with alias 'pstojano-test@dmzlab.call.ciscospark.com'"

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

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

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

2017-09-25T16:54:43.722-04:00 amer-expressway01 tvcs: UTCTime="2017-09-25 20:54:43,722" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26404" Msg-Hash="17204952472509519266"
 SIPMSG:
 |INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK781a130d234ed9aaec86834368739430283256.34216c32a0de36e16590bae36df388b6;proxy-call-id=3bbbf94a-082e-4088-8f5a-5ea7e82f8aac;rport
 Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK1cf344a8b117e;received=192.168.1.21;ingress-zone=CUCM11
 Call-ID: c030f100-9c916d13-1cdcb-1501a8c0@192.168.1.21
 CSeq: 101 INVITE
 Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=DESKTOP
 Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;party=calling;screen=yes;privacy=off
 Contact: <sip:5010@192.168.1.21:5065;transport=tcp>;video;audio
 From: "Jonathan Robb" 
      
      ;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: 
      
      
 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>

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" 
      
      ;tag=512579~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30107000
 To: 
      
      ;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

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

2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Search Completed" Reason="Forbidden" Service="SIP" Src-alias-type="SIP" Src-alias="5010@rtp.ciscotac.net" Dst-alias-type="SIP" Dst-alias="sip:pstojano-test@dmzlab.call.ciscospark.com" Call-serial-number="48c80582-ec79-4d89-82e2-e5546f35703c" Tag="4fffefed-0512-4067-ac8c-35828f0a1150" Detail="found:false, searchtype:INVITE, Info:Policy Response" Level="1" UTCTime="2017-09-25 20:54:43,726"
2017-09-25T16:54:43.725-04:00 amer-expressway01 tvcs: Event="Call Rejected" Service="SIP" Src-ip="192.168.1.5" Src-port="26404" Src-alias-type="SIP" 

*c xConfiguration Policy AdministratorPolicy Mode: "LocalCPL"

2017-09-19T10:46:10.488-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:10,488" Module="network.sip" Level="DEBUG":  Action="Sent" Local-ip="172.16.2.2" Local-port="25034" Dst-ip="146.20.193.64" Dst-port="5062" Msg-Hash="4309505007645007056"
SIPMSG:
INVITE sip:pstojano-test@dmzlab.call.ciscospark.com SIP/2.0
Via: SIP/2.0/TLS 64.102.241.236:5062;egress-zone=HybridCallServicesDNS;branch=z9hG4bK323e6b15ad0cbbf409751f67848136fa1115;proxy-call-id=a3a78ee2-c01b-4741-b29b-55aedea256d2;rport
Via: SIP/2.0/TLS 172.16.2.2:5073;branch=z9hG4bK350703fe46645f0acddef05b35adc5c157;x-cisco-local-service=nettle;received=172.16.2.2;rport=41511;ingress-zone=DefaultZone
Via: SIP/2.0/TLS 192.168.1.6:5061;egress-zone=DefaultZone;branch=z9hG4bKf71f2bf47233d6ca52b579364594ac6c1114.a402e3f25603f5a77b60b17ea47dbf72;proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb;received=192.168.1.6;rport=25025
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKfcf4cfd09d213a88bd2331cef0bc82b540559.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;received=192.168.1.5;rport=26513;ingress-zone=HybridCallServiceTraversal
Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12dd82194c4f7;received=192.168.1.21;ingress-zone=CUCM11
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 101 INVITE
Remote-Party-ID: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;privacy=off;screen=no;party=calling
Contact: <sip:172.16.2.2:5073;transport=tls>;video;audio
From: "Jonathan Robb" 
      
      
        ;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To: 
        
      
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

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" 
      
      
        ;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833 To: 
       
         ;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

2017-09-19T10:46:27.175-04:00 amer-expressway01 tvcs: UTCTime="2017-09-19 14:46:27,175" Module="network.sip" Level="DEBUG":  Action="Received" Local-ip="192.168.1.6" Local-port="7003" Src-ip="192.168.1.5" Src-port="26513" Msg-Hash="237943800593485079"
SIPMSG:
BYE sip:192.168.1.6:5071;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.1.5:5061;egress-zone=HybridCallServiceTraversal;branch=z9hG4bK90a666b3461356f8cd605cec91e4538240575.494a140082bd66357134b9eed4335df8;proxy-call-id=d4d4e950-babc-45d5-a4a7-c60a8b17a8bd;rport
Via: SIP/2.0/TCP 192.168.1.21:5065;branch=z9hG4bK12ddd10269d39;received=192.168.1.21;ingress-zone=CUCM11
Call-ID: 44bdd400-9c112db1-12d95-1501a8c0@192.168.1.21
CSeq: 102 BYE
From: "Jonathan Robb" <sip:5010@rtp.ciscotac.net>;tag=329447~c9cc7ddc-9592-49e8-a13c-79e26f48eebc-30106833
To: <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=f3734601fb0eb541
Max-Forwards: 69
Route: <sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:7003;transport=tls;lr>,<sip:proxy-call-id=be17a470-0bca-4ad5-8a6c-14872e007efb@192.168.1.6:5061;transport=tls;lr>
User-Agent: Cisco-CUCM11.5
Date: Tue, 19 Sep 2017 14:46:09 GMT
X-TAATag: 14a0bd87-1825-4ecf-9f3d-4a23cfa69725
Reason: Q.850 ;cause=47
Session-ID: 75957d4fb66a13e835c10737aa329445;remote=ed35426ed3ade6fdc3b058792333df2b
Content-Length: 0

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.

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

 SIPMSG:
 |INVITE sip:jorobb@rtp.ciscotac.net SIP/2.0
 Via: SIP/2.0/TLS 192.168.1.6:7003;egress-zone=HybridCallServiceTraversal;branch=z9hG4bKcac6d95278590991a2b516cf57e75827371;proxy-call-id=abcba873-eaae-4d64-83b4-c4541d4e620c;rport
 Via: SIP/2.0/TLS 192.168.1.6:5073;branch=z9hG4bK837b03f2cd91b6b19be4fc58edb251bf12;x-cisco-local-service=nettle;received=192.168.1.6;rport=41913;ingress-zone=DefaultZone
 Via: SIP/2.0/TLS 64.102.241.236:5061;egress-zone=DefaultZone;branch=z9hG4bK524f89592d00ffc45b7b53000271676c370.88b5177ac4d7cfcae1eb8f8be78da055;proxy-call-id=2db939b2-a49b-4307-8d96-23716a2c090b;received=172.16.2.2;rport=25010
 Via: SIP/2.0/TLS 192.168.4.150:5062;branch=z9hG4bK92f9ef952712e6610c3e6b72770c1230;received=148.62.40.63;rport=39986;ingress-zone=HybridCallServicesDNS
 Via: SIP/2.0/TLS 127.0.0.1:5070;branch=z9hG4bK-313634-3d27a6f914badee6420287903c9c6a45;rport=45939
 Call-ID: 3e613afb185751cdf019b056285eb574@127.0.0.1
 CSeq: 1 INVITE
 Contact: <sip:192.168.1.6:5073;transport=tls>
 From: "pstojano test" <sip:pstojano-test@dmzlab.call.ciscospark.com>;tag=145765215
 To: <sip:jorobb@rtp.ciscotac.net>
 Max-Forwards: 15
 Route: 
      
      

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