Pérdida de calidad en sesiones de AV en Lync.
En ocasiones hemos tenido casos reportados de pérdida de audio o video durante comunicaciones entre usuarios de Lync. En este artículo proporcionamos algunos pasos que se pueden dar para determinar el origen del problema.
En primer lugar hay que identificar y aislar el tipo de comunicación cuando el problema ocurre, y también en qué ocasiones ocurre. Hay que diferenciar si se trata de una comunicación peer to peer entre dos usuarios internos o entre más de dos usuarios o al establecer una reunión en línea. De esta forma si sólo ocurre cuando es una conferencia sabemos que pasará a través de los front end y de este modo confirmar que se trata de problemas de rendimiento del servidor o problemas de red en los frontales. El siguiente punto a identificar es el momento en el que ocurre el problema. Generalmente si se trata de rendimiento en el servidor los problemas aparecerán en horario de alta carga, pero si no somos capaces de reproducirlo fuera de horario de oficina entonces apunta casi con total seguridad a rendimiento. Es importante destacar que esto nos sirve para determinar si es problema de red o rendimiento del servidor y así acotar el origen.
Una vez que tengamos una idea precisa del momento y la casuística, es hora de mirar los logs. Lo más útil es analizar el archivo UCCAPILOG de los clientes Lync involucrados, ya que los reportes del servidor de monitoring lo que hacen realmente es recoger directamente de los clientes los datos de las sesiones. Por tanto los logs de cliente serán más precisos que los de monitoring, que suelen ser una aproximación aunque no tan exacta como los de cliente, y cuya fuente son los propios clientes. La utilidad del monitoring será sobre todo confirmar los datos de las diferentes sesiones y hacer un balance general.
El siguiente punto a identificar (para saber qué buscar exactamente en las trazas) es si la pérdida está en el audio o en el video. El audio tiene prioridad sobre el video, por tanto en caso de una videoconferencia donde se pierdan paquetes de video y no de audio no resultará raro que el audio llegue correctamente.
Por ejemplo si tenemos pérdida de video, en las trazas de cliente podemos buscar por el nombre “Video Render Pane”.
Aquí nos encontraremos con diferentes valores sobre la sesión, pero los que nos ocupan son el “VideoPacketLossRate” y “VideoFrameLossRate”.
En la documentación sobre Understanding QoE Alerting podemos ver los valores que se consideran óptimos y aceptables, y podremos compararlos con los valores del log. Evidentemente si tenemos un VideoLossRate de 100 significará que no llega nada de video. También podemos comprobarlo en el blog de Jens Trier Rasmussen https://blogs.technet.com/b/jenstr/archive/2013/09/20/what-is-the-basis-for-classifying-a-call-as-poor-in-lync-2013-qoe.aspx o en Next Hop https://blogs.technet.com/b/nexthop/archive/2012/12/10/troubleshooting-call-quality-locally-with-snooper.aspx
Por tanto los logs de cliente nos confirmarán si es una pérdida de paquetes y no un problema local o de otro tipo.
Los orígenes del problema pueden ser entonces sobrecarga del servidor, o problemas de red como hemos comentado antes aunque también puede ser producido por otros factores como por ejemplo que un usuario esté usando WIFI y no tenga ancho de banda suficiente y esté ralentizando la conferencia por completo.
En este sentido hay que comprobar que todos los usuarios implicados estén conectados por cable, en la misma ubicación, cuantos usuarios mínimos producen el problema, la hora, etc…
Si se continúa sin identificar el problema, habría que usar herramientas adicionales como Network Monitor y Contadores de Rendimiento. Los valores que se pueden incluir en los contadores son:
• Process
• Processor
• Memory
• Network Interface
• Paging File
• Logical Disk
• Physical Disk
• System
• Objects
• Redirector
• Server
• Server Work Queues
Y se pueden poner intervalos de 15 segundos mientras se reproduce el problema. El resultado nos podrá indicar si tenemos un problema de rendimiento o de red.
Con las trazas de red se podrá comprobar el flujo de datos y determinar dónde puede haber una pérdida, aunque esto requerirá conocimientos avanzados de red para comparar los datos enviados y recibidos en cada tramo.
Un saludo,
El equipo de soporte de Lync.