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, se https://status.webex.com for den nyeste informasjonen om eventuelle nettbrudd. Fra statussiden kan du også abonnere på varsler.

Sjekk disse feilsøkingspunktene knyttet til den gjensidige TLS-tilkoblingen og sertifikatene:

• Installer Webex Cloud-rotsertifikatpakken på Expressway-E.

• Konfigurer en dedikert gjensidig TLS-port på Expressway-E.

• Konfigurer en DNS-sone for skyen på Expressway-E.

• Åpne det felles TLS-portnummeret i brannmuren din – 5062, som kanskje ikke er åpen som standard.

• Finn ut hvilket rotsertifikatalternativ du bruker i Webex-skyen – alternativet brukes til å bekrefte Expressway-E-ens SIP TLS-sertifikat.

  • Standardlager – Er Expressway-E-sertifikatet ditt signert av en av de offentlige myndighetene? Hvis du er usikker, bruk alternativet for tilpasset butikk.

  • Tilpasset lagring – Er Expressway-E-sertifikatet ditt eller signatøren installert i skyen? Inneholder sertifikatet bekreftede Expressway-E-vertsnavn?

Fra kundevisningen i https://admin.webex.com, gå til Tjenester > Hybrid > Hybridsamtale > Innstillinger. Sjekk disse punktene som er relatert til SIP-destinasjonen du anga under distribusjonsprosessen:

• Verdipoengene på din dedikerte gjensidige TLS-port for Expressway-E.

• Prøv å koble til IP-adresse address:port. (Flere adresser hvis du har konfigurert en SRV.)

• Hvis du konfigurerte en IP-adresse eller et vertsnavn, angi den felles TLS-porten.

• Hvis du brukte en SRV, sørg for at den er i formatet _sips._tcp. <domene du angir som SIP-destinasjon>.

• Hvis du ikke vil sette opp en SRV, kan du skrive inn IP address:port eller hostname:port som organisasjonens SIP-destinasjon.

• Hvis anrop fra Expressway-E til skyen mislykkes og du bruker den manuelle sertifikatbehandlingsmetoden, må du sørge for å følge trinnene i Oppdatering av Webex-rotsertifikat for CA og laste opp IdenTrust-sertifikatet til Expressway-enhetene dine så snart som mulig.

• For samtaler som rutes fra Webex mot bedriften, sjekk søkeloggen og nettverksloggene på Expressway-E. 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 med eksisterende soneinnstillinger for B2B/MRA, unngår rutingløkker og gjør feilsøking enklere.

• Sjekk søkehistorikken og nettverksloggene på Expressway-E. Kontroller at SIP INVITE fra skyen ankommer Expressway-E og samsvarer med DNS-sonen du konfigurerte for skyen.

  • Hvis SIP-INVITE-en ikke ankommer eller samsvarer med den konfigurerte DNS-sonen, følger du anropets rute mot Unified Communications Manager. Dette trinnet hjelper deg med å finne ut hvor samtalen feiler eller går tapt.

  • Se sjekklisten for gjensidig TLS-feilsøking.

• Sjekk ruteoverskriften. Kontroller at den inneholder verdien for det fullstendig kvalifiserte domenenavnet (FQDN) for klyngen som er konfigurert under bedriftsinnstillingene for Unified Communications Manager og i Expressway-søkereglene. Se dette eksempelet på rutehodet og det uthevede klynge-FQDN-et:

  • Rute: <sip:[Obfuscated];transport=tls;lr>,<sip:myucmcluster.example.com;lr>

    • I dette eksemplet er hjemmeklyngens FQDN myucmcluster.example.com.

• E-poster i Unified Communications Manager må samsvare nøyaktig med e-posten (synkronisert fra Active Directory eller fra en hvilken som helst annen kilde) i Webex-skyen.

• Katalog-URI-er må samsvare med alle domener du har bekreftet i organisasjonen din.

• Sjekk kodekkonfigurasjonen din.

  Webex-tjenester støtter følgende kodeker:

  • Lyd – G.711, G.722, AAC-LD

  • Video – H.264

  Vi støtter G.729 for å delta i et Webex-møte, personlig rom-møte eller 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.

• I den berørte brukerens hjemmeklynge for Unified Communications Manager velger du System > Bedriftsparametere; Under Klyngeomfattende domenekonfigurasjonmå du sjekke innstillingen for det fullstendig kvalifiserte domenenavnet (FQDN) for klyngen. FQDN-verdien du brukte må følge disse retningslinjene:

  FQDN-retningslinje	Beskrivelse og eksempel
  Flere klynger	Oppføringen må være unik for hver klynge med hybridkall – for eksempel cluster1.example.com, cluster2.example.comog så videre.
  Ingen jokertegn	Ikke bruk oppføringer med jokertegn, som for eksempel *.example.com eller example*.com.
  Første FQDN-oppføring for hybridanrop	I en liste med flere oppføringer bruker Webex-skyen den første oppføringen til venstre for hybridanrop, 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 hybridanrop): cluster1.example.com *.example.com example*.com
  Forskjellig fra Expressway-E	Må være forskjellig fra Expressway-E-systemet, DNS og domenenavnet. Ellers fjerner Expressway-E rutehodet.
  Ny oppføring for hybridanrop	Hvis den nåværende FQDN-oppføringen i Unified CM ikke oppfyller kravene ovenfor, kan du legge til et nytt element i begynnelsen av klyngens FQDN-innstilling for hybridkall. Hvis for eksempel den eksisterende FQDN-innstillingen i Cisco Unified Communications Manager er *.example.com *.example.org, legg til en unik oppføring som ikke er jokertegn i begynnelsen av feltet: "cluster1.example.com *.example.com *.example.org"