Internet pública

Enlace troncal SIP directo (sobre la parte superior)

El CUBE o SBC del cliente debe colocarse en una IP pública. Este es nuestro modelo de implementación estándar recomendado.

Dado que este es el enfoque más simplista, también es el menos flexible. Las ventajas de una topología simplificada son la facilidad de administración y la resolución de problemas. El cliente completa los diagramas de red y los envía al equipo de voz, y se crean pares de marcado. Colocar el CUBE en una DMZ alivia las complejidades de tratar con NAT. El CUBE en sí es un firewall, y la mayoría de los proveedores medianos o grandes colocan su CUBE en una IP pública y utilizan sus capacidades de seguridad.

VPN

Una VPN es otro tipo de conexión que utiliza Internet pública. Las VPN suelen ser necesarias cuando un cliente requiere una conexión segura para SIP y RTP. También es posible que se requiera una VPN si el cliente no puede colocar el CUBE en un espacio de IP público. Se requiere una reunión de aprovisionamiento con Ingeniería de voz para las conexiones de VPN.

Puertos de voz

• rtp: 8000 - 48199

• SIP: udp 5060

VPN IPSec o IPSec a través de GRE

Las siguientes opciones están disponibles para la conectividad VPN:

• Conectividad SBC a SBC

• Conectividad GW a GW

Webex Contact Center (IPSec o IPSec a través del túnel de GRE y conectividad S2S del Webex Contact Center) para utilizar UDP/5060 en lugar de TCP/5060

Una VPN IPSec o IPSec a través de GRE es una buena opción para un enlace troncal SIP seguro cuando el CUBE está en una IP pública. Se trata de una conexión SBC a SBC (Fig. 2) con los esquemas de direcciones IP privadas de túneles de VPN también se deben considerar para evitar cualquier superposición entre los clientes. Para las conexiones GRE, las subredes IP son: 10.x.248.x y 10.x.249.x.

Sitio a sitio (S2S)

Se puede implementar una conexión S2S si el cliente necesita una conexión segura o no puede colocar el CUBE en una IP pública. Esta es una conexión de puerta de enlace a puerta de enlace. No hay subredes específicamente designadas para conexiones VPN S2S, ya que el enrutamiento se basa en un tráfico interesante sin la intervención de una interfaz lógica.

TLS y SRTP de SIP

El uso de SRTP/SIP TLS es otra opción cuando el CUBE está en una dirección IP pública. Sin embargo, el uso de SRTP/SIP TLS ha afectado el rendimiento. Un dispositivo CUBE puede manejar un tercio de las sesiones SIP si ha protegido las llamadas mediante TLS o SRTP. Esta es una conexión SBC a SBC.

Para establecer una conexión SIP TLS, es necesario intercambiar certificados. Las siguientes opciones están disponibles:

• Los certificados de firma automática se generan e intercambian entre el cliente y Webex Contact Center.

• CA pública: deben completarse los siguientes pasos para apoyar a las CA públicas:

  • El cliente debe compartir el certificado raíz que se cargará en el SBC del Centro de contacto de Webex.

  • El cliente debe actualizar el DNS para incluir las IP de los SBC del Centro de contacto de Webex.

Conectividad privada

A menudo la elección de conexión de los proveedores de grandes empresas, una conexión directa proporciona un circuito dedicado y seguro. Si el cliente necesita una conexión directa, se le puede proporcionar el documento Pautas para la orden de circuitos VPOP del Centro de contacto de Cisco Webex como paso inicial, y se debe llevar a cabo una reunión de diseño de seguimiento con el equipo de ingeniería de voz del Centro de contacto de Webex y los ingenieros del cliente como paso siguiente. El cliente debe proporcionar un diagrama de red detallado de la red de voz del cliente que incluya las interconexiones de la empresa de servicios de PSTN para la reunión. Cisco no alojará ningún equipo del cliente.

Independientemente de si el cliente elige MPLS, P2P, VPLS o SD-WAN, la topología tendrá un aspecto similar y todos los circuitos finalizarán en el router/GW del Centro de contacto de Webex y no en los CUBE del Centro de contacto de Webex.

Los requisitos de ancho de banda para una conexión directa se basan en el códec G.711 (~100 kbps por tramo de llamada), lo que permite dos tramos de llamada por sesión.

Interconexión del centro de datos

Si un cliente decide una conexión privada, será necesario pedir conexiones cruzadas del centro de datos como se describe en el documento Pautas para pedir circuitos VPOP de Cisco Webex Contact Center. El cliente será responsable del costo incurrido y de llevar el circuito del cliente a la caída designada. (Fig. 6).

Implementaciones no estándares

Si las topologías recomendadas no cumplen con todos los requisitos de la red del cliente, se debe planificar una reunión de diseño con el equipo de ingeniería de voz de Cisco a través del equipo de cuentas de Cisco del cliente para un proceso de aprobación especial. Los siguientes son ejemplos de implementaciones no estándar y de implementaciones no recomendadas:

Excepciones A2Q

Proveedor de PSTN que finaliza el circuito directamente al VPOP del Centro de contacto de Webex.

Excepciones Gold de inquilinos

Recomendamos con énfasis un enlace troncal SIP directo para los clientes de inquilinos Gold. Esta es la topología sobre la parte superior de colocar el CUBE en un espacio IP público. La necesidad de un inquilino Gold suele existir con proveedores más grandes; sin embargo, el proveedor requiere que el inquilino Gold sea una prueba de concepto para la implementación de producción prevista por el proveedor. La prueba de concepto del Inquilino Gold a menudo excede el uso de acceso abierto a Internet para un enlace troncal SIP y requeriría uno de los tipos de conexión comentados anteriormente.

Los clientes de inquilinos Gold no serán monitoreados.

Internet pública: CUBE detrás del firewall

Otra opción de implementación es colocar un CUBE en una dirección IP privada detrás de un firewall de NAT. Los requisitos de seguridad del departamento de TI del cliente pueden exigir que la aplicación de voz esté detrás de un firewall. Esta opción tiene algunos inconvenientes conocidos. Aunque esto no cause problemas en la capa de red, puede generar problemas en la capa de la aplicación SIP. La dirección IP privada se utiliza dentro de los mensajes SIP, lo que provoca errores en el procesamiento de llamadas. La capacidad del firewall es otro factor a tener en cuenta para este tipo de implementación. Los firewalls deben tener el tamaño adecuado para manejar el tráfico VoIP; de lo contrario, el firewall puede convertirse en un cuello de botella y afectar la calidad y el procesamiento de llamadas.

Las siguientes son las desventajas de esta implementación:

• Posibles problemas de configuración y configuración de CUBE al principio.

• Aumento de la carga en el firewall que podría afectar la calidad de voz.

• El cliente es responsable de la configuración de CUBE y del tamaño del firewall.

• No es una topología recomendada debido al impacto en los SLA.