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 de alto nivel & Requisitos de TelSP:

• El socio planea utilizar sip.telsp.com como el dominio de nivel superior que se comparte entre 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, gestionar 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 acceso PSTN compartido entre clientes finales.

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

  • Miami

  • Chicago

• TelSP opera sus puertas de enlace locales en nombre de los dos clientes CustA y CustB, como se los denominará a partir de ahora.

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

Asociación de la ubicación del cliente al tronco y la puerta de enlace

Webex Calling permite la creación de troncales y compartir un troncal en múltiples ubicaciones. Al crear el tronco, asocie el tronco con una ubicación.

Para CustA, los detalles del tronco son los siguientes:

La ilustración muestra la asociación de la ubicación del cliente con 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 tronco se utiliza como conexión PSTN secundaria o ruta para entradas de plan de marcado específicas. La implementación de la relación de conexión PSTN primaria y secundaria se realiza a través de un concepto de grupo de rutas. Consulte la sección Configuración del cliente de Webex para obtener más detalles.

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

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

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

Al implementar una puerta de enlace local que comparte varios troncales, Cisco EXIGE el uso de un FQDN único por troncal. Consulte Configurar troncales, grupos de rutas y planes de marcado para Webex Calling para obtener más detalles.

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

Por lo tanto, lea estos importantes consejos:

• Cisco no exige una dirección IP por troncal.

• 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 dirección IP y puerto en el gateway local por los siguientes motivos:

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

  2. Proporciona aislamiento a nivel de red entre clientes.

  3. Es típico que los controladores de borde de sesión reutilicen 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 troncal a través del aislamiento de inquilinos 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 del tronco y recomendaciones

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

Modelo 1: Dirección IP única por troncal

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

Representando la información en formato tabular:

En este mismo modelo, el socio puede utilizar una dirección SRV. Webex Calling solo permite “_sips._tcp” como combinación de servicio y protocolo para descubrir la dirección del par si se trata de 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 en una puerta de enlace pero con diferentes puertos de escucha

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 troncales alojados en la puerta de enlace local de Miami se resuelven en una IP diferente. Sin embargo, cuando se utiliza la misma IP, cada troncal se configura utilizando un FQDN en el concentrador de control y se configura con un puerto único.

En este mismo modelo, el socio utiliza una dirección SRV. Webex Calling solo permite “_sips._tcp” como combinación de servicio y protocolo para descubrir la dirección del par si se trata de un registro SRV.

Otro ejemplo de cómo se resuelve un registro SRV es el siguiente. En este ejemplo, existe 1 registro A por dirección IP. Sin embargo, el puerto es único por dirección y está representado 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

El socio es propietario 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 Webex espera que el socio publique la dirección FQDN o SRV, incluidos los registros A, en el dominio público.

• Cisco Webex espera que el socio utilice una de las autoridades de certificación enumeradas en la publicación de este documento.

Al utilizar un FQDN como dirección troncal, configure los certificados firmados con el Nombre común (CN) o el Número alternativo de sujeto (SAN) establecido en los FQDN para los troncales.

Utilice uno de estos métodos para generar los FQDN en el certificado:

• Elija uno de los FQDN como Nombre común (CN) y el resto como Número alternativo de sujeto (SAN).

• Coloque el dominio de nivel superior (sip.telsp.com) como CN y todos los FQDN como SAN.

  En el futuro, puede validar el certificado en función del dominio de nivel superior al que corresponde esta configuración.

Al utilizar un SRV como dirección troncal, configure certificados firmados con el CN o SAN en la parte de host de la dirección SRV. No es necesario el registro A o CNAME al que se resuelve la dirección SRV.

Configurar la puerta de enlace

Utilice estos recursos para configurar una puerta de enlace local.

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

Puede configurar SBC de terceros aprobados, consulte: Comenzar con la puerta de enlace local

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

Configure cada troncal según las instrucciones correspondientes para el dispositivo SBC. Para obtener las instrucciones de Cisco CUBE, consulte: Configurar la puerta de enlace local en Cisco IOS XE para Webex Calling

Configure clases de voz, pares de marcado y grupos de pares de marcado para el tráfico entrante y saliente para el troncal según la imagen:

Desde el Centro de socios, 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. Crear el tronco: agregue un tronco debajo Calling/Call Routing/Trunk para cada puerta de enlace compartida por el socio. Para configurar un enlace troncal, consulte Configurar enlaces 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 tronco en Management/Organization Settings/Domains.

   Cliente A	Cliente B
   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 detalles, consulte Administrar sus dominios

   Dado que el dominio común se utiliza para la verificación de cada cliente. Sin embargo, dado que esta verificación se realiza a nivel de la organización del cliente, asegúrese de que se genere y utilice un token diferente para la verificación en cada organización del cliente. Debido a que se utiliza un único dominio en todas las organizaciones de clientes, ninguna organización puede reclamar la propiedad del dominio.
3. Configurar la dirección SBC con FQDN—

   Para la puerta de entrada a Miami:

   Parámetro	Cliente A	Cliente B
   Ubicación	Denver	Bostón
   Nombre del enlace troncal	trunk_miami	trunk_miami
   Tipo de enlace troncal	Basado en certificado	Basado en certificado
   Tipo de dispositivo	p. ej. Cisco Unified Border Element (u otro dispositivo compatible)	p. ej. Cisco Unified Border Element (u otro dispositivo compatible)
   Tipo de dirección SBC	FQDN	FQDN
   Nombre de host	baúl.miami.custa	baúl.miami.custb
   Dominio	sip.telsp.com	sip.telsp.com
   Puerto	5061	5062
   FQDN	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.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	Cliente A	Cliente B
   Ubicación	Detroit	Dallas
   Nombre del enlace troncal	trunk_chicago	trunk_chicago
   Tipo de enlace troncal	Basado en certificado	Basado en certificado
   Tipo de dispositivo	p. ej. Cisco Unified Border Element (u otro dispositivo compatible)	p. ej. Cisco Unified Border Element (u otro dispositivo compatible)
   Tipo de dirección SBC	FQDN	FQDN
   Nombre de host	tronco.chicago.custa	tronco.chicago.custb
   Dominio	sip.telsp.com	sip.telsp.com
   Puerto	5061	5062
   FQDN	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Número máximo de llamadas simultáneas (250-6500)	500	500

   • (Opcional) No tenga un nombre único para el troncal entre clientes y el mismo nombre puede ayudar a rastrear el troncal.

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

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

   • Cualquier ubicación puede utilizar el enlace troncal en una conexión PSTN.

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

   • Cualquier plan de marcado puede utilizar el enlace troncal.

5. Vea las definiciones de troncales con las ubicaciones asociadas:

   

   Puede utilizar estos troncales para crear grupos de rutas. En la imagen, se define un grupo de rutas rg_miami_chicago que enruta las llamadas al troncal trunk_miami como opción principal y al troncal trunk_chicago como opción secundaria.

   

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

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

   

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