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 du kan bruke til å kontrollere og diagnostisere verktøy du kan bruke.
Denne delen gir en oversikt over 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.
Du kan få tilgang til testverktøyet for hybridtilkobling fra Control Hub: Gå til i kundevisningen i https://admin.webex.com, klikk på Rediger innstillinger i hybridsamtalekortet, rull ned til Standard SIP-destinasjon, og klikk på Test ved siden av SIP-destinasjonen du skrev inn.
Denne tabellen viser vanlige feil som kan oppstå når du har testet en SIP-destinasjonsadresse for Hybridsamtaler. Tabellen inneholder også videre trinn for feilsøking, inkludert koblinger til relevant informasjon i feilsøkingsveiledningen for hybridsamtaletjenester.
Feil |
Nøkkelord |
Mer informasjon og feilsøkingstrinn |
|---|---|---|
Fant ingen DNS-adresser |
DNS-SRV |
DNS-oppslag mislyktes. Kontroller at en DNS- eller SRV-post finnes for en SIP-destinasjon, og at den løses til én eller flere gyldige IP-adresser. Hvis du vil ha mer informasjon, kan du se Kan ikke løse Expressway-E DNS SRV/vertsnavn i feilsøkingsveiledningen. |
Tilkoblingen ble tidsavbrutt |
Socket-feil |
Nettverks- og/eller felles TLS-tilkobling ble tidsavbrutt. Kontroller nettverkstilkobling, tilkoblingshastighet, brannmurkonfigurasjon og felles TLS-konfigurasjon. Se disse delene i feilsøkingsveiledningen hvis du vil ha mer informasjon: |
TLS-feil |
Felles TLS-håndtrykkfeil |
Felles TLS-feil: Kontroller felles TLS-konfigurasjon i Expressway, og https://admin.webex.com at felles TLS-sertifikater finnes og er gyldige for begge plasseringer. Se Felles TLS-håndtrykkfeil i feilsøkingsveiledningen hvis du vil ha mer informasjon. |
Tilkobling mislyktes |
Socket-feil |
TCP-tilkoblingsfeil: Kontroller nettverkstilkobling, tilkoblingshastighet og/eller brannmurkonfigurasjon. Se disse delene i feilsøkingsveiledningen hvis du vil ha mer informasjon: |
Feil ved lesing/skriving av TCP |
Socket-feil |
Feil ved lesing/skriving av TCP: Prøv igjen. Sjekk nettverkstilkoblingen, brannmurkonfigurasjonen og felles TLS-konfigurasjon hvis feilen vedvarer. Se disse delene i feilsøkingsveiledningen hvis du vil ha mer informasjon: |
TCP-feil |
Socket-feil |
TCP-feil: Feil ved lesing/skriving av TCP: Prøv igjen. Sjekk nettverkstilkoblingen, brannmurkonfigurasjonen og felles TLS-konfigurasjon hvis feilen vedvarer. Se disse delene i feilsøkingsveiledningen hvis du vil ha mer informasjon: |
Denne delen gir en oversikt over feilsøkingslister og oppgaver som du kan utføre før du kontakter kundestøtte.
Hvis samtaler fra Webex til bedriften din ikke ringer på bedriftssiden, kan du se 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 å få den nyeste informasjonen om eventuelle skybrudd. Du kan også abonnere på varsler fra denne statussiden.
Kontroller disse feilsøkingspunktene relatert til gjensidig TLS-tilkobling og sertifikater:
Installer rotsertifikatbunten 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 på brannmuren – 5062, som kanskje ikke er åpent som standard.
Finn ut hvilket rotsertifikatalternativ du bruker i Webex-skyen. Alternativet brukes til å bekrefte Expressway-E SIP TLS-sertifikatet.
Standardlager – Er Expressway-E-sertifikatet signert av offentlige myndigheter? Hvis du er usikker, kan du bruke alternativet for egendefinert lagring.
Egendefinert lager – Er Expressway-E-sertifikatet eller dets signatar installert i skyen? Inneholder sertifikatet verifiserte Expressway-E-vertsnavn?
Gå til fra kundevisningen i https://admin.webex.com. Kontroller at disse punktene er relatert til SIP-målet du angir under distribusjonsprosessen:
Verdipunktene på Expressway-E viser en felles TLS-port.
Prøv å koble til IP-adresse:port. (Flere adresser hvis du har konfigurert en SRV.)
Hvis du konfigurerte en IP-adresse eller et vertsnavn, må du angi du en felles TLS-port.
Hvis du brukte en SRV, må du sørge for at den er i formatet _sips._tcp.<domenet du legger inn som en SIP-destinasjon>.
Hvis du ikke vil konfigurere en SRV, kan du skrive innIP-adresse:port eller vertsnavn:port som organisasjonens SIP-destinasjon.
Du må kontrollere søkeloggen og nettverksloggene på Expressway-Efor 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, må du vurdere å opprette dedikerte soner og søkeregler i stedet. Dette oppsettet unngår forstyrrelser i eksisterende soneinnstillinger for B2B/MRA, unngår ruteomveier og gjør feilsøking enklere.
Kontroller søkeloggen og nettverksloggene på Expressway-E. Kontroller at SIP-invitasjonen fra skyen sendes til Expressway-E og samsvarer med DNS-sonen du konfigurerte for skyen.
Hvis SIP-invitasjonen ikke sendes eller samsvarer med den konfigurerte DNS-sonen, må du følge ruten for samtalen mot Cisco Unified Communications Manager. Dette trinnet hjelper deg med å finne ut hvor samtalen mislykkes eller kobles ut.
Se sjekklisten for felles TLS-feilsøking.
Kontroller hovedruten. Kontroller at den inneholder den kvalifiserte FQDN-verdien for klyngen som er konfigurert under organisasjonsinnstillingene i Cisco Unified Communications Manager, og i Expressway-søkereglene. Se dette eksemplet på hovedrute og uthevet FQDN-klynge:
Rute: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>
I dette eksemplet er hjemklyngen FQDN myucmcluster.example.com.
E-postmeldinger i Cisco 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:
Audio – G.711, G.722, AAC-LD
Video – H.264
Vi støtter G.729 for å bli med i et Webex-møte, et personlig rommøte eller et Webex-møte fra en SIP-enhet. Vi støtter ikke G.729 for oppringing 1:1 fra Webex til en SIP-enhet eller -bro.
Velg System > Selskapsparametereunder Domenekonfigurasjon for alle klynger på hjemklyngen Cisco Unified Communications Manager for påvirkede brukere, og sjekk at klyngen er kvalifisert til domenenavninnstillingen (FQDN). FQDN-verdien du brukte, må følge disse retningslinjene:
FQDN-retningslinjer
Beskrivelse og eksempel
Flere klynger
Oppføringen må være unik for hver klynge med hybridsamtaler – for eksempel cluster1.example.com, cluster2.example.com osv.
Ingen jokertegn
Ikke bruk oppføringer med jokertegn, som *.example.com eller eksempel*.com.
Første FQDN-oppføring for hybridsamtaler
På en liste med flere oppføringer, må Webex-skyen være første oppføringen til venstre for hybridsamtaler, og denne kan ikke inneholde et jokertegn.
Se dette eksemplet med tre FQDN-oppføringer fra venstre mot høyre (det første er for hybridsamtaler):
cluster1.example.com *.example.com example*.comAnnerledes enn Expressway-E
Må være annerledes enn Expressway-E-systemet, DNS og domenenavnet. Ellers er Expressway-E-listene hovedruten.
Ny oppføring for hybridsamtaler
Hvis den gjeldende FQDN-oppføringen i Unified CM ikke oppfyller kravene som er oppført ovenfor, kan du legge til et nytt element på starten av FQDN-klyngeinnstillingen for hybridsamtaler.
Hvis for eksempel den eksisterende FQDN-innstillingen i Cisco Unified Communications Manager er *.example.com *.example.org, kan du legge til en unik oppføring som ikke er jokertegn, i starten på feltet: «cluster1.example.com *.example.com *.example.org»
