Mulțumim pentru feedback.

Acest articol este destinat echipei de asistență tehnică din cadrul organizației furnizorilor de servicii care se sprijină pe ei înșiși și pe clienții lor. Ei ar trebui să fie familiarizați cu depanarea generală, citirea jurnalelor și lucrul cu cazurile de abonați.

Acest articol este împărțit în trei secțiuni majore:

• Resurse — oferă o listă de instrumente, materiale de lectură, jurnale și contacte de care ai putea avea nevoie.
• Procese — descrie unele dintre acțiunile pe care le puteți întreprinde în timp ce depanați o problemă a clientului.
• Probleme specifice — clasifică și listează problemele despre care se știe că apar, cum să le identificați și cum le puteți rezolva.

Fișiere jurnal utile

Lista de lectură

• Portalul de cunoștințe pentru parteneri Webex pentru Cisco BroadWorks
• Ghid de configurare a platformei XSP (R23)
• Ghid de gestionare a software-ului BroadWorks (R23)
• Ghid de configurare pentru gestionarea dispozitivelor Cisco BroadWorks (R23)
• Ghid de administrare a interfeței liniei de comandă Broadworks Xsp
• Descrierea caracteristicilor jetonului de autentificare cu durată lungă de viață Versiunea 23.0
• Ghid de integrare SAML Autentificare, R23
• Ghid de opțiuni de asistență Cisco BroadWorks SSL
• Descrierea caracteristicilor de asistență Cisco CI
• Notificare Push Server (Descrierea caracteristicilor)
• Suport pentru notificări push pentru apeluri Descriere Caracteristică Versiunea 22.0
• Migrarea conectării (Android) la metoda de procedură Firebase
• Cisco BroadWorks Stocarea tokenurilor de dispozitiv pentru notificări push Descriere Caracteristică Versiunea 22.0
• Cisco BroadworksSystem Capacity Planner (foaie de calcul)
• Ghid de dimensionare a platformei Cisco BroadWorks
• Ghid de inginerie a sistemelor Cisco Broadworks
• Document privind cerințele de asistență pentru autentificarea CI Versiunea 1.0 MR-7136

Probleme și limitări cunoscute

Articolul Probleme și limitări cunoscute conține informații actualizate despre problemele cunoscute pe care le-am identificat în soluția Webex pentru BroadWorks.

Conector de întreţinere

Serviciul Webex Serviceability mărește viteza cu care personalul de asistență tehnică Cisco poate diagnostica problemele legate de infrastructură. Automatizează sarcinile de găsire, preluare și stocare a jurnalelor de diagnosticare și a informațiilor într-un caz SR. Serviciul declanșează, de asemenea, analize în funcție de semnăturile de diagnosticare, astfel încât TAC să poată identifica și rezolva mai eficient problemele legate de echipamentul local.

Pentru detalii despre modul de implementare a conectorului Serviceability, consultați Ghi dul de implementare pentru conectorul de Cisco Webex funcționalitate.

Escalarea unei probleme

După ce ați urmat unele dintre îndrumările de depanare, ar trebui să aveți o idee rezonabilă despre locul în care este înrădăcinată problema.

Procedura

1. Colectați cât mai multe informații de la sistemele legate de problemă.
2. Contactați echipa corespunzătoare de la Cisco pentru a deschide un caz.

Ce informații despre clienți să colectăm

Dacă credeți că trebuie să deschideți un caz sau să escaladați o problemă, colectați următoarele informații în timp ce depanați cu utilizatorul:

• Identificator utilizator: adresa de e-mail CI sau UUID-ul utilizatorului (acesta este identificatorul Webex, dar dacă obțineți și identificatorul BroadWorks al utilizatorului, includeți-l în detaliile cazului).
• Identificatorul organizației.
• Perioada de timp aproximativă în care a fost întâmpinată problema.
• Platforma și versiunea clientului.
• Trimiteți sau colectați jurnale de la client.
• Înregistrați ID-ul de urmărire dacă este afișat pe client.

Verificați detaliile utilizatorului în Help Desk

Administratorii parteneri care au privilegii de rol Help Desk Administrator (Basic sau Advanced) pot utiliza această procedură pentru a verifica detaliile utilizatorului utilizând vizualizarea Help Desk.

Procedura

1. Conectați-vă la Help Desk.
2. Căutați și apoi faceți clic pe utilizator. Aceasta deschide ecranul rezumatului utilizatorului.
3. Faceți clic pe numele de utilizator pentru a vedea configurația detaliată a utilizatorului. Informațiile utile din această vizualizare includ UUID-ul utilizatorului, clusterul de identitate comună (CI), clusterul de aplicații Webex, comportamentul apelurilor, GUID-ul contului BroadWorks
4. Faceți clic pe Copiere dacă trebuie să utilizați aceste informații într-un alt instrument sau să le atașați la o carcasă Cisco.

Vizualizați organizația clienților în Help Desk

Administratorii parteneri care au privilegii de rol Help Desk Administrator (Basic sau Advanced) pot utiliza această procedură pentru a vizualiza detaliile organizației clienților în vizualizarea Birou de asistență.

Procedura

1. Conectați-vă la Help Desk.
2. Căutați și apoi faceți clic pe numele organizației client.
3. Derulați în jos până când vedeți Vizualizare portal clienți și faceți clic pe Vizualizare nume client pentru a vedea o vizualizare numai în citire a organizației Client — inclusiv utilizatorii și configurația.

Preluarea jurnalelor de utilizator din Partner Hub

Atunci când depanați probleme cu clienții desktop și mobil, este important ca partenerii (și TAC) să poată vizualiza jurnalele clientului.

Procedura

1. Cereți utilizatorului să trimită jurnale. Pentru ajutor, consultați: Aplic ația Webex | Raportați o problemă.
2. Cereți utilizatorului să exporte mediul de apelare și să vă trimită fișierul ced.dat.
3. Obțineți jurnalele clienților de la Partner Hub sau Help Desk.

   Opțiunea Partner Hub:

   1. Conectați-vă la Partner Hub și găsiți Organizația clienților utilizatorului.
   2. Selectați Depan are.
   3. Selectați Jurnale.
   4. Căutați utilizatorul (prin e-mail).
   5. Vizualizați și descărcați jurnalele clientului ca fișier zip.

   Opțiunea Help Desk:

   1. Conectați-vă la Help Desk.
   2. Căutați organizația.
   3. Faceți clic pe organizație (deschide ecranul rezumat).
   4. Derulați în jos pentru a face clic pe Vizualizare client.
   5. Selectați Depan are.
   6. Selectați Jurnale.
   7. Căutați utilizatorul (prin e-mail).
   8. Vizualizați și descărcați jurnalele clientului ca fișier zip.

Cum să găsiți versiunea clientului

Procedura

1. Distribuiți acest link cu utilizatorul: https://help.webex.com/njpf8r5
2. Cereți utilizatorului să vă trimită numărul versiunii.

Verificarea clientului pentru serviciul de apelare

Procedura

1. Conectați-vă la clientul Webex.
2. Verificați dacă pictograma Opțiuni de apelare (un telefon cu un angrenaj deasupra acestuia) este prezentă în bara laterală. Dacă pictograma nu este prezentă, este posibil ca utilizatorul să nu fie încă activat pentru serviciul de apelare în Control Hub.
3. Deschideți meniul Setări/P referințe și accesați secțiunea Servicii telefonice. Ar trebui să vedeți starea Sesiune SSO Ești conectat. (Dacă este afișat un alt serviciu de telefon Webex Calling ie, cum ar fi, utilizatorul nu utilizează Webex pentru Cisco BroadWorks.)

   Această verificare înseamnă:

   • Clientul a traversat cu succes microserviciile Webex necesare.
   • Utilizatorul s-a autentificat cu succes.
   • Clientului i se emite un token web JSON de lungă durată de către sistemul dvs. BroadWorks.
   • Clientul și-a recuperat profilul dispozitivului și s-a înregistrat la BroadWorks.

Obțineți jurnale sau feedback de la clienți

• Consultați secțiunea Resurse pentru a găsi anumite jurnale de client pe clienții desktop Webex sau solicitați utilizatorilor să trimită jurnale. Pentru ajutor, consultați: Aplic ația Webex | Raportați o problemă.
• Cereți utilizatorilor clienților mobili să trimită jurnale, apoi le puteți obține prin Partner Hub sau Help Desk.
  Trimiterea jurnalelor este silențioasă. Cu toate acestea, dacă un utilizator trimite feedback, acesta merge la echipa de devops Webex App. Asigurați-vă că înregistrați numărul de feedback al utilizatorului dacă doriți să continuați cu Cisco. De exemplu:

  

Obțineți date despre mediul de apelare

Jurnalele clienților Webex sunt puternic redactate pentru a elimina informațiile de identificare personală. Ar trebui să exportați datele mediului de apelare de la client în aceeași sesiune în care observ ați problema.

Procedura

1. Pe client faceți clic pe Ajut or > Veri ficator de sănătate.
2. Selectați Resetați baza de date. Aceasta declanșează o resetare completă a clientului și încarcă ecranul de conectare al aplicației Webex.

Verificați dacă Webex ar trebui să se înregistreze la BroadWorks

Aplicația Webex verifică următoarele informații pentru a determina dacă se înregistrează la BroadWorks:

• Dreptul utilizatorului la broad works-connector.
• Comportament de apelare pentru organizație și utilizator.

Verificarea comportamentului de apelare a unui utilizator și a dreptului la conector

1. Conectați-vă la Help Desk cu acreditările de administrator partener.
2. Căutați utilizatorul.
3. Faceți clic pe utilizator și verificați intrarea Comportament de apelare. Ar trebui să fie „Apelarea în Webex”.

   

4. Faceți clic pe numele de utilizator pentru a deschide ecranul Detalii utilizator.
5. Derulați în jos pentru a localiza secțiunea drepturi și verificați dacă este inclus conec torul broadworks

   

   Un utilizator Webex pentru Cisco BroadWorks nu ar trebui să aibă dreptul standard bc-sp dacă intenționează să utilizeze Webex pentru Cisco BroadWorks. Acesta este dreptul pentru „Webex Calling(Broadcloud)”, care este apelarea aplicației Webex printr-un serviciu de apelare cloud gestionat de Cisco.

Verificați comportamentul de apelare al organizației

1. Conectați-vă la Help Desk cu acreditările de administrator partener.
2. Căutați organizația.
3. Faceți clic pe organizație și verificați intrarea Comport ament de apel are. Ar trebui să fie „Apelarea în Webex”.

Analizați PSLog pentru problemele de furnizare a utilizatorilor

Utilizați PSLog-ul serverului de aplicații pentru a vedea solicitarea HTTP POST către puntea de furnizare și răspunsul de la Webex. Într-un caz de lucru corect, răspunsul este 200 OK și după câteva minute puteți vedea că utilizatorul - și noua organizație a clientului dacă este primul utilizator - a fost creat în Webex. Puteți verifica acest lucru căutând la Help Desk adresa de e-mail pe care o vedeți în POST.

Înainte de a începe

Colectați un PSLog de pe serverul de aplicații în timpul unei încercări de furnizare a fluxului cu un utilizator de testare.

Procedura

1. Mai întâi, verificați codul de răspuns HTTP:
   • Orice altceva decât 200 OK este o eroare de furnizare a utilizatorului.
   • 200 OK ar putea indica în continuare un eșec dacăceva despre profilul abonatului nu funcționează în serviciile Webex din amonte de puntea de aprovizionare.
   • 400 poate conține un nod de mesaj în răspuns. Puntea de furnizare nu a putut procesa ceva în Subscri ber Profile. Este posibil să existe ceva în neregulă cu detaliile abonatului sau incompatibilitatea cu o setare din șablon.
   • 401 înseamnă că acreditările de furnizare introduse în AS nu se potrivesc cu cele introduse în șablon în Partner Hub.
   • 403 ar putea indica ceva configurat greșit pe Serverul de aplicații. Verificați ținta cererii. nu ar trebui să fie o adresă IP, ar trebui să fie adresa URL de punte de furnizare pe care o puteți vedea pe șablonul dvs. în Partner Hub.
   • 409 indică un conflict între Subscri berProfile furnizat și datele Webex existente. Este posibil să existe un utilizator existent cu acea adresă de e-mail. Verificați mes ajul din răspuns.
2. De asemenea, puteți verifica HTTP POST original pentru orice valori suspecte care ar putea cauza eș ecul furnizării. POST conține o structură XML Sub scriberProfile. În interiorul acestuia, nodurile utile de verificat sunt:
   • bwuserid: Utilizați acest lucru pentru a găsi profilul abonatului dacă trebuie să îl editați în BroadWorks.
   • grup: Dacă șablonul se află în „Modul furnizor de servicii”, acesta este scris cu litere mici și devine numele organizației Client pe care o vedeți în Centrul pentru parteneri.
   • ServicePro vider: Dacă șablonul se află în „modul Enterprise”, acesta este scris cu litere mici și devine numele organizației Client pe care o vedeți în Partner Hub.
   • primaryPhoneNumber: Trebuie să existe. Furnizarea eșuează fără ea.
   • e-mail: Devine ID-ul utilizatorului în Webex. Trebuie să fie valid și unic pentru Webex, altfel provizionarea eșuează.

     Ignorați strofa serviciilor: este creată de AS și acceptată, dar nu este utilizată de Webex.

Analizați jurnalele XSP pentru a depana conectarea abonaților

Acest flux descrie modul de autentificare BroadWorks. Puteți vedea modul de autentificare pe șablon ul BroadWorks, în Partner Hub. Consul tați Configurarea șabloanelor pentru clienți în https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Următoarea diagramă de scară arată interacțiunea dintre utilizator, client, serviciile Webex și sistemul BroadWorks, atunci când utilizatorul efectuează autentificarea BroadWorks în aplicația Webex. De asemenea, conexiunea dintre Webex și XSP este asigurată de MTLS.

Discuția care urmează explică ce vă puteți aștepta să vedeți atunci când investigați jurnalele pentru o autentificare reușită.

Utilizatorul interacționează cu clientul, clientul interacționează cu serviciile Webex:

• Utilizatorul furnizează adresa de e-mail aplicației Webex (1 în diagramă).
• CI știe să redirecționeze acest utilizator pentru a introduce parola BroadWorks (prin UAP) (2 în diagramă).
• Proxy-ul IDP trimite o solicitare de profil get către interfața Xsi de pe XSP.

În tomcat access_log:

• Căutați cererea GET pentru profilul abonatului, de la Webex spre interfața Xsi-Actions (2.1 în diagramă). Are ID-ul de utilizator Webex. De exemplu:

  OBȚINEȚI /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profil

În XSIActionsLog:

• Căutați cererea GET de profil de la Webex (2.1 în diagramă). Are ID-ul de utilizator Webex. De exemplu:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Anteturile includ autorizare: Basic și user-agent: BroadworkSteamsClient

• XSP face apoi autentificarea OCI-P Basic împotriva BroadWorks (AuthenticationVerifyRequest și AuthenticationVerifyResponse, ca orice altă aplicație care face autentificare de bază prin Xsi) și, de asemenea, un UserGetRequest și ServiceProviderGetRequest pentru a aduna informațiile abonatului.
• Răspunsul Xsi la Webex conține un bloc de profil XML care conține ID- ul de utilizator (BroadWorks) și alte detalii (2.2 în diagramă).

Interacțiuni client și servicii Webex:

• Proxy-ul IDP se potrivește cu profilul de utilizator primit de la BroadWorks și emite afirmația SAML către client (2.3 în diagramă).
• Clientul schimbă afirmația SAML pentru un token CI (3 în diagramă).
• Clientul verifică dacă utilizatorul conectat are dreptul la broadworks-connector (4 în diagramă). Puteți verifica drepturile utilizatorilor în Help Desk.
• Clientul utilizează tokenul CI pentru a solicita un JSON Web Token (JWT) de la proxy IDP (5 în diagramă).
• Proxy-ul IDP validează tokenul CI la CI.
• Proxy-ul IDP solicită JWT de la serviciul de autentificare.

În jurnalul AuthenticationService:

• Căutați cererea de token de la Webex (5.2 în diagramă), De exemplu: GET /AuthService/token care are antetul http _bw_user id și altele.
• XSP face OCI-P UserGetLoginInForequest, pentru a valida că ID-ul de utilizator furnizat corespunde unui utilizator BroadWorks (5.3 în diagramă). AuthService a stabilit încredere cu Webex în virtutea conexiunii MTLS, deci poate emite LLT.
• Căutați răspunsul (5.4 în diagramă) de la LongLiveDTokenManager - Token generat, subiect: bwksUserId@example.com, emitent: BroadWorks... și statusCode=200 pe care îl puteți asocia cu solicitarea inițială folosind antetul trackingid: CLIENT...

În XSIActionsLog:

• Clientul este capabil să prezinte tokenul de lungă durată la interfața Xsi-Actions pentru a obține profilul dispozitivului său (6 în diagramă). De exemplu: GET /com.broadsoft.xsi-actions/v2.0/user/bwksuSerid %40example.com/profile/device Cu autorizarea anteturilor: token purtător și agent utilizator: WebExTeams (variantă/versiune)
• Interfața Xsi-Actions POSTEAZĂ tokenul la authservice (configurat să fie pe interfața loopback) De exemplu: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token pe care îl puteți corela cu antetul trackingid: CLIENT... din GET și antetul X-BROADSOFT-CORRELATION-ID: CLIENT... din POST.

În jurnalul AuthenticationService:

• Primirea POȘTEI de la Xsi (loopback)

• A StatusCode=200 înapoi la Xsi

• Și un răspuns de validare a jetonului, având un bloc JSON „token” în corp.

• Corelat folosind trackingid-ul: CLIENT...

În XSIActionsLog:

• După ce a primit 200 OK de la authservice, care a validat stoken-ul clientului, aplicația Xsi-Actions trimite acum solicitarea OCI-P pentru UserPrimaryAndScaDeviceGetListRequest
• Primește OCI-P UserPrimaryAndS caDeviceGetListResponse care conține structura XML AccessDeviceTable.
• Răspunsul OCI-P este codificat ca răspuns Xsi la client, inclusiv structura XML AccessDevices, care are DeviceTypes. De exemplu: Business Communicator - PC și adresele URL unde clientul poate prelua fișierele de configurare a dispozitivului.

Clientul continuă în mod normal:

• Selectează o intrare de dispozitiv și interacționează cu DMS pentru a obține profilul dispozitivului (6 în diagramă).
• Se înregistrează la BroadWorks prin SBC preluat în configurație din DMS (7 în diagramă).

Probleme cu hub-ul partenerilor

1. Administratorul nu poate vedea organizațiile clienților

În calitate de administrator pentru organizația dvs. partener în Webex, ar trebui să aveți rolul Administrator complet. Acest rol este utilizat pentru gestionarea organizației partenere, inclusiv atribuirea privilegiilor administrative pentru dvs. și pentru alte persoane. Pentru a gestiona organizațiile clienților, trebuie să vă acordați (sau altor persoane) rolul Administrator complet de vânzări sau rolul Administrator de vânzări. Pentru detalii, consultați Atri buirea rolurilor contului organizației în Control Hub.

Probleme de furnizare a utilizatorilor

1. Erori IM&P integrate pentru întreprinderi/clienți specific i

Dacă aveți o combinație de întreprinderi care utilizează diferite servicii de colaborare în cloud, de exemplu, UC-One SaaS și Webex pentru Cisco BroadWorks, este posibil să fi optat pentru modificarea adaptorului de furnizare pe bază de întreprindere.

Pentru a verifica ce este configurat pentru IM&P integrat (implicit pentru întreprinderi, cu excepția cazului în care există o setare mai specifică), rulați as _CLI/Interface/Messaging> get. Pentru parametrii de aprovizionare pentru o anumită întreprindere, deschideți întreprinderea și accesați Servicii > IM& P integr at.

Verificați dacă configurația IM&P integrată pentru acea întreprindere se potrivește exact cu ceea ce este afișat în șablonul Client din Hub pentru parteneri. Următoarele setări trebuie să se potrivească, altfel furnizarea eșuează pentru toți utilizatorii din întreprindere:

2. Erori IM&P integrate pentru utilizatori specific i

Acest lucru se aplică dacă utilizați furnizarea fluxthrough și presupune că furnizarea funcționează pentru unei/majoritatea utilizatorilor (astfel încât să puteți exclude o problemă de configurare). Dacă vedeți erori IM&P integrate în BroadWorks, de exemplu, „[Eroare 18215] Eroare de furnizare cu serverul de mesagerie” și „[Eroare 18211] Eroare de comunicare cu serverul de mesagerie”, ar trebui să investigați următoarele cauze potențiale:

• Adresa de e-mail a utilizatorului ar putea exista deja CI. Căutați utilizatorul în Biroul de asistență pentru a verifica dacă adresa de e-mail a acestuia este deja acolo. Acest lucru nu este neapărat concludent, deoarece utilizatorul poate exista într-o organizație ale cărei date nu aveți voie să vedeți în Biroul de asistență.
• Utilizatorul s-a înscris independent la Webex, înainte de a fi atribuit serviciul IM&P integrat. În acest caz, o opțiune este să solicitați utilizatorului să-și șteargă conturile gratuite pe care le poate deveni parte a Organizației de clienți pe care o furnizați. Instrucțiunile sunt la https://help.webex.com/5m4i4y
• Utilizatorul nu are un număr de telefon principal atribuit profilului său (toți abonații Webex pentru Cisco BroadWorks trebuie să aibă un DID principal). Consultați subiectul despre analiza PSLog din AS.

3. Eșecuri de furnizare a utilizatorilor ca răspuns de la puntea de aprovizionare

Dacă utilizatorii nu apar în Control Hub, în câteva minute de la atribuirea IM&P integrat, aruncați o privire asupra codurilor de răspuns din serviciul de punte de furnizare. Rulați un PSlog pentru a privi codurile de răspuns HTTP.

200 OK

Un răspuns 200 OK nu înseamnă că utilizatorul este furnizat cu succes. Aceasta înseamnă că serviciul de furnizare a primit cererea și a trimis cu succes cererea corespunzătoare de creare a utilizatorului către serviciile din amonte. Tranzacția de furnizare este asincronă prin proiectare. Serviciul răspunde 200 OK deoarece procesul de creare a utilizatorului poate dura câteva minute și, din motive de performanță, nu dorim să primim mai multe solicitări pentru a crea același utilizator. Cu toate acestea, dacă utilizatorul nu apare în cele din urmă în Organizația clienților după un răspuns 200 OK, ar putea indica faptul că crearea utilizatorului a eșuat în serviciile Webex din amonte de serviciul de furnizare. Trebuie să escaladați o eroare de aprovizionare care are un răspuns 200 OK.

400 Cerere greșită

Verificați răspunsul HTTP, care ar trebui să aibă mai multe detalii despre problemele potențiale care ar putea cauza acest răspuns din partea serviciului de furnizare. Câteva exemple ale nodului:

• „Nu se poate avea încredere în e-mailul BroadWorks cu API-ul de furnizare vechi.” Adresa de e-mail asociată solicitării de furnizare a utilizatorului eșuată nu este validă sau este introdusă greșit, dar ați afirmat în șablon că adresele de e-mail pot fi de încredere. Verificați profilurile utilizatorilor din BroadWorks, în special ID-ul de e-mail.
• Organizația clientului nu este găsită în baza de date și, de asemenea, semnalizatorul de creare a organizației noi nu este activat.” Această solicitare de furnizare eșuată ar trebui să creeze o nouă organizație de clienți în Webex, dar șablonul dvs. este configurat pentru a împiedica crearea de noi organizații clienți. Dacă doriți să permiteți organizațiilor noi, pentru domeniile de e-mail care nu se potrivesc cu clienții existenți în Webex, atunci puteți să vă reconfigurați șablonul în Partner Hub și să retestați solicitarea de furnizare. Cu toate acestea, dacă nu vă așteptați să fie creată o nouă organizație pentru acest utilizator, este posibil ca adresa de e-mail să fie introdusă greșit (în special partea de domeniu). Verificați ID- ul de e-mail al utilizatorului în BroadWorks.

403 Interzis

Solicitarea de provizionare nu poate reuși până când nu remediați configurația. Va trebui să investigați cererea și răspunsul în acest caz. De exemplu, dacă vedeți o adresă IP ca țintă a solicitării de furnizare — în loc de adresa URL corespunzătoare punții de furnizare pentru organizația dvs. (consultați subiectele de configurare a firewall-ului din Ghidul soluției) — aceasta ar putea indica faptul că Serverului de aplicații lipsește o corecție necesară (ap373197).

Verificați dacă toate corecțiile necesare sunt aplicate Serverului de aplicații și că ați finalizat configurația aferentă pentru furnizarea cu succes prin flux.

409 Conflict

Cererea de furnizare nu poate continua deoarece există un utilizator existent în Webex care se potrivește cu adresa de e-mail din solicitare.

4. Utilizator Deja în CI

Scoateți e-mailul abonatului din solicitarea HTTP POST și căutați-l în Help Desk. Este posibil să nu vedeți utilizatorul dacă nu vi se permite, dar puteți vedea, de asemenea, că utilizatorul se află într-o organizație „gratuită”, de ex. „Consumator”. Puteți cere acestui utilizator să-și șteargă contul gratuit sau puteți utiliza o altă adresă de e-mail pentru a le furniza. A se vedea https://help.webex.com/ndta402.

Probleme de conectare a utilizatorului

1. Portalul de activare a utilizatorului nu se încarcă

Fluxul normal de conectare Webex pentru Cisco BroadWorks include un Portal de activare a utilizatorului în care utilizatorii își introduc parolele. Uneori, acest portal nu se încarcă după ce utilizatorul și-a furnizat adresa de e-mail în ecranul de conectare al aplicației Webex. Această problemă poate fi cauzată de partea clientului sau de partea de serviciu. Pe partea clientului, este de obicei cauzată de faptul că browserul nativ al clientului este incompatibil într-un fel cu serviciul.

2. Conectarea unică a eșuat

• În BroadWorks, verificați dacă utilizatorului i s-au atribuit tipurile de dispozitive pentru aplicația Webex (consultați secțiunea Profiluri dispozitiv din secțiunea Pregătiți mediul din Ghidul de soluții).
• Verificați dacă utilizatorul folosește parola corectă. Dacă șablonul pe care l-ați utilizat pentru furnizarea Organizației clienților utilizatorului (în Hub partener) este configurat pentru autentificarea BroadWorks, utilizatorul ar trebui să introducă parola BroadWorks „Acces Web”. Este posibil ca utilizatorul să fie nevoit să introducă ID-ul său de utilizator BroadWorks dacă adresa sa de e-mail nu este configurată ca ID de utilizator alternativ. Asigurați-vă că utilizatorul a introdus corect caracterele majuscule și minuscule.

Probleme de configurare și înregistrare a apelurilor

După ce un utilizator a fost furnizat în Webex și se conectează cu succes la aplicația Webex, aplicația se înregistrează la BroadWorks. Următoarele sunt secvența de înregistrare așteptată și semnele rezultate ale unei înregistrări sănătoase (așa cum se vede din aplicația Webex):

1. Secvența de înregistrare preconizată

1. Clientul apelează XSI pentru a obține un token de gestionare a dispozitivului și adresa URL către DMS.
2. Clientul solicită profilul dispozitivului său de la DMS prezentând simbolul de la pasul 1.
3. Clientul citește profilul dispozitivului și preia acreditările SIP, adresele și porturile.
4. Clientul trimite un Register SIP către SBC folosind informațiile de la pasul 3.
5. SBC trimite registrul SIP către AS (SBC poate efectua o căutare în NS pentru a localiza un AS dacă SBC nu cunoaște deja utilizatorul SIP.).

2. Semne așteptate de înregistrare reușită a clienților

Pictograma Opțiuni de apelare apare în interfața Webex.

În fila Servicii telefonice Webex App (de exemplu, Setări > Servicii telefon ice pe Windows, Preferințe > Servicii telefon ice pe Mac), mesajul „Sesiune SSO: sunteți conectat” înseamnă că aplicația a fost înregistrată cu succes (în acest caz la BroadWorks).

3. Clientul nu are pictograma Apel are

De cele mai multe ori acest lucru înseamnă că utilizatorul nu are licența/drepturile corecte.

Aceasta este o înregistrare nereușită. Există mai multe motive pentru care un client Webex App nu reușește să se înregistreze cu BroadWorks:

4. Servicii de apelare multiple sunt testate cu aceiași clienți

Această problemă cunoscută poate fi cauzată de schimbarea clientului între diferite terminale de apelare. Este cel mai probabil să apară în timpul încercărilor diferitelor servicii de apelare oferite prin (aceiași) clienți Webex App. Puteți reseta baza de date client (link) pentru a remedia această problemă.

5. Configurarea greșită a serviciului de autentificare

Verificați XSP-urile care găzduiesc serviciul de autentificare în raport cu Ghidul de soluții (consultați Configurarea serviciilor pe Webex pentru Cisco BroadWorks XSP). Mai exact:

• Cheile RSA (pe care le generați pe un XSP) sunt copiate pe toate XSP-urile
• Adresa URL a serviciului de autentificare a fost furnizată containerului web de pe toate XSP-urile și a fost introdusă corect în cluster în Partner Hub
• Autentificarea externă prin certificate este configurată:

  XSP_CLI/System/CommunicationUtility/Setări implicități/Autentificare externă/CertificateAuthentication>Obține

  allowUserApp = false

  allowClientApp = true

• Când utilizați MTLS, trebuie să încărcați certificatul client Webex în XSP (puteți obține certificatul de la Partner Hub, pe pagina Setări BroadWorks).

6. Configurarea greșită a etichetelor BroadWorks

Verificați dacă ați configurat etichetele BroadWorks necesare pentru aplicația Webex. Consultați Ghi dul de configurare Webex pentru Cisco BroadWorks pentru informații despre etichetele de configurare. Asigurați-vă că nu există conflicte sau valori incorecte. Mai exact, eticheta %SBC_ADDRESS_WXT% ar trebui să fie SBC către registratorul SIP pentru clienții aplicației Webex.

7. Clientul desktop deconectează serviciile de telefonie după o conexiune SSO reușită

Această problemă poate fi cauzată de același utilizator care se conectează la mai mulți clienți pe același tip de platformă. De exemplu, dacă un utilizator se conectează cu succes la aplicația Webex pe Windows și apoi se conectează la aplicația Webex pe o altă mașină Windows, există doar o sesiune SSO activă pe unul dintre computere. Acest lucru este prin design. Dacă trebuie absolut să rezolvați această problemă, puteți configura BroadWorks pentru a avea mai multe instanțe de același tip de dispozitiv, dar acestea trebuie să aibă adrese SIP unice. Această configurație este în afara domeniului de aplicare al Webex pentru Cisco BroadWorks.

8. Dispozitivul desktop nu este furnizat pentru utilizator

Această semnătură este văzută în jurnalul clientului:

[0x70000476b000] BroadworksConfigDownloader.cpp: 106 <Error>

onAccessDeviceListSucceded:bwc:scf: configDownload - profilul dispozitivului 'Business Communicator - PC' nu a fost găsit.

9. Apelurile mobile de intrare sună o dată sau nu pot fi răspunse

Apelurile de intrare către telefonul mobil Webex sună o singură dată sau utilizatorul nu poate răspunde la apelul de intrare. Alte puncte finale pentru același utilizator pot continua să sune.

Cum se identifică?

În jurnalele clientului mobil Webex, căutați codul de eroare XSI 101002 în fluxul de apel push. De exemplu:

Cod de răspuns: 400

<callID>HandlePushCallInfoFailure:bwc:Internal: Apel push: stare xsi pentru callID: xsi cod de eroare: 101002

<callID>ClosePushCallWithReason:bwc:Internal: Încercați să închideți apelul push cu id =, reason = callAbandoned

Cauză: Codul de eroare 101002 poate indica faptul că serverul de aplicații (AS) greșit este returnat în răspunsul Loc ateUser. Acest lucru se poate întâmpla atunci când utilizatorul a migrat la un AS secundar.

Verificări recomandate:

Din ADP sau XSP unde este implementat Push, rulați LocateUser pentru utilizatorul afectat:

<FQDN or IP address of NS Server>curl 'http: //:80/servlet/locateUser? <BW userID @domain >url=&returncompatibleXSP=true&callpRequest=tru'

Exemplu: curl 'http://1.1.1.1:80/servlet/LocateUser? url= 9721112222@gmail.com &returnCompatibleXSP=true&callpRequest=adevărat”

Rezoluție: Dacă LocateUser returne ază AS secundar pentru utilizator, rulați scriptul MigrateUserToDefaultNode.pl pe serverul NS principal pentru a migra utilizatorii înapoi la serverul principal de aplicații pentru cluster.

Conectați-vă la serverul NS prin SSH, accesați directorul /usr/local/broadworks/bw_base/bin și executați: migrateU serToDefaultNode.pl <hostingNE>

Exemplu: Migrate UserToDefaultNode.pl bwas1

Pentru a obține valoarea HostingNE, executați: ns_CLI/System/Device/Hostingne> get

Scriptul verifică mai întâi dacă poate găsi NE de găzduire pe care îl furnizați ca argument. După ce verifică dacă NE de găzduire este valid, actualizează DN, extensia și adresa URL la nodul implicit pentru acel NE de găzduire.

Rulați scriptul într-o perioadă de trafic redus, atunci când este posibil. Cu toate acestea, este în general acceptabil să rulați scriptul oricând, dacă este necesar, pentru a restabili serviciul pentru utilizatorii afectați.

Scriptul nu poate fi rulat doar pentru un singur utilizator. Migrează toți utilizatorii listați în ieșirea LocateUser. Dacă nu puteți rula scriptul, ștergeți și reconstruiți utilizatorul afectat în BroadWorks, astfel încât utilizatorul să fie reconstruit pe AS-ul corect.

Orice mesaj SIP de la dispozitivul utilizatorului către AS-ul secundar poate determina migrarea utilizatorului. Utilizatorii revin, de obicei, la AS principal după intervalul implicit de 15 minute, cu excepția cazului în care solicitările primite continuă să ajungă la AS secundar. De exemplu, dacă SBC nu se poate conecta la AS1 și recurge la AS secundar, utilizatorii afectați pot trece la AS secundar. În funcție de implementare, un singur grup de trunchi sau un singur utilizator poate rămâne fixat la AS secundar dacă SBC continuă să aibă probleme cu atingerea AS-ului principal.

Pentru mai multe informații, consultați următoarele documente:

• Secțiunile 3.4.5 Capacitatea de returnare a utilizatorului serverului de aplicații și 5.4.5 Rollback automat în Ghidul de redundanță Cisco BroadWorks

• Descrierea caracteristicilor îmbunătățirilor Cisco BroadWorks ASR

9. Serviciile telefonice deconectate

Dacă serviciile de telefonie se afișează ca fiind deconectate după ce utilizatorul se conectează la aplicația Webex sau dacă serviciile de telefonie se deconectează în timp ce utilizatorul utilizează clientul, verificați tipul de client și fluxul de înregistrare.

Pentru clienții Windows și Mac, aplicația Webex se înregistrează pentru SIP și păstrează o înregistrare SIP activă în timp ce utilizatorul este conectat.

Verificați următoarele:

1. Verificați dacă config-wxt.xml a fost descărcat cu succes.

În jurnalele clientului, căutați ConfigDownload.

O descărcare reușită arată:

ConfigDownload - finalizat cu succes

Dacă jurnalele prezintă următoarea eroare, verificați jurnalele AuthService pentru erori legate de token:

ConfigDownload - a eșuat cu codul de eroare: 1511

2. Verificați dacă profilul dispozitivului Webex este găsit.

În jurnalele clientului, confirmați că dispozitivul de acces este găsit și că used_value este 1. Dacă valoarea utilizată este 0, verificați dacă Linia primară este activată sau dezactivată și verificați valoarea etichetei. Pentru mai multe detalii, consultați secțiunea 6.1.44 Profil primar din Ghidul de configurare Webex pentru BroadWorks.

Exemple de intrări în jurnal:

:BWC:SCF: configDownload - dispozitiv de acces găsit

:BWC:SCF: configDownload - dispozitiv de acces: DeviceType=Business Communicator - PC, DeviceLevel=grup, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspect apel partajat

:BWC:SCF: configDownload - dispozitiv de acces: DeviceType=Connect - Mobil, DeviceLevel=grup, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspect apel partajat

:BWC:SCF: configDownload - dispozitiv de acces: DeviceType=Connect - Tabletă, DeviceLevel=grup, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Aspect apel partajat

3. Verificați dacă există eșecuri DNS atunci când rezolvați adresa proxy SIP.

Pentru detalii despre descoperirea proxy SIP, consultați secțiunea 6.1.6 Descoperirea dinamică a proxy SIP din Ghi dul de configur are Webex pentru BroadWorks.

O descoperire proxy reușită arată:

Descoperirea proxy a fost finalizată, a obținut <number>rezultate

4. Verificați dacă înregistrarea SIP nu reușește.

Dacă jurnalele arată MRegistration: TCPTimeout sau Reason: SIP; cause=200; text="last=TCP-timeout”, clientul Webex nu poate stabili o conexiune TCP de nivel scăzut la SBC. Înregistrarea SIP nu se finalizează atunci când apare această eroare. Verificați dacă TCP este blocat în rețeaua utilizatorului sau dacă SBC respinge conexiunea TCP.

Dacă solicitarea SIP REGISTER este respinsă sau nu primește un răspuns, căutați în jurnale pentru REGISTER sip și verificați dacă SIP/2.0 200 OK este returnat. Dacă nu este returnat, verificați dacă rețeaua utilizatorului blochează SIP sau dacă SBC respinge solicitarea.

În Admin BroadWorks, accesați Utilizator > Utilități > Înregistrări și verificați dacă este prezentă o înregistrare SIP validă pentru clientul Webex.

Pentru clienții mobili Android și iOS, aplicația Webex nu se înregistrează pentru SIP până când nu este plasat sau primit un apel. Înregistrarea este eliminată la finalizarea apelului. Clienții mobili se înregistrează pentru notificări push.

Pentru clienții de telefonie mobilă, verificați următoarele:

1. Verificați dacă config-wxt.xml se descarcă cu succes și dacă profilul dispozitivului este găsit, așa cum este descris pentru clienții Windows și Mac.

2. Verificați dacă înregistrarea push reușește.

În jurnalele Webex, căutați starea de înregistrare push:

OnPushRegistrationStateChanged: :Starea înregistrării push modificată, state=Neînregistrat

OnPushRegistrationStateChanged: :Starea înregistrării push modificată, state=înregistrat

În Admin BroadWorks, accesați Utilizator > Utilități > În registrări notificări push și verificați dacă este prezentă o înregistrare push validă pentru clientul Webex.

Probleme de vizualizare web cu setările apelurilor

1. Butonul/linkul de auto-îngrijire nu se afișează în aplicația We bex

Un alt simptom al acestei probleme este atunci când este afișat buton/linkul, dar făcând clic pe acesta se deschide un browser extern.

• Verificați dacă șablonul de configurare a clientului necesar este implementat și etichetele CSW sunt setate corect. (Consultați secțiunea Vizualizare web Setări apel din Ghidul de soluții Webex pentru Cisco BroadWorks).
• Verificați dacă aplicația Webex este înregistrată pentru a apela în BroadWorks.
• Verificați dacă aplicația Webex este o versiune recentă care acceptă CSWV.

2. Pagină goală sau eroare după ce faceți clic pe buton/link de îngrijire personală

În general, acest comportament în aplicația Webex indică o problemă de configurare sau implementare cu aplicația CSWV pe BroadWorks XSP. Colectați detalii pentru investigații suplimentare, inclusiv jurnale CSWV, jurnale de acces, depozit config-wxt.xml și fișier șablon, apoi ridicați un caz.

Probleme de revendicare a domeniului

Erorile de înregistrare a utilizatorilor pot apărea ca urmare a erorilor care se fac în revendicarea domeniilor. Înainte de a revendica orice domeniu, asigurați-vă că înțelegeți următoarele:

• Furnizorii de servicii nu ar trebui să revendice domeniile organizațiilor client pe care le gestionează. Aceștia ar trebui să revendice numai domeniile acelor utilizatori care se află în organizația internă a Furnizorului de servicii. Revendicarea domeniului utilizatorilor într-o organizație separată (chiar și una pe care Furnizorul de servicii o gestionează) poate duce la erori de înregistrare pentru utilizatorii din organizația client, deoarece solicitările de autentificare ale utilizatorilor sunt direcționate prin Furnizorul de servicii și nu prin organizația clientului.
• Dacă două organizații clienți (Compania A și Compania B) au același domeniu și Compania A a revendicat domeniul, înregistrarea pentru utilizatorii Companiei B poate eșua din cauza faptului că solicitările de autentificare ale utilizatorilor sunt direcționate prin organizația care are domeniul revendicat (Compania A).

  Dacă revendicați orice domeniu din greșeală și trebuie să eliminați o revendicare, consultați articolul Ges tionarea domeni ilor Webex.

Coduri de eroare ale utilizatorului final

Următorul tabel prezintă codurile de eroare ale utilizatorilor finali care pot fi văzute în portalul de activare a utilizatorului client.

Coduri de eroare pentru Directory Sync

Următoarele coduri de eroare se aplică la Directory Sync.