Hvis noget går galt med udrulningen af din hybrid-opkaldstjeneste til Webex-enheder, kan du bruge disse tip til fejlfinding til at udelukke problemer, før du åbner en sag. Hvert afsnit omhandler et komponent eller et aspekt af løsningen på et øjeblik og fejlfindingsvejledningen indeholder yderligere elementer til kontrol og diagnosticeringsværktøjer, som du kan bruge.
Dette afsnit omhandler testværktøjet til hybridforbindelse. Du kan få adgang til dette fejlfindingsværktøj fra Control Hub.
Du kan også få adgang til de kendte problemer fra de relaterede artikler.
Du kan få adgang til testværktøjet til hybridforbindelse fra ControlHub: fra kundevisningen i skal du gå til Tjenester > Hybrid , klikke på Rediger indstillinger i hybridopkaldskortet, rulle ned til Standard https://admin.webex.comSIP-destinationog klikke på Test ved siden af den SIP-destination, du indtastede.
Denne tabel viser almindelige fejl, der kan blive vist, efter du har testet SIP-destination adresse for hybridopkald. Tabellen indeholder også de næste trin til fejlfinding, herunder links til relevante oplysninger i Fejlfindingsvejledning til hybrid-opkaldstjeneste.
Fejl |
Nøgleord |
Flere oplysninger og fejlfindingstrin |
|---|---|---|
Ingen DNS-adresser fundet |
DNS SRV |
DNS-opslag mislykkedes. Kontrollér, at der findes en DNS- eller SRV-registrering for din SIP-destination, og at den oversættes til en eller flere gyldige IP-adresser. Se Kan ikke løse problemet Expressway-E DNS-SRV/værtsnavnet i fejlfindingsvejledningen for yderligere oplysninger. |
Tilslutningen har timedt ud |
Socket mislykkedes |
Netværk og/eller fælles TLS-tilslutning er time out. Kontrollér netværksforbindelse, forbindelseshastighed, firewall-konfiguration og fælles TLS-konfiguration. Se disse afsnit i fejlfindingsvejledningen for yderligere oplysninger: |
TLS-fejl |
Fejl ved fælles TLS-handshake |
Fælles TLS-fejl: Kontrollér fælles TLS-konfiguration i både Expressway og , og at fælles https://admin.webex.comTLS-certifikater er til stede og gyldige på begge placeringer. Se fælles TLS-håndtryksfejl i fejlfindingsvejledningen for yderligere oplysninger. |
Tilslutningsfejl |
Socket mislykkedes |
Fejl ved TCP-forbindelse: Kontrollér netværksforbindelsen, forbindelseshastigheden og/eller firewall-konfigurationen. Se disse afsnit i fejlfindingsvejledningen for yderligere oplysninger: |
Fejl ved TCP-læsning/-skrivning |
Socket mislykkedes |
Fejl ved TCP-læsning/-skrivning: Prøv igen. Hvis fejlen fortsætter, skal du kontrollere netværksforbindelsen, firewall-konfigurationen og den fælles TLS-konfiguration. Se disse afsnit i fejlfindingsvejledningen for yderligere oplysninger: |
TCP-fejl |
Socket mislykkedes |
TCP-fejl: Fejl ved TCP-læsning/-skrivning: Prøv igen. Hvis fejlen fortsætter, skal du kontrollere netværksforbindelsen, firewall-konfigurationen og den fælles TLS-konfiguration. Se disse afsnit i fejlfindingsvejledningen for yderligere oplysninger: |
Dette afsnit omhandler fejlfinding af tjeklister og opgaver, som du kan gennemgå, før du kontakter support.
Hvis opkald fra Webex til din virksomhed ikke ringer på virksomhedssiden, skal du gennemgå punkterne i denne tjekliste for at dobbelttjekke din konfiguration.
Inden du gennemgår disse fejlfindingsforslag, skal https://status.webex.com du se de seneste oplysninger om eventuelle cloud-udfald. Fra den statusside kan du også abonnere på underretninger.
Kontrollér disse fejlfindingspunkter, der er relateret fælles TLS forbindelse og certifikater:
Installer Webex Cloud-rodcertifikat på Expressway-E.
Konfigurer en dedikeret fælles TLS-port på Expressway-E.
Konfigurer et DNS-område for skyen på Expressway-E.
Åbn fælles TLS i din firewall-5062, som muligvis ikke er åbent som standard.
Afgør, rodcertifikat valgmulighed du bruger i Webex-skyen – valgmuligheden bruges til at verificere dit Expressway-E's SIP TLS-certifikat.
Standardbutik – Er dit Expressway-E-certifikat underskrevet af en af de offentlige myndigheder? Hvis du er usikker, så brug valgmuligheden brugertilpasset butik.
Brugertilpasset butik – Er dit Expressway-E-certifikat eller dets underskriver installeret i skyen? Indeholder certifikatet bekræftede navne Expressway-E-værtsnavne?
Fra kundevisningen i skal https://admin.webex.comdu gå til . Kontrollér disse punkter, der er relateret til din SIP-destination, som du indstillede under implementeringsprocessen:
Værdien punkter på din Expressway-E dedikeret fælles TLS port.
Prøv at tilslutte til IP-adressen:port. (Flere adresser, hvis du konfigurerede en SRV.)
Hvis du har konfigureret en IP-adresse eller værtsnavn, skal du angive fælles TLS porte.
Hvis du brugte en SRV, skal du sikre, at den er i formatet _sips._tcp.domæne, du inddstede somSIP->.
Hvis du ikke vil opsætte en SRV, kan du indtaste IP-adresse:port ellerværtsnavn:port som din organisations SIP-destination.
For opkald, der dirigeres fra Webex til virksomheden, skal du kontrollere søgehistorikken og netværkslogfiler på Expressway-E. Dette trin hjælper dig med at isolere problemet til enten skyen eller virksomheden.
Hvis du genbruger et eksisterende B2B-område og søgeregler, kan du i stedet overveje at oprette dedikerede områder og søgeregler. Denne opsætning undgår interferens med eksisterende områdeindstillinger for B2B/MRA, undgår routing-loop og gør fejlfinding nemmere.
Kontroller søgehistorik og netværkslogfiler på Expressway-E. Bekræft, at SIP INVITE fra skyen ankommer til den Expressway-E og matcher den DNS-zone, som du konfigurerede for skyen.
Hvis SIP INVITE ikke ankommer eller matcher det konfigurerede DNS-område, skal du følge rute for opkaldet mod Cisco Unified Communications Manager. Dette trin hjælper dig med at finde, hvor opkaldet ikke eller går tabt.
Se den fælles TLS fejlfindingstjekliste.
Kontroller ruteoverskriften. Bekræft, at den indeholder værdien helt kvalificeret domænenavn (FQDN), der er konfigureret under Cisco Unified Communications Manager virksomhedsindstillinger og i Expressway-søgeregler. Se dette eksempel på ruteoverskrift og fremhævet FQDN:
Rute: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>
I dette eksempel er startsideklyngen, FQDN, myucmcluster.example.com.
E-Cisco Unified Communications Manager skal matche e-mailen nøjagtigt (synkroniseret fra Active Directory eller fra enhver anden kilde) i Webex-skyen.
Katalog-URI'er skal matche alle domæner, som du har bekræftet i din organisation.
Kontroller din codec-konfiguration.
Webex-tjenesteydelser understøtter følgende codecs:
Lyd – G.711, G.722, AAC-LD
Video – H.264
Vi understøtter G.729 for at deltage i et Webex-møde, personligt lokale-møde eller Webex-møde fra en SIP-enhed. Vi understøtter ikke G.729 for at ringe 1:1 op fra Webex til en SIP-enhed eller bro.
På startsiden Cisco Unified Communications Manager de påvirkede brugere skal du vælge System > Virksomhedsparametre ; under Klyngevidere domænekonfiguration skal du markere indstillingen helt kvalificeret domænenavn (FQDN). Den FQDN værdi, du brugte, skal følge disse retningslinjer:
FQDN vejledning
Beskrivelse og eksempel
Flere klynger
Indtastningen skal være unik for hver klynge med hybridopkald- For eksempel cluster1.example.com , cluster2.example.com , osv.
Ingen jokertegn
Brug ikke poster med jokertegn, såsom *.example.com eller eksempel*.com.
Første FQDN for hybridopkald
I en liste over flere poster bruger Webex-skyen den første post til venstre til hybridopkald, og den første indtastning må ikke indeholde et jokertegn.
Se dette eksempel på tre FQDN poster fra venstre til højre (det første er til hybridopkald):
cluster1.example.com *.example.com example*.comForskellig fra Expressway-E
Skal være en anden end Expressway-E-systemet, DNS og domænenavnet. Ellers Expressway-E fratage ruteoverskriften.
Ny post for hybridopkald
Hvis din nuværende FQDN i Unified CM ikke opfylder kravene angivet ovenfor, kan du tilføje et nyt element til starten af klyngen eller FQDN for hybridopkald.
Hvis din eksisterende FQDN-indstilling i Cisco Unified Communications Manager f.eks. er *.example.com *.example.org, skal du tilføje et unikt, ikke-jokertegn i starten affeltet: "cluster1.example.com *.example.com *.example.org"
