Resolución de problemas de aplicaciones SIP

Puede utilizar este tema para solucionar problemas de aplicaciones SIP.

Acerca de esta tarea

Utilice la siguiente información básica de resolución de problemas del contenedor SIP al solucionar problemas con las aplicaciones SIP.

  • El uso medio de la CPU del sistema no debería ser superior al 60%-70%.
  • El contenedor no debería utilizar más del 70% del tamaño de almacenamiento dinámico he de VM asignado. Asegúrese de que el sistema tiene suficiente memoria física para contener el tamaño de almacenamiento dinámico de VM. Las cargas de llamadas y los tiempos de espera excedidos de sesión pueden tener un gran afecto en el uso del almacenamiento dinámico.
  • El intervalo máximo de recogida de basura de VM en el que se ejecuta el contenedor no debe exceder los 500 ms y el promedio debe ser inferior a 400 ms. La recogida de basura detallada se puede utilizar para medirlo y se puede utilizar el visor PMI para ver los tiempos de recogida de basura, el uso de la recogida de basura, las sesiones activas, etc. en formato gráfico.

Procedimiento

Utilice la siguiente lista de comprobación de resolución de problemas para solucionar problemas con las aplicaciones SIP :
  • Compruebe los puertos de escucha en la configuración
  • Utilice netstat –an para ver los puertos de escucha.
  • Verifique si hay definidos host virtuales
  • Verifique si hay definidos alias de host.
  • ¿Está instalada una aplicación? ¿Se ha iniciado?
  • Para una configuración de proxy, ¿es un clúster predeterminado configurado? Si el proxy y el servidor están en la máquina, ¿existe algún conflicto de puerto?

Resultados

Si el problema no se resuelve, busque los síntomas y soluciones específicos.
  • Síntoma: muchas retransmisiones, la CPU baja periódicamente a cero o en los registros se ve una excepción ThreadPoolQueueIsFullException

    Solución: Normalmente se trata de un problema de DNS causado por búsquedas de DNS inversas y puede confirmarse utilizando una herramienta como Ethereal. Si realiza una captura de red y envía muchas consultas DNS que contienen una dirección IP y como respuesta obtiene un nombre de host, este podría ser el problema. Asegúrese de que nscd está en ejecución si está en HP u alguna otra plataforma que requiere almacenamiento en memoria caché de servicio de nombres. La plataforma Microsoft Windows no requiere almacenamiento en memoria caché de servicio de nombres. Otra solución sería añadir nombres de host al archivo /etc/hosts.

  • Síntoma: Muchas retransmisiones, de vez en cuando la CPU aumenta rápidamente al 100%.

    Solución: Normalmente se debe a la recogida de basura y puede verificarse activando la recogida de basura detallada (a la que se puede acceder en la consola administrativa) y examinando la duración de los ciclos de recogida de basura. La solución aquí es habilitar la recogida de basura generacional estableciendo los argumentos opcionales de JVM en -Xgcpolicy:gencon.

  • Síntoma: Muchas retransmisiones, de vez en cuando la CPU aumenta rápidamente al 100% durante largos intervalos de tiempo y está habilitada la recogida de basura generacional.
    Solución: Esto suele deberse a que los objetos de sesión SIP no están anulando o no exceden el tiempo de espera en un intervalo de tiempo largo. Una solución es establecer el valor de tiempo de espera de sesión en el archivo sip.xml de la aplicación en un valor más pequeño. La forma más eficaz de manejar esta situación es que la aplicación considere anulada la sesión cuando el diálogo finalice (es decir, después de recibir un BYE). La siguiente entrada del archivo SystemOut.log indicará que el valor de tiempo de espera de sesión es para cada aplicación instalada en el contenedor:
    SipXMLParser  3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For 	App: TCK back-to-back user agent”
    Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.
  • Síntoma: Se reciben muchos mensajes de "480 Servicio no disponible" del contenedor cuando se envían nuevos mensajes INVITE al contenedor SIP. Probablemente también verá el siguiente mensajes en el archivo SystemOut.log cuando el servidor está en este estado: "LoadManager E LoadManager warn.server.oveloaded".

    Solución: Esto suele deberse a que se ha excedido una de las métricas configurables del contenedor SIP. Esto incluye el valor "Número máximo de sesiones de aplicación" y el valor "Número máximo de mensajes por periodo promedio". La solución es cambiar el valor por uno más alto.

  • Síntoma: Muchos de los reenvíos y llamadas no se llevan a cabo, junto con excepciones de OutOfMemory en el SystemErr.log.

    Solución: Esto suele significar que el tamaño de almacenamiento dinámico de VM asociado al contenedor no es lo suficientemente grande y debe cambiarse por uno mayor. Puede cambiar este valor desde la consola administrativa.

  • Síntoma: Ha recibido el mensaje "503 Servicio no disponible" al enviar una petición SIP a un proxy SIP.

    Solución: Esto en general indica que no hay ningún clúster por omisión (o regla de direccionamiento de clúster que coincida con el mensaje) configurado en el proxy.Esto también puede darse cuando el proxy SIP se configura bien pero los contenedores SIP de fondo se han detenido o se han colgado.

  • Síntoma: Ha recibido el mensaje "404 No encontrado" al enviar una petición SIP a un proxy SIP.

    Solución: Esto en general indica que no hay ningún host virtual configurado para los contenedores que residen en el clúster por omisión. También podría indicar que los servidores del clúster predeterminado del proxy no contienen una aplicación SIP o que el mensaje no coincide con una de las aplicaciones instaladas en el clúster predeterminado.

  • Síntoma: Se produce un comportamiento del tipo "memoria agotada".

    Solución: Esto puede deberse a que el tamaño de almacenamiento dinámico máximo establecido es demasiado bajo. Las aplicaciones SIP pueden consumir una cantidad significativa de memoria porque las sesiones existen durante un largo intervalo de mantenimiento de llamada. El tamaño máximo del almacenamiento dinámico de 512 MB no proporciona memoria suficiente para la carga de trabajo de tráfico de SIP. Establezca el tamaño máximo del almacenamiento dinámico para las aplicaciones SIP en el valor mínimo recomendado de 768 MB o superior.

  • Síntoma: Se recibe un "403 Prohibido" al enviar una solicitud SIP a un contenedor SIP.

    Solución: Esto en general indica que no se ha encontrado ninguna aplicación SIP adecuada SIP para manejar la solicitud SIP recibida (ninguna regla de coincidencia que coincida con el mensaje).


Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_trouble
File name: tsip_trouble.html