Prepare seu ambiente

Pontos de decisão

Consideração Perguntas a responder Recursos

Arquitetura e infra-estrutura

Quantos XSPs?

Como eles levam ao mTLS?

Planejador de capacidade do sistema Cisco BroadWorks

Guia de engenharia do Cisco BroadWorks System

Referência XSP CLI

Este documento

Provisionamento de clientes e usuários

Você pode dizer que confia em e-mails no BroadWorks?

Você deseja que os usuários forneçam endereços de e-mail para ativar suas próprias contas?

Você pode criar ferramentas para usar nossa API?

Docs de API públicas em https://developer.webex.com

Este documento

Marca Qual cor e logotipo você deseja usar? Artigo de marca do aplicativo Webex
Modelos Quais são os diferentes casos de uso do cliente? Este documento
Funcionalidades do Assinante por cliente/empresa/grupo Escolha o pacote para definir o nível de serviço por modelo. Básico, Padrão, Premium ou Softphone.

Este documento

Matriz de recursos/pacotes

Autenticação de usuário BroadWorks ou Webex Este documento
Adaptador de provisionamento (para opções de provisionamento fluxo outubro)

Você já usa o IM&P integrado, por exemplo, para UC-One SaaS?

Você pretende usar vários modelos?

Existe um caso de uso mais comum antecipado?

Este documento

Referência CLI do servidor de aplicação

Arquitetura e infra-estrutura

  • Com que tipo de escala você pretende iniciar? É possível fazer uma escala futura, mas a sua estimativa atual de uso deve impulsionar o planejamento da infra-estrutura.

  • Trabalhe com seu gerente de contas/representante de vendas da Cisco para tamanho da infraestrutura XSP, de acordo com o Planejador de capacidade do sistema BroadWorks da Cisco ( ) e o Guia de engenharia do Ciscohttps://xchange.broadsoft.com/node/1051462BroadWorks System (https://xchange.broadsoft.com/node/1051496).

  • Como você Cisco Webex as conexões mútuas TLS para os seus XSPs? Diretamente para o XSP em um DMZ ou via proxy TLS? Isso afeta seu gerenciamento de certificados e as URLs que você usa para as interfaces. (Não suportamos conexões TCP não criptografadas à borda da sua rede).

Provisionamento de clientes e usuários

Qual método de provisionamento de usuário é melhor para você?

  • Provisionamento fluxo contínuo com e-mailsconfiáveis: Ao atribuir o serviço "IM&P integrado" na BroadWorks, o assinante é automaticamente provisionado no serviço Cisco Webex.

    Se você também pode declaração de que os endereços de e-mail do assinante no BroadWorks são válidos e exclusivos para o Webex, você pode usar a variante do "e-mail confiável" de provisionamento fluxo contínuo. As contas Webex do assinante são criadas e ativadas sem a intervenção; basta que eles baixem o cliente e inscrevam-se.

    Endereço de e-mail é um atributo do usuário principal Cisco Webex. Portanto, o provedor de serviços deve fornecer um endereço de e-mail válido para o usuário, a fim de provisioná-lo para Cisco Webex serviços. Isto deve estar no atributo ID de e-mail do usuário no BroadWorks. Recomendamos que você o copie no atributo ID alternativo também.

  • Provisionamento fluxo contínuo sem e-mailsconfiáveis: Se não puder confiar nos endereços de e-mail do assinante, você ainda poderá atribuir o serviço IM&P integrado no BroadWorks para provisionar usuários no Webex.

    Com esta opção, as contas são criadas quando você atribui o serviço, mas os assinantes precisam fornecer e validar seus endereços de e-mail para ativar as contas Webex.

  • Autopro provisionamento deusuário: Esta opção não exige a atribuição do serviço IM&P no BroadWorks. Você (ou seus clientes) distribui um link de provisionamento em vez disso, e os links para baixar os diferentes clientes, com a sua marca e instruções.

    Assinantes seguem o link, então fornecem e validam seus endereços de e-mail para criar e ativar suas contas Webex. Depois, eles baixam o cliente e cadastram-se, e a Webex busca alguma configuração adicional sobre o BroadWorks (incluindo os números principais).

  • Provisionamento SP controlado viaAPIs: Cisco Webex expor um conjunto de APIs Públicas que permitem aos Provedores de Serviços desenvolver o provisionamento de usuários/assinantes em seus fluxos de trabalho existentes.

Modelos de clientes

Os modelos de cliente permitem que você defina os parâmetros pelos quais clientes e assinantes associados são provisionados automaticamente no Cisco Webex para o BroadWorks. Você pode configurar vários modelos do cliente conforme necessário, mas quando você integra um cliente, ele está associado a apenas um modelo (você não pode aplicar vários modelos a um cliente).

Alguns dos parâmetros de modelo primário estão listados abaixo.

Pacote

  • Você deve selecionar um pacote padrão ao criar um modelo (Consulte Pacotes na seção visão geral para obter detalhes). Todos os usuários que são provisionados com esse modelo, seja por fluxo e autopro provisionamento receberão o pacote padrão.

  • Você tem controle sobre a seleção do pacote para clientes diferentes criando vários modelos e selecionando pacotes padrão diferentes em cada um deles. Você pode então distribuir diferentes links de provisionamento ou diferentes adaptadores de provisionamento por empresa, dependendo do método de provisionamento de usuário escolhido para esses modelos.

  • Você pode alterar o pacote de assinantes específicos deste padrão, usando a API de provisionamento (consulte Integrando com o Webex para a API de Provisionamento BroadWorks na seção de Referência) ou através do Partner Hub.

  • Você não pode alterar o pacote de um assinante de BroadWorks. A atribuição do serviço de IM&P integrado está desligada ou está desligada; se esse serviço for atribuído ao assinante na BroadWorks, o modelo do Partner Hub associado à URL de provisionamento da empresa desse assinante definirá o pacote.

Revendedores e empresas ou provedor de serviços e grupos?

  • A maneira como seu sistema BroadWorks é configurado terá um impacto no fluxo através do provisionamento. Se você é um revendedor com Enterprises, então você precisa habilitar o modo Enterprise ao criar um modelo.
  • Se o seu sistema BroadWorks estiver configurado provedor de serviços modo de espera, você pode deixar o modo Enterprise desligado nos modelos.
  • Se você planeja provisionar organizações de clientes usando ambos os modos BroadWorks, você deve usar modelos diferentes para grupos e empresas.

Modo de autenticação

Como os assinantes dos clientes se autenticarão?

Modo de autenticação BroadWorks Webex
Identidade do usuário primário BroadWorks ID do usuário Endereço de e-mail
Fornecedor da identidade

BroadWorks.

A autenticação é facilitada por um serviço de intermediação organizado pelo Cisco Webex.

Cisco Common Identity
Autenticação multifases? Não Requer o IdP do cliente que suporte autenticação multifases.

Caminho de validação da credencial

  1. O navegador é lançado onde o usuário fornece e-mails para o fluxo de logon inicial e descubra seu modo de autenticação.

  2. O navegador é então redirecionado para Cisco Webex página de logon BroadWorks hospedada (esta página tem marca)

  3. O usuário fornece a ID de usuário e a senha do BroadWorks na página de logon.

  4. As credenciais do usuário são validadas contra o BroadWorks.

  5. Com êxito, um código de autorização é obtido da Cisco Webex. Isso é usado para obter tokens de acesso necessários para os Cisco Webex de suporte.

  1. O navegador é lançado onde o usuário fornece e-mails para o fluxo de logon inicial e descubra seu modo de autenticação.

  2. O navegador é redirecionado ao IdP (seja Cisco Common Identity ou IdP do cliente) onde eles serão apresentados com um portal de logon.

  3. O usuário fornece as credenciais apropriadas na página de logon

  4. A autenticação multifases pode ocorrer se o IdP do cliente suportar isso.

  5. Com êxito, um código de autorização é obtido da Cisco Webex. Isso é usado para obter tokens de acesso necessários para os Cisco Webex de suporte.

Vários organização de parceiros

Você irá sub-licençar o Webex para BroadWorks para outro provedor de serviços? Neste caso, cada provedor de serviços precisará de uma organização parceira distinta no Webex Control Hub para permitir que ela provisione a solução para sua base de clientes.

Adaptador e modelos de provisionamento

Quando você está usando provisionamento fluxo remoto, a URL de provisionamento que você ins dela entra no BroadWorks é derivado do modelo no Control Hub. Você pode ter vários modelos e, portanto, várias URLs de provisionamento. Isto permite que você selecione, em uma empresa por empresa, qual pacote a ser aplicado aos assinantes quando eles são concedidos o serviço IM&P integrado.

Você precisa considerar se você deseja definir uma URL de provisionamento de nível do sistema como um caminho de provisionamento padrão e qual modelo você deseja usar para isso. Dessa forma, você só precisa definir explicitamente a URL de provisionamento para essas empresas que precisam de um modelo diferente.

Além disso, tenha em mente que você já deve estar usando uma URL de provisionamento de nível de sistema, por exemplo, com o UC-One SaaS. Se esse for o caso, você pode optar por preservar a URL de nível do sistema para provisionamento de usuários no UC-One SaaS, e substituir essas empresas que estão mudando para o Webex para BroadWorks. Como alternativa, você pode querer ir para o outro lado e definir a URL de nível do sistema para Webex para BroadWorks e reconfigurar aquelas empresas que deseja manter no UC-One SaaS.

As opções de configuração relacionadas a esta decisão são detalhadas em Configurar Servidor de Aplicativo com URL do Serviço de Provisionamento na seção Implantar Webex para BroadWorks.

Requisitos mínimos

Contas

Todos os assinantes que você está provisionando para o Webex devem existir no sistema BroadWorks que você integra com a Webex. Você pode integrar vários sistemas BroadWorks, se necessário.

Todos os assinantes devem ter licenças BroadWorks e números principais.

O Webex usa endereços de e-mail como identificadores primários para todos os usuários. Se você estiver usando provisionamento fluxotrabalho com e-mails confiáveis, então os usuários devem ter endereços válidos no atributo de e-mail no BroadWorks.

Se seu modelo usar a autenticação BroadWorks, você poderá copiar os endereços de e-mail do assinante para o atributo ID alternativo no BroadWorks. Isso possibilita que os usuários se inscrevam no Webex usando seus endereços de e-mail e suas senhas BroadWorks.

Os administradores devem usar suas contas Webex para fazer o sign in ao Partner Hub.

Servidores em sua rede e requisitos de software

  • Exemplo(s) BroadWorks com versão mínima R21 SP1. Consulte os Requisitos de software BroadWorks (neste documento) para versões e patches suportados. Consulte também Gerenciamento de Ciclo de vida - Servidores BroadSoft.


    R21 SP1 só é suportado até meados de 2021. Embora você possa atualmente integrar o Webex com R21 SP1, recomendamos fortemente R22 ou posterior para a integração com o Webex.

  • A(s) ocorrência(s) do BroadWorks deve incluir pelo menos os seguintes servidores:

    • Servidor de Aplicativo (AS) com a versão BroadWorks como acima

    • Servidor de Rede (NS)

    • Servidor de Perfil (PS)

  • Reuniões ADP (Servidor(s) XSP voltados ao público ou plataforma de entrega de aplicativos (ADP) os seguintes requisitos:

    • Serviço de autenticação (BWAuth)

    • Interfaces de eventos e ações XSI

    • DMS (aplicativo da web de gerenciamento de dispositivos)

    • Interface CTI (Conexão de telefonia do computador)

    • TLS 1.2 com um certificado válido (não auto assinado) e quaisquer intermediários necessários. Requer o Administrador de Nível de Sistema para facilitar a análise das empresas.

    • Autenticação TLS Mútua (mTLS) para Serviço de Autenticação (Requer a cadeia de certificados Cisco Webex cliente pública instalada como âncoras de confiança)

    • Autenticação mútua TLS (mTLS) para a interface CTI (Requer a cadeia de certificados do Cisco Webex cliente pública instalada como âncoras de confiança)

  • Um servidor XSP/ADP separado agindo como um "Servidor para push de notificações de chamada" (um NPS no seu ambiente usado para empurrar as notificações de chamada para a Apple/Google. Chamamos aqui "CNPS" para distingui-lo do serviço no Webex que fornece notificações por push para mensagens e presença).

    Este servidor deve estar no R22 ou posterior.

  • Ordenamos um servidor XSP/ADP separado para CNPS porque a não capacidade da carga do Webex para conexões em nuvem BWKS poderia afetar de forma negativa o desempenho do servidor NPS, com o resultado de uma latência de notificação cada vez maior. Consulte o Guia de engenharia do Cisco BroadWorks Systemhttps://xchange.broadsoft.com/node/422649() para obter mais informações em escala XSP.

Telefones físicos e acessórios

Perfis de dispositivo

Estes são os arquivos DTAF que você precisa carregar nos Servidores de aplicativos para suportar aplicativos Webex como clientes de chamada. Eles são os mesmos arquivos DTAF que são usados para SaaS UC-One, no entanto há um novo config-wxt.xml.template arquivo usado para aplicativos Webex.

Nome do cliente

Tipo de perfil do dispositivo e nome do pacote

Modelo móvel Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Identidade/Tipo de Perfil do Dispositivo: Conectar - Móvel

DTAF: ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Arquivo de configuração: config-wxt.xml

Modelo do tablet Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Identidade/Tipo de Perfil do Dispositivo: Conectar - Tablet

DTAF: ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Arquivo de configuração: config-wxt.xml

Modelo de desktop Webex

https://xchange.broadsoft.com/support/uc-one/communicator/software

Identidade/Tipo de Perfil do Dispositivo: Comunicador de Negócios - PC

DTAF: ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Arquivo de configuração: config-wxt.xml

Certificados do pedido

Requisitos de certificado para autenticação TLS

Você precisará de Certificados de Segurança, assinados por uma autoridade de certificação bem conhecida e implantados em seus XSPs voltados ao público para todos os aplicativos necessários. Estas serão usadas para suportar a verificação do certificado TLS para todas as conectividade de entrada para seus servidores XSP.

Esses certificados devem incluir seu nome público XSP nome de domínio totalmente qualificado nome comum do assunto ou Nome alternativo do assunto.

Os requisitos exatos para a implantação desses certificados de servidor depende de como o seu XSPs voltados ao público são implantados:

  • Através de um proxy de ponte TLS

  • Através de um proxy de passagem TLS

  • Diretamente ao XSP

O diagrama a seguir resume onde o certificado de servidor público assinado pela CA precisa ser carregado nestes três casos:

Os CAs suportados publicamente que o aplicativo Webex suporta para autenticação estão listados nas Autoridades de Certificação suportadas para Cisco Webex híbridos.

Requisitos do certificado TLS para Proxy de ponte TLS

  • O certificado de servidor assinado publicamente é carregado no proxy.

  • O proxy apresenta este certificado de servidor assinado publicamente para o Webex.

  • O Webex confia na CA pública que assinou o certificado de servidor do proxy.

  • Um certificado assinado pela CA interna pode ser carregado no XSP.

  • O XSP apresenta este certificado de servidor assinado internamente para o proxy.

  • O proxy confia na CA interna que assinou o certificado de servidor XSP.

Requisitos de certificado TLS para proxy TLS-pass securário ou XSP no DMZ

  • O certificado de servidor assinado publicamente é carregado nos XSPs.

  • Os XSPs apresentam certificados de servidor assinados publicamente para o Webex.

  • O Webex confia na CA pública que assinou os certificados do servidor XSPs.

Requisitos de certificado adicionais para autenticação TLS mútua sobre a Interface CTI

Ao se conectar à interface CTI, o Cisco Webex apresenta um certificado de cliente como parte da autenticação mútua TLS. O certificado do cliente Webex CA/chain certificate está disponível para download através do Control Hub.

Para baixar o certificado:

Acesse o Partner Hub, acesse Configurações do > BroadWorks Calling e clique no link do certificado de download.

Os requisitos exatos para a implantação desta cadeia de certificados CA Webex depende de como o seu XSPs voltados ao público são implantados:

  • Através de um proxy de ponte TLS

  • Através de um proxy de passagem TLS

  • Diretamente ao XSP

O diagrama a seguir resume os requisitos de certificado nestes três casos:

Figura 1. Troca de certificados mTLS para CTI através de diferentes configurações de borda

(Opção) Requisitos de certificado para proxy de ponte TLS

  • O Webex apresenta um certificado de cliente assinado publicamente para o proxy.

  • O proxy confia na CA interna da Cisco que assinou o certificado de cliente. Você pode baixar esta ca/cadeia de controle do Hub de controle e adicioná-la ao armazenamento de confiança do proxy. O certificado de servidor XSP assinado publicamente também é carregado no proxy.

  • O proxy apresenta o certificado de servidor assinado publicamente ao Webex.

  • O Webex confia na CA pública que assinou o certificado de servidor do proxy.

  • O proxy apresenta um certificado de cliente assinado internamente para os XSPs.

    Este certificado deve ter o campo de extensão x509.v3 preenchido com o BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 e a finalidade do cliente TLSAuth. E.g.:

    X509v3 extensions:
        X509v3 Extended Key Usage:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

    O CN do certificado interno deve ser bwcticlient.webex.com.


    • Ao gerar certificados de cliente interno para o proxy, observe que os certificados SAN não são suportados. Os certificados do servidor interno para o XSP podem ser SAN.

    • As autoridades de certificação públicas podem não estar dispostas a assinar os certificados com o OID BroadWorks proprietário que é necessário. No caso de um proxy de ponte, você pode ser forçado a usar uma CA interna para assinar o certificado de cliente que o proxy apresenta para o XSP.

  • Os XSPs confiam na CA interna.

  • Os XSPs apresentam um certificado de servidor assinado internamente.

  • O proxy confia na CA interna.

  • A clientIdentity do servidor de aplicativos contém o CN do certificado de cliente assinado internamente apresentado ao XSP pelo proxy.

(Opção) Requisitos de certificado para proxy TLS pass securário ou XSP no DMZ

  • O Webex apresenta um certificado de cliente assinado pela CA interna da Cisco aos XSPs.

  • Os XSPs confiam na CA interna da Cisco que assinou o certificado de cliente. Você pode baixar esta ca/cadeia de controle do Hub de controle e adicioná-la ao armazenamento de confiança do proxy. O certificado de servidor XSP assinado publicamente também é carregado nos XSPs.

  • Os XSPs apresentam os certificados de servidor assinados publicamente ao Webex.

  • O Webex confia na CA pública que assinou os certificados do servidor XSPs.

  • A identificação do cliente do servidor de aplicativo contém o CN do certificado de cliente assinado pela Cisco apresentado ao XSP pelo Webex.

Prepare sua rede

Mapa de conexão

O diagrama a seguir ilustra pontos de integração. O ponto do diagrama é mostrar que você precisa revisar IPs e Portas para conexões dentro e fora do seu ambiente. As conexões que são usadas pela Webex para BroadWorks são descritas nas tabelas subsequentes.

Os requisitos de firewall para o funcionamento normal do aplicativo do cliente são listados como referências, pois já estão documentados no help.webex.com.

CONFIGURAÇÃO FIREWALL

O mapa de conexão e as tabelas a seguir descrevem as conexões e protocolos necessários entre os clientes (na ou fora da rede do cliente), a sua rede e a plataforma Webex.

Nós apenas documentamos as conexões específicas do Webex para BroadWorks. Não mostramos as conexões genéricas entre o aplicativo Webex e a nuvem Webex, que estão documentadas em:

Regras de entrada da EMEA

(Na sua rede)

Objetivo Origem Protocolo Destino Porta de destino

WebexCloud

CTI/Auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

Cti

Seu XSP

TCP/TLS 8012

443

Aplicativo Webex

Xsi/DMS

Any

HTTPS

Seu XSP

443

Os terminais do VoIP Webex

Any

SIP

Seu SBC

Protocolo e porta definidos pelo SP

TCP/UDP


É fortemente recomendado que a porta SIP seja diferente da 5060 (por exemplo, 5075) devido a problemas conhecidos com o uso da porta SIP padrão (5060) com dispositivos móveis.

Regras de Saída da EMEA

(Fora da sua rede)

Objetivo

Origem

Protocolo

Destino

Porta de destino

Provisionamento de usuários via APIs

Seu servidor de aplicação

HTTPS

webexapis.com

443

Notificações push do proxy (serviço de produção)

Seu servidor NPS

HTTPS

https://nps.uc-one.broadsoft.com/

OU 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex Common Identity

Seu servidor NPS

HTTPS

https://idbroker-eu.webex.com

443

Webex Common Identity

XSP do serviço de aut.

HTTPS

https://idbroker-eu.webex.com/idb

https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Serviços APNS e FCM

Seu servidor NPS

HTTPS

Qualquer endereço de IP*

443

Notificações push do proxy (serviço de produção)

Webex Common Identity

Serviços APNS e FCM

Seu servidor NPS

HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

Qualquer endereço de IP*

443

Provisionamento de usuários através do adaptador de provisionamento BroadWorks

Suas BroadWorks AS

HTTPS

https://broadworks-provisionamento-bridge-*.wbx2.com/

(onde * pode ter qualquer letra. Sua URL de provisionamento exata está disponível no modelo que você criou no Partner Hub)

443

† esses intervalos contêm os hosts para o proxy NPS, mas não podemos dar os endereços exatos. Os intervalos também podem conter hosts que não estão relacionados ao Webex para BroadWorks. Recomendamos que você configure o firewall para permitir o tráfego ao proxy NPS FQDN em vez disso, para garantir que sua saída seja apenas para os hosts que expormos ao proxy NPS.

* APNS e FCM não possuem um conjunto fixo de endereços IP.

Regras de entrada dos EUA

(Na sua rede)

Objetivo

Origem

Protocolo

Destino

Porta de destino

WebexCloud

CTI/Auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

Cti

Seu XSP

TCP/TLS 8012

TLS 443

Aplicativo Webex   

Xsi/DMS

Any

HTTPS

Seu XSP

443

Aplicativo Webex VoIP terminais SIP

Any

SIP

Seu SBC

Protocolo e porta definidos pelo SP

TCP/UDP


É fortemente recomendado que a porta SIP seja diferente da 5060 (por exemplo, 5075) devido a problemas conhecidos com o uso da porta SIP padrão (5060) com dispositivos móveis.

Regras de saída dos EUA

(Fora da sua rede)

Objetivo

Origem

Protocolo

Destino

Porta de destino

Provisionamento de usuários via APIs

Seu servidor de aplicação

HTTPS

webexapis.com

443

Notificações push do proxy (serviço de produção)

Seu servidor NPS

HTTPS

https://nps.uc-one.broadsoft.com/

OU 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Webex Common Identity

Seu servidor NPS

HTTPS

https://idbroker.webex.com

https://idbroker-b-us.webex.com

443

Webex Common Identity

XSP do serviço de aut.

HTTPS

https://idbroker.webex.com/idb

https://idbroker-b-us.webex.com/idb

https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Serviços APNS e FCM

Seu servidor NPS

HTTPS

Qualquer endereço de IP*

443

Provisionamento de usuários através do adaptador de provisionamento BWKS

Suas BroadWorks AS

HTTPS

https://broadworks-provisionamento-bridge-*.wbx2.com/

(onde * pode ter qualquer letra. Sua URL de provisionamento exata está disponível no modelo que você criou no Partner Hub)

443

† esses intervalos contêm os hosts para o proxy NPS, mas não podemos dar os endereços exatos. Os intervalos também podem conter hosts que não estão relacionados ao Webex para BroadWorks. Recomendamos que você configure o firewall para permitir o tráfego ao proxy NPS FQDN em vez disso, para garantir que sua saída seja apenas para os hosts que expormos ao proxy NPS.

* APNS e FCM não possuem um conjunto fixo de endereços IP.

Requisitos de rede dos serviços Webex

As tabelas de firewall de Regras de Entrada e Saída anteriores documentam apenas as conexões que são específicas do Webex para BroadWorks. Para obter informações gerais sobre conexões entre o aplicativo Webex e a nuvem Webex, consulte os Requisitos de rede dos serviçosWebex. Este artigo é genérico à Webex, mas a tabela a seguir identifica as diferentes seções do artigo e como cada seção é relevante para o Webex para BroadWorks.

Tabela 1. Requisitos de rede para conexões de aplicativos Webex (genéricos)

Seção do artigo de requisitos de rede

Relevância das informações

Resumo dos tipos e protocolos de dispositivos suportados pelo Webex

Informativo

Protocolos de transporte e codificação de codificação para dispositivos e aplicativos Webex registrados na nuvem

Informativo

Serviços Webex – Números de portas e protocolos

Deve ser lida

Sub-redes IP para serviços de mídia Webex

Deve ser lida

Domínios e URLs que precisam ser acessados para os serviços Webex

Deve ser lida

URLs adicionais dos serviços híbridos Webex

Opcional

Recursos de proxy

Opcional

802.1X – Controle de acesso à rede baseado em porta

Opcional

Requisitos de rede para serviços Webex baseados em SIP

Opcional

Requisitos de rede do áudio Webex Edge

Opcional

Um resumo de outros serviços híbridos Webex e documentação

Opcional

Serviços Webex para clientes FedRAMP

N/D

Informações adicionais

Para obter informações adicionais, consulte Whitepaper de Firewall do aplicativo Webex(PDF).

Suporte de redundância BroadWorks

Os Cisco Webex em nuvem e os aplicativos de clientes Webex que precisam acessar a rede do parceiro suportam totalmente a redundância Broadworks XSP fornecida pelo parceiro. Quando um XSP ou site não está disponível para manutenção planejada ou razão não planejada, os serviços e aplicativos da Cisco podem avançar para outro XSP ou site fornecido pelo parceiro para concluir uma solicitação.

Topologia de rede

Os XSPs Broadworks podem ser implantados diretamente na Internet ou podem residir em um DMZ frontado por um elemento de balanceamento de carga, como o F5 BIG-IP. Para fornecer geo redundância, os XSPs podem ser implantados em dois (ou mais) centros de dados, cada um pode ser frontado por um balanceador de carga, cada um com um endereço IP público atual. Se os XSPs estão atrás de um balanceador de carga, os microsserviços Webex e o aplicativo veem apenas o endereço IP do balanceador de carga e os Broadworks parecem ter apenas um XSP, mesmo se houver vários XSPs atrás.

No exemplo abaixo, os XSPs são implantados em dois sites, Site A e Site B. Existem dois XSPs frontados por um balanceador de carga em cada site. O site A tem XSP1 e XSP2 frontaldos pela LB1 e o Site B tem XSP3 e XSP4 frontados pelo LB2. Apenas os balanceadores de carga são expostos na rede pública e os XSPs estão nas redes privadas DMZ.

Serviços em nuvem Webex

CONFIGURAÇÃO DNS

Os microsserviços em nuvem Webex devem ser capazes de encontrar o(s) servidor(s) XSP broadworks para conectar-se às interfaces Xsi, serviço de autenticação e CTI.

Cisco Webex microsserviços em nuvem executarão a lookup de DNS A/AAA do hostname XSP configurado e se conectarão ao endereço de IP retornado. Isto pode ser um elemento de borda de balanceamento de carga ou pode ser o próprio servidor XSP. Se vários endereços IP forem retornados, o primeiro IP na lista será selecionado. SRV não é suportada atualmente.

Exemplo: O registro DNS A do parceiro para descoberta de Rodízio balanceou o servidor XSP/Balanceadores de carga que voltam para a internet

Tipo de gravação

Nome

Alvo

Objetivo

A

xsp.example.com

198.51.100.48

Aponta para LB1 (Site A)

A

xsp.example.com

198.51.100.49

Aponta para LB2 (Site B)

Failover

Quando os microsserviços Webex enviam uma solicitação para o Balanceador de Carga/XSP e a solicitação falha, várias coisas podem acontecer:

  • Se a falha for devido a um erro de rede (ex: TCP, SSL), os microsserviços Webex marcam o IP como bloqueado e executam imediatamente uma rota antecipada para o próximo IP.

  • Se um código de erro (HTTP 5xx) for retornado, os microsserviços Webex marcarão o IP como bloqueado e executarão imediatamente um avanço de rota para o próximo IP.

  • Se nenhuma resposta HTTP for recebida dentro de 2 segundos, o tempo da solicitação se e os microsserviços Webex marcarão o IP como bloqueado e executarão um avanço de rota para o próximo IP.

Cada solicitação é tentada 3 vezes antes que uma falha seja relatada de volta ao microsserviço.

Quando um IP está na lista bloqueada, ele não será incluído na lista de endereços para tentar ao enviar uma solicitação a um XSP. Após um período predeterminado de tempo, um IP bloqueado expira e volta à lista para tentar quando outra solicitação for feita.

Se todos os endereços de IP estão bloqueados, o microsserviço ainda tentará enviar a solicitação selecionando aleatoriamente um endereço de IP da lista bloqueada. Se bem-sucedido, esse endereço de IP é removido da lista bloqueada.

Status

O status da conectividade dos serviços em nuvem Webex para os XSPs ou balanceadores de carga pode ser visto no Control Hub. Em um Grupo de chamada BroadWorks, um status de conexão é exibido para cada uma dessas interfaces:

  • Ações XSI

  • Eventos XSI

  • Serviço de autentificação

O status da conexão é atualizado quando a página é carregada ou durante as atualizações de entrada. Os status de conexões podem ser:

  • Verde: Quando a interface pode ser alcançada em um dos IPs na lookup de registro A.

  • Vermelho: Quando todos os IPs na buscar registros A estão inacessível e a interface não estará disponível.

Os seguintes serviços usam os microsserviços para se conectarem aos XSPs e são afetados pela disponibilidade da interface XSP:

  • Logon no aplicativo Webex

  • Atualização do token do aplicativo Webex

  • E-mail/ativação automática não confiança

  • Checagem de saúde do serviço Broadworks

Aplicativo Webex

CONFIGURAÇÃO DNS

O aplicativo Webex acessa os serviços XSI-Actions &XSI-Events) e os serviços Serviço de gerenciamento dispositivos Serviço de gerenciamento (DMS) no XSP.

Ele executará a SRV DNS _xsi-client._tcp.<xsi domain> da URL configurada para encontrar os hosts XSP ou balanceadores de carga para o serviço XSI.

Veja a seguir um exemplo de SRV gravações.

Tipo de gravação

Gravar

Alvo

Objetivo

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc1.example.com

Descoberta de cliente da interface Xsi

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc2.example.com

Descoberta de cliente da interface Xsi

A

xsp-dc1.example.com

198.51.100.48

Aponta para LB1 (site A)

A

xsp-dc2.example.com

198.51.100.49

Aponta para LB2 (site B)


Cada registro A/AAAA deve mapear para um endereço de IP. Se houver vários XSPs em um DMZ atrás do dispositivo de balanceador de carga/edge, é necessário que o balanceador de carga seja configurado para manter a persistência da sessão para encaminhar todas as solicitações da mesma sessão para o mesmo XSP.

Ordenamos essa configuração porque os batimentos cardíacos XSI do cliente devem ir para o mesmo XSP que é usado para estabelecer o canal de eventos.

Se você mapear o nome A/AAAA para mais de um endereço de IP, ou se o elemento balanceador de carga/borda não mantém a persistência da sessão, o cliente eventualmente envia os batimentos cardíacos para um XSP onde não estabeleceu um canal de evento. Isso faz com que o canal seja destruída, e também em tráfego interno significativamente mais, o que prejudicará o desempenho do grupo XSP.

Durante o processo de logon, o aplicativo Webex também recuperará a URL DMS para baixar seu arquivo de configuração. O host na URL será analisado e o aplicativo Webex executará a busca de DNS A/AAAA do host para conectar ao XSP que hospeda o serviço DMS.

Exemplo: DNS Um registro para descoberta de round-Robin balanceado servidor XSP/Balanceadores de carga pelo aplicativo Webex para baixar arquivos de configuração através de DMS:

Tipo de gravação

Nome

Alvo

Objetivo

A

xsp-dms.example.com

198.51.100.48

Aponta para LB1 (site A)

A

xsp-dms.example.com

198.51.100.49

Aponta para LB2 (site B)

Como o aplicativo Webex localiza endereços XSP

O cliente tenta localizar os nós XSP usando o seguinte fluxo DNS:

  1. O cliente recupera inicialmente URLs de Xsi-Actions/Xsi-Events da Cisco Webex em nuvem (você as Cisco Webex ao criar o grupo de chamada BroadWorks associado). O nome de host/domínio Xsi é analisado da URL e o cliente executa SRV da seguinte forma:

    1. O cliente executa uma SRV de busca _xsi-client._tcp.<xsi domain="">

    2. Se a SRV de dados retornar um ou mais destinos:

      1. O cliente faz uma busca A/AAAA para esses destinos e armazena em cache os endereços de IP retornados.

      2. O cliente se conecta a um dos destinos (e, portanto, seu registro A/AAAA com um único endereço de IP) com base na prioridade de SRV e, em seguida, peso (ou aleatoriamente, se todos são iguais).

    3. Se a SRV de dados não retornar quaisquer destinos:

      O cliente faz uma busca A/AAA do parâmetro raiz Xsi e tenta se conectar ao endereço IP retornado. Isto pode ser um elemento de borda de balanceamento de carga ou pode ser o próprio servidor XSP.

      Como indicado, o registro A/AAAA deve resolver para um endereço de IP pelas mesmas razões.

  2. (Opcional) Você pode fornecer posteriormente detalhes personalizados das XSI-Ações/XSI-Events na configuração do dispositivo para o aplicativo Webex, usando as seguintes tags:

    <protocols>
    	<xsi>
    		<paths>
    			<root>%XSI_ROOT_WXT%</root>
    			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
    			<events>%XSI_EVENTS_PATH_WXT%</events>
    		</paths>
    	</xsi>
    </protocols>
    1. Esses parâmetros de configuração tomarão precedência sobre qualquer configuração no Grupo BroadWorks no Control Hub.

    2. Se eles existirem, o cliente comparará com o endereço XSI original que ele recebeu através da configuração do Grupo BroadWorks.

    3. Se houver alguma diferença detectada, o cliente re inicializará sua conectividade de Eventos XSI/Ações XSI. A primeira etapa nesta é executar o mesmo processo de busca de DNS listado no passo 1 – desta vez solicitando uma busca do valor no parâmetro %XSI_ROOT_WXT% do seu arquivo de configuração.


      Certifique-se de criar os registros de SRV correspondentes se você usar essa tag para alterar as interfaces Xsi.
Failover

Durante o logon, o aplicativo Webex executa uma busca de dns SRV _xsi para um client._tcp-client._tcp. , cria uma lista de hosts e se conecta a um dos hosts com base na prioridade SRV e, em seguida, no<xsi domain="">peso. Este host conectado torna-se o selecionado para todas as solicitações futuras. Um canal de eventos é então aberto ao organizador selecionado e um batimento cardíaco é enviado regularmente para verificar o canal. Todas as solicitações enviadas após o primeiro incluem um cookie que é retornado na resposta HTTP, portanto, é importante que o balanceador de carga mantenha a persistência da sessão (ffinity) e sempre envie solicitações para o mesmo servidor XSP de backend.

Se uma solicitação ou uma solicitação cardíaco para um anfitrião falhar, várias coisas podem acontecer:

  • Se a falha for devido a um erro de rede (ex: TCP, SSL), o aplicativo Webex avançará imediatamente para o próximo host na lista.

  • Se um código de erro (HTTP 5xx) for retornado, a solicitação falhará imediatamente.

  • Se uma resposta não for recebida dentro de um período de tempo, então a solicitação é considerada falhou devido ao tempo e as próximas solicitações são enviadas para o próximo host. No entanto, a solicitação de tempo de saída é considerada como falhou. Algumas solicitações são recuperadas após a falha (com o tempo de tentativa aumentando). As solicitações que o assumido não são vitais não são tentando.

Quando um novo host é tentado com sucesso, ele se torna o novo host selecionado se o host está presente na lista. Depois que o último host na lista for tentado, o aplicativo Webex será recoberta para o primeiro.

No caso do batimento cardíaco, se houver duas falhas consecutivas de solicitação, o aplicativo Webex irá inicializar o canal de eventos de novo.

Observe que o aplicativo Webex não executa fail back e a descoberta do serviço DNS é executada apenas uma vez no início de página.

Durante o registro, o Aplicativo Webex tenta baixar o arquivo de configuração através da interface XSP/Dms. Ele executa uma busca de registro A/AAAA do host na URL DMS recuperada e se conecta ao primeiro IP. Primeiro, ele tentará enviar a solicitação para baixar o arquivo de configuração usando um token SSO sistema. Se isso falhar por algum motivo, ele tentará novamente, mas com o nome de usuário e a senha do dispositivo.