The IESG has approved the following document: - 'Indication of support for keep-alive' (draft-ietf-sipcore-keep-12.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-keep/ Technical Summary This document defines a mechanism by which adjacent SIP entities can negotiate the use of the NAT keep-alive mechanism defined in RFC 5626, even if the other mechanisms described in RFC 5626 are not being applied. Working Group Summary The document was largely without controversy during its lifetime. Early in the discussion of the mechanism (in the SIP working group), several people challenged the utility of a mechanism for negotiating this kind of behavior (as opposed to simply sending keep-alives unilaterally). Ultimately, the working group decided that the chances for things "going wrong" under those circumstances were too great, and elected to define an explicit negotiation mechanism. Document Quality Several implementors and network operators have indicated that the have need of and plan to implement the mechanism described in this document. It is not known whether any implementations of the mechanism exist. RFC Editor Note: (This note applies to -12 of the document) In section 10, OLD: To lower the chances of the malicious SIP entity's actions having adverse affects on such proxies, when a SIP entity sends STUN keep- alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages, it MUST, based on the procedure in section 4.4.2 of RFC 5626, after 7 retransmissions, or when an error response is received for the STUN request, stop sending keep-alives for the remaining duration of the dialog (if the sending of keep- alives were negotiated for a dialog) or until the sending of keep- alives is re-negotiated for the registration (if the sending keep- alives were negotiated for a registration). NEW: To lower the chances of the malicious SIP entity's actions having adverse affects on such proxies, when a SIP entity sends STUN keep- alives to an adjacent downstream SIP entity and does not receive a response to those STUN messages (as described in section 7.2.1 of RFC 5389, [RFC5389] it MUST stop sending keep-alives for the remaining duration of the dialog (if the sending of keep- alives were negotiated for a dialog) or until the sending of keep- alives is re-negotiated for the registration (if the sending keep- alives were negotiated for a registration). In Section 8.1, OLD: This section describes the syntax extensions to the ABNF syntax defined in RFC 3261, by defining a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. NEW: This section extends the ABNF definition of via-params from RFC3261 by adding a new Via header field parameter, "keep". The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. EQUAL is defined in RFC 3261. DIGIT is defined in RFC 5234. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
