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.