IMG 1010 - SIP Session Timer
Description
The IMG supports SIP Session Timers, an extension of SIP RFC 2543 which allows a periodic refreshing of SIP sessions using the RE-INVITE message.
The refreshing allows both user agents and proxies to determine if the SIP session is still active. a keep alive mechanism for SIP sessions that allows User Agents (UA) or proxies to determine the status of a session and to release it if it is not active, even if a BYE has not been received.
Reference
RFC 4028 Session Timers in the Session Initiation Protocol (SIP)
Configuration
You configure the Session Timer in the IMG 1010 - SIP Session Timer pane. SIP Session Timer is enabled by default.
Overview
When a UAC sends an INVITE, it includes a Supported header field with the option tag 'timer', indicating support for this extension. This request passes through proxies, any one of which may have an interest in establishing a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if none is already there) or alter the value of existing Session-Expires and Min-SE header fields.
If the Session-Expires interval is too low for a proxy (lower than the value of Min-SE that the proxy would wish to assert), the proxy rejects the request with a 422 response. That response contains a Min-SE header field identifying the minimum session interval it is willing to support. The UAC will try again, this time including the Min-SE header field in the request. The header field contains the largest Min-SE header field it observed in all 422 responses previously received. This way, the minimum timer meets the constraints of all proxies along the path.
After several INVITE/422 iterations, the request eventually arrives at the UAS. The UAS can adjust the value of the session interval as if it were a proxy; when done, it places the final session interval into the Session-Expires header field in a 2xx response. The Session-Expires header field also contains a 'refresher' parameter, which indicates who is doing the refreshing -- the UA that is currently the UAC, or the UA that is currently the UAS. As the 2xx response travels back through the proxy chain, each proxy can observe the final session interval but can't change it.
From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.
The refresh requests sent once the session is established are processed identically to the initial requests, as described above. This means that a successful session refresh request will extend the session, as desired.
Implementation Details
If support of session timer is disabled, the Supported header in an outgoing request will not contain the tag ‘timer’. If the incoming request has Require header that contains tag ‘timer’, the request will be rejected with 420 response code.
If support of session timer is enabled, the IMG will always request a session timer, and depending on the configuration the IMG may enforce the session timer even if the remote gateway does not support it.
Session refresh timer will be one half of the session interval. Session end timer will be the two thirds of the session interval, or the session interval minus 32 seconds, whichever is larger.
The IMG can choose to use re-INVITE or UPDATE to do the refresh. If it is configured to use UPDATE, but the remote gateway does not support UPDATE, the IMG will use re-INVITE instead.
If re-INVITE is used, there will be an SDP on it. If UPDATE is used, there will be NO SDP on it.
A re-INVITE or UPDATE request sent within a dialog for purpose other than session refreshes will also have the effect of refreshing the session, and its processing will follow the procedures described below.