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 Tjenester > Hybrid > Hybridsamtale > Innstillinger. 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»