VSXi SIP Session Timers


The VSXi supports the SIP Session Timers (RFC4028) SIP extension. Session Timers provide a mechanism to detect the status of a session and disconnect the call if the session is not active.  Session Timers help prevent hung calls from stay up longer.

During the establishment of a SIP call the UAC (originating endpoint) and UAS (terminating endpoint) will determine if Session Timers will be used during the session, who (UAC or UAS) will be the refresher and an interval dictating how  often session refreshes will take place.

At some point before the session interval expiration, the active refresher generates a session refresh request. The session refresh may come in the form of a re-INVITE or an UPDATE.  The INVITE method will normally be used unless the remote UA has indicated support for the UPDATE method (via a SIP Allow header).

The following scenarios may happen when a session uses timers:

  1. If the refresher receives a 2XX response from the target unit the session will stay up and another refresh will be issued when the interval has expired.
  2. If the refresher never gets a response to a session refresh request, it will send a BYE to terminate the session.
  3. If the refresher fails to refresh based on the established session expires value the session will be torn down.
  4. If the non-refresher does not receive a session refresh request before it expires it may send a BYE.

The VSXi SIP Session Timers setting is available at the SIP Profile level.  SIP Profiles provide the flexibility to re-use the same characteristics to different devices or create a specific profile just for a specific resource/trunk.

To deal with a variety of possible scenarios, the VSXi supports three modes:


  • Enable_Active. The VSXi will advertise that it supports session timers and will request to be the refresher.
  • Enable_Passive. The VSXi will advertise that it supports session timers and request the other-party (UAS) to be the refresher.
  • Disabled: The VSXi will not advertise session timers.

The Session Timer Interval is the proposed session refresh interval. Depending on the role of the VSXi this is the suggested refresh interval (that may be overridden) or the enforced interval. Recommended values are 600s and 1800s depending on the application; very short intervals are not recommended. Per the RFC:

   Small session intervals can be destructive to the network.  They
   cause excessive messaging traffic that affects both user agents and
   proxy servers.  They increase the possibility of 'glare' that can
   occur when both user agents send a re-INVITE or UPDATE at the same
   time.  Since the primary purpose of the session timer is to provide a
   means to time out state in SIP elements, very small values won't
   generally be needed.  30 minutes was chosen because 95% of phone
   calls are shorter than this duration.  However, the 30 minute minimum
   is listed as a SHOULD, and not as a MUST, since the exact value for
   this number is dependent on many network factors, including network
   bandwidths and latencies, computing power, memory availability,
   network topology, and, of course, the application scenario.  After
   all, SIP can set up any kind of session, not just a phone call.  At
   the time of publication of this document, 30 minutes seems
   appropriate.  Advances in technologies may result in the number being
   excessively large five years in the future.

The following scenarios are real-world scenarios. We will describe the symptom of what you will see in a CDR and/or PCAP and provide a solution to the issue.

All calls through a specific Trunk ID that exceed the configured SIP Session Timer interval result in CDRs with a "Refresh Failure" release cause. In the example below all calls to TID 8068 fail a he 2699s mark with Session Timer configured for 2700s. This is an indicator that TID 8068 likely doesn't support Session Timers.

Solution: The recommendation in this case is to disable Session Timers.


If a UAC knows that its peer supports the UPDATE method, it is
   RECOMMENDED that UPDATE be used instead of a re-INVITE. 

Solution: The recommendation in this case is to disable Session Timers.


When Session Timers is enabled, some devices interpret the RFC's session refresh sending interval as a literal statement.

It is RECOMMENDED that this refresh be sent once
   half the session interval has elapsed.

In this case if Session Timers of 1800s was negotiated and the VSXi is the UAC (refresher) the UAS endpoint, notably a Cisco CUBE, will tear down the session at the 900s mark.

A workaround to this issue consists in adjusting the Session Expires timer in half via an SMC Profile applied to the 200 OK respone that establishes the dialog.


Sometimes you will see that a BYE coming at the session interval. For example if Session Expires of 1800s was established the BYE arrives at 1800s. We have seen this issue happens on devices that do not properly follow the RFC.

Let's look at this example:

The above trace reveals that the UAS Session Expires was 1800s and is asking the UAC to be the refresher. This particular trace had its INVITE with no Session Timers. In this case the UAS illegitimately enabled Session Timers. 

Possible solutions include disabling Session Timers on the far-end or creating an SMC rule that will drop the Session-Expires header for this Trunk ID if received.

  "ProfileID": 18,
  "ProfileName": "Remove Session-Expires Line",
  "Rules": [
      "MsgType": "RESPONSE",
      "ReqMethod": "200",
      "Conditions": [
          "Header": "Session-Expires:",
          "HeaderAttr": "HEADER_SECTION_ONLY",
          "Operator": "NEQ",
          "RightOperand": ""
      "Action": "REPLACE_MSG",
      "ReplaceDefs": [
          "ReplaceType": "DELETE_LINES",
          "Header": "Session-Expires:",
          "HeaderAttr": "HEADER_SECTION_ONLY"


If you see your calls rejected with a 422 Session Timer too small you will need to increase the configured SIP Session Timer interval. Sometime's there's a misconception that the Min-SE needs to be adjusted. The Min-SE is not the problem. The problem is the configured session timer interval.

You can set your SIP Profile to match the 422's Min-SE:

SIP/2.0 422 Session Timer too small
Via: SIP/2.0/UDP;branch=z9hG4bK1sansay2454621207rdb16213
To: <sip:+19055559083@>;tag=b4723183fs
From: <sip:+14695558019@;isup-oli=00>;tag=sansay2454621207rdb16213
Call-ID: 1035065748-0-3965751690@
Date: Mon, 06 Jan 2020 23:56:14 GMT
Min-SE: 28800
Content-Length: 0


Session Timers are a useful feature, however, a significant amount of devices do not support it or are non-conforming with respect to the RFC. If session timer is enabled towards non-conforming devices calls will get disconnected  around the negotiated session refresh interval. VSXi CDRs will print a "Refresh Failure" release cause when a call is disconnected to do a session refresh failure.

Wholesale or SIP trunking: In this environment you do not have control over the devices you are interfacing. During the interop phase verify with your customer, vendor or partner if session timers are supported.

If unclear, try placing a call (in enable_active mode) with the intent of exceeding the configured session interval. If the call stays up, session timers are supported. If the call is disconnected session timers are not supported and session timers should be disabled.

Access/retail core network: In a core network you have control of Class-5 or Feature Servers within your network. In this case you can opt to set Session Timers to enable_passive on the VSXi. This will ensure Session Timers will be in effect and will allow your Feature Server(s) to be the refresher. It is not recommended to enable session timers towards the edge/public side due to the wide variety of devices on the access side.


What happens when an ingress and egress resource have differing Session Timer Intervals? Is each side refreshed separately or does one value override the other for both sides? Session Timers run on a per-leg basis, not per-session basis. Each leg is independent. The same way, one leg may have timers enabled and the other not. This is also why SIP re-INVITEs are local and do not propagate end-to-end.