Handleiding voor probleemoplossing voor Cisco Webex Hybride Call Service Connect

Inleiding

Dit document beschrijft de Cisco Webex Hybrid Call Service Connect-oplossing die uw bestaande Cisco Call Control-infrastructuur toestaat om verbinding te maken met de Cisco Collaboration Cloud, zodat ze kunnen samenwerken.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Kennis van het Cisco Webex-aanbod
• Kennis van de oplossing van snelwegen (B2B)
• Kennis van Cisco Unified Communications Manager (Unified CM) en de integratie ervan met Express
• Unified CM 10.5(2) SU5 of hoger.
• Uitdrukking (B2B) versie X8.7.1 of hoger (X8.9.1 wordt aanbevolen)
• Sneltoets (Connectorhost) — zie Uitdrukconnector Host Support voor Cisco Webex Hybrid Services voor de momenteel ondersteunde versies

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco Unified Communications Manager
• snelwegen
• Webex voor Windows
• Webex voor Mac
• Webexfor iOS
• Webex voor Android
• Cisco Collaboration-endpoints
• Endpoints voor samenwerking via bureaublad
• IP-telefoons
• Softwareclients
  
  

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

De oplossing biedt deze mogelijkheden:

• Gebruik de Webex-app als mobiele zachte client voor audio- en videogesprekken
• Gebruik de app om overal gesprekken te maken en te ontvangen, alsof ze op kantoor waren
• Gebruik Webex, Cisco Jabber of hun schrijftelefoon om te bellen zonder de noodzaak om zich zorgen te maken over de gebruikte optie
• Ontgrendel de vraaggeschiedenis in telefoons op het bedrijf en integreer die geschiedenis in Webex

Het bereik van deze handleiding is gericht op onderwerpen die uniek zijn voor Hybrid Call Service Connect. Aangezien Hybride Call Service Connect over hetzelfde E & C-paar van de Uitdrukker loopt als andere oplossingen zoals Mobiele en Remote Access en Business to Business-oproepen, kunnen problemen met de andere oplossingen de hybride Call Service Connect beïnvloeden. Voor klanten en partners die een expressroutepaar voor gebruik met Call Service Connect opstellen, moet de Cisco VCS Expressway en VCS Control Basic Configuration-handleiding worden vermeld voordat u probeert om Hybrid Call Service Connect te implementeren. Deze handleiding voor probleemoplossing bevat firewalls/NAT-overwegingen en snelontwerp in zowel bijlage 3 als bijlage 4. Bekijk deze documentatie aandachtig. Bovendien wordt er in dit document van uitgegaan dat de host van de expressconnector en de activering van de hybride gespreksservice zijn voltooid. 

Problemen met gespreksopbouw

TMS-handshake-mislukkingen

Hybrid Call Service Connect gebruikt security transportlaag (wederzijds TLS) voor verificatie tussen Cisco Webex en de Expressway-E. Dit betekent dat zowel de Expressway-E als Cisco Webex controleren en het certificaat controleren dat elkaar aanwezig is. Aangezien wederzijdse TLS-problemen zo vaak voorkomen tijdens nieuwe implementaties van de sneltoetsen en de mogelijkheden voor oplossingen zoals Hybrid Call Service Connect, biedt deze sectie nuttige informatie en tips voor het oplossen van op certificaten gebaseerde problemen tussen de snelheden en Cisco Webex.

Wat controleert de expressway-E?

• Was het Cisco Webex-certificaat ondertekend door een openbare CA die in de lijst van Vertrouwde expressweg-E CA is opgenomen?
• Is callservice.ciscospark.com aanwezig in het veld Alternatieve naam voor onderwerp van het Cisco Webex-certificaat?

Wat controleert Cisco Webex?

• Is het expressway-E-certificaat ondertekend door een van de openbare CA's die Webex vertrouwt? (Cisco Webex Trusted CA-lijst)
• Als Expressway-E geen publiekelijk ondertekend certificaat gebruikt, was het expressopecertificaat samen met enige wortel- en intermediaire certificaten geüpload naar de Cisco Webex Control Hub (https://admin.ciscospark.com)?

Dit wordt uitgelegd zoals in de afbeelding.

Handige wederzijdse TLS-tips voor probleemoplossing

1. Onderlinge TLS-handdruk decoderen

Standaard wordt met Wireshark het SIP TLS-verkeer aangeduid als poort 5061. Dit betekent dat elke keer dat u een (wederzijdse) TLS-handdruk wilt analyseren die zich via poort 5062 voordoet, Wireshark niet zal weten hoe u het verkeer goed moet decoderen. Hier is een voorbeeld van de wederzijdse TLS handdruk die over poort 5062 plaatsvindt zoals in de afbeelding wordt getoond.

Zoals u kunt zien, is dit hoe de handdruk er uitziet met de standaardinstellingen van Wireshark. Packet-nummer 175 is het certificaat dat de sneltoets wordt verzonden naar Cisco Webex. Maar dat kun je niet bepalen zonder dat het verkeer wordt gedecodeerd. Er zijn twee methoden die u kunt gebruiken om de decode van dit verkeer te gebruiken zodat u de certificaatinformatie en de eventuele foutmeldingen gemakkelijker kunt zien.

1 bis. De stream als SSL decoderen

a. Wanneer u de handdruk van het wederzijdse TLS analyseert, eerst filtert u de opname door tcp.port==5062. Klik vervolgens met de rechtermuisknop op het eerste pakket in de stream en selecteer Decode als... zoals in de afbeelding wordt weergegeven.

b. Zodra de optie Decode As... is geselecteerd, ziet u een lijst waarin u kunt selecteren hoe u de geselecteerde stream kunt decoderen. Selecteer in de lijst SSL en klik op Toepassen en sluit het venster. Op dit punt toont de gehele stream het certificaat en de foutmeldingen die werden uitgewisseld tijdens de handdruk zoals in de afbeelding.

1 ter. SIP-TLS-poort aanpassen

Wanneer u de SIP TLS poort naar 5062 aanpast in de Voorkeuren voor draadloos harden, kunt u dan alle details zien die de handdruk omringen, die de certificaten omvat. Zo wijzigt u dit:

• Open Wireshark
• Navigeren in om uit te werken > Voorkeuren
• Protocollen uitvouwen en SIP selecteren
• Stel de SIP-TLS-poort in op 5062 en klik op Toepassen
• Stel de waarde terug op 5061 wanneer de analyse is voltooid zoals in de afbeelding.

Als u dezelfde opname nu analyseert, ziet u pakketten 169-175 gedecodeerd. Packet 175 toont het sneltoets-E certificaat en als u op het pakket boort, kunt u alle certificeringsgegevens zien zoals in de afbeelding.

2. Filtering draadloos haai

Wanneer u pakketvastlegging analyseert, is het gemakkelijk om te verliezen in de hoeveelheid pakketten die in een bepaalde opname worden waargenomen. Het is belangrijk om te begrijpen welk soort verkeer je het meest interesseert zodat je Wireshark kan filteren om dat weer te geven. Hier zijn een aantal veelvoorkomende Wireshark filters die kunnen worden gebruikt om meer informatie te krijgen over een linker-handdruk:

• TCP.poort==5062
• ssl && tcp.port==5062
• ssl.handshake.ertificaat & tcp.port==5062

3. Contractcertificaat aan dop

Van tijd tot tijd kunt u een kopie van een certificaat nodig hebben (server, wortel, of tussenpersoon). Als u niet weet waar u het certificaat wilt vinden dat u zoekt, kunt u het rechtstreeks uit een pakketvastlegging halen. Dit zijn de stappen voor het trekken van het Cisco Webex-certificaat dat bij een wederzijdse TLS-handdruk wordt weergegeven.

1. Het pakkettransport filteren met ssl.handshake.ertificaat en tcp.port==5062
2. Pak het pakket op dat afkomstig is van het Webex-serveradres en is certificaatafgedrukt in het gedeelte Info.
3. In de pakketgegevens vouwt u Secure Socket Layer > TLS Certificate > Handshake Protocol > Certificaten uit.

   Opmerking: Het bodem/laatste certificaat in de keten is de wortel CA.

4. Klik met de rechtermuisknop op het certificaat van belangstelling en selecteer Geselecteerde Packet Bytes... exporteren zoals in de afbeelding.

5. Sla het bestand op als een .cer.

6. Dubbelklik op het opgeslagen bestand om het certificaat te openen zoals in de afbeelding.

4. Instellen van niveaus voor automatische vastlegging

Er zijn twee logmodules beschikbaar op de expressway die u helpen beter te begrijpen welke logica de snelweg hanteert wanneer u de certificaten analyseert:

• ontwikkelaar.ssl
• ontwikkelaar.zone.zonemg
  
  

Standaard worden deze logmodules ingesteld op een INFO-niveau. Wanneer het wordt ingesteld op een DEBUG niveau, kunt u de informatie beginnen te zien over de certificateninspectie die gebeurt, samen met welke zone verkeer in kaart wordt gebracht. Beide functies zijn relevant voor de hybride gespreksservice. 

Voorbeeld van de Expressway-E die een SAN-inspectie van Cisco Webex's servercertificaat uitvoert.

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"

Voorbeeld van de snelweg-E-mapping van de MTLS-verbinding naar de Cisco Webex hybride DNS-zone:

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"

Hier is een lijst van de meest gebruikelijke kwesties die betrekking hebben op wederzijdse TLS-fouten tussen de snelweg-E en Cisco Webex. 

Uitgave 1. Expressway-E is geen Trust certificaatautoriteit (CA) die het Cisco Webex-certificaat heeft ondertekend

De Cisco Webex-server die in directe communicatie met de snelweg-E staat, wordt een L2SIP-server genoemd. Deze L2SIP-server moet door een intermediaire server met een algemene naam van Hydrant SSL ICA G2 worden ondertekend. De intermediair is ondertekend door een basiscertificeringsinstantie die een gezamenlijke naam van QuoVadis Root CA 2 heeft zoals in de afbeelding wordt getoond.

Opmerking: Dit kan veranderen.

De eerste stap om dit verkeer vanuit het diagnostische perspectief van de snelweg te analyseren is naar TCP-verbinding te zoeken. Nadat u TCP-verbinding hebt gezocht, zult u de DST-port=5062 waarde zoeken. Nadat u het gebied in de logbestanden hebt geïdentificeerd waar deze verbinding is gepoogd en ingesteld, kunt u vervolgens de TLS Handshake zoeken, die over het algemeen wordt aangegeven door de logitems die Handshake in uitvoering aangeven.

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"

Als de Expressway-E de Cisco Webex getekende certificaten niet vertrouwt, kunt u verwachten dat de Expressway-E het certificaat onmiddellijk na voltooiing van de handdruk kan verwerpen. Dit kan in het logbestand Expressway-E worden gevonden in deze logitems: 

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"

De foutmelding Expressway kan iets misleiden omdat deze verwijst naar een zelf-ondertekend certificaat in de certificeringsketen. Wireshark laat je de uitwisseling nader bekijken. Vanuit een perspectief van de analyse van de pakketvastlegging van Wireshark kunt u duidelijk zien dat wanneer de Webex-omgeving zijn certificaat presenteert, expressway zich omdraait en met een certificaat met een Onbekende CA-fout zoals in de afbeelding wordt weergegeven.

Oplossing:

Om deze situatie op te lossen, moet u ervoor zorgen dat de Expressway-E de Cisco Webex-certificeringsinstanties vertrouwt. Terwijl u deze certificaten eenvoudig uit een Wireshark spoor kunt halen en ze naar de Trusted CA certificatenwinkel op de Expressway kunt uploaden, biedt de Expressway een eenvoudiger methode:

• Inloggen bij de sneltoets
• Navigatie in naar toepassingen > Cloud certificaatbeheer
• Selecteer de optie Certificaten verkrijgen zoals in de afbeelding.

Op dit punt worden de Cisco Webex-certificeringsinstanties geüpload naar de Express-E Trusted CA-winkel (Onderhoud > Security > Trusted CA-certificaat).

Probleem 2. Onjuiste naam voor TLS Onderwerp Controleer naam op Expressway-E Cisco Webex hybride DNS-zone 

Als onderdeel van de wederzijdse TLS-handdruk maakt de hybride Call Service Connect gebruik van TLS Verificatie. Dit betekent dat, naast het vertrouwen op de Cisco Webex CA certificaten, de Expressway het certificaat controleert door het veld Onderwerp Alternate Name (SAN) van het certificaat te controleren dat wordt aangeboden om er zeker van te zijn dat de waarde zoals callservice.ciscospark.com aanwezig is. Als deze waarde niet aanwezig is, mislukt de inkomende vraag. 

In dit specifieke scenario, stelt de Cisco Webex server zijn certificaat aan de Expressway-E voor. Het certificaat heeft 25 verschillende SAN's. Neem het geval in waar de Expressway-E het certificaat voor de callservice.ciscospark.com SAN controleert maar dat niet vindt. Als aan deze voorwaarde is voldaan, kan je een fout zien die hierop lijkt in de diagnostische houtkap:

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"

Als u Wireshark gebruikt om deze certificaathanddruk te analyseren, kunt u vinden dat nadat Cisco Webex zijn certificaat presenteert, de Expressway RSTs de verbinding kort na zoals in de afbeelding wordt weergegeven.

Om de configuratie van deze waarde te bevestigen, kunt u naar de Webex Hybrid DNS Zone gaan die voor de oplossing is geconfigureerd. Als u de Express-E-configuratie hebt, kunt u naar het gedeelte Zone-configuratie zoeken om te bepalen hoe het TLS de onderwerpregel heeft geconfigureerd. Let er voor xConfiguration op dat de zones worden besteld met Zone 1 als eerste. Hier volgt een xConfiguration van de problematische omgeving die hierboven wordt geanalyseerd.

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

Zoals u in het voorbeeld kunt zien TLS Controleer de Onderwerp Naam is ingesteld op calllservice.ciscospark.com in plaats van callservice.ciscospark.com. (noteer het extra "l").

Oplossing:

Om dit probleem op te lossen, moet de TLS verify-naam worden gewijzigd:

• Inloggen bij de sneltoets
• Navigeren in configuratie > Zones > Zones
• Selecteer Webex Hybride services DNS-zone
• Stel het TLS-type in op CallService.ciscospark.com
• Selecteer Opslaan

Opmerking: Zie de basis voor basisloginggedrag. In deze sectie wordt de snelweg weergegeven die certificatie uitvoert en wordt de Webex Hybrid DNS Zone in kaart gebracht.

Opmerking: Vanaf expresswegcode x12.5 en later is er een nieuwe "Webex"-zone vrijgegeven. Deze Webex-zone vult de configuratie van de zone in die nodig is voor communicatie naar Webex. Dit betekent dat u niet langer de TLS Onderwerp Verificatiemodus hoeft in te stellen en TLS Controleer Onderwerp Naam. Voor vereenvoudiging van de configuratie is het aanbevolen om de Webex-zone te benutten als u x12.5 of hoger van de expressway-code gebruikt. 

Vraag 3. Expressway-E stuurt geen volledige certificaatketen naar Cisco Webex

Als deel van de wederzijdse lenshanddruk, moet Cisco Webex het certificaat van de Uitdrukkracht-E vertrouwen. Cisco Webex heeft een volledige lijst van openbare CA's waarop het vertrouwen heeft. Meestal is een TLS-handdruk geslaagd wanneer uw sneltoets-E certificaat is ondertekend door een openbaar CA dat door Cisco Webex wordt ondersteund. Door het ontwerp stuurt de Expressway-E alleen het certificaat via een TLS-handdruk, ondanks dat het is ondertekend door een openbare CA. Om de volledige keten van certificaten (wortel en tussenproduct) te verzenden, moeten deze certificaten worden toegevoegd aan de Trusted CA-certificaatwinkel op de Expressway-E zelf.

Als aan deze voorwaarde niet is voldaan, verwerpt Cisco Webex het certificaat Expressway-E. Wanneer u een voorwaarde problemen oplost die dit probleem aanpast, kunt u de diagnostische loglogs en de voump van de Expressway-E gebruiken. Wanneer je de diagnostische logs van Expressway-E analyseert, zie je een fout die hier lijkt:

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"

Als je dit analyseert vanuit een Wireshark perspectief, zie je dat de Expressway-E zijn certificaat presenteert. Als u het pakket uitbreidt, kunt u zien dat alleen het servercertificaat wordt verzonden. Cisco Webex wijst deze TLS-handdruk vervolgens af met een Onbekend CA-foutbericht zoals in de afbeelding.

Oplossing:

Om de kwestie in dit scenario aan te pakken moet u de intermediaire en de wortel CA's uploaden die bij de ondertekening van het certificaat van Expressway-E aan de Trusted CA certificslag betrokken zijn:

Stap 1. Meld u aan bij de sneltoets.
Stap 2. Navigeer naar onderhoud > Beveiliging > Vertrouwd CA-certificaat.
Stap 3. Selecteer Bestand onder het menu Upload in de buurt van de onderkant van de UI.
Stap 4. Kies het CA-certificaat dat betrokken was bij de ondertekening van de snelweg-E.
Stap 5. Selecteer CA-certificaat toevoegen.
Stap 6. Herhaal stappen voor alle CA-certificaten die betrokken zijn bij de ondertekening van het Expressway-E-certificaat (Intermediate, Root).
Stap 7. Selecteer CA-certificaat toevoegen.

Nadat dit proces is voltooid, ziet u dat de volledige keten van certificaten betrokken bij het ondertekenen van het Expressway-E server certificaat dat in de key exchange is opgenomen. Hier is een voorbeeld van wat je zou zien als je een pakketvastlegging met Wireshark analyseert.

4. Firewall beëindigt wederzijdse TLS-handdruk

De oplossing van de Uitdrukking interfaces met een firewall. Vaak loopt de inline firewall voor de oplossing één of ander type van toepassing laaginspectie. Vaak met de oplossing van de Uitdrukbaan, wanneer de firewall de controle van de toepassingslaag in werking stelt, zien de beheerders ongewenste resultaten. Dit specifieke probleem helpt u te identificeren wanneer de controle van de toepassingslaag van een firewall de verbinding abrupt heeft verstoord.

Met het gebruik van de diagnostische logbestanden van de Expressway, kunt u de poging tot wederzijdse TLS handdruk zoeken. Deze handdruk, zoals eerder vermeld, zou kort moeten komen nadat de TCP-verbinding via poort 5062 tot stand is gebracht. In dit scenario, wanneer de firewall de verbinding onderbreekt, zie je deze fouten in de diagnostische houtkap.

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"

Vanuit een perspectief van de pakketvastlegging, zult u zien dat de Expressway-E zijn certificaat aan Cisco Webex presenteert. U ziet een TCP RST vanuit de richting van Cisco Webex komen zoals in de afbeelding. 

Op het eerste gezicht denk je misschien dat er iets mis is met het Expressway-E-certificaat. Om dit probleem op te lossen, moet u eerst de antwoorden op deze vragen bepalen:

• Is de snelweg-E ondertekend door een publiek CA dat Cisco Webex vertrouwt?
• Is het sneltoets-E certificaat en alle certificaten betrokken bij de ondertekening van het snelwegcertificaat E handmatig geüpload naar de Cisco Webex Control Hub (https://admin.ciscospark.com)? 

In deze specifieke voorwaarde was de oplossing niet om de WebEx Control Hub van Cisco te gebruiken om de certificaten van de Uitdrukking te beheren. Dit betekent dat het sneltoets-E certificaat moet worden ondertekend door een openbaar CA dat Cisco Webex vertrouwt. Door op het certificaatpakket in de WinShark-opname te selecteren (zoals hierboven wordt geïllustreerd), kunt u zien dat het certificaat door een openbare CA is ondertekend en dat de volledige keten naar Cisco Webex is verzonden. Daarom moet de afgifte niet gerelateerd zijn aan het E-certificaat.

Als u op dit punt nog meer isolatie nodig hebt, kunt u een pakketopname vanuit de externe interface van de firewall uitvoeren. Het gebrek aan SSL-fout in het diagnostische logbestand is echter een belangrijk gegeven. Als u zich hierboven herinnert (Vraag 3.), als Cisco Webex het Expressway-E certificaat niet vertrouwt, moet u een of ander type SSL zien dat de verbinding verbroken maakt. In deze conditie was er geen SSL-fout beschikbaar.

Opmerking: Als u een pakketvastlegging van de firewall buiten interface zou krijgen, zou u geen TCP RST zien binnenkomen vanuit de Cisco Webex-omgeving.

Oplossing

Voor deze specifieke oplossing moet u als partner of klant vertrouwen op uw veiligheidsteam. Het team moet onderzoeken of ze een soort van toepassing-laaginspectie gebruiken voor de expressievloeistof-oplossing en als ze dat zijn, moet dit worden uitgeschakeld. Bijlage 4 van de VCS Control and Expressway Deployment Guide legt uit waarom klanten deze functie aangeraden zijn.

Vak 5. Expressway-E wordt ondertekend door openbare CA, maar Cisco Webex Control Hub heeft alternatieve certificaten geladen

Deze specifieke voorwaarde kan vaak voorkomen wanneer u de oplossing van de Uitdrukking vanuit het niets uitwerkte en u hebt niet het certificaat van de Uitdrukking-E aanvankelijk door een openbaar CA ondertekend. Wat in dit scenario gebeurt is dat u het E-servercertificaat (dat intern is getekend) uploaden naar de Cisco Webex Control Hub zodat u de TLS-onderhandeling met succes kunt voltooien. Daarna krijgt u het Expressway-E-certificaat dat door een openbare CA is ondertekend, maar u vergeet het servercertificaat uit de Cisco Webex Control Hub te verwijderen. Het is belangrijk om te weten dat wanneer een certificaat wordt geüpload naar de Cisco Webex Control Hub, dat certificaat voorrang heeft op welk certificaat en de expressway tijdens de TLS-handdruk toont.

Vanuit een diagnostisch blogperspectief van Expressway-E kan deze kwestie op de houtkap lijken die wordt bereikt wanneer Cisco Webex het expressway-E-certificaat niet vertrouwt — bijvoorbeeld het geval van de Expressway-E die zijn volledige keten niet stuurt of het expressway-E-certificaat dat niet wordt ondertekend door een openbaar CA dat Cisco Webex vertrouwt. Hieronder zie je een voorbeeld van wat je kunt verwachten in de expressway-E logging tijdens de TLS handdruk:

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"

Bekijk dit vanuit het perspectief van Wireshark u hier kunt zien dat de Expressway-E het certificaat presenteert in lijnitem 175. Een paar lijnpunten later wijst de Cisco Webex-omgeving het certificaat af met een onbekende fout van het certificaat zoals in de afbeelding.

Als u het certificaatpakket selecteert dat de sneltoets indrukt-E verstuurt, kunt u de certificaatinformatie uitbreiden om te bepalen of de sneltoets-E

1. is ondertekend door een publiek CA dat Cisco Webex vertrouwt, en

2. haar gehele keten omvat die bij de ondertekening betrokken is .

In deze situatie is aan beide voorwaarden voldaan. Dit suggereert dat er niets mis is met het Expressway-E certificaat.

Oplossing

Stap 1. Meld u aan bij de Cisco Webex Control Hub.
Stap 2. Selecteer Services in het linker deelvenster.

Stap 3. Kies Instellingen onder de hybride gesprekskaart.

Stap 4. Scrolt naar het gedeelte Call Service Connect en kijk onder de Certificaten voor Versleutelde SIP-oproepen om te zien of er ongewenste certificaten zijn opgenomen. Als dit het geval is, klikt u op het pictogram afval naast het certificaat.

stap 5. Selecteer Verwijderen.

Opmerking: Het is belangrijk dat de analyse wordt uitgevoerd en dat wordt vastgesteld dat de klant niet de certificaten gebruikt die aan de Webex Control Hub zijn geüpload voordat deze worden verwijderd.

Voor meer informatie over het uploaden van uw expressway-E certificaat in de Cisco Webex Control Hub, controleer dit gedeelte van de Hybrid Call Deployment Guide.

Uitgave 6. Expressway is geen Toewijzing van inkomende oproep aan Cisco Webex Hybrid DNS Zone

De functie Inbound TLS mapping werkt in combinatie met de TLS verify-naam, die beide op de hybride Call DNS-zone zijn ingesteld. Dit scenario schetst kwesties en uitdagingen die vóór x12.5 met de snelweg werden waargenomen. In x12 en later werd een nieuw soort zone geïmplementeerd, de "Webex"-zone. Deze zone vult alle benodigde configuratie voor de integratie met Webex voor. Als u x12.5 uitvoert en Webex Hybrid Call implementeert, is het raadzaam het Webex Zone-type te gebruiken zodat het domein van de Hybrid Call Services (callservice.webex.com) voor u automatisch wordt geconfigureerd. Deze waarde komt overeen met de Onderwerp Alternate Name van het Webex certificaat dat tijdens de Mutual TLS handshake wordt aangeboden en dat de verbinding en inkomende mapping naar de expressway in staat stelt om te slagen. 

Als u een codeversie onder x12.5 gebruikt of de Webex-zone niet gebruikt, wilt u de onderstaande uitleg gebruiken die aantoont hoe u problemen kunt identificeren en corrigeren waarbij de expressway de inkomende aanroep naar de Webex hybride DNS-zone niet in kaart brengt. 

Deze optie is in drie stappen verdeeld:

1. Expressway-E accepteert het Cisco Webex-certificaat.
2. Expressway-E inspecteert het Cisco Webex-certificaat om te bepalen of er een Onderwerp Alternatieve naam is die overeenkomt met de TLS verify-onderwerpnaam: callservice.ciscospark.com.
3. Expressway-E brengt de inkomende verbinding door de Cisco Webex Hybrid DNS Zone in kaart.

Indien de echtheidscontrole geen succes heeft, betekent dit dat de certificatie niet is geslaagd. De oproep gaat in de Standaardzone in en wordt routeerd volgens de zoekregels die voor business-to-business scenario's zijn voorzien, als business-to-business is ingesteld op Expressway-E.

Net zoals de andere scenario's, moet u zowel de diagnostische houtkap als pakketvastlegging gebruiken om te bepalen hoe deze fout eruit ziet, dan gebruik de pakketvastlegging om te zien welke kant de RST stuurt. Hier is een voorbeeld van de TCP verbinding die wordt geprobeerd, dan het vestigen. 

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"

Nu de TCP verbinding tot stand is gebracht, kan de TLS Handshake worden uitgevoerd. Je kunt zien kort nadat de handdruk begint, het komt snel uit.  

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"

Kijk naar deze situatie vanuit het perspectief van het glb, je kan een beter gevoel krijgen

• wie de RST stuurt, en
• welke certificaten worden afgegeven om na te gaan of zij juist zijn .

Wanneer je deze specifieke opname analyseert, kan je zien dat de Expressway-E de RST stuurt. Wanneer u het Cisco Webex-certificaat bekijkt dat wordt doorgegeven, kunt u zien dat het de volledige keten verstuurt. Daarnaast kunt u concluderen dat op basis van de foutmelding in het diagnostische logbestand, u het scenario kunt uitsluiten waar de Expressway-E de Cisco Webex openbare CA's niet vertrouwt. Anders ziet u een fout zoals "zichzelf getekend certificaat in certificeringsketen". U kunt in de pakketgegevens graven zoals in de afbeelding.

Door op het Webex Server certificaat te klikken en het uit te breiden om de Onderwerp Alternate Names (dnsName) te zien kunt u verifiëren om ervoor te zorgen dat het callservice.ciscospark.com vermeld heeft.

Navigeren in naar Wireshark: certificaatnummer > Verlenging > Algemene namen > Algemene naam > Naam: callservice.ciscospark.com 

Dit bevestigt volledig dat het Webex-certificaat er prima uitziet.

U kunt nu bevestigen dat het TLS Controleer Onderwerp Naam correct is. Zoals vermeld kunt u, als u de xConfiguration hebt, naar het gedeelte Zone-configuratie zoeken om te bepalen hoe het TLS verify-onderwerpnaam is geconfigureerd. Een ding om op te merken over de xConfiguration is dat de zones besteld worden met Zone 1 de eerste is het creëren. Hier volgt een xConfiguration van de problematische omgeving die hierboven wordt geanalyseerd. Het is duidelijk dat er niets mis is met de TLS verify-naam.

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

Het volgende dat moet worden onderzocht is het TLS verify-kaart. Dit bevestigt als u de TLS-verbinding naar de Webex hybride DNS-zone correct in kaart brengt. De xConfiguration is bedoeld voor de analyse van dit probleem. In de xConfiguration wordt TLS verify-kaart DNS ZIP-TLS genoemd, verify-classificatie. Zoals u in dit voorbeeld kunt zien wordt de waarde op Uit ingesteld.

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

Gezien het feit dat deze waarde op Off is ingesteld, betekent dit dat de VCS verhinderd wordt om inkomende TLS-verbindingen naar deze zone in kaart te brengen. De oproep gaat dus naar de Default Zone en wordt gecontroleerd en routeerd volgens de zoekregels die voor business-to-business-scenario's zijn voorzien, indien business-to-business is ingesteld op Expressway-E..

Oplossing

Om dit aan te pakken moet u de TLS om inkomende mapping op de Hybrid Call DNS Zone op Aan te zetten instellen. Hier zijn de stappen om dat te voltooien.

1. Inloggen bij de sneltoets
2. Navigeren in configuratie > Zones > Zones
3. Selecteer Hybride Call DNS-zone
4. Kies op TLS voor controle van inkomende mapping
5. Selecteer Opslaan

Opmerking: Zie het voor uitgangswaarde houtkapgedrag. In deze sectie wordt de snelweg weergegeven die certificatie uitvoert en wordt de Webex Hybrid DNS Zone in kaart gebracht.

Uitgave 7. Sneltoets-E gebruikt standaard zelfgetekend certificaat

Bij sommige nieuwe implementaties van Hybrid Call Service Connect wordt het ondertekenen van het Expressway-E-certificaat over het hoofd gezien of wordt aangenomen dat het standaard server-certificaat kan worden gebruikt. Sommige mensen denken dat dit mogelijk is omdat de Cisco Webex Control Hub u een aangepast certificaat in het portal laat laden. (Services > Instellingen (onder Hybride Call Card) > Upload (onder Certificaten voor versleutelde oproepen)

Als u aandachtig kijkt naar de formulering van de certificaten voor versleutelde SIP-oproepen, ziet u dit: 'Gebruik certificaten die worden geleverd vanuit de standaard Cisco Collaboration-vertrouwenslijst of uploaden uw eigen certificaten. Als u uw eigen naam gebruikt, zorg er dan voor dat de hostnamen op een geverifieerd domein staan.' Het sleutelstuk in die verklaring is "Controleer of hostname op een geverifieerd domein staat." 

Wanneer u een probleem oplossen dat met deze voorwaarde overeenkomt, houd in gedachten dat het symptoom van de richting van de vraag afhankelijk zal zijn. Als de oproep afkomstig is van een mobiele telefoon, kunt u verwachten dat de Cisco Webex-app niet zal bellen. Als je de oproep uit de zoekgeschiedenis van snelwegen trachtte op te sporen, zou je ook zien dat de oproep tot de expressway-E zou leiden en daar zou stoppen. Als de oproep afkomstig is van een Cisco Webex-app en bestemd is voor het gebouw, belt de telefoon niet op het kantoor. In dat geval zou de veteranengeschiedenis van de snelweg-E en de snelweg-C niets laten zien.

In dit specifieke scenario kwam de oproep van een telefoon in het bedrijf. Met behulp van de Expressway-E Search History kunt u bepalen dat de oproep tot de server is gemaakt. Op dit punt kun je in de diagnostische houtkap duiken om te bepalen wat er gebeurde. Om deze analyse te beginnen, kijk eerst of een TCP verbinding werd geprobeerd en gevestigd over haven 5062. Door in de diagnostische logbestanden van Expressway-E te zoeken naar "TCP-verbinding" en het doorzoeken van de regeloptie met de tag "Dst-port=5062", kunt u bepalen of de verbinding tot stand is gebracht. 

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"

Nu u de TCP-verbinding hebt bevestigd, kunt u de wederzijdse TLS-handdruk analyseren die direct daarna plaatsvindt. Zoals u in het hoofdstuk kunt zien, faalt de handdruk en is het certificaat onbekend (Detail="sslv3 alarmcertificaat onbekend")

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"

Neem een kijkje bij de pakketvastlegging die bij de diagnostische vastlegging Expressway-E is meegeleverd, kunt u zien dat de onbekende fout van het Certificaat afkomstig is van de richting van Cisco Webex zoals in de afbeelding.

Als u het certificaat van de Standaard Server van de Expressway-E inspecteert, kunt u zien dat de 'Common Name' en 'Onderwerp Alternate Names' niet het 'Verified Domain' (rtp.ciscotac.net) bevatten. U hebt dan bewijs over wat de oorzaak van dit probleem is zoals in de afbeelding wordt getoond. 

Op dit punt, bepaalde u dat het de Server certificaat van de Uitdrukking-E moet worden ondertekend door of een Openbaar CA of een Interne CA. 

Oplossing

U hebt twee opties om dit probleem op te lossen:

1. Zorg ervoor dat het E-certificaat wordt ondertekend door een publiek CA dat Cisco Webex vertrouwt.
   
   1. Log in op de sneltoets.
   2. Navigeer naar Onderhoud > Beveiliging > Server certificaat.
   3. Selecteer CSR genereren.
   4. Voer de gewenste certificaatinformatie in en controleer of het veld Aanvullende alternatieve namen het geverifieerde domein bevat dat in de Webex Control Hub is opgenomen.
   5. Klik op Generate CSR.
   6. Laat de CSR aan een derde partij openbare CA ter beschikking voor ondertekening.
   7. Navigeer bij terugkeer van het certificaat naar Onderhoud > Security > Server certificaten.
   8. Selecteer in het gedeelte Upload New Certificate naast het bestand van het servercertificaat, selecteer Bestand kiezen en selecteer het ondertekende certificaat.
   9. Selecteer de gegevens van het uploadcertificaat.
   10. Navigeer naar Onderhoud > Beveiliging > Vertrouwd CA-certificaat.
   11. Selecteer in het gedeelte Upload naast Selecteer het bestand met vertrouwde CA-certificaten en selecteer Bestand kiezen.
   12. Selecteer alle basis- en intermediaire CA-certificaten die door de openbare CA zijn geleverd.
   13. Selecteer CA-certificaat toevoegen.
   14. Start de snelweg opnieuw.
2. Zorg dat het sneltoets-E certificaat wordt ondertekend door een interne CA en uploaden vervolgens de interne CA en Expressway-E naar de Cisco Webex Control Hub.
   
   1. Inloggen in de sneltoets
   2. Navigeer naar Onderhoud > Beveiliging > Server certificaat.
   3. Selecteer Generate CSR
   4. Voer de gewenste certificaatinformatie in die garandeert dat het veld Aanvullende alternatieve namen het geverifieerde domein in de Webex Control Hub bevat
   5. Klik op Generate CSR
   6. CSR leveren aan een derde partij, publiek CA voor ondertekening
   7. Navigeer bij terugkeer van het certificaat naar Onderhoud > Security > Server certificaten
   8. Selecteer in het gedeelte Upload New Certificate naast het bestand van het servercertificaat, selecteer Bestand kiezen en selecteer het ondertekende certificaat
   9. Selecteer de gegevens van het uploadcertificaat
   10. Navigatie naar onderhoud > Beveiliging > Vertrouwd CA-certificaat
   11. Selecteer in het gedeelte Upload naast Selecteer het bestand met vertrouwde CA-certificaten en selecteer Bestand kiezen.
   12. Selecteer alle basis- en intermediaire CA-certificaten die door de openbare CA zijn geleverd.
   13. Selecteer CA-certificaat toevoegen.
   14. Start de snelweg opnieuw.

 2 bis. Upload het interne CA en snelheden-E certificaat naar de Cisco Webex Control Hub
       1. Log in op de Cisco Webex Control Hub als beheerder.
       2. Selecteer Services.
       3. Selecteer Instellingen onder de knop Hybride gespreksservicekaart.
       4. Selecteer Upload in de sectie Certificaten voor versleutelde SIP-oproepen.
       5. Kies de interne CA- en E-certificaten.

Inkomend: Cisco Webex naar locaties

Bijna elke inkomende Cisco Webex naar onbedrijfsmatige mislukking resulteert in hetzelfde gerapporteerde symptoom: "Wanneer ik van mijn Cisco Webex-app naar de app van een andere collega bel, gaat de app van de collega wel maar niet naar de mobiele telefoon." Om dit scenario problemen op te lossen, zult u het behulpzaam vinden om zowel de vraagstroom als de logica te begrijpen die voorkomen wanneer dit type van vraag wordt geplaatst.

Logic-doorloop op hoog niveau

1. De oproep van Cisco Webex-app is gestart
2. De app van de opgeroepen partij
3. De oproep is gericht aan de Cisco Webex-omgeving
4. De Cisco Webex-omgeving moet een DNS-upgrade uitvoeren op basis van de geconfigureerde SIP-bestemming van de klant in de Cisco Webex-controlehub
5. De Cisco Webex-omgeving probeert verbinding te maken met de snelweg via poort 5062
6. De Cisco Webex-omgeving probeert een wederzijdse TLS-handdruk uit te voeren
7. De Cisco Webex-omgeving verstuurt een SIP-verbinding naar de sneltoets, die wordt doorgegeven naar het collaboration-endpoints/IP-telefoon
8. Cisco Webex en de onderneming voltooien de SIP-onderhandeling
9. Cisco Webex en de onderneming beginnen met het verzenden en ontvangen van media.

Call Flow

Navigeer naar Cisco Webex-app > Cisco Webex-omgeving > Expressway-E > On-Premises Collaboration-endpoint/IP-telefoon zoals in de afbeelding getoond.

Hier zijn een aantal van de vaak voorkomende problemen waargenomen bij inkomende oproepen van Webex naar de infrastructuur op locatie.

Probleem 1. Cisco Webex kan niet de snelweg-E DNS SRV/hostname oplossen

Wanneer u aan de Cisco Webex nadenkt om aan te bellen stroom te geven, is de eerste logische stap van Cisco Webex hoe u contact opneemt met de expressway. Zoals hierboven vermeld, zal Cisco Webex proberen om verbinding te maken met de sneltoets op het kantoorgebouw door een SRV-raadpleging uit te voeren op basis van de geconfigureerde SIP-bestemming die in de pagina Hybrid Call Service Settings in de Cisco Webex-controlehub is opgenomen. 

Als u probeert deze situatie vanuit een diagnostisch logperspectief van Expressway-E te oplossen, ziet u geen verkeer vanuit Cisco Webex. Als u probeert om TCP te zoeken verbinden, zou u Dst-port=5062 niet zien, noch zou u een volgende MTLS handdruk of SIP Invite van Cisco Webex zien. 

Als dit de situatie is, moet u controleren hoe de SIP-bestemming is geconfigureerd in de Cisco Webex Control Hub. U kunt ook het Hybrid Connectivity Test Tool gebruiken om bij de probleemoplossing te helpen. Het Hybrid Connectivity Test Tool controleert als er een geldig DNS-adres is, als Cisco Webex verbinding kan maken met de poort die in de SRV-raadpleging is teruggekeerd en als de expressway op het bedrijf een geldig certificaat heeft dat Cisco Webex vertrouwt. 

1. Inloggen op de Cisco Webex Control Hub
2. SelecteerServices
3. Selecteer de instellingslink in de hybride gesprekskaart.
4. Controleer in het vak Call Service Connect het domein dat wordt gebruikt voor het openbare SIP SRV-adres in het veld SIP-bestemming. 
5. Als de record correct is ingevoerd, klikt u op Test om te zien of de record geldig is.
6. Zoals hieronder wordt weergegeven, kunt u duidelijk zien dat het publieke domein geen corresponderende SIP SRV record heeft gekoppeld aan de afbeelding. 

Selecteer testresultaten bekijken en u kunt meer details zien over het mislukken zoals in de afbeelding. 

Als een andere benadering, kunt u het SRV record ook opzoeken door nslookup te gebruiken. Hier zijn de opdrachten die u kunt uitvoeren om te controleren of de SIP-bestemming bestaat.

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

Zoals u in het bovenstaande codeponeringsblok kunt zien, is de opdracht nslookup gestart en is de server ingesteld op 8.8.8.8, een openbare Google DNS-server. Ten slotte, stelt u de record types in om naar SRV records te kijken. Op dat punt kunt u dan het volledige SRV-record uitgeven dat u wilt opzoeken. Het nettoresultaat is dat de verzoeken uiteindelijk worden ingetrokken. 

Oplossing

1. Configureer een openbaar SIP SRV-adres voor de sneltoets-E op de site die zij gebruiken om openbare domeinnamen te host. 
2. Configuratie van een hostname die aan het openbare IP adres van Expressway-E zal oplossen
3. Configureer de SIP-bestemming om een lijst te maken van het domein dat wordt gebruikt voor het SIP SRV-adres dat in Stap 1 is aangemaakt.
   1. Log in op Cisco Webex Control Hub
   2. Selecteer Services
   3. Selecteer de koppeling Instellingen in de hybride telefoonkaart
   4. In het gedeelte Call Service Connect specificeert u het domein dat voor het openbare SIP SRV-adres in het veld SIP-bestemming wordt gebruikt. 
   5. Selecteer Opslaan

Opmerking: Als het SIP SRV-record dat u wilt gebruiken al actief is op het gebied van bedrijfscommunicatie, raden we aan om een subdomein van het bedrijfsdomein te specificeren als het SIP-zoekadres in Cisco Webex Control Hub, en vervolgens een openbaar DNS SRV-record, als volgt:

Service- en -protocol: _sips._tcp.mtls.example.com
Prioriteit: 1
Gewicht: 10
Poortnummer: 5062
Doel: us-expe1.example.com

De bovenstaande aanbeveling is rechtstreeks afkomstig van de Cisco Webex Hybrid Design Guide.

Alternatieve oplossing

Als de klant geen SIP SRV record heeft (en niet van plan is er een te maken), kunnen zij anders een lijst maken van het openbare IP-adres expressway dat wordt aangevuld met ":5062". Door dit te doen, zal de Webex-omgeving geen SRV raadpleging proberen maar rechtstreeks verbinden met de %Expressway_Pub_IP%:5062. (Voorbeeld: 64.102.241.236:5062)

1. Configureer de SIP-bestemming die wordt geformatteerd als %Expressway_Pub_IP%:5062. (Voorbeeld: 64.102.241.236:5062)
   1. Log in op Cisco Webex Control Hub
   2. Selecteer Services
   3. Selecteer de koppeling Instellingen in de hybride telefoonkaart
   4. Voer in het vak Call Service Connect de %Expressway_Pub_IP%:5062 in het veld SIP-bestemming in. 
   5. Selecteer Opslaan

Voor meer informatie over het SIP-adres en/of SRV-record die moet worden ingesteld. Raadpleeg het gedeelte Hybrid Call Service Connect voor uw organisatie van de Cisco Webex Hybrid Call Service Deployment Guide of de Cisco Webex Hybrid Design Guide.

Afdeling 2: Socketfalen: Port 5062 is ingesloten in een expresse-ingang

Nadat de DNS-resolutie is voltooid, probeert de Cisco Webex-omgeving om een TCP-verbinding via poort 5062 naar het IP-adres te creëren dat tijdens de DNS-raadpleging is teruggekeerd. Dit IP-adres wordt het openbare IP-adres van de expressway-E. Als de Cisco Webex-omgeving deze TCP-verbinding niet kan opzetten, wordt de oproep naar het gebouw vervolgens mislukt. Het symptoom voor deze specifieke conditie is hetzelfde als bijna elke andere Cisco Webex-inbound-falen: de telefoon in de ruimte niet belt .

Als u problemen oplossen bij dit probleem met behulp van de diagnostische logbestanden van de snelweg, zult u geen verkeer van Cisco Webex zien. Als u probeert om TCP te zoeken verbinden, zou u geen verbindingspogingen zien voor st-port=5062, noch zou u een volgende MTLS handdruk of SIP Invite van Cisco Webex zien. Aangezien de diagnostische registratie van expressway-E in deze situatie niet nuttig is, hebt u een paar mogelijke verificatiemethoden:

1. Krijg een pakketvastlegging van de externe interface van de firewall
2. Levering van een havencontrolevoorziening
3. Gebruik het testgereedschap voor hybride connectiviteit

Aangezien het gereedschap Hybrid Connectivity Test direct in de Cisco Webex Control Hub is ingebouwd en de Cisco Webex-omgeving simuleert die probeert aan te sluiten op de expressway, is dit de meest ideale verificatiemethode die beschikbaar is. U kunt de TCP-connectiviteit in de organisatie als volgt testen:

1. Inloggen op de Cisco Webex Control Hub
2. SelecteerServices
3. Selecteer de instellingslink in de hybride gesprekskaart
4. In het vak Call Service Connect dient u er zeker van te zijn dat de waarde die in de SIP-bestemming is ingevoerd, juist is
5. Klik op Test zoals in de afbeelding.

  6. Aangezien de test heeft gefaald, kunt u op de link Testresultaten bekijken klikken om de gegevens in de afbeelding te controleren.

Zoals u in de afbeelding hierboven kunt zien, is de Socket-test mislukt bij uw poging om verbinding te maken met 64.102.241.236:5062. Als u deze gegevens naast de diagnostische logbestanden/patches voor expressway hebt, die geen verbindingspogingen tonen, hebt u nu voldoende bewijs om de configuratie van firewalls ACL/NAT/routing te onderzoeken. 

Oplossing

Aangezien dit specifieke probleem niet veroorzaakt wordt door de Cisco Webex-omgeving of de collaboration-apparatuur op gebouwen, moet u zich richten op de firewallconfiguratie. Aangezien u niet noodzakelijkerwijs het type firewall kunt voorspellen waarmee u wordt geconfronteerd, moet u vertrouwen op iemand met vertrouwdheid met het apparaat. Het is mogelijk dat het probleem gerelateerd kan zijn aan een firewall ACL, NAT of een routingfout. 

Uitgifte 3. Socketfalen: Expressway-E staat niet op poort 5062

Deze specifieke aandoening wordt vaak niet correct gediagnosticeerd. Vaak wordt aangenomen dat de firewall de oorzaak is van waarom het verkeer over poort 5062 wordt geblokkeerd. Om deze specifieke situatie op te lossen, kunt u de technieken gebruiken in "Port 5062 is geblokkeerd binnenin het bovenstaande scenario "Expressway". U zult ontdekken dat het gereedschap Hybrid Connectivity Test en elk ander gereedschap dat wordt gebruikt om de poortconnectiviteit te controleren zullen mislukken. De eerste veronderstelling is dat de firewall het verkeer blokkeert. De meeste mensen zullen dan de diagnostische houtkap van de Uitdrukkingsweg-E controleren om te bepalen of zij de TCP verbinding kunnen zien die probeert te vestigen. Ze zullen in het algemeen een loglijnitem zoeken zoals dit in de afbeelding.

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"

In deze voorwaarde bestaat de hierboven vermelde specifieke loggegevens niet. Daarom zullen veel mensen een verkeerde diagnose stellen van de aandoening en ervan uitgaan dat het de firewall is.

Als de pakketvastlegging in de diagnostische vastlegging is opgenomen, kunt u controleren of de firewall niet de oorzaak is. Hieronder staat een voorbeeld van pakketvastlegging uit het scenario waarin de Expressway-E niet luisterde via poort 5062. Deze opname wordt gefilterd door gebruik van tcp.port==5062 als het toegepaste filter zoals in de afbeelding. 

Zoals u kunt zien in de pakketvastlegging die door de sneltoets E is gegenereerd, wordt het verkeer via TCP poort 5062 niet geblokkeerd door de firewall, maar komt in feite aan. In pakketnummer 56 kunt u zien dat de snelweg-E de RST onmiddellijk na het eerste TCP SYN-pakket verzenden. Met deze informatie kunt u concluderen dat de kwestie geïsoleerd is aan de expressway-E die het pakket ontvangt; U moet het probleem oplossen vanuit het standpunt van de snelweg. Gezien het bewijsmateriaal, bedenk mogelijke redenen waarom de Expressway-E het pakje zou REST. Twee mogelijkheden die aan dit gedrag kunnen worden toegeschreven zijn:

1. De Expressway-E heeft een of ander type firewallregels die het verkeer kunnen blokkeren

2. De snelweg-E luistert niet naar wederzijds TLS-verkeer en/of luistert niet naar verkeer via poort 5062.

De firewallfunctionaliteit van de Expressway-E bestaat onder System > Protection > Firewall rules > Configuration. Toen dit in deze omgeving werd gecontroleerd, was er geen firewallconfiguratie aanwezig. 

Er zijn verschillende manieren om te verifiëren of de snelweg-E naar Mutual TLS traffic over poort 5062 luistert. U kunt dit doen door de Web Interface of de CLI als wortelgebruiker. 

Vanuit de wortel van de snelweg, als u netstat afgeeft -an | grep ':5062' , moet u wat output krijgen die vergelijkbaar is met wat u hieronder ziet. 

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

Deze informatie kan ook worden opgenomen via de webinterface van de sneltoets E. Zie de onderstaande stappen om deze informatie te verzamelen

1. Inloggen bij de expressweg-E

2. Navigatie naar onderhoudstools > poortgebruik > Lokale inkomende poorten

3. Zoeken naar poort van het type SIP en IP 5062. (rood gemarkeerd zoals in de afbeelding)

Nu je weet wat je moet zien, kan je dat vergelijken met de huidige omgeving. Vanuit het CLI-perspectief, wanneer je netstat gebruikt -an | grep ':5062' ziet de output er zo uit:

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

Daarnaast toont web UU de Mutual TLS poort niet die is opgenomen in de lijst van lokale inkomende poorten

Met deze gegevens kunt u concluderen dat de Expressway-E niet luistert naar Mutual TLS-verkeer.

Oplossing

Om dit probleem op te lossen, moet u ervoor zorgen dat de Mutual TLS-modus is ingeschakeld en dat de Mutual TLS-poort is ingesteld op 5062 in de Expressway-E:

1. Inloggen bij de sneltoets
2. Navigatie in naar Configuration > Protocols > SIP
3. Zorg ervoor dat de multi-TLS-modus is ingesteld op Aan
4. Zorg ervoor dat de wederzijdse TLS-poort is ingesteld op 5062
5. Klik op Opslaan zoals in de afbeelding.

Vraag 4. E of C ondersteunen vooraf geladen SIP-routekoppen niet

Met de Hybrid Call Service Connect wordt de oproeproutering uitgevoerd op basis van routekop. De routekop is bevolkt op basis van de informatie die het gedeelte Call Service Aware (Express Connector) van de oplossing levert aan Cisco Webex. De host van de expressway-connector vraagt Unified CM voor gebruikers die zijn ingeschakeld voor de Call Service en trekt zowel hun directory URI als de Cluster FQDN van hun Unified CM-thuiscluster. Zie dit voorbeeld, gebruik Alice en Bob:

Als Alice of Bob een gesprek voert, wordt de oproep naar hun Unified CM-vestigingen gestuurd, zodat deze op hun Cisco WebexRD kan worden geankerd voordat u de oproep naar de opgeroepen gebruiker stuurt.

Als Alice Bob moest bellen, zou de oproep naar Alice's Unified CM Home Cluster FQDN (us-cucm.voorbeeldcom) leiden. Als u de SIP INVITE analyseert die Cisco Webex naar de expressway-E stuurt, vindt u de volgende informatie in de SIP-header

Vanuit het perspectief van de Uitvoer worden de regels van het Zoeken ingesteld om de oproep niet door de URI van het verzoek maar eerder de Kop van de Route (us-cucm.voorbeeldcom) te leiden — in dit geval Alice's Unified CM home cluster.

Met deze stichting ingesteld, kunt u problemen oplossen situaties begrijpen waar de snelwegen verkeerd zijn ingesteld, waardoor de bovenstaande logica niet werkt. Zoals bijna elke andere inkomende Hybrid Call Service Connect setup-storing is het symptoom dat de telefoon op zijn terrein niet belt.

Alvorens u de diagnostische logbestanden op de Expressway analyseert, moet u bedenken hoe u deze oproep kunt identificeren:

1. De URI van het SIP-verzoek is de directory URI van de opgeroepen partij.
2. Het veld SIP VANAF is opgemaakt van de bellenpartij die is opgenomen in de lijst met "Voornaam en voornaam" <sip:WebexDisplayName@subdomain.call.ciscospark.com>

Met deze informatie kunt u de diagnostische logbestanden doorzoeken in Directory URI van genaamd Party, First and Last Name of Calling Party, of Cisco Webex SIP Address of the Calling Party. Als u geen van deze informatie hebt, kunt u op "INVITE SIP:" zoeken:" die alle SIP-oproepen plaatst die over de expressway lopen. Nadat u SIP INVITE voor de inkomende vraag hebt geïdentificeerd, kunt u de plaats van de SIP Vraag ID vinden en kopiëren. Nadat u deze waarde hebt, kunt u de diagnostische logbestanden op basis van de Call-ID gewoon doorzoeken om alle berichten te zien die correleren met deze gesprekspartner.

Een ander ding om het routingprobleem te isoleren is te bepalen hoe ver de vraag in de onderneming gaat. U kunt proberen om de informatie te vinden die hierboven op de Expressway-C vermeld staat om te zien of de oproep zover verstuurd is. Zo ja, dan zult u waarschijnlijk uw onderzoek daar willen starten.

In dit scenario ziet u dat de Expressway-C het INVITE van de Expressway-E heeft ontvangen.

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>

Belangrijk is dat de routeheader (Cluster FQDN) nog intact is. Er wordt echter geen zoeklogica uitgevoerd op basis van de routeheader (Cluster FQDN) cucm.rtp.ciscotac.net. Je ziet het bericht meteen verworpen worden met een 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

Vergeleken met een werkscenario zou u zien dat in het werkscenario de zoeklogica wordt uitgevoerd op basis van de Router Header (Cluster FQDN)

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

U kunt dan zien dat Expressway-C correct de oproep naar Unified CM (192.168.1.21) doorgeeft.

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)

Na analyse van de diagnostische houtkap die het probleem geïsoleerd heeft aan de Expressway-C en een specifieke fout (404 Not Found) kan je je concentreren op wat dit soort gedrag zou veroorzaken. Enkele overwegingen zijn:

1. De oproepen worden in en uit zones op de snelweg verplaatst door middel van zoekregels.
2. De expressways gebruiken logica die wordt genoemd Voorgeladen SIP routeondersteuning die SIP INVITE verzoeken verwerkt die routerheader bevatten. Deze waarde kan in de Zones (Traversal Server, Traversal client, buurman) aan of uit worden gezet op zowel expressway-C als Expressway-E.

U kunt de xConfiguration gebruiken om de configuratie op zowel de Expressway-E Traversal server als de Expressway-C client zones te bekijken, in het bijzonder de zones die zijn ingesteld voor Hybrid Call Service Connect. Naast de configuratie van de Zone, kunt u de regels van het Zoeken analyseren die zijn ingesteld om deze oproep van de ene zone naar de andere door te geven. U weet ook dat de Expressway-E de aanroep aan de Expressway-C heeft doorgegeven zodat de Traversal server zone configuratie daar waarschijnlijk correct is ingesteld.

Om dit te onderbreken, vertelt de xConfig hieronder dat de naam van deze zone Hybrid Call Service Traversal wordt genoemd. Het is van het TraversalServer zone type. Het communiceert met de Expressway-C over SIP TCP poort 7003.

Het belangrijkste stuk voor de Hybride Call Service is dat deze SIP-routeondersteuning op moet hebben vooraf geladen. De interface Expressway Web roept deze waarde Voorgeladen SIP-routeondersteuning op, terwijl de xConfiguration het zal weergeven zoals SIP PreloadedSipRoutes Accepteren

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"

U kunt ook bepalen dat deze Zone zoekregel 3 (Webex Hybrid) aan deze regel heeft gekoppeld. De zoekregel stuurt in wezen een 'Any'-alias die door de DNS-zone van de hybride Call Services komt en doorgeeft aan de hierboven genoemde zone, Hybrid Call Service Traversal. Zoals verwacht, worden zowel de zone van de Zoeken als de Transversal Server op de snelweg-E correct ingesteld.

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

Als u zich richt op de xConfiguration van de Expressway-C, kunt u starten door te zoeken naar de Traversal Client-zone voor Webex Hybrid. Eén makkelijke manier om dit te vinden is door te zoeken in het poortnummer dat u hebt geleerd van de SIP-poort (SIP-poort): "7003"). Dit helpt u snel de juiste zone in de xConfiguration-instelling te identificeren.

Zoals eerder kunt u de Zone Name (Hybrid Call Service Traversal), het Type (Traversal Client) en wat is ingesteld voor de SIP PreloadedRoues Accept (vooraf ingestelde SIP-routeondersteuning). Zoals u in deze xConfiguration kunt zien, wordt deze waarde ingesteld op Uit. Gebaseerd op de plaatsingsgids voor de Hybride Bel van Cisco Webex, moet deze waarde op On worden ingesteld.

Daarnaast kunnen we, als we de definitie van de voorgeladen SIP-routes controleren, duidelijk zien dat Expressway-C een bericht moet OPNIEUW-JECT hebben als deze waarde op Off is ingesteld EN INVITe een routeheader bevat: "SIP-routeondersteuning via Switch Preloaded Off, als u wilt dat de zone SIP INVITE-verzoeken met deze header afwijst."

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"

Op dit punt heb je het probleem geïsoleerd aan een verkeerde configuratie van de configuratie van de Expressway-C Traversal-clientzone. U moet de ondersteuning van de voorgeladen SIP-routes naar On wijzigen.

Oplossing

U kunt de ondersteuning van vooraf ingestelde SIP-routes als volgt instellen:

1. Inloggen bij sneltoets-C
2. Navigeren in configuratie > Zones > Zones
3. Selecteer de gebruikerszone van de Hybride Call Service Traversal (de naam zal van klant tot klant verschillen)
4. Stel de ondersteuning van vooraf ingestelde SIP-routes in op On
5. Selecteer Opslaan

Opmerking: Terwijl dit scenario de mislukking op de Expressway-C aantoonde, konden de zelfde diagnostische logfouten worden waargenomen op de Expressway-E als de Voorgeladen SIP routeondersteuning uit was op de Webex Hybrid Call Traversal Server-zone. In dat geval zou je de oproep nooit bij de Expressway-C hebben gezien en de Expressway-E zou verantwoordelijk zijn geweest voor het afwijzen van de oproep en het verzenden van de 404 Not Found.

Vraag 5. Cisco Webex-app ontvangt twee gespreksmeldingen (kantelingen)

Dit specifieke probleem is toevallig het enige inkomende oproepende scenario dat niet in het afzetten van de vraag resulteert. Voor dit probleem ontvangt de persoon die de oproep ontvangt (de zogeheten partij) twee kennisgevingen (berichten) in de Cisco Webex-app van de persoon die de oproep had geplaatst (oproepende partij). Het eerste bericht wordt gegenereerd door Cisco Webex en het tweede bericht komt van de infrastructuur op uw locatie. Hieronder staan monsters van de twee ontvangen kennisgevingen, zoals weergegeven in de afbeelding.

Het eerste bericht (toast) is van de persoon die de vraag (kijkend partij) van de kant van Cisco Webex initieert. De oproepende ID in deze instantie is de Display Name van de gebruiker die de oproep initieert. Het tweede bericht (toast) komt van het bedrijf CTI of Cisco Webex RD dat wordt toegewezen aan de gebruiker die de vraag maakt. In het begin lijkt dit gedrag eigenaardig. Als u echter het inkomende aanroepschema (van de Hybride Call Design Guide van Cisco Webex) bekijkt, is het gedrag logischer zoals in de afbeelding te zien.

Uit de afbeelding kan je zien dat Alice Bob van haar Cisco Webex-app belt en dat de oproep tot het indienen van voorstellen naar het pand wordt gestuurd. Deze vraag moet overeenkomen met de URI van de Map die aan de telefoon van Bob is toegewezen. Het probleem is dat met dit ontwerp, de directory URI ook wordt toegewezen aan zijn CTI-RD of Cisco Webex RD. Daarom, wanneer de oproep aan CTI-RD of Cisco Webex RD wordt aangeboden, wordt de vraag teruggestuurd naar Cisco Webex omdat het apparaat een Remote Destination die voor bob@example.call.ciscospark.com wordt geconfigureerd heeft. De manier waarop Cisco Webex deze situatie behandelt is dat het de specifieke telefoonboog annuleert. 

Om Cisco Webex te kunnen annuleren moet Cisco Webex eerst een parameter in de SIP header plaatsen die nodig is om dat bepaalde been te annuleren. De parameter Cisco Webex invoegen in SIP INVITE wordt "call-type=squared" genoemd en deze waarde wordt ingevoerd in de Contactheader. Als deze waarde van het bericht wordt gestript, begrijpt Cisco Webex niet hoe u de oproep kunt annuleren. 

Met deze informatie kunt u het eerder gepresenteerde scenario bekijken waar de Cisco Webex-app van de gebruiker twee meldingen (tips) ontving toen Cisco Webex-gebruiker Jonathan Robb belde. Om dit type probleem op te lossen, zult u altijd diagnostische houtkap van de Expressway-C en Expressway-E moeten verzamelen. Als startpunt kunt u de sneltoetsen Expressway-E bekijken om te bepalen dat SIP INVITE in feite de Call-type=squared waarde heeft die aanwezig is in de contactkop van de eerste Cisco Webex INVITE die binnensteekt. Dit zal ervoor zorgen dat de firewall het bericht op geen enkele manier manipuleert. Hieronder zie je een voorbeeld van het INVITE dat vanuit dit scenario naar de expressway-E komt.

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

De contactkop heeft de aanwezige call-type=squared waarde. Op dit punt moet de oproep door de sneltoets lopen en uit de zone van de Webex Hybrid Traversal Server worden verstuurd. We kunnen de sneltoetsen Expressway-E doorzoeken om te bepalen hoe de oproep vanuit de expressway-E werd verstuurd. Dit zal ons een idee geven als de Expressway-E de INVITE op een of andere manier manipuleert. 

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>

Wanneer u deze SIP INVITE bespreekt die van de sneltoets-E naar de sneltoets expressievloer-C wordt verzonden, let op dat de contactkop het aanroepen-type=squared mist. Een ander ding om op te wijzen is dat in lijn item 4, je kunt zien dat de spanning-zone gelijk is aan HybridCallServiceTraversal. U kunt nu concluderen dat de reden dat de Cisco Webex-app een tweede melding (toast) krijgt wanneer deze wordt geselecteerd, is vanwege het verwijderen van de Call-type=squared tag van de SIP INVITE Contact header. De vraag die moet worden beantwoord is wat de oorzaak zou kunnen zijn van deze gestripte kop.

De oproep moet via de Hybrid Call Service Traversal lopen die u op de Expressway hebt ingesteld, zodat dit een goede plek is om het onderzoek te starten. Als u de xConfiguration hebt, kunt u zien hoe deze zone is ingesteld. Om de Zone in de xConfiguration te identificeren, kunt u de naam gebruiken die in de Via-lijn is opgenomen en in de logbestanden wordt afgedrukt. Je kunt zien dat het hierboven heet egress-zone=HybridCallServiceTraversal. Wanneer deze naam in de Via lijn van de SIP-header is afgedrukt, worden de spaties verwijderd. De echte naam van de zone vanuit het perspectief van de xConfiguration heeft spaties en is opgemaakt bij de Transversal voor de 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"

Met de instellingen die voor de Hybrid Call Service Traversal zijn geïdentificeerd, kunt u op zoek gaan naar mogelijke instellingen die opvallen, zoals:

• Voorgeladen SIPSIPRoutes aanvaarden: Aan
• SIP-parameterBehoud-modus: Uit

Met behulp van de web interface van elke expressway, kun je zien wat de definitie van deze waarden is en wat ze doen.

Ondersteuning van voorgeprogrammeerde SIP-routers

Ondersteuning van SIP-routes voor overzetten op om deze zone in staat te stellen SIP INVITE-verzoeken te verwerken die de routekop bevatten.

Ondersteuning van SIP-routebeheer voor overzetten als u wilt dat de zone SIP INVITE-verzoeken met deze header afwijst.

SIP-parameterbehoud

Uitgaand: Premises aan Cisco Webex

Bijna elke fout in oproepen bij uitgaande ondersteuning van Cisco Webex leidt tot hetzelfde gerapporteerde symptoom: "Wanneer ik van mijn Unified CM-geregistreerde telefoon naar een andere gebruiker roep die is ingeschakeld voor Call Service Connect, gaat hun mobiele telefoon naar het bedrijf, maar hun Cisco Webex-app niet." Om dit scenario problemen op te lossen, is het belangrijk om zowel de vraagstroom als de logica te begrijpen die plaatsvinden wanneer dit type vraag wordt geplaatst.

Logic-doorloop op hoog niveau

1. Gebruiker A roept vanuit hun telefoon op voorstappen naar de directory URI van Gebruiker B
2. Gebruiker B's ter plaatse en CTI-RD/Webex-RD accepteert de oproep
3. De telefoon van de gebruiker begint bij de ringen
4. CTI-RD/Webex-RD van de gebruiker, die deze oproep doet naar de bestemming van UserB@example.call.ciscospark.com
5. Unified CM geeft deze oproep tot de sneltoets-C door
6. Expressway-C stuurt de oproep naar de snelweg-E
7. Expressway-E voert een DNS-raadpleging uit in het domein CallService.ciscospark.com
8. Expressway-E probeert verbinding te maken met de Cisco Webex-omgeving via poort 5062.
9. Expresway-E en de Cisco Webex-omgeving beginnen een wederzijdse handdruk
10. De Cisco Webex-omgeving geeft de oproep door naar de beschikbare Cisco Webex-app van gebruiker B
11. Gebruiker B's beschikbare Cisco Webex-app begint te bellen.

CallFlow

Navigeer naar Gebruiker B on-prem telefoon > Unified CM > CTI-RD/Webex-RD > Expressway-C > Expressway-E > Cisco Webex-omgeving > Cisco Webex-app zoals in de afbeelding getoond.

Opmerking: De afbeelding is getrokken uit de Cisco Webex Hybrid Design Guide.

Tips voor loganalyse

Als u problemen oplossen bij een situatie waarin de uitgaande geforceerde oproepen naar Cisco Webex mislukken, wilt u de Unified CM, Expressway-C en Expressway-E logbestanden verzamelen. Door deze stammen te hebben, kunt u zien hoe de oproep door de omgeving gaat. Een andere snelle manier om te begrijpen hoe ver de oproep in uw omgeving komt is de "zoekgeschiedenis" van de snelweg te gebruiken. De geschiedenis van het zoeken van de snelweg zal u snel toestaan om te zien of de geforkeerde vraag naar Cisco Webex aan de autosnelweg-C of E begint.

U kunt de zoekgeschiedenis als volgt gebruiken:

1. Inloggen bij de sneltoets
   Plaats een testoproep
   navigeren naar status > zoekgeschiedenis
   Controleer of u een oproep ziet die een doeladres van de Webex SIP URI heeft dat moet worden opgeroepen (user@example.call.ciscospark.com)
   Als de zoekgeschiedenis niet de vraag toont die de expressweg-E zoekgeschiedenis aanslaat, herhaal dit proces dan op de sneltoets-C

Alvorens u de diagnostische logbestanden op de Expressway analyseert, moet u bedenken hoe u deze oproep kunt identificeren:

1. De URI van het SIP-verzoek is het SIP-adres van de Cisco Webex-gebruiker
2. Het veld SIP VANUIT is opgemaakt zodat de bellenpartij in de lijst staat met "Voornaam en achternaam" <sip:Alias@Domain>

Met deze informatie kunt u de diagnostische logbestanden doorzoeken via Directory URI of Calling Party, First and Last Name of Calling Party, of Cisco Webex SIP Address of the Call Party. Als u geen van deze informatie hebt, kunt u een zoekopdracht op "INVITE SIP:" uitvoeren om alle SIP-oproepen te lokaliseren die over de expressway lopen. Zodra u SIP INVITE voor de Uitgaande vraag hebt geïdentificeerd, kunt u de plaats van de Vraag-ID van SIP plaatsen en kopiëren. Nadat je dit hebt, kan je de diagnostische logbestanden gewoon doorzoeken op basis van de Call-ID om alle berichten te zien die correleren met deze callleg.

Hier zijn een aantal van de meest gebruikelijke kwesties die met uitgaande oproepen van de Unified CM-geregistreerde telefoon naar de Cisco Webex-omgeving worden gesignaleerd wanneer de oproep wordt gedaan aan een gebruiker die voor Call Service Connect is ingeschakeld.

Vraag 1. Expressway is niet in staat om het adres callservice.ciscospark.com op te lossen

De standaardprocedure voor een DNS-zone van een snelweg is om een DNS-raadpleging uit te voeren op basis van het domein dat aan de rechterkant van een URI van een aanvraag verschijnt. Om dit te verklaren, denk aan een voorbeeld. Als de DNS-zone een oproep zou ontvangen die een aanvraag URI van pstojano-test@dmzlab.call.ciscospark.com had, dan zou een typische DNS-zone van Expressway de DNS SRV-Lookup-logica uitvoeren op dmzlab.call.ciscospark.com, wat de rechterkant van het verzoek URI is. Als de Expressway dit zou doen, kon je verwachten dat de volgende raadpleging en reactie zouden plaatsvinden.

_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

Als u goed kijkt, ziet u dat de SRV record respons een serveradres en poort 5061 aanbiedt, niet 5062.

Dit betekent dat de wederzijdse TLS-handdruk die via poort 5062 plaatsvindt niet zal plaatsvinden en dat een afzonderlijke poort wordt gebruikt voor het signaleren tussen de sneltoets en Cisco Webex. De uitdaging hiermee is dat de Invoergids voor de Hybride Call Services van Cisco Webex het gebruik van port 5061 niet expliciet uitroept omdat sommige omgevingen geen zaken toestaan om zaken te bellen.

De manier om voorbij deze standaard DNS Zone SRV lookup-logica op de Expressway te werken is door de expressway te configureren zodat deze expliciete zoekopdrachten uitvoert op basis van een waarde die u verschaft.

Wanneer u deze bepaalde oproep analyseert, kunt u zich concentreren op de Expressway-E omdat u heeft bepaald (met behulp van zoekgeschiedenis) dat de oproep tot nu toe heeft geleid. Start met de eerste SIP INVITE die in de Expressway-E komt om te zien welke zone het binnenliep, welke zoekregels worden gebruikt, welke Zone de oproep uitgaat en welke DNS lookup-logica optreedt als je correct naar de DNS-zone wordt verzonden. 

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>

In deze SIP INVITE, kunt u de URI (Application URI), de Call-ID (991f7e80-9c1517a-130ac-1501a8c0), From ("Jonathan Robb" <sip:5010@rtp.ciscotac.net To (SIP:pstojano-test@dmzlab.call.ciscospark.com) en User-Agent (Cisco-CUCM11.5). Nadat deze INVITE is ontvangen, moet de snelweg nu een logisch besluit nemen om te bepalen of hij de oproep naar een andere zone kan sturen. De sneltoets zal dit doen op basis van zoekregels.

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

Op basis van het logfragment hierboven kunt u zien dat de Expressway-E is geparseerd met vier zoekregels, maar er is slechts één (Webex Hybrid - naar Webex Cloud) overwogen. De zoekregel had een prioriteit van 90 en was bedoeld om naar de DNS-zone voor hybride gespreksservices te gaan. Nu de vraag naar een DNS-zone wordt verzonden, kunt u de DNS SRV-favorieten die op de Expressway-E plaatsvinden opnieuw bekijken

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"

In het bovenstaande fragment kunt u zien dat de Expressway-E de SRV-raadpleging heeft uitgevoerd aan de rechterkant van de URI met het verzoek (_sips._tcp.dmzlab.call.ciscospark.com) en dat de functie is opgelost aan een hostname van l2sip-cfa-01.wbx2.com en poort 5061. De hostname l2sip-cfa-01.wbx2.com lost op tot 146.20.193.64. Met deze informatie is de volgende logische stap die de Expressway zal nemen om een TCP SYN-pakket naar 146.20.193.64 te verzenden zodat het kan proberen om de oproep in te stellen. Van de Expressway-E-logging kunt u bekijken of dit gebeurt.

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"

In het bovenstaande diagnostische logingfragment van Expressway-E kunt u zien dat de Expressway-E probeert verbinding te maken met het IP 146.20.193.64 dat eerder werd opgelost via TCP-poort 5061, maar deze verbinding schiet volledig tekort. Dit kan ook worden gezien in het kader van de pakketvastlegging die is verzameld. 

Op basis van deze resultaten is het duidelijk dat het verkeer over port 5061 niet slaagt. Hybride Call Service Connect is echter bedoeld om TCP-poort 5062 en niet 5061 te gebruiken. Daarom moet u bedenken waarom het niet de Expressway-E is die een SRV record oplost die port 5062 zou teruggeven. Om die vraag te beantwoorden kunt u naar mogelijke configuratieproblemen op de Expressway-E Webex hybride DNS-zone zoeken. 

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

In de xConfiguration van de Expressway-E kunt u zien dat er twee speciale waarden voor de DNS-raadpleging zijn: DNSOverify-naam en DNSOverify-correctie. Gebaseerd op deze xConfiguration is de DNSOque Override ingesteld op Off, daarom zou de DNSOverify-naam niet van kracht worden. Om beter te begrijpen wat deze waarden doen, kunt u het Web UI van de Uitdrukking gebruiken om de definitie van de waarden omhoog te kijken.

DNS-aanvraag wijzigen (vertaalt naar DNSOverride in xConfig)

Routes uitgaande SIP-oproepen van deze zone naar een handmatig gespecificeerd SIP-domein in plaats van het domein in de gedialineerde bestemming. Deze optie is voornamelijk bedoeld voor gebruik met Cisco Webex Call Service. Zie www.cisco.com/go/hybrid-services.

Domain om naar te zoeken (vertaalt naar DNSOverride Name in xConfig)

Voer een FQDN in om in DNS in plaats van het zoeken naar het domein in de uitgaande SIP URI te vinden. De oorspronkelijke SIP URI wordt niet gewijzigd.

Nu u deze definities hebt, is het duidelijk dat deze waarden als deze correct zijn ingesteld volledig relevant zijn voor onze DNS lookup-logica. Als u dit koppelt met de verklaringen van de plaatsingsgids voor de Hybride Call Services van Cisco Webex, zou u zien dat het DNS-verzoek wijzigen op On moet worden ingesteld en dat het domein om naar te zoeken op callservice.ciscospark.com moet worden ingesteld. Als u deze waarden zou veranderen om de juiste informatie te specificeren, zou de DNS SRV lookup-logica volledig anders zijn. Hieronder staat een fragment van wat je zou kunnen verwachten vanuit het perspectief van de Expressway-E diagnostische houtkap

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"

Oplossing

1. Inloggen bij de sneltoets
2. Navigeren in naar Configuratiezones > Zones
3. Selecteer de optie Webex Hybrid DNS-zone die is geconfigureerd
4. Stel het DNS-verzoek wijzigen in op On
5. Stel het domein in om naar waarde te zoeken op callservice.ciscospark.com
6. De wijzigingen opslaan

Opmerking: Als er op de snelweg slechts één DNS-zone wordt gebruikt, moet een afzonderlijke DNS-zone worden geconfigureerd voor gebruik met de hybride Call-service om gebruik te maken van deze waarden.

Eigen 2. Port 5062 is geblokkeerd naar Cisco Webex

Een ding dat uniek is aan de geforceerde uitbellen die uitvallen voor Cisco Webex is dat de app Cisco Webex van de opgeroepen partij een gezamenlijke knop op hun app presenteert alhoewel de client nooit ringen. Zoals het scenario hierboven, zal u voor deze kwestie opnieuw de zelfde gereedschappen en het registreren moeten gebruiken om te begrijpen waar de mislukking bestaat. Zie het gedeelte van dit artikel zoals in de afbeelding voor tips over het isoleren van gespreksproblemen en het analyseren van logbestanden.

Illustratie van de gezamenlijke toets die wordt gepresenteerd

Net zoals Uitgaande Call Issue #1 kan je de analyse starten bij de Expressway-E diagnostiek, omdat je de Search History op de expressway hebt gebruikt om te bepalen dat de oproep zo ver komt. Zoals eerder, begin met de eerste INVITE die in de Expressway-E van de Expressway-C komt. Vergeet niet dat je wilt zoeken naar:

1. of de expressway-E de INVITE ontvangt
2. Of de logica van de Zoeken de vraag naar de hybride DNS-zone doorgeeft
3. Of de DNS-zone het DNS-opnameproces uitvoert en op het juiste domein
4. Of het systeem een TCP-handshake voor Port 5062 heeft geprobeerd en juist heeft ingesteld
5. Of de Mutual TLS Handshake is geslaagd

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>

Zoals u in het bovenstaande INVITE kunt zien, wordt het INVITE als normaal ontvangen. Dit is een "ontvangen" actie en het komt van het IP-adres Expressway-C. U kunt nu overgaan op Zoekregel Logic

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

Gebaseerd op het logfragment hierboven, kunt u zien dat de Expressway-E door vier zoekregels is geparseerd maar slechts één regel (Webex hybride - naar Webex Cloud) werd overwogen. De zoekregel had een prioriteit van 90 en was bedoeld om naar de DNS-zone voor hybride Call Services. Nu de vraag naar een DNS Zone wordt verzonden, kunt u de DNS SRV-favorieten bekijken die op de Expressway-E plaatsvinden. Dit is allemaal heel normaal. U kunt zich nu richten op de DNS-opnamelogica

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"

U kunt duidelijk zien dat in dit geval het callservice.ciscospark.com SRV-record is opgelost. Het antwoord is vier verschillende geldige records die allemaal haven 5062 gebruiken. Dit is normaal gedrag. Op dit punt kan je nu de TCP handdruk analyseren die hierna zou moeten komen. Zoals eerder vermeld in het document, kunt u de diagnostische logbestanden naar "TCP verbinden" zoeken en naar het lijnitem zoeken dat de Dst-port="5062" toont. Hieronder zie je een voorbeeld van wat je in dit scenario ziet:

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"

U kunt ook de TCP-handdruk gebruiken die met de diagnostische logbundel was meegeleverd om meer gedetailleerde informatie te krijgen over de TCP-handdruk zoals in de afbeelding wordt weergegeven.

Op dit punt, kunt u concluderen dat de Expressway-E de vraag correct routeert. De uitdaging in dit scenario is dat een TCP verbinding niet met de Webex omgeving kan worden gevestigd. Dit zou kunnen gebeuren omdat de Webex-omgeving niet reageert op het TCP SYN-pakket maar dit is onwaarschijnlijk omdat de server die de verbinding verwerkt, wordt gedeeld tussen vele klanten. De waarschijnlijker oorzaak in dit scenario is een of ander type intermediair apparaat (firewall, IPS, enz.) dat het verkeer niet uit staat. 

Oplossing

Omdat de kwestie geïsoleerd was, zouden deze gegevens aan de netwerkbeheerder van de klant moeten worden verstrekt. Daarnaast kunt u, als u meer informatie nodig hebt, de externe interface van het randapparaat en/of de firewall voor verder bewijs afdrukken. Vanuit het standpunt van de snelweg, is er geen verdere actie te ondernemen aangezien de kwestie niet op dat apparaat ligt. 

Kwestie 3. Onjuiste configuratie van de standaard voor snelwegen

Onjuiste configuratie van de zoekregel is een van de grootste configuratie-gerelateerde problemen op de snelwegen. De configuratiekwesties van de zoekregel kunnen bidirectioneel zijn, omdat u zoekregels voor inkomende oproepen nodig hebt en u zoekregels voor uitgaande oproepen nodig hebt. Terwijl je door deze kwestie loopt, zul je ontdekken dat regex-kwesties vrij algemeen zijn op de expressweg, maar niet altijd de oorzaak zijn van een zoekregel-kwestie. In dit specifieke segment, zal je door een uitgaande roep lopen die faalt. Zoals al onze andere uitgaande geforceerde call scenario's, blijven de symptomen hetzelfde:

• De geroepen app Cisco Webex aangeboden
• De beltelefoon speelde een ring terug
• De telefoon van de opgeroepen gebruiker belde
• De app Cisco Webex van de genoemde gebruiker is nooit gebeld

Zoals alle andere scenario's, zult u ook CUCM SDL sporen samen met Expressway-C en E diagnostische logs willen gebruiken. Zoals eerder, zou u de voor hefboomgeschiedenis en tips van het hefboomeffect van de Geschiedenis van het Onderzoek moeten verwijzen voor het identificeren van een vraag in de diagnostische logboeken. Zoals eerder, werd het bepaald aan de hand van de Expressway-E Search History dat deze oproep het daar maakte en faalde. Hieronder staat het begin van de analyse waarvoor we kijken naar de eerste SIP INVITE die vanuit de expressway-E in de Expressway-C komt.

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>

Met behulp van de Call-ID (d58f2680-9c91200a-1c7ba-1501a8c0) van de SIP-header kunt u snel alle berichten zoeken die bij deze dialoog horen. Wanneer je kijkt naar de derde hit in de blogs voor de Call-ID, zie je dat de Expressway-E direct een 404 Not to the Expressway-C verstuurt. 

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