Subject: [sipcore] Draft new: draft-holmberg-sipcore-rkeep-00

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jun 2012 07:41:24 +0200

Hi,

I've submitted a new draft, draft-holmberg-sipcore-rkeep, which defines a mechanism for a SIP entity to indicate willingness to receive keep-alives from an adjacent entity.

The mechanism is based on RFC 6223, which defines a similar mechanism for indicating willingness to send keep-alives.

The need for this comes from the smart phone environment.  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 frequency, 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.

RFC 6223, and this draft, defines the usage of STUN for the keep-alives, so the STUN response will act as the keep-alive.
Regards,

Christer