The basic SIP as defined by RFC 3261
does not include a "keep alive"
mechanism. As such, it is possible that one end of a session may fail and be unable to signal the release of the session. One possible scenario where this may occur is in the cases where an internal fault on a remote node results in the call instance being lost on the remote node. This would result in no further signalling from the remote node associated with that call instance. The local node would have no indication from the remote node should that party release the call.
(G)MSC Servers may support the SIP Session Timer as specified in RFC 4028
as a means to determine whether a SIP session is still active by attempting to perform a session refresh, and therefore as a means to know when resources may be released if one end of the session fails.
The procedure negotiates the rate at which the session refresh occurs. The procedure is compatible and still operational should the far end or other SIP entity not support the Session Timer procedure.
shows a message sequence example for the optional use of the SIP Session Timer procedures. During call origination each MSC Server may negotiate the use of the SIP Session Timer. This is accomplished through the exchange of the Session-Expires and Min-SE SIP header in the INVITE request and 2xx response. Support of the session timer extension procedure is indicated by placing the "timer"
tag in the Supported header in the INVITE request. The use of session continuity and the session expiration timer value may be negotiated independently between each MSC Server pair. The session refresh request may be either an INVITE request or UPDATE request. The use of the UPDATE request does not require the exchange of SDP and is recommended by RFC 4028
When a failure of the session continuity is detected, the call will be cleared by the MSC servers independently on either side of the failure point according to the normal call clearing procedures (see clause 7