Zendesk Talk utiliza Internet para hacer y recibir llamadas telefónicas, por eso es importante contar con una red rápida y confiable. Lo más conveniente es usar una red alámbrica que tenga desactivado Wi-Fi, pero sea cual sea la red que se utilice, lo más probable es que se tendrá que configurar para que funcione correctamente con Talk. Si usted mismo no puede realizar esos cambios, hable con el departamento de TI para que ellos se encarguen. La configuración correcta puede ayudarle a reducir:
- Latencia. El tiempo que se demoran los paquetes RTP (medios) en llegar a su destino. La latencia puede ocasionar un retardo de los medios y ocasionar interrupciones en la conversación. Entre más baja sea la latencia, más probable es que se escuche como que si solo hubiera dos personas hablando en la misma sala. A medida que aumenta la latencia, ocurre lo contrario, y la llamada se ve afectada por interrupciones y pausas que pueden hacer que las personas hablen al mismo tiempo.
- Fluctuación del retardo. El cambio en la latencia con el transcurso del tiempo. Este tipo de fluctuación suena como interferencia o como si alguien estuviera tratando de conectar un micrófono, pero sin conseguirlo. Además, las personas que llaman podrían no escuchar al interlocutor.
- Pérdida de paquetes. Cuando se digitalizan y se transmiten las señales de voz, se dividen en paquetes. Si algunos de los paquetes no logran llegar a su destino, faltarán algunas partes pequeñas de las señales de audio, lo cual resultará en una distorsión audible de la llamada.
La información de este artículo tiene el propósito de ayudar a reducir al mínimo los problemas relacionados con la red, y sacar el máximo provecho de Talk. Si desea información general sobre cómo prepararse para usar Talk, consulte Optimización de la calidad de Zendesk Talk. A fin de descartar cualquier problema de red, asegúrese de que todo esté cableado: auriculares cableados con clavija de 3,5 mm y una conexión cableada a Internet (Wi-Fi desactivado).
Algunas aplicaciones usan mucho ancho de banda, especialmente las aplicaciones de streaming. Zendesk Talk necesita 500 kbps por cada agente que usa Talk, de esta manera Talk y Zendesk Support podrán funcionar lado a lado. Si tiene 50 agentes y cada uno necesita 500 kbps exclusivos (calidad de servicio), necesitaría un mínimo de 50 mbps por línea.
Si está tratando de resolver problemas de red, intente cerrar aplicaciones como Netflix, Spotify, YouTube, etc.
En este artículo se tratan los siguientes temas:
Requisitos de puertos, dominios y direcciones IP de Talk
Es posible que tenga que hacer algunos ajustes a la red para permitir que Talk funcione. Los cambios se tienen que poder hacer en todos los firewalls, routers, interruptores, balanceadores de carga y cualquier otro hardware o software que podría bloquear o manipular el tráfico de Talk en la red.
Puertos
Asegúrese de que los puertos de la siguiente tabla puedan comunicarse con todos los dominios y las direcciones IP que se describen en este artículo.
Zendesk se aloja en Amazon Web Services (AWS). Si desea ver una lista de todos los intervalos de IP de AWS que se tienen que admitir, consulte Configuración del firewall para usarse con Zendesk.
También debe permitir su subdominio de Zendesk en la red, por ejemplo:
*.{{susubdominio}}.zendesk.com
Talk utiliza los siguientes puertos (de salida):
| TCP / UDP: | 443,3478 |
| UDP | 10.000 a 60.000 | 443 | 3478 |
| TCP | 5349 |
Dominios de Twilio
Twilio es el proveedor de Voz para Zendesk Talk. Esta lista presenta los dominios de Twilio a los que tendrá que dar acceso.
| chunderw-gll.twilio.com |
| chunderw-vpc-gll.twilio.com |
| chunderw-vpc-gll-au1.twilio.com |
| chunderw-vpc-gll-br1.twilio.com |
| chunderw-vpc-gll-ie1.twilio.com |
| chunderw-vpc-gll-jp1.twilio.com |
| chunderw-vpc-gll-sg1.twilio.com |
| chunderw-vpc-gll-us1.twilio.com |
| matrix.twilio.com |
| eventgw.twilio.com |
| chunderw-vpc-gll-de1.twilio.com |
| gwasset.twilio.com |
| sdk.twilio.com |
Direcciones IP de Twilio
Esta lista presenta los dominios de Twilio a los que tendrá que dar acceso.
| 54.252.254.64/26 |
| 177.71.206.192/26 |
| 54.171.127.192/26 |
| 52.215.127.0/24 |
| 54.65.63.192/26 |
| 54.169.127.128/26 |
| 54.172.60.0/23 |
| 34.203.250.0/23 |
| 35.156.191.128/25 |
Agregados recientemente
| 54.244.51.0/24 | 44.234.69.0/25 |
| 3.1.77.0/24 | 3.235.111.128/25 |
| 3.112.80.0/24 | 18.141.157.128/25 |
| 3.122.181.0/24 | 18.180.220.128/25 |
| 18.228.249.0/24 | 3.249.63.128/25 |
| 3.104.90.0/24 | 3.7.35.128/25 |
| 72.52.10.0/24 | 18.230.125.0/25 |
| 65.9.130.0/24 | 3.25.42.128/25 |
https://pubsub-shard2-17-1.zendesk.com
https://pubsub-shard2-17-2.zendesk.com
https://pubsub-shard2-17-3.zendesk.com
https://pubsub-shard2-17-4.zendesk.com
Consideraciones adicionales
Asimismo, se deben realizar las siguientes configuraciones de red adicionales:
- Asegúrese de que las direcciones IP y los dominios tanto de Zendesk como de Twilio queden excluidos de la inspección de estado de paquetes (SPI) porque de lo contrario, podría experimentar tiempos de conexión TCP y UDP altos.
- En algunos casos, los clientes han advertido que si un interruptor u otro equipo de red se conecta en un Cisco Smart Switch configurado incorrectamente, se podrían dejar sin validez los dominios y las direcciones IP admitidos. Para evitar que esto suceda, no conecte ningún equipo que no sea apto para conectarse en un interruptor inteligente y verifique con los ingenieros encargados de la red que esté configurado de manera tal que refleje la configuración anterior.
- El firewall deberá admitir el uso del protocolo UDP de salida hacia la Internet pública desde los navegadores que usarán Talk y, en respuesta, admitir el tráfico de retorno. No es posible reducir el intervalo de IP porque Zendesk está alojado en AWS. Puede que vea algunas direcciones IP que están ligeramente fuera del intervalo debido a las redes AWS.
- Si el router incluye la función SIP ALG (SIP Application Level Gateway) o la inspección de estado de paquetes (SPI), desactive ambas funciones en las redes que usan Zendesk Talk.
- Talk no funcionará con MPLS ni con VPN. No permita tráfico para los dominios y las direcciones IP que estén supuestos a canalizarse a través de una VPN.
Después de permitir las conexiones a todas las direcciones IP y los dominios arriba indicados para los puertos señalados (cada puerto necesita acceder a todos los dominios y direcciones IP indicados) Zendesk Talk no debería tener ningún problema para hacer y recibir llamadas.
Uso de Talk con un proxy, MPLS o VPN
Talk no funcionará con una configuración proxy, MPLS o VPN debido a un servicio llamado GLL que funciona en segundo plano. Este servicio se encarga de elegir la mejor ruta de red para canalizar la llamada. Si usa un proxy, MPLS o VPN, la verdadera ubicación de los agentes no es revelada, así que Talk no puede desviar la llamada correctamente, lo que puede producir latencia y otros problemas que afectan la calidad de la llamada. Si tiene que utilizar un proxy, MPLS o VPN, excluya el tráfico para los dominios de Zendesk o Twilio (incluido su subdominio.zendesk.com FQDN) y utilice las direcciones IP que se especifican en este artículo para canalizar la llamada a través de la VPN.
Zendesk Talk no es compatible con los entornos de escritorio virtuales.
Uso de DSCP
Si desea información y pautas para implementar DSCP, consulte Configurar ajustes de calidad de servicio (QoS) para Talk en dominios Windows.
Las etiquetas DSCP en los paquetes resultan útiles para indicarles a los aparatos de la red cómo deben priorizar el tráfico. De manera predeterminada, las llamadas de Talk tienen una etiqueta DSCP de 46. Si la red sufre problemas de saturación, considere la posibilidad de implementar DSCP usando las instrucciones que se describen en este artículo. Twilio Client 1.3 y las versiones superiores activan DSCP de manera predeterminada en los navegadores compatibles (p. ej., Google Chrome).
Los navegadores compatibles etiquetan los paquetes de medios WebRTC. Esto hace posible un manejo diferenciado en una red LAN para que los medios en tiempo real reciban trato prioritario frente a cualquier otro tráfico en la red. El campo de servicios diferenciado está ubicado en el octeto TOS del encabezado IPv4 o el octeto de clase de tráfico IPv6. Un nodo de red que sea compatible con los servicios diferenciados (p. ej., un router) incluye un clasificador que selecciona paquetes en función del valor del campo DS, la administración del búfer y los mecanismos de programación de paquetes capaces de brindar el tratamiento de reenvío de paquetes específico indicado por el valor del campo DS.
Con Twilio Client 1.3, los paquetes RTP enviados tendrán un punto de código de servicio diferenciado (DSCP) en sus capturas de paquetes Wireshark locales. Cuando se activa DSCP, el motor WebRTC marca los paquetes RTP con EF y los valores relacionados con el reenvío agilizado:
- binario: 101 110
- hex: 0x2e
- decimal: 46
Es necesario usar un navegador compatible con WebRTC, por ejemplo, Chrome o Firefox. Si se implementa DSCP (recomendado), se debe usar Chrome (última versión, no beta) ya que es el único navegador compatible.
Para verificar si está usando la última versión de Chrome, vaya a “chrome://help/” en la barra de dirección. Si ve el botón Reiniciar, haga clic en él para actualizar Chrome.
Verificar que DSCP funcione correctamente
En algunos entornos de Windows, las etiquetas DSCP son eliminadas aunque la red esté configurada para DSCP. Con Wireshark, los ingenieros encargados de la red pueden verificar si Windows está eliminando dichas etiquetas DSCP. Entonces, se puede aplicar una Directiva de grupo para imponer DSCP o, si los equipos no pertenecen a un dominio, se puede implementar caso por caso.
A fin de asegurarse de que Windows no esté quitando las etiquetas DSCP, se tendrán que realizar los siguientes pasos, según si el equipo pertenece a un dominio o no.
Verificar las etiquetas DSCP de las máquinas que pertenecen a un dominio
En las máquinas que pertenecen a un dominio, para controlar la configuración de QoS que se utiliza para ciertas aplicaciones se diseñan distintas reglas de Directiva de grupo.
Realice los pasos siguientes para garantizar que los paquetes WebRTC tengan prioridad, lo que hará que el marcador funcione de manera óptima.
Para que lo anterior funcione, será necesario hacer que las máquinas cliente utilicen esta nueva Directiva de grupo. Normalmente, solo es necesario reiniciar el equipo.
Para verificar las etiquetas DSCP de una máquina que pertenece a un dominio, siga estos pasos:
- Escriba "gpedit.msc" en la línea de comandos para abrir las reglas de Directiva de grupo.
- En Configuración del equipo, seleccione QoS basada en directivas.
- Haga clic con el botón derecho y seleccione Crear nueva directiva.
- Se abre una interfaz de asistente para ayudarle a configurar las reglas de QoS.
- En la primera pantalla, ingrese "Salesloft DSCP" como el nombre de la directiva y especifique un valor de DSCP de "46".
- Haga clic en Siguiente.
- En la segunda pantalla, seleccione Solo las aplicaciones con este nombre de archivo ejecutable y luego ingrese "Chrome.exe".
- Haga clic en Siguiente.
- En la tercera pantalla, no es necesario ingresar ninguna configuración; haga clic en Siguiente.
- En la última pantalla, seleccione el protocolo al cual se aplicará la QoS. Para Salesloft Dialer, UDP será la única opción.
Verificar las etiquetas DSCP de las máquinas que no pertenecen a un dominio
Esta sección describe cómo modificar la configuración del registro para poder especificar la opción QoS que será utilizada según las opciones de la Directiva de grupo que se configuren.
Para verificar las etiquetas DSCP de una máquina que no pertenece a un dominio, siga estos pasos:
- Vaya a HKEY_LOCAL_MACHINE > CurrentControlSet > Services > tcpip > QoS.
- Si la clave QoS no existe, haga clic con el botón derecho del mouse en TCP/IP y seleccione Nueva clave.
- Para el nombre, ingrese "QoS."
- A continuación, seleccione la clave QoS.
- Si la cadena no existe aún, cree un nuevo valor para la cadena llamado "Do not use NLA".
- Establezca el valor en 1.
- Reinicie el equipo para que la configuración tenga efecto.
Requisitos para equipos Windows
Existe la posibilidad de que ocurran problemas con Zendesk Talk si se usa un equipo con un sistema operativo Windows. Es necesario que los clientes de Zendesk Talk usen el servicio “Experiencia de calidad de audio y video de Windows (QWAVE)” y tengan el tipo de inicio establecido en Automático (no en Manual, que es el valor predeterminado).
Para asegurarse de que QWAVE esté activado y el inicio sea automático
- En el menú de inicio de Windows, escriba “cmd”.
- Con el botón derecho del mouse, haga clic en el icono Símbolo del sistema y luego haga clic en Ejecutar como administrador.
- Pegue el siguiente texto en la línea de comandos:
net start QWAVE
- Presione Intro. Verá los siguientes resultados.
- Para asegurarse de que esto tenga un tipo de inicio automático permanentemente, pegue lo siguiente en la línea de comandos para establecer el tipo de inicio del servicio en automático:
REG add "HKLM\SYSTEM\CurrentControlSet\services\QWAVE" /v Start /t REG_DWORD /d 2 /f
- Presione Intro.
Ahora el tipo de inicio para el servicio “QWAVE” estará establecido en Automático. Si ocurre un error al realizar los pasos descritos anteriormente, pídale a un miembro del departamento de TI o a un administrador informático que se encargue de realizar este proceso (para usar la línea de comandos es necesario ser un administrador).
Establezca una directiva de grupo en la red para que todos los equipos-cliente establezcan el servicio en automático. Así no perderá tiempo configurando manualmente cada equipo.
Resolución de problemas adicionales
Después de completar los pasos anteriores, también puede usar el SDK de Twilio para examinar la calidad de las llamadas. Si desea más información, consulte Voice Insights SDK Events Reference (en inglés).
0 Comentarios
Inicie sesión para dejar un comentario.