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:
- 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.
- If the refresher never gets a response to a session refresh request, it will send a BYE to terminate the session.
- If the refresher fails to refresh based on the established session expires value the session will be torn down.
- If the non-refresher does not receive a session refresh request before it expires it may send a BYE.
VSXi SIP Session Timers Configuration
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.
Troubleshooting problems
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.
Case 1: 408 refresh failure CDR
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.
Hint: The CDR will indicate the device causing the failure (not responding to the VSXi refreshes). In the example above "Termination Stack Cause" points that the Termination TID caused the problem and its SIP Profile needs to be adjusted.
Case 2: Issue handling UPDATE Method causes call drop
Another issue seen is that the far-end device advertises support for the UPDATE Method in the form of a SIP Allow header.
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, UPDATE
Based on the RFC it is RECOMMENDED that the UPDATE method is used when supported.
If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE.
However, when the VSXi issues the refresh in the form of an UPDATE instead of a re-INVTE the device doesn't respond.
Solution: The recommendation in this case is to disable Session Timers.
An alternate fix is to create an SMC Profile that will strip the UPDATE method from the Allow header. The VSXi will refresh with a re-INVITE instead of an UPDATE.
{
"ProfileID": 17,
"ProfileName": "Remove UPDATE method from Allow Header",
"Rules": [
{
"MsgType": "RESPONSE",
"RspCodeList": "200",
"Conditions": [
{
"Header": "Allow:",
"HeaderAttr": "HEADER_SECTION_ONLY",
"Regex1": "UPDATE",
"Operator": "NEQ",
"RightOperand": ""
}
],
"Action": "REPLACE_MSG",
"ReplaceDefs": [
{
"ReplaceType": "FINDSUB_LINES",
"Header": "Allow:",
"HeaderAttr": "HEADER_SECTION_ONLY",
"Regex1": ",UPDATE",
"Output": ""
}
]
}
]
}
Case 3: Call drops at half-point with Normal BYE
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.
{
"ProfileID": "100",
"ProfileName": "Replaces Expires Value",
"Rules": [{
"MsgType": "RESPONSE",
"RspCodeList": "200",
"Conditions": [{
"Header": "Session-Expires",
"HeaderAttr": "HEADER_SECTION_ONLY",
"RegEx1": "[0-9]+;",
"RegEx2": "[0-9]+",
"Operator": "EQ",
"RightOperand": "1800"
}],
"Action": "REPLACE_MSG",
"ReplaceDefs": [{
"ReplaceType": "FINDSUB_LINES",
"Header": "Session-Expires",
"HeaderAttr": "HEADER_SECTION_ONLY",
"RegEx1": "[0-9]+;",
"RegEx2": "[0-9]+",
"Operator": "EQ",
"RightOperand": "1800",
"Output": "900"
}]
}]
}
Case 4: Call drops at session interval
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"
}
]
}
]
}
Case 5: SIP 422 session timer too small.
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 10.0.0.2:5060;branch=z9hG4bK1sansay2454621207rdb16213
To: <sip:+19055559083@10.0.0.147>;tag=b4723183fs
From: <sip:+14695558019@10.0.0.32;isup-oli=00>;tag=sansay2454621207rdb16213
Call-ID: 1035065748-0-3965751690@10.0.0.31
CSeq: 1 INVITE
Date: Mon, 06 Jan 2020 23:56:14 GMT
Min-SE: 28800
Content-Length: 0
Best practices
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.
Frequently Asked Questions
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.