Mulțumim pentru feedback.

Acest articol este destinat echipei de asistență tehnică din cadrul organizațiilor furnizori de servicii care se ocupă de ei înșiși și de clienții lor. Ar trebui să fie familiarizați cu depanarea generală, citirea jurnalelor și lucrul cu cazurile abonaților.

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

• Resurse — oferă o listă de instrumente, materiale de lectură, jurnale și contacte de care ați putea avea nevoie.
• Procese — descrie unele dintre acțiunile pe care le puteți întreprinde atunci când depanați o problemă a unui client.
• Probleme specifice — clasifică și enumeră problemele despre care se știe că apar, cum se pot identifica și cum se pot rezolva.

Fișiere jurnal utile

Listă 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 Cisco BroadWorks Device Management (R23)
• Ghid de administrare a interfeței de linie de comandă Broadworks Xsp
• Long-Lived Autentificare Token Caracteristica Descriere Release 23.0
• Ghid de integrare a autentificării SAML, R23
• Ghidul opțiunilor de asistență Cisco BroadWorks SSL
• Descrierea funcției de asistență Cisco CI
• Server de notificare push (Descrierea caracteristicii)
• Push Notification Support pentru apeluri Caracteristica Descriere Release 22.0
• Metoda de procedură pentru migrarea Connect (Android) către Firebase
• Stocarea Cisco BroadWorks a jetoanelor de dispozitiv pentru notificări push Descrierea caracteristicii Versiunea 22.0
• Planificator de capacitate a sistemului Cisco BroadWorks (foaie de calcul)
• Ghid de dimensionare a platformei Cisco BroadWorks
• Ghid de inginerie a sistemului Cisco Broadworks
• Cerințe 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 for BroadWorks.

Conector Serviceability

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

Pentru detalii despre cum se implementează conectorul Serviceability, consultați Ghidul de implementare pentru Cisco Webex Serviceability Connector.

Escaladarea unei probleme

După ce ați urmat o parte din instrucțiunile de depanare, ar trebui să aveți o idee destul de clară despre cauza problemei.

procedură

1. Colectați cât mai multe informații posibil din 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.
• Intervalul aproximativ de timp în care a apărut 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 administrator Help Desk (de bază sau avansat) pot utiliza această procedură pentru a verifica detaliile utilizatorului utilizând vizualizarea Help Desk.

procedură

1. Conectați-vă la Biroul de asistență.
2. Căutați, apoi faceți clic pe utilizator. Aceasta deschide ecranul rezumat al 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 de apelare și 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 un caz Cisco.

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

Administratorii parteneri care au privilegii de administrator Help Desk (de bază sau avansat) pot utiliza această procedură pentru a vizualiza detaliile organizației clientului în vizualizarea Help Desk.

procedură

1. Conectați-vă la Biroul de asistență.
2. Căutați, apoi faceți clic pe numele organizației client.
3. Derulați în jos până când vedeți Vizualizare portal client și faceți clic pe Vizualizare nume client pentru a vedea o vizualizare doar în citire a organizației client – inclusiv utilizatori și configurație.

Preluarea jurnalelor utilizatorilor din Centrul pentru parteneri

Atunci când se depanează problemele clienților desktop și mobil, este important ca partenerii (și TAC) să poată vizualiza jurnalele clienților.

procedură

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

   Opțiunea Hub partener:

   1. Conectați-vă la Hubul de parteneri și găsiți Organizația clienților utilizatorului.
   2. Selectare Depanare.
   3. Selectare 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 Biroul de asistență.
   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. Selectare Depanare.
   6. Selectare 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ăsești versiunea clientului

procedură

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

Verificare client pentru apelarea serviciului

procedură

1. Conectați-vă la clientul Webex.
2. Verificați dacă pictograma Opțiuni de apelare (un telefon cu o treaptă de viteză deasupra acesteia) este prezentă pe bara laterală. Dacă pictograma nu este prezentă, este posibil ca utilizatorul să nu fie încă activat pentru serviciul de apelare din Control Hub.
3. Deschideți meniul Setări/Preferințe și accesați secțiunea Servicii telefonice. Ar trebui să vedeți starea sesiunii SSO La care v-ați conectat. (Dacă un alt serviciu telefonic, cum ar fi Webex Calling, este afișat, utilizatorul nu utilizează Webex pentru Cisco BroadWorks.)

   Această verificare înseamnă:

   • Clientul a traversat cu succes microservicii Webex necesare.
   • Utilizatorul s-a autentificat cu succes.
   • Clientului i se emite un token web JSON de lungă durată de către sistemul dumneavoastră BroadWorks.
   • Clientul și-a preluat 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 clienți pe clienții desktop Webex sau solicitați utilizatorilor să trimită jurnale. Pentru ajutor, consultați: Aplicația Webex | Raportează o problemă.
• Solicitați utilizatorilor clienților mobili să trimită jurnale, apoi le puteți obține prin intermediul Centrului pentru parteneri sau al Centrului de asistență.
  Trimiterea jurnalelor este silențioasă. Cu toate acestea, dacă un utilizator trimite feedback, acesta merge la echipa Webex App devops. Asigurați-vă că înregistrați numărul de feedback al utilizatorului dacă doriți să urmăriți Cisco. De exemplu:

  

Obțineți date despre mediul de apelare

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

procedură

1. Pe client, faceți clic pe Ajutor > Verificator de stare.
2. Selectați Reinițializare bază de date. Aceasta declanșează o resetare completă a clientului și încarcă ecranul de conectare la aplicația 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:

• Drept de acces al utilizatorului la broadworks-connector.
• Comportamentul la apel pentru organizație și utilizator.

Verificați comportamentul de apelare al unui utilizator și dreptul 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 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 găsi secțiunea entitlements și verificați dacă broadworks-connector este inclus.

   

   Un utilizator Webex for Cisco BroadWorks nu ar trebui să aibă dreptul bc-sp-standard dacă intenționează să utilizeze Webex for Cisco BroadWorks. Acesta este dreptul pentru „Webex Calling (Broadcloud)”, care este apelarea prin aplicația Webex printr-un serviciu de apelare în 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 bifați intrarea Comportament apel. Ar trebui să fie "Apelarea în Webex".

Analizați PSLog pentru probleme de furnizare a utilizatorilor

Utilizați PSLog-ul serverului de aplicații pentru a vedea solicitarea HTTP POST la puntea de asigurare a accesului și răspunsul de la Webex. Într-un caz de lucru corect, răspunsul este de 200 OK și după câteva minute puteți vedea că utilizatorul - și noul Client org dacă este primul utilizator - a fost creat în Webex. Puteți verifica acest lucru căutând în Biroul de asistență 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 asigurare a accesului prin flux cu un utilizator de test.

procedură

1. Mai întâi, verificați codul de răspuns HTTP:
   • Orice altceva decât 200 OK este o eroare de asigurare a accesului de utilizator.
   • 200 OK ar putea indica în continuare o eroare dacă ceva legat de profilul abonatului nu funcționează în serviciile Webex din amonte de puntea de furnizare.
   • 400 poate conține un nod message în răspuns. Puntea de furnizare nu a putut procesa ceva în subscriberProfile. Este posibil să fie ceva în neregulă cu detaliile abonatului sau incompatibilitate cu o setare din șablon.
   • 401 înseamnă că acreditările de asigurare a accesului introduse în as nu se potrivesc cu cele introduse în șablon în Hubul partenerilor.
   • 403 ar putea indica ceva configurat greșit pe Application Server. Verificați ținta solicitării. nu ar trebui să fie o adresă IP, ar trebui să fie adresa URL a punții de asigurare a accesului pe care o puteți vedea în șablon în Hubul partenerilor.
   • 409 indică un conflict între datele furnizate subscriberProfile și datele Webex existente. Este posibil să existe un utilizator existent cu acea adresă de e-mail. Bifați semnul message din răspuns.
2. De asemenea, puteți verifica postarea HTTP originală pentru orice valori suspecte care ar putea provoca eșecul provizionării. Comanda POST conține o structură XML subscriberProfile. În interiorul acesteia, noduri utile pentru a verifica sunt:
   • bwuserid: Folosește această funcție pentru a găsi profilul abonatului dacă trebuie să îl editezi în BroadWorks.
   • group: Dacă șablonul este în „Modul Furnizor de servicii”, acesta este scris cu literă mică și devine numele organizației Client pe care o vedeți în Centrul pentru parteneri.
   • serviceProvider: Dacă șablonul este î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. Provizionarea eșuează fără ea.
   • email: Devine ID-ul utilizatorului în Webex. Trebuie să fie valid și unic pentru Webex, altfel asigurarea accesului nu reușește.

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

Analizați jurnalele XSP pentru a depana erorile de conectare a abonaților

Acest flux descrie modul de autentificare BroadWorks. Puteți vedea modul de autentificare în șablonul BroadWorks, în Hub partener. Consultați Configurarea șabloanelor de client în https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Următoarea diagramă cu scale prezintă 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 securizată prin MTLS.

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

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

• Utilizatorul furnizează adresa sa 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 pentru interfața Xsi de pe XSP.

În motan access_log:

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

  GET /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

În XsiActionsLog:

• Căutați solicitarea 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 authorization: Basic și user-agent: broadworksTeamsClient

• XSP face apoi autentificarea de bază OCI-P î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 colecta informațiile abonatului.
• Răspunsul Xsi către Webex conține un bloc XML Profile care conține (BroadWorks) userId și alte detalii (2.2 în diagramă).

Interacțiuni cu serviciile client și Webex:

• Proxy-ul IDP potrivește profilul utilizatorului primit de la BroadWorks și emite aserțiunea SAML clientului (2.3 în diagramă).
• Clientul schimbă aserțiunea SAML pentru un token CI (3 în diagramă).
• Clientul verifică dacă utilizatorul conectat are dreptul de conector broadworks (4 în diagramă). Puteți verifica drepturile utilizatorilor în Help Desk.
• Clientul folosește un token CI pentru a solicita un token web JSON (JWT) de la proxy-ul IDP (5 în diagramă).
• Proxy-ul IDP validează token-ul CI la CI.
• Proxy-ul IDP solicită JWT de la serviciul de autentificare.

În jurnalul de autentificareService:

• Căutați solicitarea de token de la Webex (5.2 în diagramă), de exemplu: GET /authService/token care are antetul http_bw_userid și altele.
• XSP efectuează OCI-P UserGetLoginInfoRequestpentru a valida dacă ID-ul de utilizator furnizat corespunde unui utilizator BroadWorks (5.3 în diagramă). AuthService a stabilit încrederea cu Webex în virtutea conexiunii mTLS, astfel încât poate emite LLT.
• Căutați răspunsul (5.4 în diagramă) de la LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks … și StatusCode=200 pe care îl puteți asocia cu solicitarea originală folosind antetul trackingid: CLIENT… .

În XsiActionsLog:

• Clientul poate prezenta token-ul cu viață lungă 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 anteturile authorization: Bearer token și user-agent: WebexTeams (variant/version)
• Interfața Xsi-Actions trimite token-ul prin POST către serviciul de autentificare (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 le puteți corela cu antetul trackingid: CLIENT… din GET și cu antetul X-BROADSOFT-CORRELATION-ID : CLIENT… din POST.

În jurnalul de autentificareService:

• Primirea postului de la Xsi (loopback)

• Înapoi la Xsi StatusCode=200

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

• Corelată utilizând trackingid: CLIENT…

În XsiActionsLog:

• După ce a primit 200 OK de la authservice, care a validat stoken-ul clientului, aplicația Xsi-Actions trimite acum o cerere OCI-P pentru UserPrimaryAndSCADeviceGetListRequest
• Primește OCI-P UserPrimaryAndSCADeviceGetListResponse care conține structura XML accessDeviceTable.
• Răspunsul OCI-P este codificat ca răspuns Xsi către client, incluzând structura XML AccessDevices, care are deviceTypes. De exemplu: Business Communicator – PC și URL-urile unde clientul poate prelua fișierele de configurare a dispozitivului.

Clientul continuă ca de obicei:

• Selectează o intrare de dispozitiv și interacționează cu DMS pentru a obține profilul dispozitivului (6 în diagramă).
• Înregistrări către BroadWorks prin SBC preluate în configurație din DMS (7 în diagramă).

Probleme legate de Centrul pentru parteneri

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

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

Probleme de furnizare a utilizatorilor

1. IM integrat & Erori P pentru întreprinderi specifice / clienți

Dacă aveți un mix de companii 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 pentru fiecare companie în parte.

Pentru a verifica ce este configurat pentru IM integrat & P (implicit pentru întreprinderi, cu excepția cazului în care există o setare mai specifică), executați AS_CLI/Interface/Messaging> get. Pentru parametrii de furnizare ai unei anumite întreprinderi, deschideți întreprinderea și accesați Servicii > IM integrat & P..

Verificați dacă configurația IM&P integrată pentru acea întreprindere se potrivește exact cu ceea ce se afișează în șablonul de client din Hubul de parteneri. Următoarele setări trebuie să se potrivească sau asigurarea accesului nu reușește pentru toți utilizatorii din întreprindere:

2. IM integrat & Erori P pentru anumiți utilizatori

Acest lucru se aplică dacă utilizați furnizarea de flux și presupune că furnizarea funcționează pentru some/most utilizatori (pentru a putea exclude o problemă de configurare). Dacă vedeți mesaje instant integrate & Erori P în BroadWorks, de exemplu, “[Error 18215] Eroare de furnizare a informațiilor la serverul de mesagerie” și “[Error 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 secțiunea Help Desk pentru a verifica dacă adresa sa de e-mail există deja acolo. Acest lucru nu este neapărat concludent, deoarece utilizatorul poate exista într-o organizație ale cărei date nu aveți permisiunea de a le vizualiza în Centrul de asistență.
• Utilizatorul s-a înscris independent la Webex, înainte de a i se atribui serviciul IM&P integrat. În acest caz, o opțiune este ca utilizatorul să își șteargă conturile gratuite, astfel încât să poată deveni parte a organizației clientului 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 for Cisco BroadWorks trebuie să aibă un DID principal). A se vedea subiectul privind analiza PSLog de la AS.

3. Erori de furnizare a serviciilor de utilizator ca răspuns de la puntea de furnizare a serviciilor

Dacă utilizatorii nu apar în Control Hub, în câteva minute de la atribuirea funcției Integrated IM & P, uită-te la codurile de răspuns de la serviciul de punte de aprovizionare. Executați un PSLog pentru a vă uita la codurile de răspuns HTTP.

200 OK

Un răspuns 200 OK nu înseamnă că utilizatorul a fost aprovizionat cu succes. Aceasta înseamnă că serviciul de furnizare a primit cererea și a transmis cu succes cererea corespunzătoare de creare a utilizatorului către serviciile din amonte. Tranzacția de asigurare a accesului este asincrotă prin concepție. Serviciul răspunde cu mesajul 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. Totuși, dacă utilizatorul nu apare în cele din urmă în Organizația clientului după un răspuns 200 OK, acest lucru 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 asigurare a accesului care are un răspuns de 200 OK.

400 Cerere proastă

Verificați răspunsul HTTP care ar trebui să aibă mai multe detalii despre problemele potențiale care ar putea provoca acest răspuns de la serviciul de asigurare a accesului. Câteva exemple de noduri:

• "Nu puteți avea încredere în e-mailul BroadWorks cu API-ul de asigurare a accesului moștenit." Adresa de e-mail asociată cu solicitarea de asigurare a accesului pentru utilizator care nu a reușit nu este validă sau este tastată greșit, dar ați afirmat în șablon că adresele de e-mail pot fi de încredere. Verificați profilurile utilizatorilor în BroadWorks, în special id-ul de e-mail.
• Organizația client nu a fost găsită în baza de date și, de asemenea, semnalizatorul de creare a unei noi organizații nu este activat. Această solicitare de asigurare a accesului nereușită ar trebui să creeze o nouă organizație client în Webex, dar șablonul este configurat pentru a preveni crearea de noi organizații client. Dacă doriți să permiteți organizații noi, pentru domenii de e-mail care nu se potrivesc cu clienții existenți în Webex, atunci aveți posibilitatea să reconfigurați șablonul în Hub partener și să retestați solicitarea de asigurare a accesului. Cu toate acestea, dacă nu vă așteptați să fie creată o nouă organizație pentru acest utilizator, poate că adresa de e-mail este tastată greșit (în special partea de domeniu). Verificați id-ul de e-mail al utilizatorului în BroadWorks.

403 Interzis

Cererea de furnizare nu poate avea succes până când nu remediați configurația. În acest caz, va trebui să investigați cererea și răspunsul. De exemplu, dacă vedeți o adresă IP ca țintă a solicitării de asigurare a accesului - în loc de URL-ul corespunzător al punții de asigurare a accesului pentru organizația dvs. (consultați subiectele de configurare a paravanului de protecție din Ghidul de soluții) - ar putea indica faptul că serverului de aplicații îi lipsește un patch necesar (ap373197).

Verificați dacă toate corecțiile necesare sunt aplicate serverului de aplicații și dacă ați finalizat configurația aferentă pentru asigurarea accesului cu succes prin flowthrough.

409 Conflict

Solicitarea de asigurare a accesului 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

Obțineți e-mailul abonatului din solicitarea HTTP POST și căutați-l în Biroul de asistență. Este posibil să nu vedeți utilizatorul dacă nu vi se permite, dar este posibil să vedeți, de asemenea, că utilizatorul se află într-o organizație "gratuită", de exemplu "Consumator". Puteți solicita 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 utilizatorilor

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

Fluxul normal de conectare Webex pentru Cisco BroadWorks include un portal de activare a utilizatorilor unde utilizatorii își introduc parolele. Uneori, acest portal nu se încarcă după ce utilizatorul a introdus adresa de e-mail în ecranul de conectare la aplicația Webex. Această problemă poate fi cauzată pe partea de client sau pe partea de service. Pe partea de client, este de obicei cauzată de browser-ul nativ al clientului fiind incompatibil într-un fel cu serviciul.

2. Sign On unic nu a reușit

• În BroadWorks, verificați dacă utilizatorului i-au fost atribuite tipurile de dispozitive pentru aplicația Webex (consultați secțiunea Profiluri de dispozitive din secțiunea Pregătirea mediului din Ghidul soluțiilor).
• Verificați dacă utilizatorul folosește parola corectă. Dacă șablonul pe care l-ați utilizat pentru a furniza Organizația Clientului utilizatorului (în Partner Hub) este configurat pentru autentificarea BroadWorks, utilizatorul trebuie să introducă parola sa de „Acces Web” BroadWorks. De asemenea, 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 configurat î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 funcționale (așa cum se vede din aplicația Webex):

1. Secvența de înregistrare așteptată

1. Clientul apelează XSI pentru a obține un simbol de gestionare a dispozitivului și URL-ul la DMS.
2. Clientul solicită profilul dispozitivului său de la DMS prin prezentarea token-ului de la pasul 1.
3. Clientul citește profilul dispozitivului și preia acreditările SIP, adresele și porturile.
4. Clientul trimite un REGISTRU SIP la SBC utilizând 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 ale înregistrării cu succes a clientului

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

În fila de servicii telefonice a aplicației Webex (de exemplu, Setări > Servicii telefonice pe Windows, Preferințe > Servicii telefonice pe Mac), mesajul „Sesiune SSO: Sunteți conectat" înseamnă aplicația înregistrată cu succes (la BroadWorks în acest caz).

3. Clientul nu are pictogramă de apelare

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 ar putea eșua înregistrarea la BroadWorks:

4. Mai multe servicii de apelare sunt testate cu aceiași clienți

Această problemă cunoscută poate fi cauzată de schimbarea clientului între diferite apeluri înapoi se termină. Cel mai probabil, acest lucru se întâmplă în timpul perioadelor de probă ale diferitelor servicii de apelare oferite prin intermediul (aceleași) clienți ai aplicației Webex. Aveți posibilitatea să reinițializați 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 conformitate cu Ghidul de soluții (consultați Configurarea serviciilor pe Webex pentru Cisco BroadWorks XSPs). Special:

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

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>get

  allowUserApp = false

  allowClientApp = true

• Când utilizați MTLS, trebuie să încărcați certificatul clientului Webex în XSP-uri (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 Ghidul de configurare Webex for 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-ul către registratorul SIP pentru clienții Webex App.

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

Această problemă poate fi cauzată de același utilizator conectarea la mai mulți clienți de 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ă o sesiune SSO activă doar pe una dintre mașini. Acest lucru este de proiectare. Dacă trebuie neapărat să rezolvați această problemă, puteți configura BroadWorks să aibă mai multe instanțe de același tip de dispozitiv, dar 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 utilizatorului

Această semnătură este vizibilă în jurnalul clientului:

[0x70000476b000] BroadWorksConfigDownloader.cpp:106

onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

9. Apelurile primite de pe mobil sună o dată sau nu se poate răspunde

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

Cum să identific?

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

Cod de răspuns: 400

handlePushCallInfoFailure:BWC:INTERNAL: Apel împins: Starea xsi pentru ID apel: <callID> Cod de eroare xsi: 101002

closePushCallWithReason:BWC:INTERNAL: Încearcă să închizi apelul push cu ID-ul = <callID>, motiv = ApelAbandonat

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

Verificări recomandate:

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

curl 'http://:80/servlet/LocateUser?url=&returnCompatibleXSP=true&callPRequest=true'

Exemplu: curl 'http://1.1.1.1:80/servlet/LocateUser?url=9721112222@gmail.com&returnCompatibleXSP=true&callPRequest=true'

Rezoluție: Dacă LocateUser returnează AS-ul secundar pentru utilizator, rulează scriptul migrateUserToDefaultNode.pl pe serverul NS principal pentru a migra utilizatorii înapoi la serverul de aplicații principal pentru cluster.

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

Exemplu: migrateUserToDefaultNode.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 elementul de ne (NE) de găzduire pe care îl furnizați ca argument. După ce verifică dacă NE-ul de găzduire este valid, actualizează DN-ul, extensia și URL-ul la nodul implicit pentru acel NE de găzduire.

Executați scriptul într-o perioadă cu trafic redus, atunci când este posibil. Totuși, 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 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. De obicei, utilizatorii revin la AS-ul principal după intervalul implicit de 15 minute, cu excepția cazului în care cererile primite continuă să ajungă la AS-ul secundar. De exemplu, dacă SBC nu se poate conecta la AS1 și recurge la AS-ul secundar, utilizatorii afectați pot trece la AS-ul secundar. În funcție de implementare, un singur grup de trunchiuri sau utilizator poate rămâne conectat la AS-ul secundar dacă SBC-ul continuă să aibă probleme în a ajunge la AS-ul primar.

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

• Secțiunile 3.4.5 Capacitate de revenire la setările utilizatorului serverului de aplicații și 5.4.5 Revenire automată în Ghidul de redundanță Cisco BroadWorks

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

Probleme legate de vizualizarea web a setărilor de apeluri

1. Îngrijire personală button/link nu se afișează în aplicația Webex

Un simptom diferit al acestei probleme este atunci când butonul / link-ul este afișat, dar făcând clic pe acesta deschide un browser extern.

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

2. Pagină goală sau eroare după ce ați făcut clic pe Îngrijire personală button/link

În general, acest comportament în aplicația Webex indică o problemă de configurare sau de implementare a aplicației CSWV pe BroadWorks XSP. Colectați detalii pentru investigații suplimentare, inclusiv jurnalele CSWV, jurnalele de acces, depozitul de configurare.xml și fișierul șablon, apoi ridicați un caz.

Probleme legate de revendicările de domeniu

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

• Furnizorii de servicii nu ar trebui să revendice domeniile organizațiilor clienților pe care le gestionează. Acestea ar trebui să revendice numai domeniile acelor utilizatori care se află în organizația internă a furnizorului de servicii. Revendicarea domeniului utilizatorilor dintr-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, mai degrabă decât prin organizația client.
• Dacă două organizații de clienți (compania A și compania B) partajează același domeniu și compania A a revendicat domeniul, înregistrarea pentru utilizatorii companiei B poate să nu reușească 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 Gestionare domenii Webex.

Coduri de eroare pentru utilizatorii finali

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

Coduri de eroare pentru sincronizarea directorului

Următoarele coduri de eroare se aplică la Sincronizare director.