Solución

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 
	}