Session Initiation Protocol (SIP) Session Timer Glare Handling

defines a mechanism, where periodic SIP requests are sent in order to allow SIP user agents and proxies to determine whether a SIP session is still active. The usage of the mechanism is negotiated using two new SIP header fields (Session-Expires and Min-SE), a new option tag ('timer') and a new SIP response code (422).

1. Section 7.4 of says that, in a session refresh request sent within a dialog with an active session timer, the Session-Expires header field should be included in the request. However, the text is unclear regarding including the Session-Expires header field in a session refresh request when a negotiation of session timer usage is still ongoing, e.g., if one user agent is sending a request that contains a Session-Expires header field and, before it receives the associated 2xx response, receives a request from the peer user agent that also contains a Session-Expires header field. Such scenario might cause a glare situation, with conflicting negotiation parameters. 2. The absence of the Session-Expires header field in a 2xx response to an (re-)INVITE request or UPDATE request means that the mechanism isn't used. This can be used to reject the usage of the mechanism when sending a response. However, the text is unclear that this only applies to cases where the associated SIP request contained a Session-Expires header field.

This document updates , by clarifying the procedures for negotiating usage of the Session Initiation Protocol (SIP) session timer mechanism . The following clarifications are provided: A Session-Expires header field can only be included in a session refresh request if there is no ongoing negotiation of usage of the session timer mechansim. A user agent shall, if it receives a session request with a Session-Expires header field during an ongoing negotiation of usage of the session timer mechanism, send a 491 (Request Pending) response to the request. The absence of a Session-Expires header field in a response will disable usage of the session timer mechanism only if the associated requuest contained a Session-Expires header field.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This section updates the third paragraph in section 7.2 of , by clarifying that the absence of a Session-Expires header field in a response will disable usage of the session timer mechanism only if the associated request contained a Session-Expires header field.

This section updates the fifth paragraph in section 7.4 of , by clarifying that the Session-Expires header field can only be included in a refresh request if there is no ongoing negotiation of usage of the session timer mechanism.

This section updates the second paragraph section 8.1 of , by clarifying that a proxy can insert a Session-Expires header field in a request only if there is no ongoing negotiation of usage of the session timer mechanism.

This section updates section 8.1 of , by clarifying that a session refresh request that is received while there is an ongoing negotiation of usage of the session timer mechanism shall be rejected by a 491 (Request Pending) response. The clarification is done by adding a new paragraph between the fouth and fifth paragraphs of the section.

The security considerations associated with the SIP Session-Timer mechanism are described in . This specification adds clarification text for avoiding session-timer negotiation race conditions, and does not introduce new security considerations.

This specification makes no requests from IANA.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-sipcore-sessiontimer-race-00 Submission of draft-ietf-sipcore-sessiontimer-race-00