Dacă apelurile de la Webex către întreprinderea dvs. nu sună pe partea întreprinderii, parcurgeți punctele din această listă de verificare pentru a verifica de două ori configurația.

Înainte de a parcurge aceste sugestii de depanare, consultați https://status.webex.com pentru cele mai recente informații despre orice întrerupere a norului. De la acea pagină de stare, vă puteți abona și la notificări.

Verificați aceste puncte de depanare legate de conexiunea și certificatele reciproce TLS:

• Instalați pachetul de certificate rădăcină Webex cloud pe Expressway-E.

• Configurați un port TLS reciproc dedicat pe Expressway-E.

• Configurați o zonă DNS pentru cloud pe Expressway-E.

• Deschideți numărul portului TLS reciproc din firewall—5062, care este posibil să nu fie deschis în mod implicit.

• Determinați ce opțiune de certificat rădăcină utilizați în Webex Cloud - opțiunea este utilizată pentru a verifica certificatul SIP TLS al Expressway-E.

  • Magazin implicit - Certificatul dvs. Expressway-E este semnat de una dintre autoritățile publice? Dacă nu sunteți sigur, utilizați opțiunea magazin personalizat.

  • Magazin personalizat — Certificatul dvs. Expressway-E sau semnatarul acestuia este instalat în cloud? Certificatul conține nume de gazdă Expressway-E verificate?

Din vizualizarea clientului din https://admin.webex.com, acces ați Servicii > Hibrid > Apel hibrid > Setări. Verificați aceste puncte care sunt legate de destinația SIP pe care ați setat-o în timpul procesului de implementare:

• Punctele de valoare la portul TLS reciproc dedicat Expressway-E.

• Încercați să vă conectați la adresa IP: port. (Mai multe adrese dacă ați configurat un SRV.)

• Dacă ați configurat o adresă IP sau un nume de gazdă, specificați portul TLS reciproc.

• Dacă ați utilizat un SRV, asigurați-vă că este în formatul _sips. _tcp. < domeniul pe care l-ați introdus ca destinație SI P>.

• Dacă nu doriți să configurați un SRV, puteți introduce adresa IP :port sau gazdă:port ca destin ație SIP a organizației.

• Dacă apelurile de la Expressway-E către cloud eșuează și utilizați metoda de gestionare manuală a certificatelor, asigurați-vă că urmați pașii din Actualizarea certificatului CA Root Webex și încărcați certificatul IdenTrust pe dispozitivele dvs. Expressway cât mai curând posibil.

• Pentru apelurile care direcționează de la Webex către întreprindere, verificați istoricul căutărilor și jurnalele de rețea de pe Expressway-E. Acest pas vă ajută să izolați problema fie în cloud, fie la întreprindere.

• Dacă reutilizați o zonă B2B existentă și reguli de căutare, luați în considerare crearea zonelor dedicate și a regulilor de căutare. Această configurare evită interferența cu setările zonei existente pentru B2B/MRA, evită buclele de rutare și facilitează depanarea.

• Verificați istoricul căutărilor și jurnalele de rețea de pe Expressway-E. Verificați dacă SIP INVITE din cloud ajunge la Expressway-E și se potrivește cu zona DNS pe care ați configurat-o pentru cloud.

  • Dacă SIP INVITE nu ajunge sau nu se potrivește cu zona DNS configurată, urmați ruta apelului către Managerul de comunicații unificate. Acest pas vă ajută să găsiți unde apelul eșuează sau se pierde.

  • Consultați lista de verificare reciprocă de depanare TLS.

• Verificați antetul traseului. Verificați dacă conține valoarea numelui de domeniu complet calificat al clusterului (FQDN) care este configurată în setările întreprinderii Unified Communications Manager și în regulile de căutare Expressway. Consultați acest exemplu de antet de traseu și FQDN al clusterului evidențiat:

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

    • În acest exemplu, clusterul de domiciliu FQDN este myucmcluster.example.com.

• E-mailurile din Unified Communications Manager trebuie să se potrivească exact cu e-mailul (sincronizat din Active Directory sau din orice altă sursă) din cloud Webex.

• URI-urile directorului trebuie să corespundă tuturor domeniilor pe care le-ați verificat în organizația dvs.

• Verificați configurația codecului.

  Serviciile Webex acceptă următoarele codecuri:

  • Audio — G.711, G.722, AAC-LD

  • Video-H.264

  Suportăm G.729 pentru a vă alătura unei întâlniri Webex, a unei întâlniri a camerei personale sau a unei întâlniri Webex App de pe un dispozitiv SIP. Nu acceptăm G.729 pentru apelarea 1:1 din aplicația Webex către un dispozitiv SIP sau o punte.

• În clusterul Unified Communications Manager de acasă al utilizatorilor afectați, selectați Sistem > Parametri de întreprindere; sub Configurare domeniu la nivel de cluster, verificați setarea nume de domeniu complet calificat al cluster ului (FQDN). Valoarea FQDN pe care ați folosit-o trebuie să respecte aceste instrucțiuni:

  Ghidul FQDN	Descriere și exemplu
  Clustere multiple	Intrarea trebuie să fie unică pentru fiecare cluster cu apelare hibridă — De exemplu, cluster1.example.comcluster2.example.com, și așa mai departe.
  Fără wildcard-uri	Nu utilizați intrări cu caractere wildcard, cum ar fi *.example.com sau example*.com.
  Prima intrare FQDN pentru apeluri hibride	Într-o listă de intrări multiple, norul Webex utilizează prima intrare din stânga pentru apelarea hibridă, iar prima intrare nu trebuie să conțină un wildcard. Vedeți acest exemplu de trei intrări FQDN de la stânga la dreapta (prima fiind pentru apelarea hibridă): cluster1.example.com *.example.com example*.com
  Diferit de Expressway-E	Trebuie să fie diferit de sistemul Expressway-E, DNS și numele de domeniu. În caz contrar, Expressway-E elimină antetul traseului.
  Nouă intrare pentru apelarea hibridă	Dacă intrarea curentă FQDN în Unified CM nu îndeplinește cerințele enumerate mai sus, puteți adăuga un element nou la începutul setării FQDN cluster pentru apelare hibridă. De exemplu, dacă setarea FQDN existentă Cisco Unified Communications Manager este *.example.com *.example.org, adăugați o intrare unică, fără wildcard la începutul câmpului: "cluster1.example.com *.example.com *.example.org”