Internet público

Troncal SIP directo (sobre la parte superior)

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

Como 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 solución de problemas. El cliente completa los diagramas de red y los envía al equipo de voz, y se crean pares de marcación. 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 / grandes colocan su CUBE en un IP público y utilizan sus capacidades de seguridad.

Vpns

Un VPN es otro tipo de conexión que utiliza Internet público. Las VPN a menudo son necesarias cuando un cliente requiere una conexión segura para SIP y RTP. También se puede requerir una VPN si el cliente no puede colocar el cubo en un espacio IP público. Se requiere una reunión de aprovisionamiento con ingeniería de voz para VPN conexiones.

Puertos de voz

• RTP: 8000 - 48199

• SIP: UDP 5060

IPSec VPN o IPSec sobre GRE

Las siguientes opciones están disponibles para VPN Connectivity:

• Conectividad de SBC a SBC

• Conectividad de GW a GW

Webex Contact Center (IPSec o IPSec sobre túnel GRE y conectividad S2S de Webex Contact Center) para usar UDP/5060 en lugar de TCP/5060

Un IPSec VPN o IPSec sobre GRE es una buena opción para un troncal SIP seguro cuando el CUBE está en una IP pública. Esta es una conexión de SBC a SBC. (Fig. 2) con túneles de VPN también deben considerarse esquemas de direcciones IP privadas para evitar cualquier solapamiento entre clientes. Para las conexiones GRE, IP subredes 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 un IP público. Se trata de una conexión de puerta de enlace a puerta de enlace. No hay subredes específicamente designadas para conexiones de VPN S2S, ya que el enrutamiento se basa en tráfico interesante sin la participación de una interfaz lógica.

TLS SIP y SRTP

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

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

• Los certificados autofirmados se generan e intercambian entre el cliente y Webex Contact Center.

• CA pública: se deben completar los siguientes pasos para admitir la CA pública:

  • El cliente debe compartir el certificado raíz que se cargará en el SBC de Webex Contact Center.

  • El cliente debe actualizar el DNS para incluir las IP de los SBC de Webex Contact Center.

Conectividad privada

A menudo, la opció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 Cisco Webex Contact Center Pautas de pedido de circuitos VPOP como paso inicial, y se debe realizar 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 el siguiente paso. El cliente debe proporcionar un diagrama de red detallado de la red de voz del cliente, incluidas las interconexiones del operador RTC 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 se verá similar y todos los circuitos terminarán en Webex enrutador / GW del centro de contacto y no en Webex CUBE del centro de contacto.

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

Conexión cruzada del centro de datos

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

El documento Cisco Webex Contact Center Pautas de pedido de circuitos VPOP se proporcionará al cliente directamente durante el proceso de incorporación en caso de que se prefiera esta opción de conectividad.

Implementaciones no estándar

Si las topologías recomendadas no cumplen con todos los requisitos de la red del cliente, se debe programar 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 e implementaciones que no se recomiendan:

Excepciones A2Q

Proveedor de RTC que termina el circuito directamente a Webex VPOP de centro de contacto.

Excepciones para inquilinos Gold

Recomendamos encarecidamente un troncal SIP directo para los clientes de Gold Tenant. Esta es la topología exagerada de colocar el CUBE en un espacio IP público. La necesidad de un inquilino Gold a menudo existe 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 del proveedor. La prueba de concepto Gold Tenant a menudo excede el uso de acceso abierto a Internet para un troncal SIP y requeriría uno de los tipos de conexión discutidos anteriormente.

Los clientes de Gold Tenant no serán monitoreados.

Internet público – CUBE detrás del firewall

Colocar un CUBE en una dirección IP privada detrás de un firewall NAT es otra opción de implementación. Los requisitos de seguridad del departamento de TI del cliente pueden estipular tener la aplicación de voz detrás de un firewall. Esta opción tiene algunos inconvenientes conocidos. Aunque esto puede no causar problemas en la capa de red, puede dar lugar a problemas en la capa de aplicación SIP. La dirección IP privada se utiliza dentro de los mensajes SIP, lo que provoca errores de 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 puede 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 a la calidad de voz.

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

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

No se recomienda esta topología debido a las complejidades de tratar con SIP y NAT. Se requiere una reunión con el equipo de ingeniería de voz de Cisco y el cliente para la aprobación de este tipo de implementación.