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 
	}