Obrigado pelos seus comentários.

Este artigo é destinado à equipe de suporte técnico de uma organização prestadora de serviços que apóia a si mesma e a seus clientes. Eles devem estar familiarizados com a solução geral de problemas, com a leitura de registros e com o trabalho com casos de assinantes.

Este artigo está dividido em três seções principais:

• Recursos — fornece uma lista de ferramentas, material de leitura, registros e contatos que você pode precisar.
• Processos — descreve algumas das ações que você pode tomar ao solucionar um problema do cliente.
• Problemas específicos — categoriza e lista os problemas que já se sabe que ocorrem, como identificá-los e como você pode resolvê-los.

Arquivos de log úteis

Lista de leitura

• Portal de conhecimento do parceiro Webex for Cisco BroadWorks
• Guia de configuração da plataforma XSP (R23)
• Guia de gerenciamento de software BroadWorks (R23)
• Guia de configuração do gerenciamento de dispositivos Cisco BroadWorks (R23)
• Guia de administração da interface de linha de comando Broadworks Xsp
• Descrição do recurso de token de autenticação de longa duração, versão 23.0
• Guia de integração de autenticação SAML, R23
• Guia de opções de suporte SSL do Cisco BroadWorks
• Descrição do recurso de suporte do Cisco CI
• Servidor push de notificação (descrição do recurso)
• Suporte de notificação push para chamadas: descrição do recurso, versão 22.0
• Método de procedimento de migração do Connect (Android) para o Firebase
• Cisco BroadWorks Storage of Device Tokens for Push Notifications: Descrição do recurso, versão 22.0
• Planejador de capacidade do sistema Cisco Broadworks (planilha)
• Guia de dimensionamento da plataforma Cisco BroadWorks
• Guia de engenharia do sistema Cisco Broadworks
• Documento de requisitos de suporte à autenticação CI, versão 1.0 MR-7136

Problemas e limitações conhecidos

O artigo Problemas e limitações conhecidos tem informações atualizadas sobre problemas conhecidos que identificamos na solução Webex for BroadWorks.

Conector de facilidade de manutenção

O serviço Webex Serviceability aumenta a velocidade com que a equipe de assistência técnica da Cisco pode diagnosticar problemas com a infraestrutura. Ele automatiza as tarefas de encontrar, recuperar e armazenar registros de diagnóstico e informações em um caso de SR. O serviço também aciona análises com base em assinaturas de diagnóstico para que o TAC possa identificar e resolver problemas com seu equipamento local com mais eficiência.

Para obter detalhes sobre como implantar o conector de capacidade de manutenção, consulte Guia de implantação do conector de capacidade de Cisco Webex manutenção.

Escalando um problema

Depois de seguir algumas das orientações de solução de problemas, você deve ter uma ideia razoável de onde o problema está enraizado.

Procedimento

1. Colete o máximo de informações possível dos sistemas relacionados ao problema.
2. Entre em contato com a equipe apropriada da Cisco para abrir um caso.

Quais informações do cliente coletar

Se você achar que precisa abrir um caso ou encaminhar um problema, colete as seguintes informações ao solucionar problemas com o usuário:

• Identificador de usuário: endereço de e-mail CI ou UUID do usuário (esse é o identificador Webex, mas se você também obtiver o identificador BroadWorks do usuário, inclua-o nos detalhes do caso).
• Identificador da organização.
• Período aproximado durante o qual o problema ocorreu.
• Plataforma e versão do cliente.
• Envie ou colete registros do cliente.
• Registre o ID de rastreamento, se mostrado no cliente.

Verifique os detalhes do usuário no Help Desk

Os administradores de parceiros que têm privilégios de função de Administrador do Help Desk (Básico ou Avançado) podem usar esse procedimento para verificar os detalhes do usuário usando a visualização do Help Desk.

Procedimento

1. Faça login no Help Desk.
2. Pesquise e clique no usuário. Isso abre a tela de resumo do usuário.
3. Clique no nome do usuário para ver a configuração detalhada do usuário. As informações úteis nessa exibição incluem o UUID do usuário, o cluster de identidade comum (CI), o cluster de aplicativos Webex, o comportamento de chamada, o GUID da conta BroadWorks
4. Clique em Copiar se precisar usar essas informações em outra ferramenta ou anexá-las a um gabinete Cisco.

Exibir a organização do cliente no Help Desk

Os administradores de parceiros que têm privilégios de função de Administrador do Help Desk (Básico ou Avançado) podem usar esse procedimento para visualizar os detalhes da organização do cliente na visualização do Help Desk.

Procedimento

1. Faça login no Help Desk.
2. Pesquise e clique no nome da organização do cliente.
3. Role para baixo até ver a Visualização do Portal do Cliente e clique em Exibir Nome do Cliente para ver uma visualização somente para leitura da organização do Cliente, incluindo usuários e configuração.

Recupere registros de usuários do Partner Hub

Ao solucionar problemas de desktop e cliente móvel, é importante que os parceiros (e o TAC) possam visualizar os registros do cliente.

Procedimento

1. Peça ao usuário para enviar registros. Para obter ajuda, consulte: Aplicativo Webex | Relatar um problema.
2. Peça ao usuário que exporte o ambiente de chamada e envie o arquivo ced.dat.
3. Obtenha os registros do cliente no Partner Hub ou no Help Desk.

   Opção Partner Hub:

   1. Faça login no Partner Hub e encontre a organização do cliente do usuário.
   2. Selecione Solução de problemas.
   3. Selecione Registros.
   4. Pesquise o usuário (por e-mail).
   5. Visualize e baixe os registros do cliente como um arquivo zip.

   Opção Help Desk:

   1. Faça login no Help Desk.
   2. Pesquise a organização.
   3. Clique na organização (abre a tela de resumo).
   4. Role para baixo até clicar em Exibir cliente.
   5. Selecione Solução de problemas.
   6. Selecione Registros.
   7. Pesquise o usuário (por e-mail).
   8. Visualize e baixe os registros do cliente como um arquivo zip.

Como encontrar a versão do cliente

Procedimento

1. Compartilhe este link com o usuário: https://help.webex.com/njpf8r5
2. Peça ao usuário que lhe envie o número da versão.

Verificação do cliente para o serviço de chamadas

Procedimento

1. Faça login no cliente Webex.
2. Verifique se o ícone Opções de Chamada (um telefone com uma engrenagem acima) está presente na barra lateral. Se o ícone não estiver presente, talvez o usuário ainda não esteja habilitado para o serviço de chamada no Control Hub.
3. Abra o menu Configurações/Preferências e vá para a seção Serviços Telefônicos. Você deve ver o status Sessão SSO em que você está conectado. (Se um serviço telefônico diferente, como, for exibidoWebex Calling, o usuário não está usando o Webex para Cisco BroadWorks.)

   Essa verificação significa:

   • O cliente percorreu com sucesso os microsserviços Webex necessários.
   • O usuário foi autenticado com sucesso.
   • O cliente recebe um token web JSON de longa duração pelo seu sistema BroadWorks.
   • O cliente recuperou seu perfil de dispositivo e se registrou na BroadWorks.

Obtenha registros ou feedback do cliente

• Consulte a seção Recursos para encontrar registros de clientes específicos em clientes de desktop Webex ou pedir aos usuários que enviem registros. Para obter ajuda, consulte: Aplicativo Webex | Relatar um problema.
• Peça aos usuários de clientes móveis que enviem registros e, em seguida, você poderá obtê-los por meio do Partner Hub ou do Help Desk.
  O envio de registros é silencioso. No entanto, se um usuário enviar feedback, ele será enviado para a equipe de devops do aplicativo Webex. Certifique-se de registrar o número de feedback do usuário se quiser entrar em contato com a Cisco. Por exemplo:

  

Obtenha dados do ambiente de chamadas

Os registros do cliente Webex são altamente editados para remover informações de identificação pessoal. Você deve exportar os dados do ambiente de chamada do cliente na mesma sessão em que notar o problema.

Procedimento

1. No cliente, clique em Ajuda > Health Checker.
2. Selecione Redefinir banco de dados. Isso aciona uma reinicialização completa do cliente e carrega a tela de login do aplicativo Webex.

Verifique se o Webex deve se registrar no BroadWorks

O aplicativo Webex verifica as seguintes informações para determinar se você deve se registrar na BroadWorks:

• Direito do usuário ao broadworks-connector.
• Comportamento de chamada para organização e usuário.

Verificar o comportamento de chamada e os direitos do conector de um usuário

1. Faça login no Help Desk com suas credenciais de administrador parceiro.
2. Pesquise o usuário.
3. Clique no usuário e marque a entrada Calling Behavior. Deve ser “Calling in Webex”.

   

4. Clique no nome do usuário para abrir a tela Detalhes do usuário.
5. Role para baixo para localizar a seção de direitos e verifique se o broadworks-connector está incluído

   

   Um usuário do Webex for Cisco BroadWorks não deve ter o direito ao padrão bc-sp se pretende usar o Webex for Cisco BroadWorks. Esse é o direito de “Webex Calling(Broadcloud)”, que é a chamada do aplicativo Webex por meio de um serviço de chamadas em nuvem gerenciado pela Cisco.

Verifique o comportamento de chamada da organização

1. Faça login no Help Desk com suas credenciais de administrador parceiro.
2. Pesquise a organização.
3. Clique na organização e marque a entrada Comportamento de chamada. Deve ser “Calling in Webex”.

Analise o PSLog para problemas de aprovisionamento de usuários

Use o PsLog do servidor de aplicativos para ver a solicitação HTTP POST para a ponte de provisionamento e a resposta do Webex. Em um caso de funcionamento correto, a resposta é 200 OK e, após alguns minutos, você pode ver que o usuário - e a nova organização do cliente, se for o primeiro usuário - foi criada no Webex. Você pode verificar isso pesquisando no Help Desk o endereço de e-mail que você vê no POST.

Antes de começar

Colete um PSLog do servidor de aplicativos durante uma tentativa contínua de provisionamento com um usuário de teste.

Procedimento

1. Primeiro, verifique o código de resposta HTTP:
   • Qualquer coisa diferente de 200 OK é uma falha no aprovisionamento do usuário.
   • 200 OK ainda pode indicar uma falha se algo no perfil do assinante não funcionar nos serviços Webex acima da ponte de provisionamento.
   • 400 pode conter um nó de mensagem na resposta. A ponte de provisionamento não conseguiu processar algo no SubscriberProfile. Pode haver algo errado com os detalhes do assinante ou incompatibilidade com uma configuração no modelo.
   • 401 significa que as credenciais de provisionamento inseridas no AS não coincidem com as inseridas no modelo no Partner Hub.
   • 403 pode indicar que algo está configurado incorretamente no servidor de aplicativos. Verifique o destino da solicitação. Não deve ser um endereço IP, deve ser a URL da ponte de aprovisionamento que você pode ver no seu modelo no Partner Hub.
   • 409 indica um conflito entre o SubscriberProfile fornecido e os dados Webex existentes. Pode haver um usuário existente com esse endereço de e-mail. Verifique a mensagem na resposta.
2. Você também pode verificar se há valores suspeitos no HTTP POST original que possam causar falha no provisionamento. O POST contém uma estrutura XML SubscriberProfile. Dentro disso, os nós úteis a serem verificados são:
   • bwuserid: Use isso para encontrar o perfil do assinante se precisar editá-lo no BroadWorks.
   • grupo: se o modelo estiver no “modo de provedor de serviços”, ele estará em minúsculas e se tornará o nome da organização do cliente que você vê no Partner Hub.
   • ServiceProvider: se o modelo estiver no “modo corporativo”, ele estará em minúsculas e se tornará o nome da organização do cliente que você vê no Partner Hub.
   • Número de telefone principal: deve existir. O provisionamento falha sem ele.
   • email: se torna o ID do usuário no Webex. Deve ser válido e exclusivo para o Webex, caso contrário, o provisionamento falhará.

     Ignore a estrofe de serviços: ela é criada pelo AS e aceita, mas não usada pelo Webex.

Analise os registros do XSP para solucionar problemas de login do assinante

Esse fluxo descreve o modo de autenticação do BroadWorks. Você pode ver o modo de autenticação no modelo BroadWorks, no Partner Hub. Consulte Configurar seus modelos de cliente em https://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

O diagrama de escada a seguir mostra a interação entre o usuário, o cliente, os serviços Webex e o sistema BroadWorks, quando o usuário está fazendo a autenticação BroadWorks no aplicativo Webex. Além disso, a conexão entre o Webex e o XSP é protegida pelo MTLS.

A discussão a seguir explica o que você pode esperar ao investigar os registros para um login bem-sucedido.

O usuário interage com o cliente, o cliente interage com os serviços Webex:

• O usuário fornece seu endereço de e-mail para o aplicativo Webex (1 no diagrama).
• O CI sabe redirecionar esse usuário para inserir sua senha do BroadWorks (via UAP) (2 no diagrama).
• O IDP Proxy envia uma solicitação de obtenção de perfil para a interface Xsi no XSP.

No access_log do tomcat:

• Procure a solicitação GET para o perfil do assinante, do Webex até a interface Xsi-Actions (2.1 no diagrama). Ele tem o ID de usuário Webex. Por exemplo:

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

No log XSIActionsLog:

• Procure a solicitação GET do perfil do Webex (2.1 no diagrama). Ele tem o ID de usuário Webex. Por exemplo:

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Os cabeçalhos incluem autorização: Basic e user-agent: BroadworkSteamsClient

• O XSP então faz a autenticação básica OCI-P contra o BroadWorks (AuthenticationVerifyRequest e AuthenticationVerifyResponse, como qualquer outro aplicativo que faz autenticação básica via Xsi) e também um UserGetRequest e ServiceProviderGetRequest para coletar as informações do assinante.
• A resposta Xsi ao Webex contém um bloco de perfil XML contendo a ID de usuário (BroadWorks) e outros detalhes (2.2 no diagrama).

Interações entre o cliente e os serviços Webex:

• O proxy IDP corresponde ao perfil do usuário recebido da BroadWorks e emite a declaração SAML para o cliente (2,3 no diagrama).
• O cliente troca a afirmação SAML por um token CI (3 no diagrama).
• O cliente verifica se o usuário conectado tem o direito ao conector broadworks (4 no diagrama). Você pode verificar os direitos do usuário no Help Desk.
• O cliente usa o token CI para solicitar um JSON Web Token (JWT) do proxy IDP (5 no diagrama).
• O proxy IDP valida o token CI no CI.
• O proxy IDP solicita o JWT do serviço de autenticação.

No log do AuthenticationService:

• Procure a solicitação de token do Webex (5.2 no diagrama), por exemplo: GET /AuthService/Token que tem o cabeçalho http_bw_userid e outros.
• O XSP executa o OCI-P UserGetLoginInfoRequest, para validar se o ID de usuário fornecido corresponde a um usuário BroadWorks (5.3 no diagrama). O AuthService estabeleceu confiança com o Webex em virtude da conexão mTLS, portanto, pode emitir LLT.
• Procure a resposta (5,4 no diagrama) do LongLivedTokenManager - Token gerado, assunto: bwksUserId@example.com, emissor: BroadWorks... e statusCode=200, que você pode associar à solicitação original usando o cabeçalho trackingid: CLIENT...

No log XSIActionsLog:

• O cliente pode apresentar o token de longa duração na interface Xsi-Actions para obter seu perfil de dispositivo (6 no diagrama). Por exemplo: GET /com.broadsoft.xsi-actions/v2.0/user/BWKSUserID %40example.com/profile/device Com a autorização dos cabeçalhos: token do portador e agente do usuário: WebexTeams (variante/versão)
• A interface Xsi-Actions PUBLICA o token no authservice (configurado para estar na interface de loopback). Por exemplo: 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token, que você pode correlacionar com o cabeçalho trackingid: CLIENT... no GET e o cabeçalho X-BROADSOFT-CORRELATION-ID: CLIENT... no POST.

No log do AuthenticationService:

• O recebimento do POST da Xsi (loopback)

• Um StatusCode=200 de volta ao Xsi

• E uma resposta de validação de token, com um bloco JSON “token” no corpo.

• Correlacionado usando o trackingid: CLIENT...

No log XSIActionsLog:

• Depois de receber 200 OK do authservice, que validou o token do cliente, o aplicativo Xsi-Actions agora envia a solicitação OCI-P para UserPrimary e SCADeviceGetlistRequest
• Recebe OCI-P UserPrimary e SCADeviceGetListResponse contendo a estrutura XML AccessDeviceTable.
• A resposta OCI-P é codificada como resposta Xsi ao cliente, incluindo a estrutura XML AccessDevices, que tem os DeviceTypes. Por exemplo: Business Communicator — PC e os URLs em que o cliente pode recuperar os arquivos de configuração do dispositivo.

O cliente continua normalmente:

• Seleciona uma entrada de dispositivo e interage com o DMS para obter o perfil do dispositivo (6 no diagrama).
• Registra-se no BroadWorks via SBC recuperado na configuração do DMS (7 no diagrama).

Problemas do Partner Hub

1. O administrador não consegue ver as organizações dos clientes

Como administrador da sua organização parceira no Webex, você deve ter a função de administrador completo. Essa função é usada para gerenciar sua organização parceira, incluindo a atribuição de privilégios administrativos a você e a outras pessoas. Para gerenciar organizações de clientes, você precisa conceder a si mesmo (ou a outras pessoas) a função de Administrador Completo de Vendas ou Administrador de Vendas. Para obter detalhes, consulte Atribuir funções de conta da organização no Control Hub.

Problemas de aprovisionamento de usuários

1. Erros de IM&P integrados para empresas/clientes específicos

Se você tem uma mistura de empresas usando diferentes serviços de colaboração em nuvem, por exemplo, UC-One SaaS e Webex for Cisco BroadWorks, você pode ter optado por modificar o adaptador de provisionamento por empresa.

Para verificar o que está configurado para IM&P integrado (padrão para empresas, a menos que exista uma configuração mais específica), execute as_CLI/interface/messaging> get. Para os parâmetros de provisionamento de uma empresa específica, abra a empresa e acesse Serviços > IM&P Integrado.

Verifique se a configuração de IM&P integrada para essa empresa corresponde exatamente ao que é mostrado no modelo do cliente no Partner Hub. As configurações a seguir devem corresponder ou o provisionamento falhará para todos os usuários da empresa:

2. Erros de IM&P integrados para usuários específicos

Isso se aplica se você estiver usando o provisionamento contínuo e presume que o provisionamento esteja funcionando para alguns ou para a maioria dos usuários (para que você possa descartar um problema de configuração). Se você estiver vendo erros de IM&P integrados no BroadWorks, por exemplo, “[Erro 18215] Erro de provisionamento com servidor de mensagens” e “[Erro 18211] Erro de comunicação com servidor de mensagens”, você deve investigar as seguintes causas possíveis:

• O endereço de e-mail do usuário já pode existir CI. Procure o usuário no Help Desk para verificar se seu endereço de e-mail já está lá. Isso não é necessariamente conclusivo, porque o usuário pode existir em uma organização cujos dados você não tem permissão para ver no Help Desk.
• O usuário se inscreveu de forma independente no Webex, antes de receber o serviço integrado de IM&P. Nesse caso, uma opção é fazer com que o usuário exclua suas contas gratuitas para que ele possa se tornar parte da organização do cliente que você está provisionando. As instruções estão em https://help.webex.com/5m4i4y
• O usuário não tem um número de telefone principal atribuído ao seu perfil (todos os assinantes do Webex for Cisco BroadWorks devem ter um DID primário). Veja o tópico sobre a análise do PsLog do AS.

3. Falhas no provisionamento de usuários em resposta à ponte de provisionamento

Se os usuários não aparecerem no Control Hub, alguns minutos após a atribuição do IM&P integrado, dê uma olhada nos códigos de resposta do serviço de ponte de provisionamento. Execute um PSLog para ver os códigos de resposta HTTP.

200 OK

Uma resposta de 200 OK não significa que o usuário foi provisionado com sucesso. Isso significa que o serviço de provisionamento recebeu a solicitação e enviou com êxito a solicitação de criação de usuário correspondente aos serviços upstream. A transação de provisionamento é assíncrona por design. O serviço responde 200 OK porque o processo de criação do usuário pode levar vários minutos e, por motivos de desempenho, não queremos receber várias solicitações para criar o mesmo usuário. No entanto, se o usuário eventualmente não aparecer na organização do cliente após uma resposta de 200 OK, isso pode indicar que a criação do usuário falhou nos serviços Webex anteriores ao serviço de provisionamento. Você precisa escalar uma falha de provisionamento que tenha uma resposta de 200 OK.

400 Solicitação incorreta

Verifique a resposta HTTP, que deve ter mais detalhes sobre possíveis problemas que podem causar essa resposta do serviço de provisionamento. Alguns exemplos do nó:

• “Não posso confiar no e-mail da BroadWorks com a API de provisionamento herdada.” O endereço de e-mail associado à falha na solicitação de provisionamento de usuários não é válido ou está digitado incorretamente, mas você afirmou no modelo que os endereços de e-mail são confiáveis. Verifique os perfis dos usuários no BroadWorks, especificamente o ID do e-mail.
• A organização do cliente não foi encontrada no banco de dados e o sinalizador de criação de uma nova organização também não está ativado.” Essa solicitação de provisionamento falhada deve criar uma nova organização de clientes no Webex, mas seu modelo está configurado para impedir a criação de novas organizações de clientes. Se você quiser permitir novas organizações, para domínios de e-mail que não correspondam aos clientes existentes no Webex, você pode reconfigurar seu modelo no Partner Hub e testar novamente a solicitação de provisionamento. No entanto, se você não espera que uma nova organização seja criada para esse usuário, talvez o endereço de e-mail esteja digitado incorretamente (especificamente a parte do domínio). Verifique o ID de e-mail do usuário no BroadWorks.

403 Proibido

A solicitação de provisionamento não poderá ser bem-sucedida até que você corrija a configuração. Nesse caso, você precisará investigar a solicitação e a resposta. Por exemplo, se você ver um endereço IP como o destino da solicitação de provisionamento — em vez da URL de ponte de provisionamento apropriada para sua organização (consulte os tópicos de configuração do firewall no Guia de Soluções) — isso pode indicar que seu servidor de aplicativos não tem um patch necessário (ap373197).

Verifique se todos os patches necessários foram aplicados ao servidor de aplicativos e se você concluiu a configuração relacionada para um provisionamento contínuo bem-sucedido.

409 Conflito

A solicitação de provisionamento não pode continuar porque há um usuário existente no Webex que corresponde ao endereço de e-mail na solicitação.

4. O usuário já está no CI

Retire o e-mail do assinante da solicitação HTTP POST e procure-o no Help Desk. Você pode não ver o usuário se não tiver permissão, mas também pode ver que o usuário está em uma organização “gratuita”, por exemplo “Consumidor”. Você pode pedir a esse usuário que exclua sua conta gratuita ou pode usar um endereço de e-mail diferente para provisioná-la. Consulte https://help.webex.com/ndta402.

Problemas de login do usuário

1. O Portal de Ativação do Usuário não carrega

O fluxo normal de login do Webex para Cisco BroadWorks inclui um portal de ativação do usuário no qual os usuários inserem suas senhas. Às vezes, esse portal não carrega depois que o usuário fornece seu endereço de e-mail na tela de login do aplicativo Webex. Esse problema pode ser causado no lado do cliente ou no lado do serviço. No lado do cliente, geralmente é causado pelo fato de o navegador nativo do cliente ser incompatível de alguma forma com o serviço.

2. Falha no login único

• No BroadWorks, verifique se o usuário recebeu os tipos de dispositivo para o aplicativo Webex (consulte a seção Perfis de dispositivos na seção Prepare seu ambiente do Guia de soluções).
• Verifique se o usuário está usando a senha correta. Se o modelo que você usou para provisionar a organização do cliente do usuário (no Partner Hub) estiver configurado para autenticação BroadWorks, o usuário deverá digitar sua senha de “Acesso à Web” do BroadWorks. O usuário também pode precisar inserir sua ID de usuário da BroadWorks se seu endereço de e-mail não estiver configurado como uma ID de usuário alternativa. Verifique se o usuário inseriu letras maiúsculas e minúsculas corretamente.

Problemas de configuração e registro de chamadas

Depois que um usuário é provisionado no Webex e ele entra com sucesso no aplicativo Webex, o aplicativo se registra no BroadWorks. A seguir estão a sequência de registro esperada e os sinais resultantes de um registro saudável (conforme visto no aplicativo Webex):

1. Sequência de registro esperada

1. O cliente chama o XSI para obter um token de gerenciamento de dispositivos e a URL para o DMS.
2. O cliente solicita seu perfil de dispositivo ao DMS apresentando o token da etapa 1.
3. O cliente lê o perfil do dispositivo e recupera as credenciais, endereços e portas SIP.
4. O cliente envia um SIP REGISTER para a SBC usando as informações da etapa 3.
5. O SBC envia o SIP REGISTER para o AS (o SBC pode realizar uma pesquisa no NS para localizar um AS se o SBC ainda não conhecer o usuário do SIP).

2. Sinais esperados de sucesso no registro de clientes

O ícone Opções de chamada aparece na interface Webex.

Na guia Serviços telefônicos do aplicativo Webex (por exemplo, Configurações > Serviços de telefone no Windows, Preferências > Serviços telefônicos no Mac), a mensagem “Sessão SSO: você está conectado” significa que o aplicativo foi registrado com sucesso (neste caso, na BroadWorks).

3. O cliente não tem ícone de chamada

Na maioria das vezes, isso significa que o usuário não tem a licença/direitos corretos.

Este é um registro malsucedido. Há vários motivos pelos quais um cliente do aplicativo Webex falharia no registro na BroadWorks:

4. Vários serviços de chamada sendo testados com os mesmos clientes

Esse problema conhecido pode ser causado pela mudança do cliente entre diferentes back-ends de chamada. É mais provável que ocorra durante testes de diferentes serviços de chamada oferecidos por meio de (os mesmos) clientes do aplicativo Webex. Você pode redefinir o banco de dados do cliente (link) para solucionar esse problema.

5. Configuração incorreta do serviço de autenticação

Verifique os XSPs que hospedam o serviço de autenticação no Guia de soluções (consulte Configurar serviços em seu Webex para Cisco BroadWorks XSPs). Especificamente:

• As chaves RSA (que você gera em um XSP) são copiadas em todos os XSPs
• O URL do serviço de autenticação foi fornecido ao contêiner web em todos os XSPs e inserido corretamente no cluster no Partner Hub
• A autenticação externa por certificados está configurada:

  XSP_CLI/Sistema/Utilitário de Comunicação/Configurações padrão/Autenticação externa/Autenticação de certificado > Obter

  allowUserApp = false

  allowClientApp = true

• Ao usar o MTLS, você deve carregar o certificado do cliente Webex para os XSPs (você pode obter o certificado do Partner Hub, na página de configurações do BroadWorks).

6. Configuração incorreta das tags BroadWorks

Verifique se você configurou as tags BroadWorks necessárias para o aplicativo Webex. Consulte o Guia de configuração do Webex for Cisco BroadWorks para obter informações sobre tags de configuração. Certifique-se de que não haja conflitos ou valores incorretos. Especificamente, a tag %SBC_ADDRESS_WXT% deve ser o SBC em relação ao seu registrador SIP para clientes do aplicativo Webex.

7. O cliente de desktop desconecta os serviços telefônicos após uma conexão SSO bem-sucedida

Esse problema pode ser causado pelo mesmo usuário fazendo login em vários clientes no mesmo tipo de plataforma. Por exemplo, se um usuário entrar com sucesso no aplicativo Webex no Windows e, em seguida, entrar no aplicativo Webex em uma máquina Windows diferente, haverá somente uma sessão de SSO ativa em uma das máquinas. Isso é intencional. Se você realmente precisar contornar esse problema, poderá configurar o BroadWorks para ter várias instâncias do mesmo tipo de dispositivo, mas elas devem ter endereços SIP exclusivos. Essa configuração está fora do escopo do Webex para Cisco BroadWorks.

8. Dispositivo desktop não provisionado para o usuário

Essa assinatura é vista no log do cliente:

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

onAccessDeviceListSucceeded:bwc:scf: configDownload - o perfil do dispositivo 'Business Communicator - PC' não foi encontrado.

9. As chamadas móveis recebidas tocam uma vez ou não podem ser atendidas

As chamadas recebidas para o Webex Mobile tocam apenas uma vez, ou o usuário não pode atender a chamada de entrada. Outros endpoints para o mesmo usuário podem continuar tocando.

Como identificar?

Nos registros do cliente móvel Webex, procure o código de erro XSI 101002 no fluxo de chamadas push. Por exemplo:

Código de resposta: 400

<callID>handlePushCallInfoFailure:bwc:internal: chamada push: xsi status para callID: código de erro xsi: 101002

<callID>closePushCallWithReason:bwc:internal: Tente fechar a chamada push com id =, reason = callAbandoned

Causa: O código de erro 101002 pode indicar que o Application Server (AS) errado foi retornado na resposta LocateUser. Isso pode acontecer quando o usuário migra para um AS secundário.

Verificações recomendadas:

No ADP ou no XSP em que o Push está implantado, execute LocateUser para o usuário afetado:

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

Exemplo: curl 'http://1.1.1.1:80/servlet/LocateUser? url= 9721112222@gmail.com &returnCompatibleXsp=true&callprequest=True'

Resolução: Se LocateUser retornar o AS secundário para o usuário, execute o script MigrateUserToDefaultNode.pl no servidor NS primário para migrar os usuários de volta para o servidor de aplicativos primário do cluster.

Faça login no servidor NS por meio de SSH, vá para o diretório /usr/local/broadworks/bw_base/bin e execute: migrateUserToDefaultNode.pl <hostingNE>

Exemplo: migrateUserToDefaultNode.pl bwas1

Para obter o valor HostingNE, execute: NS_CLI/system/device/hostingNE> get

O script primeiro verifica se consegue encontrar o NE de hospedagem que você fornece como argumento. Depois de verificar se o NE de hospedagem é válido, ele atualiza o DN, a extensão e o URL para o nó padrão desse NE de hospedagem.

Execute o script durante um período de baixo tráfego, quando possível. No entanto, geralmente é aceitável executar o script a qualquer momento, se necessário, para restaurar o serviço para os usuários afetados.

O script não pode ser executado somente para um único usuário. Ele migra todos os usuários listados na saída LocateUser. Se você não conseguir executar o script, exclua e reconstrua o usuário afetado no BroadWorks para que ele seja reconstruído no AS correto.

Qualquer mensagem SIP do dispositivo do usuário para o AS secundário pode fazer com que o usuário migre. Os usuários normalmente revertem para o AS primário após o intervalo padrão de 15 minutos, a menos que as solicitações recebidas continuem chegando ao AS secundário. Por exemplo, se o SBC não conseguir se conectar ao AS1 e recorrer ao AS secundário, os usuários afetados poderão mudar para o AS secundário. Dependendo da implantação, um único grupo de troncos ou usuário pode permanecer preso ao AS secundário se o SBC continuar tendo problemas para acessar o AS primário.

Para obter mais informações, consulte os seguintes documentos:

• Seções 3.4.5 Capacidade de reversão do usuário do servidor de aplicativos e 5.4.5 Reversão automática no Guia de redundância do Cisco BroadWorks

• Descrição do recurso de aprimoramentos do Cisco BroadWorks ASR

9. Serviços telefônicos desconectados

Se os serviços telefônicos aparecerem como desconectados após o usuário entrar no aplicativo Webex, ou se os serviços telefônicos se desconectarem enquanto o usuário estiver usando o cliente, verifique o tipo de cliente e o fluxo de registro.

Para clientes Windows e Mac, o aplicativo Webex se registra no SIP e mantém um registro SIP ativo enquanto o usuário está conectado.

Verifique o seguinte:

1. Verifique se o config-wxt.xml foi baixado com sucesso.

Nos registros do cliente, pesquise ConfigDownload.

Um download bem-sucedido mostra:

configDownload - concluído com sucesso

Se os registros mostrarem o erro a seguir, verifique se há erros relacionados ao token nos registros do AuthService:

configDownload - falha com o código de erro: 1511

2. Verifique se o perfil do dispositivo Webex foi encontrado.

Nos registros do cliente, confirme se o dispositivo de acesso foi encontrado e se used_value é 1. Se used_value for 0, verifique se a Linha primária está ativada ou desativada e verifique o valor da tag. Para obter mais detalhes, consulte a seção 6.1.44 Perfil primário no Guia de configuração do Webex for BroadWorks.

Exemplos de entradas de registro:

:BWC:SCF: configDownload - dispositivo de acesso encontrado

:BWC:SCF: configDownload - dispositivo de acesso: deviceType=Business Communicator - PC, deviceLevel=group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: aparência de chamada compartilhada

:BWC:SCF: configDownload - dispositivo de acesso: deviceType=connect - Mobile, deviceLevel=group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: aparência de chamada compartilhada

:BWC:SCF: configDownload - dispositivo de acesso: deviceType=connect - Tablet, deviceLevel=group, allowTermination=1, isDeviceOwner [has_value: 0, used_value: 1], hasOwnerDevice: 1, EndpointType: aparência de chamada compartilhada

3. Verifique se há falhas de DNS ao resolver o endereço proxy SIP.

Para obter detalhes sobre a descoberta do proxy SIP, consulte a seção 6.1.6 Descoberta dinâmica do proxy SIP no Guia de configuração do Webex for BroadWorks.

Uma descoberta bem-sucedida de proxy mostra:

A descoberta do proxy foi concluída, obteve <number>resultados

4. Verifique se o registro do SIP está falhando.

Se os registros mostrarem mRegistration: TcpTimeout ou Reason: SIP; cause=200; text="last=TCP-timeout”, o cliente Webex não poderá estabelecer uma conexão TCP de baixo nível com o SBC. O registro do SIP não é concluído quando esse erro ocorre. Verifique se o TCP está bloqueado na rede do usuário ou se o SBC está rejeitando a conexão TCP.

Se a solicitação SIP REGISTER for rejeitada ou não receber uma resposta, pesquise nos registros por REGISTER sip e verifique se SIP/2.0 200 OK foi retornado. Se não for retornado, verifique se a rede do usuário está bloqueando o SIP ou se o SBC está rejeitando a solicitação.

No BroadWorks Admin, vá para Usuário > Utilitários > Registros e verifique se um registro SIP válido está presente para o cliente Webex.

Para clientes móveis Android e iOS, o aplicativo Webex não se registra no SIP até que uma chamada seja feita ou recebida. O registro é removido quando a chamada é concluída. Clientes móveis se cadastram para receber notificações push.

Para clientes móveis, verifique o seguinte:

1. Verifique se o config-wxt.xml foi baixado com êxito e se o perfil do dispositivo foi encontrado, conforme descrito para clientes Windows e Mac.

2. Verifique se o registro push foi bem-sucedido.

Nos registros do Webex, procure o estado do registro push:

onPushRegistrationStateChanged: :Estado do registro push alterado, state=Não registrado

onPushRegistrationStateChanged: :Estado do registro push alterado, state=registered

No BroadWorks Admin, vá para Usuário > Utilitários > Registros de notificação push e verifique se um registro push válido está presente para o cliente Webex.

Problemas de visualização na web das configurações de chamada

1. O botão/link Self Care não está sendo exibido no aplicativo Webex

Um sintoma diferente desse problema é quando o botão/link é exibido, mas clicar nele abre um navegador externo.

• Verifique se o modelo de configuração do cliente necessário foi implantado e as tags CSW estão configuradas corretamente . (Consulte a seção Call Settings Webview no Guia de soluções Webex for Cisco BroadWorks).
• Verifique se o aplicativo Webex está registrado para chamadas no BroadWorks.
• Verifique se o aplicativo Webex é uma versão recente que suporta CSWV.

2. Página em branco ou erro após clicar no botão/link Self Care

Geralmente, esse comportamento no aplicativo Webex indica um problema de configuração ou implantação com o aplicativo CSWV no BroadWorks XSP. Colete detalhes para uma investigação mais aprofundada, incluindo registros CSWV, registros de acesso, repositório config-wxt.xml e arquivo de modelo e, em seguida, levante um caso.

Problemas de reivindicação de domínio

Erros de registro do usuário podem ocorrer como resultado de erros cometidos na reivindicação de domínios. Antes de reivindicar qualquer domínio, certifique-se de entender o seguinte:

• Os provedores de serviços não devem reivindicar os domínios das organizações de clientes que eles gerenciam. Eles devem reivindicar somente os domínios dos usuários que estão na organização interna do provedor de serviços. Reivindicar o domínio de usuários em uma organização separada (mesmo que seja gerenciada pelo provedor de serviços) pode resultar em erros de registro para os usuários na organização do cliente, pois as solicitações de autenticação do usuário são encaminhadas pelo provedor de serviços e não pela organização do cliente.
• Se duas organizações de clientes (Empresa A e Empresa B) compartilharem o mesmo domínio e a Empresa A tiver reivindicado o domínio, o registro dos usuários da Empresa B poderá falhar devido ao fato de as solicitações de autenticação do usuário serem encaminhadas pela organização que reivindicou o domínio (Empresa A).

  Se você reivindicar algum domínio por engano e precisar remover uma reivindicação, consulte o artigo Gerenciar seus domínios Webex.

Códigos de erro do usuário final

A tabela a seguir descreve os códigos de erro do usuário final que podem ser vistos no portal de ativação do usuário cliente.

Códigos de erro para sincronização de diretórios

Os códigos de erro a seguir se aplicam à sincronização de diretórios.