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.