Indication of support for reverse keep-alive

RFC 6223 defines a mechanism, which allows adjacent SIP entities to explicitly negotiate usage of the NAT keep-alive mechanisms defined in SIP Outbound . The "keep" parameter allows SIP entities, when sending a request, to indicate willingness to send keep-alives, and it allows SIP entities, when sending a response, indicate willingness to receive keep-alives. In some cases a SIP device, located behind a NAT, is not able to send keep-alives. One reason can be that the scheduling policy of the operating system used by the SIP device does not meet the requirement for sending keep-alives using a proper interval, meaning that NAT bindings might not be kept. In such cases, the device needs to request another device to send keep-alives towards the itself. Then, the keep-alive response message sent from the SIP device will ensure that the NAT binding is kept open. This specification defines a new Session Initiation Protocol (SIP) Via header field parameter , "rkeep". The "rkeep" parameter allows a SIP entity to indicate willingness to receive keep-alives from its adjacent downstream SIP entity, the adjacent downstream SIP entity to indicate willingness to send keep-alives, and for SIP entities willing to send keep-alives to inform the receiver about the keep-alive interval. The following sections describe use-cases where a mechanism to explicitly negotiate usage of keep-alives is needed.

The mechanism defined in this specification MUST only be used by SIP entities that are not able, e.g. because the scheduling policy of the operating system used by the SIP device does not meet the requirement for sending keep-alives using a proper interval.

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 BCP 14, RFC 2119 .

Keep-alives: The keep-alive messages defined in RFC 5626. "rkeep" parameter: A SIP Via header field parameter that a SIP entity can insert in the topmost Via header field that it adds to the request, to explicitly indicate willingness to receive keep-alives from its adjacent downstream SIP entity. A SIP entity can add a parameter value to the "rkeep" parameter, or remove an existing parameter value, in a response to explicitly indicate willingness to send keep-alives to its adjacent upstream SIP entity. SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261. Adjacent downstream SIP entity: The adjacent SIP entity in the direction towards which a SIP request is sent. Adjacent upstream SIP entity: The adjacent SIP entity in the direction from which a SIP request is received.

This section describes how SIP UAs and proxies negotiate usage of keep-alives associated with a registration, or a dialog, which types of SIP requests can be used in order to negotiate the usage, and the lifetime of the negotiated keep-alives. SIP entities indicate willingness to receive keep-alives from the adjacent downstream SIP entity using SIP requests. The associated responses are used by SIP entities to indicate willingness to send keep-alives. Both SIP entities can indicate a recommended keep-alive interval. The procedures to negotiate usage of keep-alives are identical for SIP UAs and proxies. NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from an adjacent SIP entity, sending of keep-alives towards that adjacent SIP entity needs to be separately negotiated.

The lifetime of negotiated keep-alives depends on whether the keep-alives are associated with a registration or a dialog. The rules defined in RFC 6223 also apply when keep-alives are negotiated using the 'rkeep' Via header field parameter.

As defined in RFC 5626, a SIP entity that supports receiving of keep-alives must act as a STUN server . The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626. When a SIP entity sends or forwards a request, if it wants to negotiate the receiving of keep-alives associated with a registration, or a dialog, it MUST insert a "rkeep" parameter in the topmost Via header field that it adds to the request, to indicate willingness to receive keep-alives. The SIP entity MAY add a parameter value to the "rkeep" parameter before sending or forwarding the request. The parameter value, if present and with a value other than zero, represents a recommended keep-alive interval, given in seconds. When the SIP entity receives the associated response, if the "rkeep" parameter in the topmost Via header field of the response contains a "rkeep" parameter value with a non-zero value, or a value which is different from the value sent in the request (counting a "rkeep" parameter without a value) it MUST be prepared to start receiving keep-alives from the same destination from where it received the response which was used to negotiate the receiving of keep-alives. If the "rkeep" parameter does not contain a value, the SIP entity MUST assume that keep-alives will be sent using the recommended keep-alive interval, if any, that the SIP entity added to the associated request. If the associated response contains the same "rkeep" parameter value as the request (counting a "rkeep" parameter without a value), the SIP entity MUST assume that keep-alives will not be sent. Once a SIP entity has negotiated receiving of keep-alives associated with a dialog towards an adjacent SIP entity, it MUST NOT insert a "rkeep" parameter in any subsequent SIP requests, associated with the dialog, towards that adjacent SIP entity. Such "rkeep" parameter MUST be ignored, if received. Since an ACK request does not have an associated response, it can not be used to negotiate usage of keep-alives. Therefore, a SIP entity MUST NOT insert a "rkeep" parameter in the topmost Via header field of an ACK request. Such "rkeep" parameter MUST be ignored, if received. A SIP entity MUST NOT indicates willingness to receive keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set . If an INVITE request is used to indicate willingness to receive keep-alives, as long as at least one response (provisional or final) to the INVITE request contains a "rkeep" parameter with a parameter value which is different from the value in the request (counting a "rkeep" parameter without a value) it is seen as an indication that the adjacent downstream SIP entity is willing to send keep-alives associated with the dialog on which the response is received.

As defined in RFC 5626, a SIP entity that supports sending of keep-alives must act as a Session Traversal Utilities for NAT (STUN) client . The SIP entity must support those aspects of STUN that are required in order to apply the STUN keep-alive mechanism defined in RFC 5626, and it must support the CRLF keep-alive mechanism defined in RFC 5626. RFC 5626 defines when to use STUN, respectively double-CRLF, for keep-alives. When a SIP entity sends or forwards a response, and the adjacent upstream SIP entity indicated willingness to receive keep-alives without a recommended keep-alive interval, if the SIP entity is willing to send keep-alives associated with the registration, or the dialog, to the adjacent upstream SIP entity it MUST add a parameter value to the "rkeep" parameter, before sending or forwarding the response. The parameter value, represents the keep-alive interval, given in seconds, that the sender of the keep-alives will use. If the adjacent upstream SIP entity provided a recommended keep-alive interval, and if the SIP entity is willing to send keep-alives using that interval, it MUST remove the "rkeep" parameter value which indicates the recommended keep-alive interval, before sending or forwarding the response. NOTE: The reason for removing the "rkeep" parameter value is to indicate that the SIP entity supports the mechanism, and simply does not forward an unknown parameter. If the adjacent upstream SIP entity provided a recommended keep-alive interval, and if the SIP entity is willing to send keep-alives using a different interval, it MUST modify the "rkeep" parameter value which indicates the recommended keep-alive interval, before sending or forwarding the response. There might be multiple responses to an INVITE request. When a SIP entity indicates willingness to send keep-alives in a response to an INVITE request, it MUST add a parameter value to the "rkeep" parameter in at least one reliable response to the request. The SIP entity MAY add identical parameter values to the "rkeep" parameters in other responses to the same request. The SIP entity MUST NOT add different parameter value to the "rkeep" parameters in responses to the same request. The SIP entity SHOULD indicate the willingness to send keep-alives as soon as possible. In case an INVITE request is forked , there might be responses associated with multiple early dialogs . When a SIP entity indicates willingness to send keep-alives, it MUST add a parameter in at least one reliable response per early dialog. Once an early dialog is terminated (e.g. when a 200 OK final response associated with anohter early dialog is received) the SIP entity MUST cease sending keep-alives negotiated for the terminated early dialog. A SIP entity MUST NOT indicates willingness to send keep-alives associated with a dialog, unless it has also inserted itself in the dialog route set . When the SIP entity has indicated willingness to send keep-alives, it MUST start sending keep-alives towards the same destination where it sent the response used to indicate willingness to send keep-alives.

If a SIP entity sends a SIP response, where the topmost Via header field contains a "rkeep" parameter with a non-zero value that indicates the keep-alive interval, given in seconds, it MUST use the procedures defined for the Flow-Timer header field . According to the procedures, the SIP entity must send keep-alives at least as often as the indicated keep-alive interval, and if the SIP entity uses the indicated keep-alive interval then it should send its keep-alives so that the interval between each keep-alive is randomly distributed between 80% and 100% of the indicated keep-alive interval. This specification does not define any semantic for a "rkeep" Via header parameter value with a zero value. A SIP entity MUST NOT insert a zero value to a "rkeep" parameter. A SIP entity that receives a "rkeep" parameter with a zero value SHOULD NOT assume that the sender of the response will send keep-alives towards the SIP entity. This specification does not specify actions to take if negotiated keep-alives are not received. As defined in RFC 5626, the receiving SIP entity may consider a connection to be dead in such situations. NOTE: The Flow-Timer header field has no impact on keep-alives negotiated using the "rkeep" Via header field parameter.

| | | Via: Alice;rkeep | | | |--- REGISTER-------------->| | | Via: P1 | | | Via: Alice;rkeep | | | | | |<-- 200 OK ----------------| | | Via: P1 | | | Via: Alice;rkeep | |<-- 200 OK ---------------| | | Via: Alice;rkeep=30 | | | | | | | | | *** Timeout *** | | | | |<=== STUN request ========| | |=== STUN response =======>| | | | | | *** Timeout *** | | | | |<=== STUN request ========| | |=== STUN response =======>| | | | | ]]>

This section describes the syntax extensions to the ABNF syntax defined in RFC 3261, by defining a new Via header field parameter, "rkeep". The ABNF defined in this specification is conformant to RFC 5234 .

This specification defines a new Via header field parameter, called "rkeep", in the "Header Field Parameters and Parameter Values" sub-registry as per the registry created by . The syntax is defined in . The required information is:

The Security Considerations in RFC 6223 apply.

The following persons provided comments and feedback on the document: Paul Kyzivat, Dan Wing, Gethin Liddell and Venkata Ramesh Balabhadruni.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-sipcore-rkeep-03 New version submitted due to expiration of previous version. Changes from draft-holmberg-sipcore-rkeep-02 New version submitted due to expiration of previous version. Changes from draft-holmberg-sipcore-rkeep-01 New version submitted due to expiration of previous version. Changes from draft-holmberg-sipcore-rkeep-00 Forking text added. Editorial corrections. - s/6263/6223. - s/frequency/interval. Example added.