Feilsøk hybridsamtaler
Hvis noe går galt med distribusjonen av hybridsamtaletjenesten for Webex-enheter, kan du bruke disse feilsøkingstipsene til å utelukke problemer før du åpner en sak. Hver del gir en rask oversikt over en komponent eller et aspekt av løsningen, og feilsøkingsveiledningen inneholder flere elementer for å kontrollere og diagnostisere verktøy som du kan bruke.
Denne delen dekker testverktøyet for hybridtilkobling. Du kan få tilgang til dette feilsøkingsverktøyet fra Control Hub.
Du kan også få tilgang til kjente problemer fra de relaterte artiklene.
Testverktøy for hybridtilkobling (Control Hub)
Du kan få tilgang til testverktøyet for hybridtilkobling fra Control Hub: Fra kundevisningen i https://admin.webex.com går du til , klikker på Rediger innstillinger på hybridsamtalekortet, blar til Standard SIP-destinasjon, og klikker deretter på Test ved siden av SIP-destinasjonen du skrev inn.
Denne tabellen viser vanlige feil som kan oppstå etter at du har testet en SIP-destinasjonsadresse for hybridsamtaler. Tabellen inneholder også neste trinn for feilsøking, inkludert koblinger til relevante detaljer i feilsøkingsveiledningen for hybridsamtaletjeneste.
Feil |
Nøkkelord |
Mer informasjon og feilsøkingstrinn |
---|---|---|
Ingen DNS-adresser funnet |
dns srv |
DNS-oppslag mislyktes. Kontroller at det finnes en DNS- eller SRV-post for SIP-destinasjonen din, og at den løses til én eller flere gyldige IP-adresser. Se Kan ikke løse Expressway-E DNS SRV/vertsnavn i feilsøkingsveiledningen hvis du vil ha mer informasjon. |
Tilkobling tidsavbrutt |
Socket-feil |
Nettverkstilkobling og/eller felles TLS-tilkobling ble tidsavbrutt. Kontroller nettverkstilkobling, tilkoblingshastighet, brannmurkonfigurasjon og felles TLS-konfigurasjon. Se disse delene i feilsøkingsveiledningen for mer informasjon: |
TLS-feil |
Felles TLS-håndtrykkfeil |
Felles TLS-feil: Kontroller felles TLS-konfigurasjon i både Expressway og https://admin.webex.com, og at felles TLS-sertifikater finnes og er gyldige på begge steder. Se Felles TLS-håndtrykkfeil i feilsøkingsveiledningen for mer informasjon. |
Tilkoblingsfeil |
Socket-feil |
TCP-tilkoblingsfeil: Kontroller nettverkstilkoblingen, tilkoblingshastigheten og/eller brannmurkonfigurasjonen. Se disse delene i feilsøkingsveiledningen for mer informasjon: |
Feil ved lesing/skriving av TCP |
Socket-feil |
Feil ved lesing/skriving av TCP: Prøv igjen. Kontroller nettverkstilkoblingen, brannmurkonfigurasjonen og felles TLS-konfigurasjon hvis feilen vedvarer. Se disse delene i feilsøkingsveiledningen for mer informasjon: |
TCP-feil |
Socket-feil |
TCP-feil: Feil ved lesing/skriving av TCP: Prøv igjen. Kontroller nettverkstilkoblingen, brannmurkonfigurasjonen og felles TLS-konfigurasjon hvis feilen vedvarer. Se disse delene i feilsøkingsveiledningen for mer informasjon: |
Denne delen dekker feilsøkingslister og oppgaver som du kan gjennomgå før du kontakter kundestøtte.
Hvis anrop fra Webex til bedriften din ikke ringer på bedriftssiden, kan du gå gjennom punktene i denne sjekklisten for å dobbeltsjekke konfigurasjonen.
Før du går gjennom disse feilsøkingsforslagene, kan du se https://status.webex.com for den nyeste informasjonen om eventuelle skyavbrudd. Fra denne statussiden kan du også abonnere på varsler.
Sjekk disse feilsøkingspunktene relatert til gjensidig TLS-tilkobling og sertifikater:
-
Installer rotsertifikatpakken for Webex-skyen på Expressway-E.
-
Konfigurer en dedikert felles TLS-port på Expressway-E.
-
Konfigurer en DNS-sone for skyen på Expressway-E.
-
Åpne det felles TLS-portnummeret i brannmuren – 5062, som kanskje ikke er åpent som standard.
-
Finn ut hvilket rotsertifikatalternativ du bruker i Webex-skyen – Alternativet brukes til å bekrefte Expressway-Es SIP TLS-sertifikat.
-
Standardlager – Er Expressway-E-sertifikatet ditt signert av en av myndighetene? Hvis du er usikker, kan du bruke alternativet for egendefinert lager.
-
Egendefinert lager – Er Expressway-E-sertifikatet eller dets signatar installert i skyen? Inneholder sertifikatet verifiserte Expressway-E-vertsnavn?
-
Fra kundevisningen i https://admin.webex.com går du til . Kontroller disse punktene som er relatert til SIP-destinasjonen du angir under distribusjonsprosessen:
-
Verdipunktene på din Expressway-E dedikerte felles TLS-port.
-
Prøv å koble til IP-adresse:port. (Flere adresser hvis du konfigurerte en SRV.)
-
Hvis du har konfigurert en IP-adresse eller et vertsnavn, må du angi den felles TLS-porten.
-
Hvis du brukte en SRV, må du kontrollere at den er i formatet _sips._tcp.<domene du skrev inn som SIP-destinasjon>.
-
Hvis du ikke vil konfigurere en SRV, kan du angi IP-adresse:port eller vertsnavn:port som organisasjonens SIP-destinasjon.
-
Hvis anrop fra Expressway-E til skyen mislykkes og du bruker den manuelle metoden for sertifikatadministrasjon, må du sørge for å følge trinnene i Webex Root CA-sertifikatoppdatering og laste opp IdenTrust-sertifikatet til Expressway-enhetene dine så snart som mulig.
-
Sjekk søkehistorikken og nettverksloggene på Expressway-E for samtaler som går fra Webex til bedriften. Dette trinnet hjelper deg med å isolere problemet til enten skyen eller bedriften.
-
Hvis du bruker en eksisterende B2B-sone og søkeregler på nytt, bør du vurdere å opprette dedikerte soner og søkeregler i stedet. Dette oppsettet unngår forstyrrelser i eksisterende soneinnstillinger for B2B/MRA, unngår rutingsløkker og gjør feilsøking enklere.
-
Sjekk søkehistorikken og nettverksloggene på Expressway-E. Kontroller at SIP-invitasjonen fra skyen ankommer til Expressway-E og samsvarer med DNS-sonen du konfigurerte for skyen.
-
Hvis SIP-invitasjonen ikke ankommer eller samsvarer med den konfigurerte DNS-sonen, må du følge ruten for samtalen mot Unified Communications Manager. Dette trinnet hjelper deg med å finne ut hvor samtalen mislykkes eller tapt.
-
Se sjekklisten for felles TLS-feilsøking.
-
-
Sjekk ruteoverskriften. Kontroller at den inneholder den kvalifiserte FQDN-verdien for klyngen som er konfigurert under bedriftsinnstillingene for Unified Communications Manager og i Expressway-søkereglene. Se dette eksemplet med ruteoverskrift og uthevet klynge FQDN:
-
Rute: ,
-
I dette eksemplet er hjemklyngen FQDN myucmcluster.example.com.
-
-
-
E-postene i Unified Communications Manager må samsvare nøyaktig med e-posten (synkronisert fra Active Directory eller fra en annen kilde) i Webex-skyen.
-
Katalog-URI-er må samsvare med alle domener du har bekreftet i organisasjonen.
-
Kontroller kodekkonfigurasjonen.
Webex-tjenester støtter følgende kodeker:
-
Lyd – G.711, G.722, AAC-LD
-
Video – H.264
Vi støtter G.729 for å bli med i et Webex-møte, et personlig rom-møte eller et Webex-appmøte fra en SIP-enhet. Vi støtter ikke G.729 for oppringing 1:1 fra Webex-appen til en SIP-enhet eller bro.
-
-
Velg System > Bedriftsparametere på hjemklyngen for de berørte brukerne. Under Domenekonfigurasjon for hele klyngen kontrollerer du innstillingen for fullstendig kvalifisert domenenavn (FQDN). FQDN-verdien du brukte, må følge disse retningslinjene:
FQDN-veiledning
Beskrivelse og eksempel
Flere klynger
Oppføringen må være unik for hver klynge med hybridsamtaler – for eksempel
cluster1.example.com
,cluster2.example.com
og så videre.Ingen jokertegn
Ikke bruk oppføringer med jokertegn, for eksempel *.example.com eller eksempel*.com.
Første FQDN-oppføring for hybridsamtaler
I en liste over flere oppføringer bruker Webex-skyen den første oppføringen til venstre for hybridsamtaler, og den første oppføringen må ikke inneholde et jokertegn.
Se dette eksemplet med tre FQDN-oppføringer fra venstre til høyre (den første er for hybridsamtaler):
klynge1.example.com *.example.com eksempel*.com
Forskjellig fra Expressway-E
Må være forskjellig fra Expressway-E-systemet, DNS og domenenavnet. Ellers vil Expressway-E stripe ruteoverskriften.
Ny oppføring for hybridsamtaler
Hvis din nåværende FQDN-oppføring i Unified CM ikke oppfyller kravene som er oppført ovenfor, kan du legge til et nytt element i begynnelsen av klyngens FQDN-innstilling for hybridsamtaler.
Hvis for eksempel den eksisterende FQDN-innstillingen i Cisco Unified Communications Manager er *.example.com *.example.org, legger du til en unik oppføring som ikke er jokertegn i begynnelsen av feltet: «cluster1.example.com *.example.com *.example.org»