Browsed by
Tag: update

Keep-alive

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? Of course, 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.

Final V31

Final V31

We released the final V31, that means we will be focus on next very important version V32 which will be our next LTS version to replace V24.

In fact, lots of features have been merged into the latest V31, and we will stay with V31 for several months since it is the base line of V32.  Please refer to following sections for more details about the key points.

Tools upgraded

In Windows platforms, we upgrade several important tools for V31.  The VC++ is upgraded to VC2010, so new MSS is using VC2010 run-time libraries. It could be powerful and better than previous VC2008 which has several manifest problems in customers’ environments.

The basic SSL library is migrated from OpenSSL to LibreSSL in MSS for windows. In Linux system, we still keep OpenSSL at this time and will move to LibreSSL in future. LibreSSL provides official windows library and we think it is optimized to be better than OpenSSL. If you are deploying “SIP over TLS”, this modification could be much better and safer then previous versions.

SIP stack upgraded

In recent days, we work with several customers to process scenarios with different IMS networks. We have to say we met several strange and very old SIP call flows. That’s ok, V31 is refined to fit these requirements.

“18X with/without SDP” flows are supported. “18X” means 180 or 183, so you can see several possibilities, such as “180 with SDP”, “180 without SDP”, “183 with SDP”, “183 without SDP”, and so on, and their orders are different. Sometimes we receive 180 firstly, sometimes we receive 183 firstly. In most scenarios, these messages are used to play different ring-back tone, so it is not only something with SIP stack but also something with media connections which means MSS inner MG module is upgraded too.

Another key point is SIP-UPDATE. Some IMS networks don’t use 18x to bring ring-back tone media information, they use SIP-UPDATE messages.  In another IMS network, we find it use “SIP-UPDATE without SDP” to keep alive in dialog. It is an interesting topic and we hope to write another blog to describe these scenarios carefully. Anyway, V31 is upgraded to support part of SIP-UPDATE to work with such IMS networks. We don’t implement all features about SIP-UPDATE and MSS will not invoke SIP-UPDATE flow by itself. If MSS wants to change media, it always invokes reINVITE procedures.

“tel” number format is supported in V31. Traditional soft-switch networks could transfer this format to MSS when they work with PSTN networks. We don’t understand why these soft-switch don’t convert it to SIP URL. Now V31 can accept that. Of course, MSS will never send out such number format.