SIP sessions and HTTP sessions do not apply the same session expiration time model (Issue 1180)

Description

The session expiration model of SIP sessions is different from the HTTP expiration time logic. In HTTP, the session is automatically extended, outside of the control of the application, whenever a new HTTP request is received in that HTTP session.

With SIP sessions, the application is in control over the duration of the SipApplicationSession (SAS), subject to approval by the SIP container. Applications can use the setExpires method to indicate when the SAS should expire. setExpires defines an expiration time relative to the moment the setExpires method is called. The container can modify, reject, or accept the duration indicated in setExpires. If the session is not invalidated, then the sessionExpired callback is performed at the time defined by setExpires . In this callback, the application can try to extend the duration of the SAS by invoking a new setExpires, again subject to modification, rejection, or acceptance by the container.

For this reason, converged applications that start out with the same expiration time of the SipApplicationSession (SAS) and on the HTTP session will notice that the SAS times out before the HTTP session if new requests were received on the HTTP session.

Solution

The best way to deal with the different expiration time handling of the SIP and the HTTP session is to start with a large enough SAS expiration time, which is the total time that the application session is expected to live (including several HTTP requests). The SAS lifetime could even be set to infinite, specifically if invalidateWhenReady semantics are used, in which case, the SipApplicationSession is invalidated when the last protocol child session becomes invalidated. The initial expiration time for the SAS can be configured in the deployment descriptor.

If the maximum total duration can be estimated in advance, no further code is needed, as it is then appropriate to invalidate both the Sip session and the HTTP session when the SAS expires. If the maximum duration cannot be estimated in advance, then the SipApplicationSession can be extended when it expires, as shown in the code snippet below.

In the SipApplicationSessionListener implementation, you can do something like this:

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 
	}