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 Teams
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

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 (https://xchange.broadsoft.com/node/473873)e o Guia de engenharia de sistemas do Cisco Broad W orks ( https://xchange.broadsoft.com/node/422649 ).

  • 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 que os Provedores de Serviços criem o provisionamento de usuários/assinantes em seus fluxos de trabalho existentes.

Marca

Você pode aplicar um logotipo e uma única cor (para a barra de navegação) ao Webex Teams cliente. O portal de ativação do usuário usa as mesmas configurações.

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 de Cliente conforme necessário. Alguns dos parâmetros principais 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 adpaters de provisionamento por empresa, dependendo do seu 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 em seus 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 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 System(https://xchange.broadsoft.com/node/422649) para obter mais 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 aplicativo para suportar Webex Teams como clientes de chamada. Eles são os mesmos arquivos DTAF como usados para SaaS UC-One, no entanto, há um novo arquivo de modelo config-wxt.xml que é usado para o Webex Teams.

Nome do cliente Tipo de perfil do dispositivo e nome do pacote

Webex Teams móvel

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

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

DTAF: ucone-mobile-ucaas_DTAF-#.#.#.##.zip

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

Webex Teams de desktop

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

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

DTAF: ucone-desktop-ucaas_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 Webex Teams suportes para autenticação estão listados em Autoridades de Certificação suportadas para Cisco Webex serviços 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 contra o AuthService

Cisco Webex interage com o Serviço de Autenticação através de TLS mútuo conexão autenticada. Isso significa que o Webex apresenta um certificado de cliente e o XSP deve validá-lo. Para confiar neste certificado, use a cadeia de certificados CA do Webex para criar um âncora de confiança no XSP (ou proxy). A cadeia de certificados está disponível para download via Partner Hub:

  1. Vá para Configurações > chamada BroadWorks.

  2. Clique no link do certificado de download.


Você também pode obter a cadeia de certificados de https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

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 onde a cadeia de certificados ca Webex deve ser implantada nesses três casos.

Requisitos do certificado TLS mútuo para Proxy de ponte TLS

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

  • A cadeia de certificados CA do Webex é implantada no proxy trust store, assim o proxy confia no certificado do cliente.

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

  • O proxy apresenta um 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.:

    Extensões X509v3:

    Uso da chave estendida X509v3:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticação do Cliente Web TLS 

    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.

  • Os XSPs confiam na CA interna.

  • Os XSPs apresentam um certificado de servidor assinado internamente.

  • O proxy confia na CA interna.

Requisitos do certificado TLS mútuo para proxy TLS-pass securário ou XSP no DMZ

  • O Webex apresenta um certificado de cliente assinado pelo Webex CA para os XSPs.

  • A cadeia de certificados ca Webex é implantada no armazenamento de confiança do XSPs, assim os XSPs confiam no certificado do cliente.

  • O certificado de servidor XSP assinado publicamente também é 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.:

    Extensões X509v3:
        Uso da chave estendida X509v3:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticação do Cliente Web TLS

    • 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 para o 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 pelo Webex para BroadWorks estão descritas nas tabelas a seguir.

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

Configuração do 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 Teams 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

Webex Teams do cliente

Xsi/DMS

Any

HTTPS

Seu XSP

443

Webex Teams VoIP terminais SIP

Any

SIP

Seu SBC

SP configurado TCP

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

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-provisioning-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

Webex Teams do cliente   

Xsi/DMS

Any

HTTPS

Seu XSP

443

Webex Teams VoIP terminais SIP

Any

SIP

Seu SBC

SP configurado TCP

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

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

CONFIGURAÇÃO DNS

O Webex para clientes BroadWorks deve ser capaz de encontrar o(s) servidor(s) BroadWorks XSP para autenticação, autorização, controle de chamada e gerenciamento de dispositivos.

A nuvem Webex deve ser capaz de encontrar seu(s) servidor(s) BroadWorks XSP para conectar-se a interfaces Xsi e serviço de autenticação.

Você pode precisar gravar várias entradas DNS se você tiver diferentes servidores XSP para diferentes finalidades.


Recomendamos fortemente que você configure SRV de registro para resolver os XSPs que você usa com o Webex para BroadWorks. Usar apenas registros A/AAAA provoca tráfego interno desnecessário entre os XSPs, reduzindo o desempenho.

Como Cisco Webex nuvem encontre endereços XSP

Cisco Webex em Nuvem executarão a buscar DNS A/AAAA 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, a entrada inicial na lista será selecionada.

Exemplos 2 e 3 abaixo capturam os registros A/AAAA mapeando para endereços ip individuais e múltiplos, respectivamente.

No cenário múltiplos Endereços de IP, recomendamos que você configure as entradas DNS para girar em uma forma de rodízio, para distribuir as conexões do cliente do Webex.

Como os clientes encontram 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 de client._tcp.<xsi domain="">

      (Veja o exemplo a seguir 1)

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

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

      O cliente se conecta à porta SRV em um dos endereços IP retornados. Ele escolhe um endereço baseado na prioridade 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.

      (Veja os exemplos a seguir 2 e 3)

  2. (Opcional) Você pode subsequentemente fornecer detalhes personalizados de XSI-Ações/XSI-Events na confguração de dispositivo para o cliente Webex Teams, 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 XSI Actions/XSI Events. A primeira etapa é executar o mesmo processo de busca de DNS listado no passo 1 - desta vez usando o parâmetro %XSI_ROOT_WXT% do arquivo de configuração.


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

Exemplo de registros DNS

Tabela 1. Exemplo 1: Registros SRV DNS para descoberta de clientes de várias internets voltadas para servidores XSP

Tipo de gravação

Gravar

Alvo

Objetivo

SRV

_xsi-client._tcp.seu xsp.example.com.

xsp01.example.com

Descoberta de cliente da interface Xsi

SRV

_xsi-client._tcp.seu xsp.example.com.

xsp02.example.com

Descoberta de cliente da interface Xsi

A

xsp01.example.com.

198.51.100.48

Procurar IP XSP

A

xsp02.example.com.

198.51.100.49

Procurar IP XSP

Tabela 2. Exemplo 2: Dns Um Registro para descoberta do pool do servidor XSP de balanceador de carga fronting

Tipo de gravação

Nome

Alvo

Objetivo

A

your-xsp.example.com.

198.51.100.50

Procurar IP de balanceador de carga de borda

Tabela 3. Exemplo 3: Dns Um registro para descoberta do pool de servidores XSP balanceado de Round-Robin

Tipo de gravação

Nome

Alvo

Objetivo

A

your-xsp.example.com.

198.51.100.48

Procurar IP XSP

A

your-xsp.example.com.

198.51.100.49

Procurar IP XSP

Recomendações DNS de nós XSP

  • Você deve usar um único registro A/AAA:

    • se você precisar resolver um proxy reverso de balanceamento de carga para os servidores XSP

  • Você deve usar gravações round-robin A/AAAA:

    •  se você tiver várias internets voltadas para servidores XSP

  • Você deve usar a Descoberta do Serviço DNS se você:

    • É necessário pesquisar diretórios em ambientes com vários XSPs.

    • Tenha integrações pré-existentes que exigem SRV descoberta.

    • Possuem configurações exclusivas em que os registros A/AAA padrão são insuficientes.