Keep-alive
In the field of SIP communication, there are two types of keep-alive mechanisms: device-level keep-alive and session (dialog) keep-alive.
Device-level keep-alive currently has mature and unified solutions that comply with RFC 3261, namely detection using the OPTIONS method. If the peer device returns a 200 OK response, the device is considered alive. Terminals can also detect device-level keep-alive using REGISTER requests.
Manufacturers have never had a unified solution for session keep-alive. Although RFC 4028 defines reINVITE and UPDATE for session keep-alive detection, these two operations are too complex for such purpose. They can trigger media renegotiation, which impairs call quality.
At present, manufacturers share basically the same idea: since normal reINVITE and UPDATE operations will trigger new media negotiation, can we use them without SDP directly for session keep-alive? reINVITE is an exception: reINVITE without SDP has already been used in the 3PCC procedure, so it can no longer be used for session keep-alive.
Based on our experience in interconnecting with equipment from various manufacturers over the years, we summarize the following operations for session keep-alive:
- UPDATE without SDP
- INFO without SDP
- MESSAGE without SDP
Default behavior of the latest version of miniSIPServer:
If the above three types of SIP messages are received during a session, the server will enter the session keep-alive processing flow. If the session exists, a 200 OK response will be returned.
UPDATE and INFO can only be transmitted within a session by nature, so they inherently meet the requirements of keep-alive. We recommend using INFO first, as it is explicitly defined in RFC3261 and will definitely be supported by all manufacturers’ equipment. In contrast, the UPDATE method is defined in a supplementary specification. Some manufacturers’ equipment may not support UPDATE, let alone UPDATE without SDP.
MESSAGE can be transmitted both within a session and outside a session, and is used to deliver instant messages. We restrict MESSAGE without SDP to be transmitted only within a session and reserve it for the session keep-alive process.