Debe tener en cuenta determinados comportamientos de tiempo de ejecución cuando escriba aplicaciones SIP (Session Initiation Protocol).
Es posible que el contenedor no acepte los esquemas URI que no sean de SIP.
El
contenedor SIP no rechazará un mensaje si no reconoce el esquema en el URI
(Uniform Resource Indicator) de solicitud porque el contenedor no puede saber qué esquemas
de URI están soportados por las aplicaciones. Los elementos SIP pueden dar soporte a un URI de petición con un esquema distinto a sip o sips, por ejemplo, el esquema pres: tiene un significado concreto para los servidores de presencia, pero el contenedor no los reconoce. Depende de la aplicación determinar si se acepta o se rechaza un esquema específico. Los elementos SIP pueden convertir los URI que no son SIP por medio de cualquier mecanismo disponible, lo que da como resultado los URI de SIP o los URI de SIPS o de cualquier otro esquema como, por ejemplo, el esquema de URI tel de RFC 2806 [9].
Para usuarios en transición: Cuando una aplicación SIP envía una solicitud a un URI de SIP a través de TLS (Transport Layer Security) en la versión 6.1, el esquema de URI de solicitud cambia de "sip" a "sips". En la versión actual, el esquema no cambia. Puede invertir el comportamiento
nuevo mediante la modificación del código de la aplicación. Con un URI "sips", el
comportamiento sigue siendo el mismo después de realizar la actualización de la versión
6.1 a 7.0 o posterior.
Invocación de sucesos de escucha de sesiones
Los sucesos SipSessionListener
y SipApplicationSessionListener sólo se invocan si una aplicación solicita el objeto de sesión correspondiente. Para ello, utilice en la aplicación el método que se muestra en la Tabla 1.Tabla 1. Métodos que invocan sucesos de escucha de sesión. Esta tabla lista los métodos que invocan sucesos de escucha de sesión.
| Suceso |
Método |
| SipSessionListener |
getSession() |
| SipApplicationSessionListener |
getApplicationSession() |
Activación y pausa de las sesiones
Durante una operación normal, este producto no migra nunca una sesión de un servidor a otro. La migración de sesiones se lleva a cabo únicamente como resultado de un error del servidor. Por lo tanto, no se invoca nunca el retorno de llamada de pausa del método SipSessionActivationListener. No obstante, el retorno de llamada de activación se invoca cuando una anomalía fuerza la sustitución por anomalía de la sesión a un servidor diferente.
Recursos externos
Si una aplicación SIP efectúa una E/S intensiva o accede a una base de datos externa, puede bloquearse durante varios milisegundos. Si es posible, utilice las API asíncronas para estos recursos. Bajo presión, una aplicación SIP bloqueada puede desencadenar un tiempo de espera de solicitud o una retransmisión.
Atributos de la aplicación SIP
Evite colocar objetos grandes o BLOB como atributos de sesión SIP (mediante la API SIPSession.setAttribute). Esto puede afectar al rendimiento general si se combina con una alta disponibilidad (HA). La misma recomendación se aplica a SIPApplicationSession.setAttribute. En la
mayoría de los casos, el objeto grande se puede sustituir por varias series
simples o compuestas.