SIP 会话的会话到期模型与 HTTP 失效时间逻辑不同。在 HTTP 中,HTTP 会话在收到新的 HTTP 请求时会自动延长,并不受应用程序的控制。
而对于 SIP 会话,应用程序可在 SIP 容器批准下,控制 SipApplicationSession (SAS) 的持续时间。应用程序可使用 setExpires 方法来指示 SAS 应该在何时失效。setExpires 会相对于调用 setExpires 方法的时刻指定一个失效时间。容器可以修改、拒绝或接受 setExpires 中指示的持续时间。如果会话没有失效,则在 setExpires 定义的时刻执行 sessionExpired 回调。在回调中,应用程序可通过调用新的 setExpires 来尝试延长 SAS 的持续时间,但仍由容器来决定是否修改、拒绝或接受。
出于这个原因,尽管在聚合应用程序启动时,SipApplicationSession (SAS) 和 HTTP 会话上的失效时间是相同,如果在 HTTP 会话上收到了新请求,SAS 将会在 HTTP 会话之前超时。
解决 SIP 和 HTTP 会话到期时间不同的最佳方法是,启动时设置足够长的 SAS 失效时间,大小相当于应用程序会话预期存活的总时间(包含几个 HTTP 请求)。甚至,还可以将 SAS 生命周期设置为无限长,尤其是在使用了 invalidateWhenReady 语义时;在这种情形下,SipApplicationSession 到最后一个协议子会话到期时才会失效。SAS 的初始失效时间可以在部署描述符中进行配置。
如果可以事先估计总持续时间的最大值,则无需使用更多代码,因为在 SAS 失效时 SIP 会话和 HTTP 会话也会同时失效。如果不能事先估计总持续时间的最大值,则可在到期时延长 SipApplicationSession,代码片段如下所示。
在 SipApplicationSessionListener 实施中,可使用类似如下的代码:
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 }