Inscripționare
18 iun. 2021 | vizualizare(ări) | persoane au considerat că este util

Ghid de depanare Webex pentru BroadWorks

Sfaturi de depanare pentru Webex pentru BroadWorks, inclusiv subiecte să, liste de fișiere jurnal și utilizările acestora și sfaturi pentru investigarea problemelor specifice.

Depanare Webex pentru BroadWorks

Depanare Webex pentru BroadWorks

Depanarea Webex pentru BroadWorks

Acest document este destinat persoanelor tehnice din organizațiile furnizorilor de servicii care se sprijină pe ei înșiși și pe clienții lor. Anticipăm că aveți o anumită familiaritate cu depanarea în general, citirea jurnalelor și lucrul cu cazurile abonaților.

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

  • Resurse, care este o listă de instrumente, materiale de citire, jurnale și persoane de contact de care este posibil să aveți nevoie.
  • Procese, care descrie unele dintre acțiunile pe care le puteți face în timp ce depanați o problemă de client.
  • Probleme specifice, care clasifică și listează problemele despre care s-a știut că apar, să le identificați și le-ați putea rezolva.

Modificare istoric

Dată

Versiune

Modifică

Iunie 08, 2021

1.7

S-a adăugat coloana Acțiune sugerată la tabelul Coduri de eroare utilizator final

Iunie 04, 2021

1.6

Corectarea la tabelul Coduri de eroare utilizator final

Mai 19, 2021

1.5

Secțiunea Probleme de revendicare domeniu adăugate

Aprilie 22, 2021

1.4

Coduri de eroare actualizate ale utilizatorului final cu două coduri suplimentare: 200016 și 200054

Aprilie 13, 2021

1.3

Adăugat informații despre Webex Serviceability Connectior

Decembrie 08, 2020

1.2

Document actualizat. Rebranding Webex Teams în Webex (aplicație).

Coduri de eroare utilizator final adăugate

Noiembrie 03, 2020

1.1

Vizualizare Web Setări apel adăugat

Octombrie 22, 2020

1.0

Document nou introdus

Inscripționare
18 iun. 2021| vizualizare(ări) | persoane au considerat că este util

Resurse

Resurse de depanare Webex pentru BroadWorks

Contacte


Începând din octombrie 2020, migrăm asistența pentru clienți BroadSoft către procesele și instrumentele de asistență Cisco CX. Aceasta înseamnă că partenerii Webex pentru BroadWorks trebuie să treacă de la utilizarea Xchange pentru gestionarea cazurilor la utilizarea Support Case Manager (SCM).

Ne așteptăm ca migrația să se desfășoare timp de aproximativ 3 luni și până la sfârșitul anului calendaristic 2020. Echipa BroadWorks/UCaaS TAC va începe să susțină cazuri în CSOne / Lightning în loc de BroadSoft Jira atunci când sunteți migrat. Poate fi necesar să consultați cazurile din ambele sisteme în timpul perioadei de migrare.

Consultați Tranziția de asistență BroadSoft moștenită pentru detalii.

Fișiere jurnal utile

Nume jurnal Sursă Util pentru depanare
PSLog Server aplicație Provizionare prin flux
tomcat access_log XSP Conectarea aplicației Webex
XsiActionsLog XSP Interacțiunile de conectare a aplicațiilor Webex cu Proxy-ul Webex IDP, interacțiunile cu clienții pentru interogarea profilurilor de dispozitiv
jurnal de servicii de autentificare XSP Conectarea aplicației Webex (validarea și emiterea token-urilor)
XSLog XSP?

Abonamente mobile pentru notificări push

Semnalizarea apelurilor

Jurnal de pornire a aplicației Webex

Windows: \Users\{username}\AppData\Local\CiscoSpark\current_log.txt

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/current_log

Mobil: Utilizare jurnale trimitere

Pornire (secvență)

Verificări ale drepturilor pentru utilizator

Inițializarea bibliotecii BWC pentru conectarea la BroadWorks

getUserProfile &JwT token fetch logare

BroadWorks apelează jurnalul de aplicații Webex

Client

Windows: \Users\{username}\AppData\Local\CiscoSpark\bwc\current_log.txt

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/bwc/current_log

Mobil: Utilizare jurnale trimitere

Tot traficul SIP pentru înregistrare și apeluri

Păstrați în viață de trafic pentru a BWKS Backend

Caracteristici de apel medii care necesită semnalizare (Hold/Resume, Transfer etc.)

Jurnal media (Webex Media Engine)

Client

Windows:

\Users\{username}\AppData\Local\CiscoSpark\media\*.log

Mac:

/Users/{username}/Library/Logs/SparkMacDesktop/media/

Mobil: Utilizare jurnale trimitere

Toate media de logare

Codec-uri negociate pentru un apel

Caracteristici mid call

Listă de lectură

Conector Serviceability

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

Pentru detalii despre implementarea conectorului de service, accesați Ghidul de implementare pentru Cisco Webex Serviceability Connector lahttps://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/spark/hybridservices/serviceability/cmgt_b_deployment-guide-spark-hybrid-service-connector.html.

Inscripționare
18 iun. 2021| vizualizare(ări) | persoane au considerat că este util

Procese

Webex pentru procesele de depanare BroadWorks

Escaladarea unei probleme

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

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 (consultați secțiunea Contacte)

Ce informații despre client să colecteze

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: Adresă de e-mail CI sau UUID utilizator (acesta este identificatorul Webex, dar dacă obțineți și identificatorul BroadWorks al utilizatorului, acest lucru vă va ajuta)

  • Identificator organizație

  • Intervalul de timp aproximativ în care a fost experimentată problema

  • Platforma și versiunea clientului

  • Trimiterea sau colectarea jurnalelor de la client

  • Înregistrați ID-ul de urmărire dacă este afișat pe client

Verificarea detaliilor utilizatorului în Biroul de asistență

1

Conectați-vă la https://admin.webex.com/helpdesk.

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 la apelare, 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.

Vizualizare organizație client în Biroul de asistență

1

Conectați-vă la https://admin.webex.com/helpdesk.

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 clienți și faceți clic pe Vizualizare Nume Client pentru a vedea o vizualizare doar în citire a org-ului Client , inclusiv utilizatorii și configurația.

Regăsire jurnale utilizator din Hub partener

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

1

Solicitați utilizatorului să trimită jurnale.

2

Solicitați utilizatorului să exporte mediul de apelare pentru a vă trimite fișierul ced.dat.

3

Obțineți jurnalele clienților de la Hubul partener sau de la Biroul de asistență (a se vedea mai jos).

Opțiunea Hub partener:

  1. Conectați-vă la Hubul de parteneri și găsiți Organizația clienților utilizatorului.

  2. Selectați Depanare.

  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 Biroul de asistență.

  2. Căutați organizația.

  3. Faceți clic pe organizație (deschide ecranul rezumat).

  4. Defilaț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.

se găsește versiunea clientului

1

Partajați acest link cu utilizatorul: https://help.webex.com/njpf8r5.

2

Solicitați utilizatorului să vă trimită numărul versiunii.

Serviciu de verificare client pentru apelare

1

Conectați-vă la clientul Webex.

2

Verificați dacă pictograma Opțiuni de apelare (un telefon cu un echipament deasupra acestuia) 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 BroadWorks.)

Această verificare înseamnă:

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

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

  • 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.

  • Cereți utilizatorilor de clienți mobili să trimită jurnale, apoi le puteți obține prin hub-ul partener sau biroul 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 de mediu 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.

1

În client, faceți clic pe imaginea de profil, apoi faceți clic pe Ajutor > Export date mediu apelare.

2

Salvați cedarea fișierului rezultat.dat pentru depanarea problemelor de apelare pentru acest utilizator.

Important: Deconectează sau repornește clientul șterge memoria cache internă. Dacă exportați ced.dat după aceea, datele exportate nu vor corespunde cu niciun jurnal care a fost trimis înainte de memoria cache.

Reinițializare bază de date Webex

1

Pe client faceți clic pe Ajutor > Verificator de sănătate.

2

Selectați Reinițializare bază de date.

Acest lucru 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ă să vă înregistrați la BroadWorks:

  • Dreptul utilizatorului la conectorul broadworks

  • Apelarea comportamentului pentru organizație și utilizator

Verificați comportamentul de apelare al unui utilizator și dreptul la conector

  1. Conectați-vă la Help Desk (https://admin.webex.com/helpdesk) cu acreditările de administrator partenere.

  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. Defilați în jos pentru a localiza entitlements secțiune și verificați dacă broadworks-connector este inclusă.


    Un utilizator Webex pentru BroadWorks NU trebuie să aibă bc-sp-standard în cazul în care intenționează să utilizeze Webex pentru BroadWorks. Acesta este dreptul pentru "Webex Calling (Broadcloud)", care este aplicația Webex care apelează 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 (https://admin.webex.com/helpdesk) cu acreditările de administrator partenere.

  2. Căutați organizația.

  3. Faceți clic pe organizație și verificați intrarea Comportament apelare. Ar trebui să fie "Apelarea în Webex".

Analizați PSLog pentru problemele de asigurare a accesului 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.

1

Primul lucru de verificat este 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 despre profilul abonatului nu funcționează în serviciile Webex din amonte de podul de aprovizionare.

  • 400 poate conține o message nod în răspuns. Puntea de provizionare 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 subscriberProfile și datele Webex existente. Este posibil să existe un utilizator existent cu acea adresă de e-mail. Verificați message în răspuns.

2

De asemenea, puteți verifica postarea HTTP originală pentru orice valori suspecte care ar putea provoca eșecul provizionării.

POST conține o subscriberProfile Structură XML. În interiorul acesteia, noduri utile pentru a verifica sunt:

  • bwuserid: Utilizați acest lucru pentru a găsi profilul de abonat dacă trebuie să îl editați în BroadWorks.

  • group: Dacă șablonul este în "Modul furnizor de servicii", acesta este coborât și devine numele org-ului Client pe care îl vedeți în Hubul partener.

  • serviceProvider: Dacă șablonul este în "Modul întreprindere", acesta este coborât și devine numele org-ului Client pe care îl vedeți în Hubul partener.

  • primaryPhoneNumber: Trebuie să existe. Provizionarea eșuează fără ea.

  • email: Devine ID-ul de utilizator în Webex. Trebuie să fie valid și unic pentru Webex, altfel asigurarea accesului nu reușește.


 

Ignorați services strofă: este creat de AS și acceptat, dar nu 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 î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ă scară afișează interacțiunea dintre utilizator, client, servicii Webex și sistemul BroadWorks, atunci când utilizatorul face autentificare BroadWorks în aplicația Webex. De asemenea, conexiunea dintre Webex și XSP este asigurată de 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ă.

Figura 1. Autentificare BroadWorks și configurare dispozitiv

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 access_log tomcat:

  • 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 la Webex conține un XML Profile bloc care conține (BroadWorks) userId și alte detalii (2.2 în diagramă).

Interacțiuni cu serviciile client și Webex:

  • Proxy-ul IDP se potrivește profilului 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 simbol 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 utilizează simbolul CI pentru a solicita un simbol Web JSON (JWT) de la proxy IDP (5 în diagramă)

  • Proxy-ul IDP validează simbolul CI la CI

  • Proxy IDP solicită JWT de la serviciul de autentificare

În jurnalul de autentificareService:

  • Căutați solicitarea de simbol de la Webex (5,2 în diagramă), de exemplu:

    GET /authService/token

    care a http_bw_userid antet și altele.

  • XSP face OCI-P UserGetLoginInfoRequest, pentru a valida faptul că 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ă) din LongLivedTokenManager - Token generated, subject: bwksUserId@example.com, issuer: BroadWorks …

    și StatusCode=200 pe care le puteți asocia cu solicitarea inițială utilizând trackingid: CLIENT… Antet.

În XsiActionsLog:

  • Clientul este acum capabil să prezinte token-ul de lungă durată la interfața Xsi-Actions pentru a obține profilul dispozitivului (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 POSTs token-ul la authservice (configurat pentru a fi 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 trackingid: CLIENT… antetul din GET și X-BROADSOFT-CORRELATION-ID : CLIENT… antetul din POST.

În jurnalul de autentificareService:

  • Primirea postului de la Xsi (loopback)

  • A StatusCode=200 înapoi la Xsi

  • Și un răspuns de validare token, având o "token" Blocul JSON din corp.

  • Corelată utilizând trackingid: CLIENT…

În XsiActionsLog:

  • După ce a primit 200 OK de la authservice, care a validat simbolul clientului, aplicația Xsi-Actions trimite acum o solicitare OCI-P pentru UserPrimaryAndSCADeviceGetListRequest

  • Primește OCI-P UserPrimaryAndSCADeviceGetListResponse care conține accessDeviceTable Structură XML.

  • Răspunsul OCI-P este codificat ca răspuns Xsi la client, inclusiv AccessDevices structura XML, 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ă)

  • Registre la BroadWorks prin SBC preluate în configurație de la DMS (7 în diagramă)

Inscripționare
18 iun. 2021| vizualizare(ări) | persoane au considerat că este util

Probleme specifice

Webex pentru probleme specifice de depanare BroadWorks

Probleme cu hubul partenerilor

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 clienților, trebuie să vă acordați dumneavoastră (sau altor persoane) rolul de Administrator Complet vânzări sau Rolul de Administrator vânzări. A se vedea https://help.webex.com/fs78p5.

Probleme de asigurare a accesului pentru utilizatori

Erori integrate de IM&P pentru anumite întreprinderi / clienți

Dacă aveți un mix de întreprinderi care utilizează diferite servicii de colaborare în cloud, de exemplu UC-One SaaS și Webex pentru BroadWorks, este posibil să fi optat pentru modificarea adaptorului de asigurare a accesului pentru fiecare î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ă), executați AS_CLI/Interface/Messaging> get. Pentru parametrii de asigurare a accesului pentru o anumită întreprindere, deschideți întreprinderea și mergeți la Servicii > IM&P integrat.

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:

Setare IM&P integrată BroadWorks Enterprise

Setare șablon client hub partener

URL server de mesagerie

URL de asigurare a accesului

Nume utilizator server mesagerie

Nume cont asigurare acces

Parolă server mesagerie

Parolă cont de asigurare a accesului, Confirmare parolă

Erori IM&P integrate pentru anumiți utilizatori

Acest lucru se aplică dacă utilizați asigurarea accesului prin flux și presupune că asigurarea accesului funcționează pentru unii/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 asigurare a accesului 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 lor de e-mail este deja acolo. Acest lucru nu este neapărat concludent, deoarece utilizatorul poate exista într-o organizație ale cărei date nu vi se permite să le vedeți în Help Desk.

  • 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ă contul gratuit, astfel încât să poată 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 BroadWorks trebuie să aibă un DID principal). A se vedea subiectul privind analiza PSLog de la AS.

Erori de asigurare a accesului pentru utilizatori ca răspuns de la Puntea de asigurare a accesului

Dacă utilizatorii nu apar în Control Hub, în câteva minute de la atribuirea IM&P integrat, aruncați o privire la codurile de răspuns din serviciul punte de asigurare a accesului. 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 este furnizat 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 la 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 clientului după un răspuns OK 200, ar putea indica faptul că crearea utilizatorului nu a reușit în serviciile Webex în 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 <message> nod:

  • "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.

  • "Client org nu se găsește în baza de date și, de asemenea, noi org crearea de pavilion 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 provizionare nu are nicio șansă de reușită. 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 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.

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.

Utilizatori Conectați-vă probleme

Portalul de activare a utilizatorului nu se încarcă

Fluxul normal de conectare Webex for BroadWorks include un portal de activare a utilizatorului unde utilizatorii își introduc parolele. Uneori, acest portal nu se încarcă după ce utilizatorul și-a furnizat 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.

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 dispozitiv din secțiunea Pregătiți mediul din Ghidul de soluții).

  • Verificați dacă utilizatorul utilizează parola corectă: Dacă șablonul pe care l-ați utilizat pentru a furniza organizația de clienți a utilizatorului (în Hubul partener) este configurat pentru autentificarea BroadWorks, utilizatorul ar trebui să introducă parola broadworks "Web Access".

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, apoi 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 se vede din aplicația Webex):

Secvență de înregistrare așteptată

  1. Clientul apelează XSI pentru a obține un simbol de gestionare a dispozitivului și adresa URL către DMS

  2. Clientul solicită profilul dispozitivului său de la DMS prin prezentarea simbolului de la pasul 1

  3. Clientul citește profilul dispozitivului și regăsește acreditările, adresele și porturile SIP

  4. Clientul trimite un REGISTRU SIP la SBC folosind informațiile de la pasul 3

  5. SBC trimite SIP REGISTER la AS (SBC poate efectua o căutare în NS pentru a localiza un AS dacă SBC nu cunoaște deja utilizatorul SIP.)

Semne așteptate ale înregistrării cu succes a clienților

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

În fila Servicii telefonice pentru aplicații 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).

Clientul nu are pictogramă apelare

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

Clientul afișează fila Servicii telefonice, dar fără sesiune SSO

Aceasta este o înregistrare nereușită. Există mai multe motive pentru care un client de aplicație Webex nu ar reuși înregistrarea cu BroadWorks:

Servicii de apelare multiplă testate cu aceiași clienți

Această problemă cunoscută poate fi cauzată de schimbarea clientului între diferite apeluri înapoi se termină. Este cel mai probabil să apară în timpul încercărilor diferitelor servicii de apelare oferite prin (aceiași) clienți ai aplicației Webex. Aveți posibilitatea să reinițializați baza de date client (link) pentru a remedia această problemă.

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 XSP-urile BroadWorks). 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 de client Webex în XSP-uri (puteți obține certificatul din Partner Hub, pe pagina Setări BroadWorks)

Configurarea greșită a etichetelor BroadWorks

Verificați dacă ați configurat etichetele BroadWorks necesare pentru aplicația Webex (consultați secțiunea BroadWorks necesare pentru Webex în Ghidul de soluții) și dacă 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.

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, apoi se conectează la aplicația webex pe un alt computer Windows, există doar o sesiune SSO activă pe unul 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 webex pentru BroadWorks.

Dispozitiv desktop neaprovizionat pentru utilizator

Această semnătură este văzută în jurnalul clientului (\bwc\) :

<Error> [0x70000476b000] BroadWorksConfigDownloader.cpp:106 onAccessDeviceListSucceeded:BWC:SCF: ConfigDownload - the device profile 'Business Communicator - PC' is not found.

Probleme de vizualizare Web a setărilor apelurilor

Butonul de auto-îngrijire / 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 etichetele CSW sunt setate corect. (Consultați Secțiunea Webview Setări apel din Ghidul de soluții Webex for BroadWorks).

  • Verificați dacă aplicația Webex este înregistrată pentru apelare în BroadWorks.

  • Verificați dacă aplicația Webex este o versiune recentă care acceptă CSWV.

Pagină necompletată sau eroare după ce faceți clic pe butonul/linkul de auto-îngrijire

Î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 jurnalele CSWV, jurnalele de acces, depozitul de configurare.xml și fișierul șablon, apoi ridicați un caz.

Probleme de revendicare domeniu

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 de clienți 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 distribuite 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 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 Gestionare domenii Webex.

Coduri de eroare utilizator final

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


Aceasta nu este o listă exhaustivă de coduri de eroare. Tabelul listează numai codurile de eroare existente pentru care aplicația Webex nu oferă în prezent o direcție clară utilizatorului.
Tabelul 1. Coduri de eroare utilizator final

Cod de eroare

Mesaj de Eroare

Acțiune sugerată

200010

Validarea acreditărilor nu a reușit ca utilizator BroadWorks neautorizat

Utilizatorul ar trebui să încerce o combinație diferită de nume de utilizator și parolă.

În caz contrar, administratorul trebuie să reinițializeze parola în BroadWorks.

200016

Validarea acreditărilor ca sesiune nu s-a găsit

Utilizatorul trebuie să reîmprospăteze browserul și să reîncerce numele de utilizator/parola.

200018

Validarea acreditărilor nereușite ca utilizator este blocată

Utilizatorul ar trebui să aștepte 10 minute, apoi să încerce din nou.

200019

Validarea acreditărilor nereușite ca utilizator adăugare nu a reușit pentru activarea de sine

Admin ar trebui să verifice setările de auto-activare în Control Hub

200022

Trimiterea e-mailului ca utilizator nu a fost neautentificată

Utilizatorul ar trebui să reîncerce onboarding și introducerea acreditărilor.

200026

Validarea e-mailului nu a reușit din cauza erorii de verificare prealabilă sau a stării incorecte a utilizatorului în așteptare pentru PartnerOrgUUID : {partnerOrgUUID} , BroadoworksUUID : {broadworksUUID} , ConfigSetUUID : {configSetUUID}

Admin ar trebui să informeze utilizatorul că au introdus adresa de e-mail greșită, deoarece adresa de e-mail este asociată cu o altă organizație.

200039

Validarea e-mailului nereușit ca id-ul de e-mail deja utilizat într-o altă orgă

Utilizatorul ar trebui să încerce din nou onboarding la același link de verificare, dar folosind un ID de utilizator BroadWorks diferit.

În caz contrar, administratorul organizației client din org diferite ar trebui să șteargă contul de utilizator existent.

200040

Validarea e-mailului nereușit ca configSet nu se potrivește cu configSet în customerConfig

Admin ar trebui să compare linkul de verificare pe care utilizatorul l-a utilizat cu linkul configurat în Control Hub. Cele două linkuri și configSets trebuie să se potrivească.

200041

Validarea nereușită a e-mailului ca utilizator are deja dreptul la un alt serviciu în conflict, drepturi contradictorii

Utilizatorul ar trebui să încerce din nou onboarding la același link de verificare utilizând un ID de utilizator BroadWorks diferit.

În caz contrar, administratorul org client care gestionează serviciul în conflict ar trebui să șteargă serviciul în conflict sau drepturile.

200042

Validarea nereușită a e-mailului ca e-mail este deja asociată cu un alt Id utilizator BroadWorks

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

În caz contrar, administratorul trebuie să șteargă celălalt utilizator care utilizează această adresă de e-mail.

200043

Validarea e-mailului nereușit ca mapare de configurare client utilizator este incorectă

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

În caz contrar, administratorul trebuie să șteargă celălalt utilizator care utilizează această adresă de e-mail.

200044

Validarea e-mailului nereușit ca IDutilizare utilizator este deja utilizată în acest cluster BroadWorks

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

În caz contrar, administratorul organizației client care gestionează contul de utilizator existent care utilizează această adresă de e-mail trebuie să șteargă acel cont de utilizator.

200045

Adăugarea nereușită a utilizatorului prin activarea de sine ca utilizator face deja parte dintr-o altă orgă

Utilizatorul ar trebui să reîncerce la bord, dar cu o altă adresă de e-mail.

În caz contrar, administratorul organizației client care administrează org diferite ar trebui să șteargă contul existent.

200046

Adăugarea nereușită a utilizatorului prin auto-activare, deoarece există mai mulți utilizatori în așteptare cu aceleași broadworksUserId sub același cluster BroadWorks

Administratorul ar trebui să șteargă utilizatorii în așteptare din Control Hub

200047

Adăugarea nereușită a utilizatorului prin activarea de sine ca IDutilizare utilizator este deja utilizată în acest cluster BroadWorks

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

În caz contrar, administratorul organizației client care gestionează contul de utilizator existent ar trebui să șteargă acel cont de utilizator existent sau să elimine alte drepturi.

200048

Adăugarea nereușită a utilizatorului prin activarea de sine ca adresă de e-mail a fost deja furnizată cu un alt ID de utilizare BroadWorks

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

200049

Adăugarea nereușită a utilizatorului prin activarea de sine ca IDutilizare utilizator este deja utilizată în acest cluster BroadWorks

Utilizatorul ar trebui să încerce din nou cu altă adresă de e-mail.

În caz contrar, administratorul organizației client care gestionează contul de utilizator existent ar trebui să șteargă acel cont de utilizator existent sau să elimine alte drepturi..

200050

Adăugarea nereușită a utilizatorului prin activarea de sine ca PROVISIONINGID nu se potrivește cu ID-ul de furnizare așteptat al întreprinderii abonatului

Administratorul ar trebui să compare linkul de verificare pe care utilizatorul l-a utilizat cu linkul configurat în Control Hub.

Cele două linkuri și configSets trebuie să se potrivească.

200051

Adăugarea nereușită a utilizatorului prin activarea de sine ca spEnterpriseId specificat în această solicitare intră în conflict cu un furnizor de servicii sau cu o întreprindere deja furnizată din acest cluster BroadWorks

Administratorul ar trebui să verifice orgiile existente în Control Hub și să se asigure că nu creează o orgă cu un nume care există deja.

200054

Validarea e-mailului nereușit ca regiune a nepotrivirii org-ului clientului și a org-ului partenerului

Administratorul ar trebui să verifice setările org și org pentru clienți partenere din Control Hub și să se asigure că regiunile se potrivesc.

A fost acest articol util?

Articole conexe

Vizualizate recent

×