Preparar su entorno

Puntos de decisión

Consideración Preguntas para responder Recursos

Arquitectura e infraestructura

¿Cuántos XSP?

¿Cómo toman mTLS?

Planificador de capacidad del sistema Cisco BroadWorks

Guía de ingeniería del sistema Cisco BroadWorks

Referencia XSP CLI

Este documento

Aprovisionamiento de clientes y usuarios

¿Puede aserer que confía en los correos electrónicos en BroadWorks?

¿Desea que los usuarios proporcionen direcciones de correo electrónico para activar sus propias cuentas?

¿Puede crear herramientas para utilizar nuestra API?

Documentos de API públicas en https://developer.webex.com

Este documento

Imagen de marca ¿Qué color y logotipo desea utilizar? Artículo de marca de Teams
Plantillas ¿Cuáles son sus diferentes casos de uso de clientes? Este documento
Características del suscriptor por cliente/empresa/grupo Elija el paquete para definir el nivel de servicio por plantilla. Básica, Estándar, Premium

Este documento

Matriz de características/paquetes

Autenticación de usuario BroadWorks o Webex Este documento
Adaptador de aprovisionamiento (para opciones de aprovisionamiento de flujo)

¿Ya utiliza IM&P integrado, por ejemplo, para SaaS UC-One?

¿Desea utilizar varias plantillas?

¿Hay más casos de uso comunes anticipados?

Este documento

Referencia CLI del servidor de aplicaciones

Arquitectura e infraestructura

  • ¿Con qué tipo de escala desea iniciar? Es posible escalar en el futuro, pero la estimación del uso actual debería impulsar la planificación de la infraestructura.

  • Trabaje con su gerente de cuentas/representante de ventas de Cisco para tamaño de su infraestructura XSP, según el Planificador de capacidades del sistema Cisco BroadWorks (https://xchange.broadsoft.com/node/473873 ) y la Guía de ingeniería del sistema CiscoBroad Works ( https://xchange.broadsoft.com/node/422649).

  • ¿Cómo Cisco Webex conexiones de TLS mutuo a sus XSP? ¿Directamente al XSP en una DMZ o a través del proxy TLS? Esto afecta a sus administración de certificados pantalla y a las direcciones URL que utiliza para las interfaces. (No son compatibles con conexiones TCP no cifradas en el borde de su red).

Aprovisionamiento de clientes y usuarios

¿Cuál es el método de aprovisionamiento de usuarios que mejor se ajusta a usted?

  • Aprovisionamiento de flujo con correos electrónicosconfiables: Al asignar el servicio "IM&P integrado" en BroadWorks, el suscriptor es aprovisionado automáticamente en Cisco Webex.

    Si también puede aserer que las direcciones de correo electrónico del suscriptor de BroadWorks son válidas y son únicas para Webex, puede utilizar la jerarquía de "correo electrónico de confianza" del aprovisionamiento de flujo. Las cuentas del suscriptor de Webex se crean y se activan sin su intervención; simplemente descarguen el cliente e inicien sesión.

    Dirección de correo electrónico es un atributo de usuario clave en Cisco Webex. Por lo tanto, Proveedor de servicios debe proporcionar una dirección de correo electrónico válida para el usuario a fin de aprovisionarlos para Cisco Webex válidos. Debe estar en el atributo de ID de correo electrónico del usuario en BroadWorks. Le recomendamos que también la copie en el atributo ID alternativo.

  • Aprovisionamiento de flujo sin correos electrónicos deconfianza: Si no puede confiar en las direcciones de correo electrónico del suscriptor, aún puede asignar el servicio de IM&P integrado en BroadWorks para aprovisionar a los usuarios en Webex.

    Con esta opción, las cuentas se crean cuando usted asigna el servicio, pero los suscriptores deben proporcionar y validar sus direcciones de correo electrónico para activar las cuentas de Webex.

  • Aprovisionamiento automático deusuarios: Esta opción no requiere la asignación de servicios de IM&P en BroadWorks. En su lugar, usted (o los clientes) distribuyen un enlace de aprovisionamiento, y los enlaces para descargar a los diferentes clientes con su imagen de marca e instrucciones.

    Los suscriptores siguen el enlace, y luego suministran y validan sus direcciones de correo electrónico para crear y activar sus cuentas de Webex. Luego descargan el cliente e inician sesión, y Webex obtiene cierta configuración adicional sobre él desde BroadWorks (incluidos los números principales).

  • Aprovisionamiento controlado por SP a través deAPI: Cisco Webex un conjunto de API públicas que permiten a los proveedores de servicios generar aprovisionamiento de usuarios/suscriptores en sus flujos de trabajo existentes.

Imagen de marca

Puede aplicar un logotipo y un solo color (para los barra de navegación) al Webex Teams cliente. El portal de activación de usuarios utiliza la misma configuración.

Plantillas del cliente

Las plantillas de clientes le permiten definir los parámetros mediante los cuales se aprovisionan automáticamente los clientes y los suscriptores asociados en Cisco Webex para BroadWorks. Puede configurar varias plantillas de clientes según sea necesario. Algunos de los parámetros primarios se enumeran a continuación.

Paquete

  • Debe seleccionar un paquete predeterminado cuando cree una plantilla (consulte Paquetes en la sección Descripción general para obtener más detalles). Todos los usuarios que se aprovisionan con esa plantilla, ya sea mediante el paso de flujo o el aprovisionamiento automático, reciben el paquete predeterminado.

  • Puede tener control sobre la selección del paquete para diferentes clientes mediante la creación de varias plantillas y la selección de diferentes paquetes predeterminados en cada una. Luego puede distribuir diferentes enlaces de aprovisionamiento, o diferentes adpaters de aprovisionamiento por empresa, según el método de suministro de usuarios elegido para esas plantillas.

  • Puede cambiar el paquete de suscriptores específicos de esta configuración predeterminada mediante la API de aprovisionamiento (consulte Integración con Webex para la API de aprovisionamiento de BroadWorks en la sección de Referencia) o a través del Concentrador de socios.

  • No puede cambiar el paquete de un suscriptor desde BroadWorks. La asignación del servicio de IM&P integrada está lista o desactivada; si el suscriptor tiene asignado este servicio en BroadWorks, la plantilla del Concentrador de socios asociada con la URL de aprovisionamiento de la empresa del suscriptor define el paquete.

¿Revendedores y empresariales Proveedor de servicios grupos y proveedores?

  • La forma en que se configura su sistema BroadWorks tiene un impacto en el flujo a través del aprovisionamiento. Si es revendedor de Empresas, tiene que habilitar el modo Empresarial al crear una plantilla.
  • Si su sistema broadWorks está configurado en Proveedor de servicios de mantenimiento, puede dejar el modo Empresarial desactivado en sus plantillas.
  • Si planea aprovisionar organizaciones de clientes mediante ambos modos de BroadWorks, debe utilizar diferentes plantillas para grupos y empresas.

Modo de autenticación

¿Cómo autenticarán los suscriptores de los clientes?

Modo de autenticación BroadWorks Webex
Identidad del usuario principal BroadWorks ID de usuario Dirección de correo electrónico
Proveedor de identidad

BroadWorks.

La autenticación es facilitada por un servicio intermedio alojado por el Cisco Webex.

Cisco Common Identity
¿Autenticación de varios factores? No Requiere IdP de cliente que admita autenticación de varios factores.

Ruta de validación de credenciales

  1. Se inicia el explorador donde el usuario provee el correo electrónico para el flujo de conexión inicial y descubre su modo de autenticación.

  2. Luego, el navegador se redirige a una Cisco Webex inicio de sesión de BroadWorks alojada (esta página es personalizada)

  3. El usuario proporciona el ID de usuario y la contraseña de BroadWorks en la página de inicio de sesión.

  4. Las credenciales del usuario se validan con BroadWorks.

  5. Al tener éxito, se obtiene un código de autorización de Cisco Webex. Esto se utiliza para obtener los tokens de acceso necesarios para Cisco Webex de .

  1. Se inicia el explorador donde el usuario provee el correo electrónico para el flujo de conexión inicial y descubre su modo de autenticación.

  2. El explorador es redireccionado al IdP (ya sea Cisco Common Identity o IdP de cliente) donde se les presentará un portal de inicio de sesión.

  3. El usuario proporciona las credenciales adecuadas en la página de inicio de sesión

  4. La autenticación de varios factores puede tener lugar si el IdP del cliente lo admite.

  5. Al tener éxito, se obtiene un código de autorización de Cisco Webex. Esto se utiliza para obtener los tokens de acceso necesarios para Cisco Webex de .

Acuerdos para varios socios

¿Va a suscribirse a una sub licencia de Webex para BroadWorks a otro proveedor de servicios? En este caso, cada proveedor de servicios necesitará una organización de socio distinta en Webex Control Hub que les permita aprovisionar la solución para su base de clientes.

Adaptador y plantillas de aprovisionamiento

Cuando utiliza el aprovisionamiento de flujo, la URL de aprovisionamiento que introduzca en BroadWorks se deriva de la plantilla en Control Hub. Puede tener varias plantillas y, por lo tanto, varias URL de aprovisionamiento. Esto le permite seleccionar, empresa por empresa, qué paquete se aplicará a los suscriptores cuando se les otorgue el servicio de IM&P integrado.

Tiene que considerar si quiere establecer una URL de aprovisionamiento a nivel del sistema como una ruta de aprovisionamiento predeterminada y qué plantilla desea utilizar para eso. De esta manera, solo tiene que configurar explícitamente la URL de aprovisionamiento para aquellas empresas que necesitan una plantilla diferente.

Además, tenga en cuenta que es posible que ya esté usando una URL de aprovisionamiento a nivel de sistema, por ejemplo con SaaS para UC-One. Si ese es el caso, puede optar por conservar la URL del nivel del sistema para aprovisionar usuarios en SaaS de UC-One, y anular para las empresas que se trasladan a Webex para BroadWorks. Como alternativa, es posible que quiera ir al otro lado y configurar la URL del nivel del sistema para Webex para BroadWorks, y reconfigurar aquellas empresas que desea conservar en SaaS para UC-One.

Las opciones de configuración relacionadas con esta decisión se detallan en configurar el servidor de aplicaciones con la URL del servicio de aprovisionamiento en la sección Implementar Webex para BroadWorks.

Requisitos mínimos

Cuenta

Todos los suscriptores que aprovisionamiento para Webex deben existir en el sistema de BroadWorks que integre con Webex. Puede integrar varios sistemas de BroadWorks si es necesario.

Todos los suscriptores deben tener licencias de BroadWorks y números principales.

Webex utiliza direcciones de correo electrónico como identificadores principales para todos los usuarios. Si está utilizando el aprovisionamiento de flujo con correos electrónicos de confianza, sus usuarios deben tener direcciones válidas en el atributo de correo electrónico de BroadWorks.

Si en su plantilla se utiliza la autenticación de BroadWorks, puede copiar las direcciones de correo electrónico del suscriptor en el atributo de ID alternativo en BroadWorks. Esto permite que los usuarios inicien sesión en Webex utilizando sus direcciones de correo electrónico y sus contraseñas de BroadWorks.

Sus administradores deben usar sus cuentas de Webex para iniciar sesión en el concentrador de socios.

Requisitos de red y software de los servidores

  • Instancia(s) de BroadWorks con la versión mínima R21 SP1. Consulte Requisitos del software de BroadWorks (en este documento) para ver las versiones y revisiones compatibles. Consulte también Administración del ciclo de vida : Servidores de BroadSoft.


    R21 SP1 solo es compatible hasta mediados de 2021. Aunque actualmente puede integrar Webex con R21 SP1, recomendamos encarecidamente R22 o versiones posteriores para la integración con Webex.

  • Las instancias de BroadWorks deben incluir al menos los siguientes servidores:

    • El servidor de aplicaciones (AS) con la versión de BroadWorks tal como se mencionó

    • Servidor de red (NS)

    • Servidor de perfiles (PS)

  • Servidor(s) XSP o plataforma de entrega de aplicaciones (ADP) orientadas al público cumplen con los siguientes requisitos:

    • Servicio de autenticación (autenticación BW)

    • Interfaces de eventos y acciones de XSI

    • DMS (aplicación web de administración de dispositivos)

    • Interfaz CTI (integración de telefonía informática)

    • TLS 1.2 con un certificado válido (no de firma propia) y cualquier paso intermedio requerido. Requiere administración del nivel del sistema para facilitar la búsqueda empresarial.

    • Autenticación TLS mutua (mTLS) para el servicio de autenticación (requiere que la cadena de certificados del cliente de Cisco Webex pública se instale como anclajes de confianza)

    • Autenticación TLS mutua (mTLS) para la interfaz CTI (requiere que la cadena de certificados del cliente de Cisco Webex pública se instale como anclajes de confianza)

  • Un servidor XSP/ADP separado que actúa como un "Servidor de push de notificaciones de llamadas" (un NPS en su entorno utilizado para enviar notificaciones de llamadas a Apple/Google. Aquí lo llamamos "CNPS" para distinguirlo del servicio de Webex que ofrece notificaciones emergentes de mensajería y presencia.

    Este servidor debe estar en R22 o posterior.

  • Recomendamos un servidor XSP/ADP separado para CNPS debido a que la falta de disponibilidad de la carga de Webex para las conexiones de nube de BWKS podría afectar de manera negativa el rendimiento del servidor NPS, con el resultado de un aumento de la latencia de las notificaciones. Consulte la Guía de ingeniería del sistema Cisco BroadWorks(https://xchange.broadsoft.com/node/422649) para obtener más información sobre la escala de XSP.

Teléfonos físicos y accesorios

Perfiles de dispositivos

Estos son los archivos DTAF que necesita cargar en sus servidores de aplicaciones para admitir Webex Teams de llamadas. Son los mismos archivos DTAF que se utilizan para SaaS con UC-One. Sin embargo, hay un nuevo archivo config-wxt.xml.template que se utiliza para las Webex Teams.

Nombre del cliente Tipo de perfil y nombre del paquete del dispositivo

Webex Teams plantilla móvil

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

Identidad/Tipo de perfil del dispositivo: Conectar - Móvil

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

Archivo de configuración: config-wxt.xml

Webex Teams plantilla de escritorio

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

Identidad/Tipo de perfil del dispositivo: Business Communicator - PC

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

Archivo de configuración: config-wxt.xml

Solicitar certificados

Requisitos del certificado para la autenticación TLS

Necesitará certificados de seguridad, firmados por una autoridad de certificación conocida e implementados en su Zona XSP orientadas al público para todas las aplicaciones necesarias. Estos se utilizarán para admitir la verificación del certificado TLS para toda la conectividad entrante a sus servidores de XSP.

Estos certificados deben incluir su nombre público de XSP nombre de dominio completamente calificado como Nombre común del sujeto o Nombre alternativo del sujeto.

Los requisitos exactos para implementar estos certificados de servidor dependen de cómo se implementen sus XSP orientadas al público:

  • A través de un proxy de conexión TLS

  • A través de un proxy de transferencia TLS

  • Directamente al XSP

El siguiente diagrama resume el lugar en el que se debe cargar el certificado de servidor público firmado por una CA en estos tres casos:

Las CA admitidas públicamente que Webex Teams para la autenticación están listadas en Autoridades de certificados admitidas para Cisco Webex Servicios híbridos de.

Requisitos del certificado TLS para el proxy tls bridge

  • El certificado del servidor firmado públicamente se carga en el proxy.

  • El proxy debe presentar este certificado de servidor firmado públicamente en Webex.

  • Webex confía en la CA pública que firmó el certificado del servidor del proxy.

  • Se puede cargar un certificado firmado de CA interno en el XSP.

  • El XSP presenta este certificado de servidor firmado internamente al proxy.

  • El proxy confía en la CA interna que firmó el certificado del servidor XSP.

Requisitos del certificado TLS para el proxy de paso TLS o XSP en DMZ

  • El certificado del servidor firmado públicamente se carga en los XSP.

  • Los XSP presentan certificados de servidor firmados públicamente en Webex.

  • Webex confía en la CA pública que firmó los certificados del servidor de los XSP.

Requisitos adicionales de certificados para la autenticación de TLS mutuo contra AuthService

Cisco Webex interactúa con el servicio de autenticación a través de TLS mutuo conexión autenticada. Esto significa que Webex debe presentar un certificado de cliente y el XSP debe validarlo. Para confiar en este certificado, utilice la cadena de certificados de CA de Webex para crear un anclaje de confianza en XSP (o proxy). La cadena de certificados está disponible para descargar a través del Concentrador de socios:

  1. Vaya a Configuración > Llamadas de BroadWorks.

  2. Haga clic en el enlace para descargar el certificado.


También puede obtener la cadena de certificados de https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt.

Los requisitos exactos para implementar esta cadena de certificados de Ca de Webex dependen de cómo se implementen sus servidores XSP de cara al público:

  • A través de un proxy de conexión TLS

  • A través de un proxy de transferencia TLS

  • Directamente al XSP

El siguiente diagrama resume el lugar en el que debe implementarse la cadena de certificados de CA de Webex en estos tres casos.

Requisitos del certificado de TLS mutuo para el proxy del puente TLS

  • Webex presenta un certificado de cliente firmado por una CA de Webex al proxy.

  • La cadena de certificados de CA de Webex se implementa en el almacén de confianza del proxy, de modo que el proxy confía en el certificado del cliente.

  • El certificado del servidor XSP firmado públicamente también se carga en el proxy.

  • El proxy debe presentar un certificado de servidor firmado públicamente en Webex.

  • Webex confía en la CA pública que firmó el certificado del servidor del proxy.

  • El proxy presenta un certificado de cliente firmado internamente a los XSP.

    Este certificado debe tener el campo de extensión x509.v3 Extended Key Usage completo con el BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3y el propósito de la autenticación de cliente TLS. E.g.:

    Extensiones X509v3:

    Uso de la clave extendida X509v3:

    1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticación de cliente web TLS 

    Al generar certificados de clientes internos para el proxy, tenga en cuenta que los certificados SAN no son compatibles. Los certificados internos del servidor para el XSP pueden ser SAN.

  • Los XSP confían en la CA interna.

  • Los XSP presentan un certificado de servidor firmado internamente.

  • El proxy confía en la CA interna.

Requisitos del certificado de TLS mutuo para el proxy de paso tls o XSP en DMZ

  • Webex presenta un certificado de cliente firmado de CA de Webex a los XSP.

  • La cadena de certificados de CA de Webex se implementa en el almacén de confianza de XSP, de modo que los XSP confían en el certificado del cliente.

  • El certificado del servidor XSP firmado públicamente también se carga en los XSP.

  • Los XSP presentan certificados de servidor firmados públicamente en Webex.

  • Webex confía en la CA pública que firmó los certificados del servidor de los XSP.

Requisitos adicionales de certificados para la autenticación de TLS mutuo a través de la interfaz CTI

Al conectarse a la interfaz CTI, Cisco Webex certificado de cliente como parte de la autenticación de TLS mutuo. El certificado ca/certificado de cadena de certificado del cliente de Webex está disponible para descargar a través de Control Hub.

Para descargar el certificado:

Inicie sesión en el Partner Hub, seleccione Configuración > Llamadas de BroadWorks y haga clic en el enlace para descargar el certificado.

Los requisitos exactos para implementar esta cadena de certificados de Ca de Webex dependen de cómo se implementen sus servidores XSP de cara al público:

  • A través de un proxy de conexión TLS

  • A través de un proxy de transferencia TLS

  • Directamente al XSP

El siguiente diagrama resume los requisitos del certificado en estos tres casos:

Figura 1. Exchange de certificados mTLS para CTI a través de diferentes configuraciones de Edge

(Opción) Requisitos de certificados para el proxy del puente TLS

  • Webex presenta un certificado de cliente firmado públicamente al proxy.

  • El proxy confía en la CA interna de Cisco que firmó el certificado del cliente. Puede descargar esta CA/cadena desde el Concentrador de control y agregarla al almacén de confianza del proxy. El certificado del servidor XSP firmado públicamente también se carga en el proxy.

  • El proxy debe presentar el certificado de servidor firmado públicamente en Webex.

  • Webex confía en la CA pública que firmó el certificado del servidor del proxy.

  • El proxy presenta un certificado de cliente firmado internamente a los XSP.

    Este certificado debe tener el campo de extensión x509.v3 Extended Key Usage completo con el BroadWorks OID 1.3.6.1.4.1.6431.1.1.8.2.1.3 y el propósito de la autenticación de cliente TLS. E.g.:

    Extensiones X509v3:
        Uso de la clave extendida X509v3:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, Autenticación de cliente web TLS

    • Al generar certificados de clientes internos para el proxy, tenga en cuenta que los certificados SAN no son compatibles. Los certificados internos del servidor para el XSP pueden ser SAN.

    • Es posible que las autoridades de certificados públicas no estén dispuestos a firmar certificados con el OID de propiedad de BroadWorks que se requiere. En el caso de un proxy de conexión, es posible que esté obligado a usar una CA interna para firmar el certificado de cliente que el proxy debe presentar al XSP.

  • Los XSP confían en la CA interna.

  • Los XSP presentan un certificado de servidor firmado internamente.

  • El proxy confía en la CA interna.

  • ClientIdentity del servidor de aplicaciones contiene el nombre común del certificado del cliente firmado internamente presentado al XSP por el proxy.

(Opción) Requisitos del certificado para el proxy de paso TLS o XSP en DMZ

  • Webex presenta un certificado de cliente interno firmado por una CA de Cisco a los XSP.

  • Los XSP confían en la CA interna de Cisco que firmó el certificado del cliente. Puede descargar esta CA/cadena desde el Concentrador de control y agregarla al almacén de confianza del proxy. El certificado del servidor XSP firmado públicamente también se carga en los XSP.

  • Los XSP presentan los certificados de servidor firmados públicamente a Webex.

  • Webex confía en la CA pública que firmó los certificados del servidor de los XSP.

  • El ClientIdentity del servidor de aplicaciones contiene el nombre común del certificado de cliente firmado por Cisco presentado al XSP por Webex.

Preparar su red

Mapa de conexión

En el siguiente diagrama se ilustran los puntos de integración. El punto del diagrama es mostrar que debe revisar las IP y los puertos para las conexiones hacia y fuera de su entorno. Las conexiones que utiliza Webex para BroadWorks se describen en las siguientes tablas.

Sin embargo, los requisitos del firewall para el funcionamiento normal de la aplicación cliente están enumerados como referencias, ya que ya están documentados en help.webex.com.

Configuración del firewall

En la asignación de conexiones y en las siguientes tablas se describen las conexiones y protocolos requeridos entre los clientes (conectados o desactivados a la red del cliente), su red y la plataforma de Webex.

Solo documentemos las conexiones específicas de Webex para BroadWorks. No mostramos las conexiones genéricas entre Teams y la nube de Webex, que se documentan en:

Reglas de entrada de EMEA

(Dentro de la red)

Propósito Origen Protocolo Destino Puerto de destino

WebexCloud

CTI/Autenticación/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

Su XSP

TCP/TLS 8012

443

Webex Teams aplicación del cliente

Xsi/DMS

Cualquiera

HTTPS

Su XSP

443

Webex Teams VoIP extremos SIP

Cualquiera

SIP

Su SBC

SP configuró TCP

Reglas de salida de EMEA

(Fuera de la red)

Propósito

Origen

Protocolo

Destino

Puerto de destino

Aprovisionamiento de usuarios a través de API

Su servidor de aplicaciones

HTTPS

webexapis.com

443

Notificaciones de push de proxy (servicio de producción)

Su servidor NPS

HTTPS

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

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

443

Webex Common Identity

Su servidor NPS

HTTPS

https://idbroker-eu.webex.com

443

Servicios APNS y FCM

Su servidor NPS

HTTPS

Cualquier dirección IP*

443

Notificaciones de push de proxy (servicio de producción)

Webex Common Identity

Servicios APNS y FCM

Su servidor NPS

HTTPS

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

https://idbroker-eu.webex.com

Cualquier dirección IP*

443

Aprovisionamiento de usuarios a través del adaptador de aprovisionamiento BroadWorks

Su BroadWorks AS

HTTPS

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

(donde * podría ser cualquier letra. Su URL exacta de aprovisionamiento está disponible en la plantilla que cree en el Concentrador de socios)

443

† Estos rangos contienen los organizadores para el proxy de NPS, pero no podemos proporcionar las direcciones exactas. Los rangos también pueden contener organizadores que no se relacionan con Webex para BroadWorks. Le recomendamos que configure su firewall para que permita el tráfico al proxy de NPS FQDN en su lugar, para asegurarse de que su salida solo sea hacia los hosts a los que exponemos para el proxy de NPS.

* APNS y FCM no tienen un conjunto establecido de direcciones IP.

Reglas de entrada de EE. UU.

(Dentro de la red)

Propósito

Origen

Protocolo

Destino

Puerto de destino

WebexCloud

CTI/Autenticación/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

Su XSP

TCP/TLS 8012

TLS 443

Webex Teams aplicación del cliente   

Xsi/DMS

Cualquiera

HTTPS

Su XSP

443

Webex Teams VoIP extremos SIP

Cualquiera

SIP

Su SBC

SP configuró TCP

Reglas de salida de EE. UU.

(Fuera de la red)

Propósito

Origen

Protocolo

Destino

Puerto de destino

Aprovisionamiento de usuarios a través de API

Su servidor de aplicaciones

HTTPS

webexapis.com

443

Notificaciones de push de proxy (servicio de producción)

Su servidor NPS

HTTPS

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

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

443

Webex Common Identity

Su servidor NPS

HTTPS

https://idbroker.webex.com

443

Servicios APNS y FCM

Su servidor NPS

HTTPS

Cualquier dirección IP*

443

Aprovisionamiento del usuario a través del adaptador de aprovisionamiento BWKS

Su BroadWorks AS

HTTPS

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

(donde * podría ser cualquier letra. Su URL exacta de aprovisionamiento está disponible en la plantilla que cree en el Concentrador de socios)

443

† Estos rangos contienen los organizadores para el proxy de NPS, pero no podemos proporcionar las direcciones exactas. Los rangos también pueden contener organizadores que no se relacionan con Webex para BroadWorks. Le recomendamos que configure su firewall para que permita el tráfico al proxy de NPS FQDN en su lugar, para asegurarse de que su salida solo sea hacia los hosts a los que exponemos para el proxy de NPS.

* APNS y FCM no tienen un conjunto establecido de direcciones IP.

Configuración de DNS

Los clientes de BroadWorks deben poder encontrar sus servidores de BroadWorks XSP para la autenticación, la autorización, el control de llamadas y la administración de dispositivos.

La nube de Webex debe poder encontrar su(s) servidor(s) de BroadWorks XSP para conectarse a las interfaces de Xsi y al servicio de autenticación.

Es posible que necesite grabar varias entradas de DNS si tiene servidores XSP diferentes para diferentes propósitos.


Le recomendamos encarecidamente que configure registros SRV para resolver los XSP que utiliza con Webex para BroadWorks. El uso de solo registros A/AAAA provoca un tráfico interno innecesario entre sus XSP, lo que reduce el rendimiento.

Cómo Cisco Webex nube encuentra direcciones XSP

Cisco Webex servicios de la nube realizarán la búsqueda A/AAAA de DNS del nombre de host XSP configurado y se conectará a la dirección IP devuelta. Podría ser un elemento del borde del nivelador de carga, o podría ser el mismo servidor XSP. Si se devuelven varias direcciones IP, se seleccionará la entrada inicial en la lista.

Los ejemplos 2 y 3 a continuación capturan la asignación de registros A/AAAA a direcciones IP únicas y múltiples respectivamente.

En la situación de varias direcciones IP, le recomendamos que configure las entradas de DNS para rotar en forma rotativa, para distribuir las conexiones de clientes desde Webex.

Cómo encuentran los clientes direcciones XSP

El cliente intenta localizar los nodos XSP utilizando el siguiente flujo DNS:

  1. El cliente recupera inicialmente las URL de Xsi-Actions/Xsi-Events de Cisco Webex nube (las introdujo al crear el grupo de llamadas de BroadWorks asociado). El nombre de host/dominio Xsi se analiza a partir de la URL y el cliente realiza SRV búsqueda como se muestra a continuación:

    1. El cliente realiza una SRV búsqueda directa para _xsi que client._tcp.<xsi domain="">

      (Consulte el siguiente ejemplo 1)

    2. Si la SRV búsqueda de datos devuelve uno o más objetivos:

      El cliente realiza una búsqueda de A/AAAA para esos objetivos y almacena las direcciones IP devueltas en el caché.

      El cliente se conecta al puerto SRV en una de las direcciones IP devueltas. Elige una dirección en función de la prioridad de SRV número, luego el peso (o al azar si todos son iguales).

    3. Si la SRV búsqueda rápida no devuelve ningún objetivo:

      El cliente realiza una búsqueda A/AAAA del parámetro raíz de Xsi y luego intenta conectarse a la dirección IP devuelta. Podría ser un elemento del borde del nivelador de carga, o podría ser el mismo servidor XSP.

      (Consulte los siguientes ejemplos 2 y 3)

  2. (Opcional) Posteriormente, puede proporcionar detalles de XSI-Actions/XSI-Events personalizados en la confguración del dispositivo para el cliente Webex Teams, usando las siguientes etiquetas:

    
    <protocols>
        <xsi>
            <paths>
                <root>%XSI_ROOT_WXT%</root>             <actions>%XSI_ACTIONS_PATH_WXT%</actions>             <events>%XSI_EVENTS_PATH_WXT%</events>
            </paths>
        </xsi>
    </protocols>
    1. Estos parámetros de configuración tienen precedencia sobre cualquier configuración en su grupo de BroadWorks en el Concentrador de control.

    2. Si existen, el cliente se comparará con la dirección XSI original que recibió a través de la configuración del grupo de BroadWorks.

    3. Si se detecta alguna diferencia, el cliente lo inicializará de nuevo en Acciones de XSI/Conectividad de XSI Events. El primer paso de esto es realizar el mismo proceso de búsqueda de DNS listado en el paso 1: esta vez se utiliza el parámetro %XSI_ROOT_WXT% del archivo de configuración.


      Asegúrese de crear los registros de SRV correspondientes si utiliza esta etiqueta para cambiar las interfaces Xsi.

Registros de DNS de ejemplo

Tabla 1. Ejemplo 1: Dns SRV registros para la detección de clientes de varios servidores XSP de Internet frontales

Tipo de grabación

Grabar

Destino

Propósito

SRV

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

xsp01.example.com

Detección de cliente de la interfaz Xsi

SRV

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

xsp02.example.com

Detección de cliente de la interfaz Xsi

A

xsp01.example.com.

198.51.100.48

Búsqueda de IP de XSP

A

xsp02.example.com.

198.51.100.49

Búsqueda de IP de XSP

Tabla 2. Ejemplo 2: Registro de DNS A para la detección del equilibrio de carga frente al pool de servidores XSP

Tipo de grabación

Nombre

Destino

Propósito

A

your-xsp.example.com.

198.51.100.50

Búsqueda de IP del equilibrio de carga de límite

Tabla 3. Ejemplo 3: DNS A Registro para la detección de pool de servidores XSP de Internet con equilibrio entre ida y vuelta

Tipo de grabación

Nombre

Destino

Propósito

A

your-xsp.example.com.

198.51.100.48

Búsqueda de IP de XSP

A

your-xsp.example.com.

198.51.100.49

Búsqueda de IP de XSP

Recomendaciones de DNS de nodos XSP

  • Debe usar un solo registro A/AAAA:

    • si necesita resolver un proxy inverso de nivelador de carga a los servidores XSP

  • Debe usar registros A/AAAA de turno completo:

    •  si tiene varios servidores de XSP orientadas a Internet

  • Debe utilizar la Detección de servicios de DNS si:

    • Se necesita una búsqueda de directorio en entornos con varios XSP.

    • Tenga integraciones preexistentes que requieran SRV detección automática.

    • Tenga configuraciones únicas cuando los registros A/AAAA estándares no sean suficientes.