Gracias por sus comentarios.

Consideremos un socio hipotético de Webex llamado TelSP para ilustrar los diferentes modelos de implementaciones que el socio puede adoptar.

Aquí están las especificaciones y requisitos de alto nivel de TelSP:

• El socio planea usar sip.telsp.com como el dominio de nivel superior que se comparte con todos los clientes que administra.

• El socio es propietario de sip.telsp.com y puede administrar la infraestructura DNS y las autoridades de certificación, administrar direcciones DNS y firmar certificados para este dominio y sus subdominios.

• El socio puede implementar dos controladores de borde de sesión distintos (físicos o virtuales) como puertas de enlace locales para el acceso PSTN compartido entre los clientes finales.

• El socio tiene dos sitios físicos, y ambos sitios comparten conectividad PSTN:

  • Miami

  • Chicago

• TelSP opera sus puertas de enlace locales en nombre de los dos clientes CuSTa y CustB, como se les denomina aquí.

El escenario deseado es tener la originación/terminación de PSTN para ambos clientes que utilizan las puertas de enlace de Miami y Chicago suministradas por el socio, como se muestra en la ilustración:

Ejemplo de implementación simplificada

El siguiente ejemplo simplificado demuestra cómo la identidad de certificados de pares permite que un solo certificado admita múltiples enlaces troncales de clientes:

• Certificado —sip.telsp.com

• Troncos

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Identidad de certificación de pares —sip.telsp.com

• Resultado

  • Se utiliza un solo certificado

  • Se admiten múltiples troncales para clientes

Asociar la ubicación del cliente a la red troncal y la puerta de enlace

Las siguientes secciones proporcionan asignaciones de configuración detalladas para la implementación descrita anteriormente.

Webex Callingpermite la creación de troncos y el uso compartido de un tronco en múltiples ubicaciones. Al crear el baúl, asocie el baúl con una ubicación.

Para CuSTa, los detalles del maletero son los siguientes:

La ilustración muestra la asociación de la ubicación del cliente a Gateway y Trunk para CuSTa:

En esta implementación, el enlace troncal asociado con la ubicación es la conexión PSTN principal para esa ubicación. El otro enlace troncal se utiliza como una conexión o ruta PSTN secundaria para entradas específicas del plan de marcado. La implementación de la relación de conexión PSTN primaria y secundaria es a través de un concepto de Route Group. Consulte la sección Configurar troncales de puerta de enlace en la sección Control Hub para obtener más detalles.

Para CustB, se crea una configuración similar con los siguientes enlaces troncales:

La ilustración muestra la asociación de la ubicación del cliente a Gateway y Trunk para CustB:

La ilustración muestra una tercera ubicación, a saber, Nueva York, que puede agregar más tarde y señalar el tronco trunk_chicago como su conexión PSTN principal .

Al implementar una puerta de enlace local que comparte múltiples enlaces troncales, Cisco exige el uso de un FQDN único por enlace troncal. Consulte Configurar enlaces troncales, grupos de rutas y planes de marcación para llamadas WebEx para obtener más información.

El uso de una dirección IP y un puerto conocido por tronco es una opción ideal. Sin embargo, obtener una dirección IPv4 pública puede ser un desafío para algunos socios que desean usar una dirección por puerta de enlace por sitio.

Por lo tanto, lea estos importantes indicadores:

• Cisco no establece una dirección IP por tronco.

• Una dirección troncal puede resolverse en una dirección IP única o en la dirección compartida entre otro tronco.

• Cisco recomienda configurar cada conexión troncal con una combinación única de direcciones IP y puertos en la puerta de enlace local por las siguientes razones:

  1. El mantenimiento de enlaces de conexión TCP separados por enlace troncal admite la capacidad máxima de llamadas simultáneas por enlace troncal. Compartir direcciones IP y combinaciones de puertos entre enlaces troncales puede afectar negativamente a la capacidad de llamada.

  2. Proporciona aislamiento a nivel de red entre clientes

  3. Es típico de los controladores de borde de sesión reutilizar la conexión de socket TCP efímera a menos que se proporcione aislamiento como un inquilino único particionado por una dirección IP o un puerto de escucha único para el inquilino.

  4. La conexión o conexiones por enlace troncal a través del aislamiento del inquilino proporciona un mejor rendimiento específicamente en condiciones de red con alta pérdida de datos. Por lo tanto, el tráfico de un cliente no afecta al otro.

Dirección IP por puerta de enlace: Configuración troncal y recomendaciones

Consulte estos ejemplos de diferentes modelos para la planificación:

Modelo 1: Dirección IP única por tronco

En este modelo, todos los enlaces troncales alojados por ambas puertas de enlace se resuelven en una dirección IP única y cada uno de estos enlaces troncales puede o no usar el mismo puerto, pero idealmente el mismo puerto.

Representación de la información en formato tabular:

En este mismo modelo, el socio puede usar una dirección SRV. Webex Callingsolo permite “_sips. _tcp” como la combinación de servicio y protocolo para descubrir la dirección del par si es un registro SRV.

Una muestra de cómo se resuelve un registro SRV

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Modelo 2: IP compartida por puerta de enlace, puertos de escucha únicos

En este modelo, todos los troncales alojados en la puerta de enlace local de Chicago se resuelven en la misma dirección IP y todos los enlaces troncales alojados en la puerta de enlace local de Miami se resuelven a una IP diferente. Sin embargo, cuando se utiliza la misma IP, cada enlace troncal se configura mediante un FQDN en el concentrador de control y se configura con un puerto único.

En este mismo modelo, el socio está usando una dirección SRV. Webex Callingsolo permite “_sips. _tcp” como la combinación de servicio y protocolo para descubrir la dirección del par si es un registro SRV.

Otra muestra de cómo se resuelve un registro SRV es la siguiente. En este ejemplo, existe un registro A por dirección IP. Sin embargo, el puerto es único por dirección y se representa a través de una configuración DNS específica que vincula una dirección SRV al puerto correcto.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

Para los enlaces troncales basados en SRV, la identidad del certificado de pares se completa inicialmente a partir de los valores SRV configurados y se puede personalizar, sujeto a las mismas reglas de validación.

El socio es dueño de telsp.com y sus subdominios. Por lo tanto, el servidor DNS y la autoridad para obtener certificados firmados por una autoridad de certificación aprobada recae en el socio.

• Cisco Webexespera que el socio publique la dirección FQDN o SRV, incluidos los registros A en el dominio público.

• Cisco Webexespera que el socio utilice una de las autoridades certificadoras enumeradas en este documento.

Al configurar enlaces troncales usando FQDN o SRV:

• Cada tronco aún debe tener un FQDN único para enrutamiento e identificación

• Los registros DNS (A Record o SRV) deben estar configurados y resolvidos correctamente

• Estos FQDN se utilizan para señalización y enrutamiento. La validación del certificado se realiza con la identidad de certificado de pares configurada, que se establece de forma predeterminada en los valores FQDN troncal, pero se puede personalizar para una identidad compartida propiedad del socio.

  El campo de identidad de certificado de pares se completa previamente desde el FQDN troncal y se puede anular con un dominio compartido propiedad del socio para usar un único certificado en múltiples enlaces troncales de clientes.

Configurar la puerta de enlace

Utilice estos recursos para configurar una puerta de enlace local.

Para configurar Cisco CUBE, utilice este procedimiento: Configurar puerta de enlace local en Cisco IOS XE para Webex Calling

Puede configurar SBC de terceros aprobados, consulte: Comenzar con Local Gateway

Configure la puerta de enlace alojada por el socio de acuerdo con estas pautas: Comenzar con Local Gateway

Establezca cada baúl de acuerdo con las instrucciones pertinentes para el dispositivo SBC. Para obtener las instrucciones de Cisco CUBE, consulte: Configurar puerta de enlace local en Cisco IOS XE para Webex Calling

Configurar clases de voz, marcar pares y marcar grupos de pares para el tráfico entrante y saliente del tronco según la imagen:

Al aprovisionar un enlace troncal, Control Hub ofrece una opción para configurar la identidad de certificación de pares en la página Agregar enlace troncal. Esta mejora simplifica el flujo de trabajo al permitir a los socios configurar y reutilizar un único dominio de nivel superior en múltiples organizaciones de clientes. Este enfoque elimina la necesidad de certificados separados por cliente o troncal, lo que reduce el esfuerzo operativo y simplifica el proceso de configuración.

Al configurar enlaces troncales en Control Hub, defina una identidad de certificado de pares para permitir el uso de un único certificado para su dominio de nivel superior en todas las organizaciones de clientes. Asegúrese de que la CN o SAN del certificado incluya este dominio de nivel superior. Con la identidad de certificado de pares, la puerta de enlace local utiliza un único certificado cuyo CN o SAN contiene el dominio compartido del socio (por ejemplo, sip.telsp.com). Los certificados comodín (por ejemplo, *.sip.telsp.com) no son compatibles. Webex Callingacepta este certificado para cada enlace troncal de cliente configurado explícitamente con ese valor como su identidad de certificado de pares. El certificado debe contener el valor exacto de identidad de certificado de pares configurado en su CN o SAN. Esto elimina la necesidad de configurar certificados separados o entradas CN/SAN para los FQDN troncales individuales.

Verificación de dominio y uso de certificados

Es importante entender cómo la verificación de dominio difiere del uso del certificado:

• Verificación de dominio (por cliente): cada organización cliente debe verificar independientemente el dominio (por ejemplo, sip.telsp.com) agregando un registro TXT único en DNS. Esto asegura que el socio sea el propietario del dominio y evita el uso no autorizado.

• Administración de certificados (global): un único certificado emitido para el dominio de nivel superior del socio se puede compartir en todos los enlaces troncales de clientes mediante la identidad de certificado de pares. No hay ningún requisito para mantener certificados separados por cliente o por cajuela.

Comportamiento de identidad de certificación de pares

La identidad del certificado de pares define la identidad que se Webex Calling espera en el certificado presentado por la puerta de enlace local.

Cuando se configura:

• Webex Callingvalida el certificado haciendo coincidir la identidad de certificado de pares configurada con la CN o SAN en el certificado

• Si los valores coinciden, se acepta la conexión TLS

• Si los valores no coinciden, se rechaza la conexión

Solo los troncales configurados explícitamente con la identidad de certificación de pares coincidente pueden autenticarse .

La validación del certificado por sí sola no es la única comprobación que se realiza durante la autenticación. Además de validar el certificado CN o SAN con la identidad de certificado de pares configurada, Webex Calling también verifica que el FQDN troncal esté explícitamente configurado y asociado con la identidad de certificado de pares coincidente en Control Hub.

La identidad del certificado de pares se llena previamente a partir de los valores FQDN/SRV troncales. Si mantiene los valores predeterminados, el comportamiento del certificado por tronco existente no cambia. Los troncales basados en certificados existentes continúan funcionando sin modificaciones. Puede adoptar una identidad de certificación de pares compartida en troncales nuevos o existentes a su propio ritmo, y ambos modelos pueden coexistir.

1. Ejemplo de configuración válido:

   • Certificado CN —sip.telsp.com

   • Certificado SAN —custa.sip.telsp.com

   • Identidad de certificación de pares —custa.sip.telsp.com

   • FQDN del tronco —trunk.miami.custa.sip.telsp.com

   Resultado: la conexión se realiza correctamente porque la identidad del certificado de pares (custa.sip.telsp.com) coincide con el valor SAN en el certificado y el FQDN troncal (trunk.miami.custa.sip.telsp.com) es un subdominio de la identidad de certificado de pares configurada.

2. Ejemplo de fallo de conexión:

   • Certificado CN —sip.telsp.com

   • Certificado SAN —custa.sip.telsp.com

   • Identidad de certificación de pares —custb.sip.telsp.com

   • FQDN del tronco —trunk.miami.custb.sip.telsp.com

   Resultado: la conexión falla en el enlace TLS porque la identidad del certificado de pares (custb.sip.telsp.com) no está presente en la CN o SAN del certificado. El FQDN troncal es correctamente un subdominio de la identidad del certificado de pares, pero el certificado no lleva esa identidad.

3. Ejemplo de configuración no válido:

   • Certificado CN —sip.telsp.com

   • Certificado SAN —custa.sip.telsp.com

   • Identidad de certificación de pares —custa.sip.telsp.com

   • FQDN del tronco —trunk.miami.custb.sip.telsp.com

   Resultado: Control Hub rechaza esta configuración en el momento de ahorrar porque el FQDN troncal (trunk.miami.custb.sip.telsp.com) no es igual o un subdominio de la identidad de certificado de pares configurada (custa.sip.telsp.com).

Desde Partner Hub, puede iniciar el Centro de control para CuSTa o CuSTB y configurar la puerta de enlace. Utilice este procedimiento para configurar para cada cliente:

1. Cree el enlace troncal: agregue un enlace troncal en Llamadas/Enrutamiento de llamadas/Troncal para cada puerta de enlace compartida del socio. Para configurar un tronco, consulte Configurar troncales, grupos de rutas y planes de marcado para Webex Calling

2. Agregar un dominio y verificar: agregue y verifique el siguiente dominio que se utiliza para crear un enlace troncal en Configuraciones de administración/Organización/Dominios.

   ClienteB	ClienteC
   sip.telsp.com	sip.telsp.com

   Al agregar un dominio, se genera un token y se coloca en el registro TXT del dominio en el servidor DNS del socio. Este registro permite a Control Hub verificar que el dominio es propiedad del socio. Para obtener más información, consulte Administrar sus dominios

   El dominio común se utiliza para la verificación en cada cliente. Sin embargo, dado que esta verificación se realiza a nivel de organización del cliente, asegúrese de que se genere un token diferente y se use para la verificación en cada organización del cliente. Debido a que se utiliza un solo dominio en todas las organizaciones de clientes, y cada organización cliente debe verificar el dominio de forma independiente mediante un registro TXT único, incluso cuando comparte el mismo dominio.

   Solo se requiere la verificación de dominio para la identidad de certificación de pares. No reclame el dominio compartido en una organización cliente. Un dominio puede ser reclamado por una sola organización, mientras que el mismo dominio se puede verificar en varias organizaciones.

3. Configurar la dirección SBC con FQDN—

   Para la puerta de entrada de Miami:

   Parámetro	ClienteB	ClienteC
   Ubicación	Denver	Boston
   Nombre del maletero	Trunk_miami	Trunk_miami
   Tipo de maletero	Basado en certificados	Basado en certificados
   Tipo de dispositivo	p.ej. Cisco Unified Border Element(u otro dispositivo compatible)	p.ej. Cisco Unified Border Element(u otro dispositivo compatible)
   SBC Tipo de dirección	FQDN	FQDN
   Nombre de host	LGW.Miami	LGW.Miami
   Dominio	sip.telsp.com	sip.telsp.com
   Puerto	5061	5062
   FQDN	LGW.Miami.Customerb.sip.Telsp.com: 5061	LGW.Miami.Customerc.SIP.Telsp.com:5062
   Número máximo de llamadas simultáneas (250-6500)	500	500

   Para la puerta de entrada a Chicago:

   Parámetro	ClienteB	ClienteC
   Ubicación	Detroit	Dallas
   Nombre del maletero	Trunk_chicago	Trunk_chicago
   Tipo de maletero	Basado en certificados	Basado en certificados
   Tipo de dispositivo	p.ej. Cisco Unified Border Element(u otro dispositivo compatible)	p.ej. Cisco Unified Border Element(u otro dispositivo compatible)
   SBC Tipo de dirección	FQDN	FQDN
   Nombre de host	lgw.chicago	lgw.chicago
   Dominio	sip.telsp.com	sip.telsp.com
   Puerto	5061	5062
   FQDN	LGW.Chicago.Customerb.sip.Telsp.com:5061	LGW.Chicago.Customerc.SIP.Telsp.com:5062
   Número máximo de llamadas simultáneas (250-6500)	500	500

   • (Opcional) Los nombres de los troncales no necesitan ser únicos en todas las organizaciones de clientes. La reutilización del mismo nombre (por ejemplo, trunk_miami) hace que el maletero sea más fácil de rastrear.

   • Ciertos SBC permiten configurar el mismo puerto, pero esta configuración puede afectar la capacidad. Por lo tanto, utilice diferentes puertos.

4. Identidad de certificación de pares—

   • Prefijo: el prefijo es opcional. Déjelo vacío para establecer la identidad del certificado de pares solo en el dominio. Este es el modelo de certificado compartido utilizado en este artículo (identidad de certificado de pares: sip.telsp.com, que cubre todos los enlaces troncales de clientes). Opcionalmente, introduzca un prefijo para definir una identidad de certificado más específica (por ejemplo, prefijo: CustomerB, Dominio: CustomerB.sip.telsp.com para un certificado por cliente). El FQDN del tronco en sí permanece definido por la dirección SBC, el nombre de host y los campos de dominio, y debe ser igual o un subdominio de la identidad de certificado de pares resultante.

     Ejemplo:

     Prefijo: cliente B

     Dominio: sip.telsp.com

     Resultado: Customerb.sip.telsp.com

   • Dominio: Seleccione un dominio de la lista de dominios verificados en la organización del cliente. La identidad del certificado de pares resultante (prefijo + dominio) debe coincidir con la CN o SAN del certificado que presenta su SBC. Webex Callingutiliza este valor para autenticar la conexión TLS.

     

     Control Hub rechaza esta configuración al ahorrar tiempo porque el FQDN troncal no está bajo la identidad de certificado de pares configurada.

     Si la identidad del certificado de pares no coincide con la CN o SAN en el certificado presentado por la SBC, Webex Calling rechaza la conexión TLS y el enlace troncal no se establece.

5. Uso de troncales: elija cualquier ubicación arbitraria para el maletero, debido a lo siguiente:

   • Cualquier ubicación puede usar el maletero en una conexión PSTN.

   • Puede acceder al maletero a través de un grupo de rutas.

   • Cualquier plan de marcado puede usar el maletero.

6. Vea las definiciones de troncal con las ubicaciones asociadas:

   

   Puede usar estos troncales para crear grupos de rutas. En la imagen, se define un grupo de ruta rg_miami_chicago que rutas llama al tronco trunk_miami como opción principal y al tronco trunk_chicago como opción secundaria.

   

   Puede definir un segundo grupo de ruta rg_chicago_miami que enruta las llamadas al tronco trunk_chicago como la opción principal y al tronco trunk_miami como opción secundaria.

7. Los troncales y los grupos de rutas definidos ahora están disponibles en la opción PSTN de Conexión de llamada para cada ubicación. En la imagen, vea la ubicación de Denver.

   

8. Puede usar los troncos y grupos de rutas en la definición del plan de marcado. Por ejemplo, un rango de números local en Chicago para el cliente se divide para terminar en el grupo de ruta rg_chicago_miami (para todas las ubicaciones) en la imagen:

   

   

Aprovisionamiento a escala con API

Los socios que administran un gran número de organizaciones de clientes pueden aprovisionar dominios a escala utilizando API en lugar de la interfaz de usuario.

• Verificar dominio

• Enrutamiento de llamadas