Děkujeme za vaši zpětnou vazbu.

Tento článek je určen týmu technické podpory v organizaci poskytovatele služeb, který podporuje sebe a své zákazníky. Měli by být obeznámeni s obecným řešením problémů, čtením protokolů a prací s případy předplatitelů.

Tento článek je rozdělen do tří hlavních sekcí:

• Zdroje — obsahuje seznam nástrojů, materiálů pro čtení, protokolů a kontaktů, které můžete potřebovat.
• Procesy — popisuje některé akce, které můžete provést při řešení problému zákazníka.
• Specifické problémy — kategorizuje a uvádí seznam problémů, o kterých bylo známo, že se vyskytly, jak je odhalit a jak je můžete potenciálně vyřešit.

Užitečné soubory protokolu

Seznam čtení

• Portál znalostí partnerů Webex pro Cisco BroadWorks
• Průvodce konfigurací platformy XSP (R23)
• Průvodce správou softwaru BroadWorks (R23)
• Průvodce konfigurací správy zařízení Cisco BroadWorks (R23)
• Příručka správy rozhraní příkazového řádku Broadworks Xsp
• Popis funkce ověřovacího tokenu s dlouhou životností Verze 23.0
• Průvodce integrací SAML Authentication, R23
• Průvodce možnostmi podpory Cisco BroadWorks SSL
• Popis funkce podpory Cisco CI
• Notification Push Server (popis funkce)
• Podpora oznámení Push pro volání Popis funkce Vydání 22.0
• Připojení (Android) Migrace na Firebase Metoda postupu
• Cisco BroadWorks Ukládání tokenů zařízení pro oznámení push Popis funkce Vydání 22.0
• Plánovač kapacity systému Cisco Broadworks (tabulka)
• Průvodce dimenzováním platformy Cisco BroadWorks
• Průvodce systémovým inženýrstvím Cisco Broadworks
• Dokument o požadavcích na podporu ověřování CI verze 1.0 MR-7136

Známé problémy a omezení

Článek Známé problémy a omezení obsahuje aktuální informace o známých problémech, které jsme identifikovali v řešení Webex pro BroadWorks.

Konektor použitelnosti

Služba Webex Servicability zvyšuje rychlost, s jakou mohou pracovníci technické pomoci společnosti Cisco diagnostikovat problémy s infrastrukturou. Automatizuje úkoly vyhledávání, načítání a ukládání diagnostických protokolů a informací do případu SR. Služba také spouští analýzu podle diagnostických podpisů, aby TAC mohl efektivněji identifikovat a řešit problémy s místním zařízením.

Podrobnosti o nasazení konektoru Servisability naleznete v části Průvodce nasazením konektoru Cisco Webex Servisability Connec tor.

Eskalace problému

Poté, co budete postupovat podle některých pokynů pro odstraňování problémů, měli byste mít rozumnou představu o tom, kde je problém zakořeněn.

Postup

1. Shromážděte co nejvíce informací ze systémů souvisejících s problémem.
2. Obraťte se na příslušný tým společnosti Cisco a otevřete případ.

Jaké informace o klientech shromažďovat

Pokud si myslíte, že potřebujete otevřít případ nebo eskalovat problém, shromážděte při řešení potíží s uživatelem následující informace:

• Identifikátor uživatele: e-mailová adresa CI nebo UUID uživatele (toto je identifikátor Webex, ale pokud získáte také identifikátor BroadWorks uživatele, uveďte jej do podrobností případu).
• Identifikátor organizace.
• Přibližný časový rámec, během kterého došlo k problému.
• Klientská platforma a verze.
• Odesílejte nebo sbírejte protokoly od klienta.
• Zaznamenejte ID sledování, pokud je zobrazeno na klientovi.

Kontrola uživatelských údajů v Help Desku

Správci partnerů, kteří mají oprávnění k roli Help Desk Administrator (Basic nebo Advanced), mohou pomocí tohoto postupu zkontrolovat podrobnosti o uživateli pomocí zobrazení Help Desk.

Postup

1. Přihlaste se do Help Desk.
2. Vyhledejte uživatele a klikněte na něj. Otevře se obrazovka souhrnu uživatelů.
3. Kliknutím na uživatelské jméno zobrazíte podrobnou konfiguraci uživatele. Užitečné informace v tomto zobrazení zahrnují UUID uživatele, cluster společné identity (CI), cluster aplikací Webex, chování volání, GUID účtu BroadWorks
4. Klepněte na tlačítko Kop írovat, pokud potřebujete tyto informace použít v jiném nástroji, nebo je připojte k pouzdru společnosti Cisco.

Zobrazení organizace zákazníků v Help Desku

Správci partnerů, kteří mají oprávnění k roli správce Help Desk (Basic nebo Advanced), mohou pomocí tohoto postupu zobrazit podrobnosti o organizaci zákazníků v zobrazení Help Desk.

Postup

1. Přihlaste se do Help Desk.
2. Vyhledejte název organizace zákazníka a klikněte na něj.
3. Přejděte dolů, dokud se nez obrazí Zobrazení zákaznického portálu, a kliknutím na Zobrazit jméno zákazníka zobrazíte zobrazení organizace zákazníka pouze pro čtení — včetně uživatelů a konfigurace.

Načíst protokoly uživatelů z Partner Hub

Při řešení potíží s klientskými počítači a mobilními klienty je důležité, aby partneři (a TAC) mohli zobrazit protokoly klientů.

Postup

1. Požádejte uživatele o odeslání protokolů. Nápovědu naleznete v tématu: Aplikace Webex | Nahlášení problému.
2. Požádejte uživatele o export volacího prostředí a odešlete soubor ced.dat.
3. Získejte protokoly klientů z Partner Hub nebo Help Desk.

   Možnost Partnerského centra:

   1. Přihlaste se do centra partnerů a vyhledejte organizaci zákazníků uživatele.
   2. Vyberte Od straňování problémů.
   3. Vyberte Proto koly.
   4. Vyhledejte uživatele (e-mailem).
   5. Zobrazte a stáhněte protokoly klienta jako soubor zip.

   Možnost Help Desk:

   1. Přihlaste se do Help Desk.
   2. Vyhledejte organizaci.
   3. Klikněte na organizaci (otevře se souhrnná obrazovka).
   4. Přejděte dolů a klikněte na Zobrazit zákazníka.
   5. Vyberte Od straňování problémů.
   6. Vyberte Proto koly.
   7. Vyhledejte uživatele (e-mailem).
   8. Zobrazte a stáhněte protokoly klienta jako soubor zip.

Jak najít verzi klienta

Postup

1. Sdílejte tento odkaz s uživatelem: https://help.webex.com/njpf8r5
2. Požádejte uživatele, aby vám zaslal číslo verze.

Klientská kontrola pro volací službu

Postup

1. Přihlaste se ke klientovi Webex.
2. Zkontrolujte, zda je na postranním panelu zobrazena ikona Možnosti volání (sluchátko s ozubeným kolem). Pokud ikona není přítomna, nemusí být uživatel ještě povolen pro volající službu v Control Hubu.
3. Otevřete nabídku Nastavení/Předvolby a přejděte do sekce Telefonní služby. Měl by se zobrazit stav relace SSO Jste přihlášeni. (Pokud je zobrazena jiná telefonní službaWebex Calling, například, uživatel nepoužívá Webex pro Cisco BroadWorks.)

   Toto ověření znamená:

   • Klient úspěšně prošel požadovanými mikroslužbami Webex.
   • Uživatel se úspěšně ověřil.
   • Klientovi je váš systém BroadWorks vydán webový token JSON s dlouhou životností.
   • Klient získal svůj profil zařízení a zaregistroval se do BroadWorks.

Získání protokolů klientů nebo zpětné vazby

• V části Zdroje najdete konkrétní protokoly klientů na desktopových klientech Webex nebo požádejte uživatele o odeslání protokolů. Nápovědu naleznete v tématu: Aplikace Webex | Nahlášení problému.
• Požádejte uživatele mobilních klientů, aby posílali protokoly, pak je můžete získat prostřednictvím Partner Hub nebo Help Desk.
  Odesílání protokolů je tiché. Pokud však uživatel odešle zpětnou vazbu, přejde do týmu devops aplikace Webex. Pokud chcete navázat kontakt se společností Cisco, nezapomeňte zaznamenat číslo zpětné vazby uživatele. Například:

  

Získání dat o volacím prostředí

Protokoly klientů Webex jsou silně redigovány, aby se odstranily osobně identifikovatelné informace. Data volacího prostředí byste měli exportovat z klienta ve stejné relaci, kdy si všim nete problému.

Postup

1. Na klientovi klikněte na Ná pově da > Kontrola stavu.
2. Vyberte možnost Ob novit databázi. Tím se spustí úplné resetování klienta a načte přihlašovací obrazovku aplikace Webex.

Ověřte, zda by se Webex měl zaregistrovat do BroadWorks

Aplikace Webex zkontroluje následující informace, aby určila, zda se má zaregistrovat do BroadWorks:

• Nárok uživatele na broad works-connector.
• Chování volání pro organizaci a uživatele.

Kontrola chování uživatele při volání a oprávnění konektoru

1. Přihlaste se k Help Des ku pomocí přihlašovacích údajů správce partnera.
2. Vyhledejte uživatele.
3. Klikněte na uživatele a zaškrtněte položku Chování volání. Mělo by to být „Volání ve Webex“.

   

4. Kliknutím na uživatelské jméno otevřete obrazovku Podrobnosti o uživateli.
5. Přejděte dolů a vyhledejte sekci oprávnění a ověřte, zda je zahrnut konektor broadworks

   

   Uživatel Webex pro Cisco BroadWorks by neměl mít nárok na standard bc-sp, pokud má v úmyslu používat Webex pro Cisco BroadWorks. Toto je nárok na „Webex Calling(Broadcloud)“, což je volání aplikace Webex prostřednictvím služby cloudového volání spravované společností Cisco.

Kontrola chování organizace při volání

1. Přihlaste se k Help Des ku pomocí přihlašovacích údajů správce partnera.
2. Vyhledejte organizaci.
3. Klikněte na organizaci a zaškrtněte položku Chování volání. Mělo by to být „Volání ve Webex“.

Analyzujte PSLog pro problémy se zřizováním uživatelů

Pomocí protokolu PSLog aplikačního serveru zobrazíte požadavek HTTP POST na zřizovací můstek a odpověď od Webex. Ve správném pracovním případě je odpověď 200 OK a po několika minutách můžete vidět uživatele - a nová organizace zákazníka, pokud je prvním uživatelem - byla vytvořena ve Webexu. Můžete to ověřit hledáním e-mailové adresy, kterou vidíte v POST v Help Desku.

Než začnete

Shromážděte PSLog z aplikačního serveru během pokusu o zřizování průtoku s testovacím uživatel em.

Postup

1. Nejprve zkontrolujte kód odpovědi HTTP:
   • Cokoliv jiného než 200 OK je selhání zřizování uživatele.
   • 200 OK může stále znamenat selhání, pokud něco o profilu účastníka nefunguje ve službách Webex před zřizovacím můstkem.
   • 400 může obsahovat uzel zprávy v odpovědi. Zřizovací můstek nemohl zpracovat něco v Subscri ber Profile. Může být něco špatného s podrobnostmi o účastníkovi nebo nekompatibilita s nastavením v šabloně.
   • 401 znamená, že pověření pro zřizování zadaná v AS se neshodují s přihlašovacími údaji zadanými v šabloně v Partner Hub.
   • 403 může naznačovat něco špatně nakonfigurovaného na aplikačním serveru. Zkontrolujte cíl požadavku. neměla by to být adresa IP, měla by to být adresa URL zřizovacího můstku, kterou můžete vidět na své šabloně v Partner Hub.
   • 409 označuje konflikt mezi dodaným Subscri berProfile a existujícími daty Webex. Může existovat existující uživatel s touto e-mailovou adresou. Zkontrolujte zprávu v odpovědi.
2. Můžete také zkontrolovat původní HTTP POST, zda neobsahuje podezřelé hodnoty, které by mohly způsobit selhání zřizování. POST obsahuje strukturu XML Sub scriberProfile. Uvnitř jsou užitečné uzly ke kontrole:
   • bwuserid: Použijte toto k vyhledání profilu odběratele, pokud jej potřebujete upravit v BroadWorks.
   • group: Pokud je šablona v režimu poskytovatele služeb, zobrazí se malá písmena a stane se názvem zákaznické organizace, kterou vidíte v Centru partnerů.
   • ServicePro vider: Pokud je šablona v „Podnikovém režimu“, zobrazí se malá písmena a stane se názvem zákaznické organizace, kterou vidíte v Centru partnerů.
   • PrimaryPhoneNumber: Musí existovat. Bez něj se zřizování nezdaří.
   • e-mail: Stává se ID uživatele ve Webexu. Musí být platný a jedinečný pro Webex, jinak se zřizování nezdaří.

     Ignorujte sloku služeb: je vytvořena společností AS a přijata, ale nepoužívána Webex.

Analyzujte protokoly XSP pro řešení potíží s přihlášením odběratele

Tento postup popisuje režim ověřování BroadWorks. Režim ověřování můžete vidět na šablon ě BroadWorks v partnerském centru. Viz Konfigurace zákaznických šablon na adrese https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Následující diagram žebříčku ukazuje interakci mezi uživatelem, klientem, službami Webex a systémem BroadWorks, když uživatel provádí ověřování BroadWorks v aplikaci Webex. Také spojení mezi Webex a XSP je zabezpečeno MTLS.

Následující diskuse vysvětluje, co můžete očekávat při zkoumání protokolů pro úspěšné přihlášení.

Uživatel komunikuje s klientem, klient komunikuje se službami Webex:

• Uživatel zadá svou e-mailovou adresu do aplikace Webex (1 v diagramu).
• CI ví, že přesměruje tohoto uživatele k zadání hesla BroadWorks (přes UAP) (2 v diagramu).
• Proxy IDP odešle požadavek na získání profilu do rozhraní Xsi na XSP.

V tomcat access_log:

• Vyhledejte požadavek GET pro profil předplatitele, od Webex směrem k rozhraní Xsi-Actions (2.1 v diagramu). Má ID uživatele Webex. Například:

  ZÍSKEJTE /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profil

V XSIActionsLog:

• Vyhledejte profil GET požadavek od Webex (2.1 v diagramu). Má ID uživatele Webex. Například:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Hlavičky zahrnují autorizaci: Basic a user-agent: BroadworkSteamsClient

• XSP pak provede ověřování OCI-P Basic proti BroadWorks (AuthenticationVerifyRequest a AuthenticationVerifyResponse, jako každá jiná aplikace provádějící základní autentizaci přes Xsi) a také UserGetRequest a ServiceProviderGet Request ke shromažďování informací o předplatiteli.
• Odpověď Xsi na Webex obsahuje blok profilu XML obsahující ID uživatele (BroadWorks) a další podrobnosti (2.2 v diagramu).

Interakce se službami klienta a Webex:

• Proxy IDP odpovídá uživatelskému profilu přijatému z BroadWorks a vydává klientovi tvrzení SAML (2.3 v diagramu).
• Klient vymění tvrzení SAML za token CI (3 v diagramu).
• Klient zkontroluje, zda má přihlášený uživatel oprávnění broadworks-connector (4 v diagramu). Uživatelská oprávnění můžete zkontrolovat v Help Desku.
• Klient používá CI token k vyžádání webového tokenu JSON (JWT) z proxy serveru IDP (5 v diagramu).
• Proxy IDP ověřuje CI token na CI.
• Proxy IDP požaduje JWT z ověřovací služby.

V protokolu AuthenticationService:

• Vyhledejte požadavek na token z Webex (5.2 v diagramu), Například: GET /AuthService/token, který má hlavičku http _bw_ userid a další.
• XSP provede OCI-P UserGetLoginInForequest, aby ověřil, že zadané ID uživatele odpovídá uživateli BroadWorks (5.3 v diagramu). AuthService vytvořila důvěru s Webex na základě připojení MTL, takže může vydávat LLT.
• Vyhledejte odpověď (5.4 v diagramu) z LongLivedTokenManager - Token generován, předmět: bwksUserId@example.com, vydavatel: BroadWorks... a statusCode=200, které můžete přiřadit k původnímu požadavku pomocí hlavičky trackingid: CLIENT...

V XSIActionsLog:

• Klient je schopen prezentovat token s dlouhou životností na rozhraní Xsi-Actions, aby získal profil zařízení (6 v diagramu). Například: GET /com.broadsoft.xsi-actions/v2.0/user/bwksuSerid %40example.com/profile/device S autorizací záhlaví: Token nositele a uživatelský agent: WebExTeams (varianta/verze)
• Rozhraní Xsi-Actions pošle token do authservice (nakonfigurováno tak, aby byl na rozhraní zpětné smyčky) Například: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token, který můžete korelovat s hlavičkou trackingid: CLIENT... v GET a hlavičkou X-BROADSOFT-CORRELATION-ID: CLIENT... v POST.

V protokolu AuthenticationService:

• Příjem POST od Xsi (loopback)

• StatusCode=200 zpět na Xsi

• A odpověď na ověření tokenu, která má v těle blok JSON „token“.

• Korelováno pomocí trackingid: CLIENT...

V XSIActionsLog:

• Po obdržení 200 OK od authservice, která ověřila stoken klienta, nyní aplikace Xsi-Actions odešle požadavek OCI-P pro UserPrimaryAndScaDeviceGetListRequest
• Přijme OCI-P UserPrimaryAndS caDeviceGetListResponse obsahující strukturu XML AccessDeviceTable.
• Odpověď OCI-P je kódována jako odpověď Xsi na klienta, včetně struktury AccessDevices XML, která má DeviceTypes. Například: Business Communicator - PC a adresy URL, kde může klient načíst konfigurační soubory zařízení.

Klient pokračuje jako obvykle:

• Vybere položku zařízení a interaguje s DMS pro získání profilu zařízení (6 v diagramu).
• Registry do BroadWorks přes SBC načtené v konfiguraci z DMS (7 v diagramu).

Problémy s partnerským centrem

1. Správce nevidí organizace zákazníků

Jako správce vaší partnerské organizace ve Webexu byste měli mít roli úplného správce. Tato role se používá pro správu partnerské organizace, včetně přiřazování oprávnění správce sobě i ostatním. Chcete-li spravovat organizace zákazníků, musíte sobě (nebo jiným osobám) udělit roli úplného správce prodeje nebo roli Správce prodeje. Podrobnosti naleznete v tématu Přiřaz ení rolí účtů organizace v Řídicím centru.

Problémy s přidělováním uživatelů

1. Integrované chyby IM&P pro konkrétní podniky/zákazníky

Pokud máte kombinaci podniků využívajících různé služby cloudové spolupráce, například UC-One SaaS a Webex pro Cisco BroadWorks, možná jste se rozhodli upravit adaptér zřizování pro jednotlivé podniky.

Chcete-li zkontrolovat, co je nakonfigurováno pro integrované IM&P (výchozí pro podniky, pokud neexistuje konkrétnější nastavení), spusťte příkaz as _CLI/Interface/Messaging> get. Pro parametry zřizování konkrétního podniku otevřete podnik a přejděte do nabídky Služby > Integrované IM &P.

Zkontrolujte, zda konfigurace integrované IM&P pro daný podnik přesně odpovídá tomu, co je zobrazeno v šabloně zákazníka v centru partnerů. Následující nastavení se musí shodovat, jinak se zřizování nezdaří pro všechny uživatele v podniku:

2. Integrované chyby IM&P pro konkrétní uživatele

To platí, pokud používáte průběžné zřizování a předpokládá, že zřizování funguje u některého/většiny uživatelů (takže můžete vyloučit problém s konfigurací). Pokud se ve službě BroadWorks zobrazují integrované chyby IM&P, například „[Chyba 18215] Chyba zřizování se serverem pro zasílání zpráv“ a „[Chyba 18211] Chyba komunikace se serverem pro zasílání zpráv“, měli byste prozkoumat následující možné příčiny:

• E-mailová adresa uživatele již mohla existovat CI. Vyhledejte uživatele v Help Desku a zkontrolujte, zda jeho e-mailová adresa již existuje. To nemusí být nutně přesvědčivé, protože uživatel může existovat v organizaci, jejíž data nemáte povoleno vidět v Help Desku.
• Uživatel se nezávisle zaregistroval do Webex před přiřazením služby Integrated IM&P. V tomto případě je jednou z možností, aby uživatel odstranil své bezplatné účty, které se mohou stát součástí organizace zákazníků, kterou zřizujete. Pokyny jsou na https://help.webex.com/5m4i4y
• Uživatel nemá k profilu přiřazené primární telefonní číslo (všichni předplatitelé Webex pro Cisco BroadWorks musí mít primární DID). Viz téma analýzy PSlog z AS.

3. Selhání zřizování uživatelů v reakci na zřizovací můstek

Pokud se uživatelé v Řídicím centru nezobrazují, podívejte se během několika minut od přiřazení integrované zprávy IM&P na kódy odezvy ze služby zřizování můstků. Spusťte PSlog a podívejte se na kódy odpovědí HTTP.

200 OK

Odpověď 200 OK neznamená, že uživatel byl úspěšně zřízený. To znamená, že služba zajišťování obdržela požadavek a úspěšně odeslala odpovídající požadavek na vytvoření uživatele do služeb upstream. Transakce zřizování je podle návrhu asynchronní. Služba odpovídá 200 OK, protože proces vytváření uživatele může trvat několik minut a z důvodů výkonu nechceme přijímat více požadavků na vytvoření stejného uživatele. Pokud se však uživatel nakonec nezobrazí v organizaci zákazníků po odpovědi 200 OK, mohlo by to znamenat, že vytvoření uživatele selhalo ve službách Webex před službou zřizování. Je třeba eskalovat selhání zřizování, které má odpověď 200 OK.

400 Špatný požadavek

Zkontrolujte odpověď HTTP, která by měla obsahovat podrobnější informace o potenciálních problémech, které by mohly způsobit tuto odpověď ze strany zajišťovací služby. Některé příklady uzlu:

• „Nelze důvěřovat e-mailu BroadWorks se starším zřizovacím rozhraním API.“ E-mailová adresa přidružená k chybnému požadavku na zřízení uživatele není platná nebo je zadána nesprávně, ale v šablon ě jste tvrdili, že e-mailové adresy mohou být důvěryhodné. Zkontrolujte profily uživatelů v BroadWorks, konkrétně e-mailové ID.
• Organizace zákazníka není nalezena v databázi a také nový příznak vytvoření organizace není povolen.“ Tento neúspěšný požadavek na zřízení by měl vytvářet novou organizaci zákazníků ve Webexu, ale vaše šablona je nakonfigurována tak, aby bránila vytváření nových organizací zákazníků. Pokud chcete povolit nové organizace pro e-mailové domény, které neodpovídají stávajícím zákazníkům ve Webexu, můžete šablonu znovu nakonfigurovat v centru partnerů a znovu otestovat požadavek na zřízení. Pokud však neočekáváte vytvoření nové organizace pro tohoto uživatele, možná je e-mailová adresa chybně zadána (konkrétně část domény). Zkontrolujte e-mail ové ID uživatele v BroadWorks.

403 Zakázáno

Požadavek na zřízení nemůže být úspěšný, dokud konfiguraci neopravíte. V tomto případě budete muset prošetřit žádost a odpověď. Pokud například vidíte adresu IP jako cíl požadavku na zřízení namísto příslušné adresy URL zřizovacího můstku pro vaši organizaci (viz témata konfigurace brány firewall v Průvodci řešením), může to znamenat, že aplikačnímu serveru chybí požadovaná oprava (ap373197).

Zkontrolujte, zda jsou na aplikačním serveru použity všechny požadované opravy a zda jste dokončili související konfiguraci pro úspěšné zřizování průtoku.

409 Konflikt

Žádost o zřízení nemůže pokračovat, protože ve Webexu existuje existující uživatel, který odpovídá e-mailové adrese v požadavku.

4. Uživatel již v CI

Vyjměte e-mail předplatitele z požadavku HTTP POST a vyhledejte jej v Help Desku. Nem usíte vidět uživatele, pokud vám to není povoleno, ale můžete také vidět, že uživatel je v „svobodné“ organizaci, např. „Spotřebitel“. Můžete požádat tohoto uživatele, aby smazal svůj bezplatný účet, nebo můžete použít jinou e-mailovou adresu k jejich poskytnutí. Viz https://help.webex.com/ndta402.

Problémy s přihlášením uživatele

1. Portál aktivace uživatele se nenačte

Normální tok přihlášení Webex pro Cisco BroadWorks zahrnuje portál aktivace uživatele, kde uživatelé zadávají svá hesla. Někdy se tento portál nenačte poté, co uživatel zadal svou e-mailovou adresu na přihlašovací obrazovce aplikace Webex. Tento problém může být způsoben na straně klienta nebo na straně služby. Na straně klienta je to obvykle způsobeno tím, že nativní prohlížeč klienta je nějakým způsobem nekompatibilní se službou.

2. Jednotné přihlášení se nezdařilo

• V aplikaci BroadWorks zkontrolujte, zda byly uživateli přiřazeny typy zařízení pro aplikaci Webex (viz část Profily zařízení v části Pří prava prostředí v Průvodci řešením).
• Zkontrolujte, zda uživatel používá správné heslo. Pokud je šablona, kterou jste použili k zřízení organizace zákazníků uživatele (v centru partnerů), nakonfigurována pro ověřování BroadWorks, měl by uživatel zadat heslo BroadWorks „Web Access“. Uživatel může také potřebovat zadat své uživatelské ID BroadWorks, pokud jeho e-mailová adresa není nakonfigurována jako alternativní ID uživatele. Ujistěte se, že uživatel správně zadal velká a malá písmena.

Problémy s konfigurací volání a registrací

Po zřízení uživatele ve Webexu a úspěšném přihlášení k aplikaci Webex se aplikace zaregistruje do služby BroadWorks. Následuje očekávaná sekvence registrace a výsledné známky zdravé registrace (jak je vidět z aplikace Webex):

1. Očekávaná registrační sekvence

1. Klient zavolá XSI, aby získal token správy zařízení a adresu URL k DMS.
2. Klient požaduje profil svého zařízení z DMS předložením tokenu z kroku 1.
3. Klient přečte profil zařízení a načte pověření SIP, adresy a porty.
4. Klient odešle SIP REGISTER do SBC pomocí informací z kroku 3.
5. SBC odešle SIP REGISTER do AS (SBC může provést vyhledávání v NS a vyhledat AS, pokud SBC ještě nezná uživatele SIP.).

2. Očekávané známky úspěšné registrace klienta

V rozhraní Webex se zobrazí ikona Volby volání.

Na kartě Telefonní služby aplikace Webex (např. Nastavení > Telefonní služby v systému Windows, Před volby > Telefonní služby na Macu) zpráva „Session SSO: Jste přihlášeni“ znamená, že aplikace byla úspěšně zaregistrována (v tomto případě na BroadWorks).

3. Klient nemá ikonu Volání

Většinou to znamená, že uživatel nemá správnou licenci /oprávnění.

Jedná se o neúspěšnou registraci. Existuje několik důvodů, proč by klient aplikace Webex neuspěl při registraci u BroadWorks:

4. Testování více volacích služeb se stejnými klienty

Tento známý problém může být způsoben změnou klienta mezi různými zpětnými koncovkami. S největší pravděpodobností k tomu dojde během zkušebních verzí různých volacích služeb nabízených prostřednictvím (stejných) klientů aplikace Webex. Chcete-li tento problém vyřešit, můžete resetovat databázi klientů (odkaz).

5. Nesprávná konfigurace ověřovací služby

Zkontrolujte XSP hostující ověřovací službu podle Průvodce řešením (viz Konfigurace služeb na vašem Webex pro Cisco BroadWorks XSP). Konkrétně:

• Klíče RSA (které generujete na jednom XSP) jsou zkopírovány do všech XSP
• Adresa URL ověřovací služby byla zadána webovému kontejneru na všech XSP a zadána správně do clusteru v Partner Hub
• Externí ověřování certifikáty je nakonfigurováno:

  xsp_CLI/System/CommunicationUtility/Výchozí nastavení/ExternalAuthentication/CertificateAuthentication>GET

  allowUserApp = false

  allowClientApp = true

• Pokud používáte MTLS, musíte nahrát klientský certifikát Webex do XSP (certifikát můžete získat z centra partnerů na stránce Nastavení BroadWorks).

6. Nesprávná konfigurace značek BroadWorks

Zkontrolujte, zda jste nakonfigurovali požadované značky BroadWorks pro aplikaci Webex. Informace o konfiguračních značkách naleznete v Průvodci konfigurací Webex pro Cisco BroadWorks. Ujistěte se, že neexistují žádné konflikty nebo nesprávné hodnoty. Konkrétně by značka %SBC_ADDRESS_WXT% měla být SBC směrem k vašemu registrátorovi SIP pro klienty aplikace Webex.

7. Desktopový klient odpojí telefonní služby po úspěšném připojení SSO

Tento problém může být způsoben tím, že se stejný uživatel přihlásí k více klientům na stejném typu platformy. Pokud se například uživatel úspěšně přihlásí k aplikaci Webex v systému Windows a poté se přihlásí k aplikaci Webex na jiném počítači se systémem Windows, je na jednom z počítačů aktivní pouze relace SSO. To je podle návrhu. Pokud tento problém absolutně potřebujete vyřešit, můžete nakonfigurovat BroadWorks tak, aby měl více instancí stejného typu zařízení, ale musí mít jedinečné adresy SIP. Tato konfigurace je mimo rozsah Webex pro Cisco BroadWorks.

8. Stolní zařízení není zřízeno uživateli

Tento podpis je vidět v protokolu klienta:

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

onAccessDeviceListSucceded:bwc:scf: configDownload - profil zařízení 'Business Communicator - PC' nebyl nalezen.

9. Příchozí mobilní hovory zazvoní jednou nebo na ně nelze odpovědět

Příchozí hovory do mobilního telefonu Webex vyzvánějí pouze jednou nebo uživatel nemůže přijmout příchozí hovor. Ostatní koncové body pro stejného uživatele mohou nadále vyzvánět.

Jak identifikovat?

V protokolech mobilních klientů Webex vyhledejte kód chyby XSI 101002 v toku push volání. Například:

Kód odpovědi: 400

<callID>handlePushCallInfoFailure:bwc:Internal: Push call: stav xsi pro callID: xsi kód chyby: 101002

<callID>ClosePushCallWithReason:bwc:Internal: Zkuste zavřít push hovor s id =, reason = callAbandoned

Příčina: Kód chyby 101002 může znamenat, že v odpovědi Loc ateUser je vrácen nesprávný aplikační server (AS). K tomu může dojít, když uživatel migroval na sekundární AS.

Doporučené kontroly:

Z ADP nebo XSP, kde je nasazen Push, spusťte LocateUser pro postiženého uživatele:

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

Příklad: curl 'http://1.1.1.1:80/servlet/LocateUser? url= 9721112222@gmail.com &returnCompatibleXSP=true&callpRequest=pravda'

Řešení: Pokud LocateUser vrátí sekundární AS pro uživatele, spusťte skript MigrateUserToDefaultNode.pl na primárním serveru NS a migrujte uživatele zpět na primární aplikační server clusteru.

Přihlaste se k serveru NS přes SSH, přejděte do adresáře /usr/local/broadworks/bw_base/bin a spusťte: migrateusertodefaultnode.pl <hostingNE>

Příklad: Migrate UserToDefaultNode.pl bwas1

Chcete-li získat hodnotu HostingNE, spusťte: NS_CLI/System/Device/Hostingne> get

Skript nejprve zkontroluje, zda může najít hostingové NE, které uvedete jako argument. Poté, co ověří, že hostingový NE je platný, aktualizuje DN, příponu a adresu URL na výchozí uzel pro daný hostingový NE.

Pokud je to možné, spusťte skript během období s nízkým provozem. Je však obecně přijatelné spustit skript kdykoli, pokud je to nutné k obnovení služby pro postižené uživatele.

Skript nelze spustit pouze pro jednoho uživatele. Miguje všechny uživatele uvedené ve výstupu LocateUser. Pokud skript nemůžete spustit, odstraňte a znovu vytvořte postiženého uživatele v BroadWorks tak, aby byl uživatel znovu vytvořen na správném AS.

Jakákoli zpráva SIP z uživatelského zařízení do sekundárního AS může způsobit migraci uživatele. Uživatelé se obvykle vracejí zpět do primárního AS po výchozím 15minutovém intervalu, pokud příchozí požadavky nadále nedostanou do sekundárního AS. Pokud se například SBC nemůže připojit k AS1 a opakuje se k sekundárnímu AS, mohou postižení uživatelé přejít na sekundární AS. V závislosti na nasazení může jedna kmenová skupina nebo uživatel zůstat připnutý k sekundárnímu AS, pokud má SBC i nadále problémy s dosažením primárního AS.

Další informace naleznete v následujících dokumentech:

• Oddíly 3.4.5 Schopnost vrácení uživatele aplikačního serveru a 5.4.5 Automatické vrácení zpět v příručce Cisco BroadWorks Redundancy Guide

• Popis funkce vylepšení Cisco BroadWorks ASR

9. Telefonní služby odpojeny

Pokud se telefonní služby zobrazí jako odpojené po přihlášení uživatele k aplikaci Webex nebo pokud se telefonní služby odpojí, když uživatel používá klienta, zkontrolujte typ klienta a postup registrace.

Pro klienty Windows a Mac se aplikace Webex zaregistruje pro SIP a udržuje aktivní registraci SIP, zatímco je uživatel přihlášen.

Zkontrolujte následující:

1. Ověřte, zda soubor config-wxt.xml byl úspěšně stažen.

V protokolech klienta vyhledejte ConfigDownload.

Úspěšné stažení ukazuje:

ConfigDownload - úspěšně dokončeno

Pokud protokoly vykazují následující chybu, zkontrolujte v protokolech AuthService chyby související s tokeny:

ConfigDownload - selhal s kódem chyby: 1511

2. Ověřte, zda je nalezen profil zařízení Webex.

V protokolech klienta potvrďte, že bylo nalezeno přístupové zařízení a že hodnota used_value je 1. Pokud hodnota used_value je 0, zkontrolujte, zda je Primární řádek povolen nebo zakázán, a ověřte hodnotu tagu. Další podrobnosti naleznete v části 6.1.44 Primární profil v Průvodci konfigurací Webex pro BroadWorks.

Příklady záznamů protokolu:

:BWC:SCF: configDownload - nalezeno přístupové zařízení

:BWC:SCF: configDownload - přístupové zařízení: DeviceType=Business Communicator - PC, DeviceLevel=group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Vzhled sdíleného hovoru

:BWC:SCF: configDownload - přístupové zařízení: DeviceType=Připojit - Mobilní, DeviceLevel=skupina, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Vzhled sdíleného hovoru

:BWC:SCF: configDownload - přístupové zařízení: DeviceType=Connect - Tablet, DeviceLevel=Group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: Vzhled sdíleného hovoru

3. Zkontrolujte selhání DNS při řešení adresy proxy SIP.

Podrobnosti o zjišťování SIP proxy naleznete v části 6.1.6 Dynamické zjišťování proxy serveru SIP v Prů vodci konfigur ací Webex pro BroadWorks.

Úspěšný objev proxy ukazuje:

Objev proxy dokončen, získalo <number>výsledky

4. Zkontrolujte, zda registrace SIP selhává.

Pokud protokoly zobrazují MRegistration: TCPTimeout nebo Reason: SIP; cause=200; text="last=TCP-timeout“, klient Webex nemůže navázat nízkoúrovňové připojení TCP k SBC. Registrace SIP se nedokončí, když dojde k této chybě. Zkontrolujte, zda je protokol TCP v síti uživatele blokován, nebo zda SBC odmítá připojení TCP.

Pokud je požadavek SIP REGISTER zamítnut nebo neobdrží odpověď, vyhledejte v protokolech REGISTR sip a ověřte, zda je vrácen SIP/2.0 200 OK. Pokud není vrácena, zkontrolujte, zda síť uživatele blokuje SIP nebo zda SBC požadavek odmítá.

V aplikaci BroadWorks Admin přejděte na Uživatel > Nástroje > Registrace a ověřte, zda je pro klienta Webex k dispozici platná registrace SIP.

U mobilních klientů se systémem Android a iOS se aplikace Webex nezaregistruje pro SIP, dokud není uskutečněn nebo přijat hovor. Registrace je odstraněna po dokončení hovoru. Mobilní klienti se registrují pro push oznámení.

U mobilních klientů zkontrolujte následující:

1. Ověřte, zda se soubor config-wxt.xml úspěšně stáhne a zda je nalezen profil zařízení, jak je popsáno pro klienty Windows a Mac.

2. Ověřte, zda je registrace push úspěšná.

V protokolech Webex vyhledejte stav registrace push:

onPushRegistrationStateChanged: :Stav registrace push změněn, state=Neregistrováno

onPushRegistrationStateChanged: :Stav registrace push změněn, state=Registrováno

V aplikaci BroadWorks Admin přejděte na Uživatel> Ná stroje > Registrace oznámení push a ověřte, zda je pro klienta Webex k dispozici platná registrace push.

Problémy s webovým zobrazením nastavení hovorů

1. Tlačítko/odkaz Self Care se nezobrazuje v aplikaci Webex

Jiným příznakem tohoto problému je, když se zobrazí tlačítko/odkaz, ale kliknutím na něj se otevře externí prohlížeč.

• Ověřte, zda je nasazena požadovaná šablona konfigurace klienta a jsou správně nastaveny tagy CSW. (Viz část Webview nastavení volání v Průvodci řešením Webex pro Cisco BroadWorks).
• Ověřte, zda je aplikace Webex registrována pro volání v BroadWorks.
• Zkontrolujte, zda je aplikace Webex nejnovější verze, která podporuje CSWV.

2. Prázdná stránka nebo chyba po kliknutí na tlačítko/odkaz Self Care

Obecně platí, že toto chování v aplikaci Webex označuje problém s konfigurací nebo nasazením aplikace CSWV na serveru BroadWorks XSP. Shromážděte podrobnosti pro další vyšetřování, včetně protokolů CSWV, protokolů přístupu, úložiště config-wxt.xml a souboru šablony, a poté vyvolejte případ.

Problémy s nárokováním domény

Chyby registrace uživatelů mohou nastat v důsledku chyb, ke kterým dochází při nárokování domén. Než si nárokujete doménu, ujistěte se, že rozumíte následujícím skutečnostem:

• Poskytovatelé služeb by si neměli nárokovat domény zákaznických organizací, které spravují. Měli by požadovat pouze domény těch uživatelů, kteří jsou v interní organizaci poskytovatele služeb. Nárok na doménu uživatelů v samostatné organizaci (i té, kterou spravuje poskytovatel služeb) může mít za následek chyby v registraci uživatelů v organizaci zákazníka, protože žádosti o ověření uživatele jsou směrovány spíše prostřednictvím poskytovatele služeb než organizace zákazníka.
• Pokud dvě zákaznické organizace (společnost A a společnost B) sdílejí stejnou doménu a společnost A si doménu nárokovala, registrace pro uživatele společnosti B může selhat kvůli skutečnosti, že žádosti o ověření uživatele jsou směrovány prostřednictvím organizace, která má doménu nárokovanou (společnost A).

  Pokud si omylem nárokujete domény a potřebujete reklamaci ode brat, přečtěte si článek Správa domén Webex.

Chybové kódy koncového uživatele

Následující tabulka popisuje chybové kódy koncového uživatele, které lze vidět na portálu aktivace uživatele klienta.

Chybové kódy pro synchronizaci adresářů

Následující chybové kódy platí pro synchronizaci adresářů.