El contenedor SIP no puede procesar solicitudes de CANCELACIÓN si se ha enviado una respuesta 100.
La aplicación debe enviar una respuesta provisional (como 1xx), de modo que la instancia remota sea capaz de CANCELAR la solicitud de INVITACIÓN.
El modelo de finalización de sesión de las sesiones SIP es distinto a la lógica de tiempo de finalización del protocolo HTTP. En HTTP, la duración de la sesión se amplía de forma automática, fuera del control de la aplicación, siempre que la sesión HTTP recibe una solicitud HTTP.
En cambio, en las sesiones SIP, la aplicación se encuentra bajo el control de la SipApplicationSession (SAS) que, a su vez, debe aprobar el contendor SIP. Las aplicaciones pueden usar el método setExpires para indicar cuándo debe finalizar la SAS. setExpires define el tiempo de finalización relativo al momento en el que se invoca el método setExpires. El contenedor puede modificar, rechazar o aceptar la duración indicada en setExpires . Si la sesión se no se ha invalidado, la devolución de llamada sessionExpired se genera en el momento definido por setExpires. En dicha devolución de llamada, la aplicación puede intentar ampliar la duración de la SAS invocando un nuevo método setExpires, una vez más sujeto a la modificación, el rechazo o la aceptación por parte del contenedor.
Por este motivo, en las aplicaciones convergentes que se inicien con el mismo tiempo de finalización en la SipApplicationSession (SAS) y en la sesión HTTP, el tiempo de SAS se agotará antes que el de la sesión HTTP si se han recibido solicitudes nuevas en la sesión HTTP.
La mejor forma de afrontar la divergencia entre la administración del tiempo de finalización de la sesión SIP y la sesión HTTP es comenzar con un tiempo de finalización de la SAS de una duración conveniente, que debe corresponderse con el periodo de tiempo total que se prevé que durará la sesión de aplicaciones (incluidas varias solicitudes HTTP). El ciclo de duración de la SAS se puede definir incluso como infinito, en concreto si se utiliza la semántica invalidateWhenReady, en cuyo caso, SipApplicationSession se invalida cuando la última sesión secundaria de protocolo queda invalidada. El tiempo inicial de finalización de la SAS se puede configurar en el descriptor de implementación.
Si la duración total máxima puede estimarse por adelantado, no se necesita ningún otro código, ya que el código actual es apropiado para invalidar la sesión SIP y la sesión HTTP cuando la SAS caduque. Si la duración máxima no se puede estimar por adelantado, la duración de la SipApplicationSession puede ampliarse cuando ésta haya caducado, tal y como se muestra en el fragmento de código siguiente.
En la implementación de SipApplicationSessionListener, puede hacer algo así:
public void sessionExpired(SipApplicationSessionEvent sasEvent) { // check if the SAS needs to be extended first, if so: int granted = sasEvent.getApplicationSession().setExpires(2); if (granted <= 0) { System.out.println("extension rejected"); } else if (granted < 2) { System.out.println("extension granted with lower value " + granted); } // else allowed }
Se trata de un problema ocasional. El contenedor SIP responde de forma intermitente con un mensaje de error de servidor 500, en lugar de con un mensaje 481 en el que se indica que la llamada o transacción no existe cuando hay una condición de competencia entre el mensaje 200 para la solicitud de NOTIFICACIÓN, lo cual indica que la sesión se ha eliminado, y la solicitud de SUSCRIPCIÓN enviada por el cliente al recibir la NOTIFICACIÓN.
El cliente debe actualizar la solicitud de SUSCRIPCIÓN mucho antes de que la suscripción caduque.
Cuando recibe una solicitud de INVITACIÓN, Communications Server primero actúa como UAS, responde a la solicitud con 1XX y, a continuación, envía mediante el servidor proxy la solicitud de INVITACIÓN a otra instancia, que responde con el mensaje 200 ACEPTADO. 1xx crea una bifurcación virtual interna, mientras que el mensaje 200 crea una bifurcación real. Cuando se recibe el mensaje 200 ACEPTADO de B, se debe cancelar la bifurcación virtual interna.
El seguimiento de esta excepción no afecta a las funciones de la bifurcación virtual del proxy.
El método getLastAccessedTime de una sesión SIP no proporciona resultados precisos.
Las aplicaciones que deben mantener un seguimiento de lastAccessedTime tendrán que almacenar la información automáticamente en la SipApplicationSession.
synchronized (sas) { Long last = (Long) sas.getAttribute("myLastAccessedTime"); if (last == null) {last = 0}; // do something with the last one // and... // set the new one. sas.setAttribute("myLastAccessedTime", System.currentTimeMillis()); }
Después de eliminar una escucha SIP que está configurada para solicitudes TCP y UDP, la escucha permanece activa durante un cierto tiempo. Las solicitudes UDP que se envían a la escucha podrían recibir una respuesta de la escucha.
No hay una solución conocida. La escucha SIP deja de recibir solicitudes UDP después de un cierto tiempo. Este problema no afecta a las solicitudes TCP.
Descripción
Communications Server genera una excepción cuando recibe una cabecera de contacto sin "<>". Según SIP RFC 3261, no es obligatorio que la dirección contenga "<>". Esto puede provocar problemas de interoperabilidad con otros dispositivos compatibles con SIP.
Solución
Utilice "<>" en la cabecera de contacto.
Communications Server genera excepciones en un valor UUID no válido, en lugar de devolver el mensaje 400 de solicitud errónea. El valor UUID se encuentra en el valor sip.instance de la cabecera de contacto SIP.
No hay una solución conocida.
Este problema aparece de forma intermitente únicamente en Windows. Communications Server no recibe los mensajes UDP.
Defina la siguiente opción de JVM tal y como se describe a continuación y reinicie Communications Server.
org.jvnet.glassfish.comms.disableUDPSourcePort=true