In order to manage long-running call sessions there are multiple settings that should be considered in this scenario; any one of these would "tear down" a session that would be considered no longer valid. The recommendation in this area is to set a finite value for each of these timeouts that is reasonable for the SIP network in question. Most of these settings (with the exception of the "T" timers) are to be found in the "sip-settings" container or "media" container (in the case of the media inactivity-timeout) within a session-config.
- A session-config may be found in one of 4 locations:
A vsp/session-config-pool entry (vsp/session-config-pool/entry xyz)
A policy rule’s session-config (vsp/policies/session-policies/policy default/rule xyz/session-config
A "directly attached" session-config (such as one configured in a dial-plan, registration plan, etc.)
With regards the settings in the following steps, a value of "0" means there is no timeout.
- SIP "T" Timers
These timers (T1, T2, and T4) can be found in the vsp/static-stack-settings and affect how a session is managed (and retransmissions are sent) until a response is received. Note that a restart is required to make any changes to these settings effective.
While the operation of these timers is a very complex description provided in RFC 3261, it is worth noting here the following excerpt from the RFC:
"For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission."
For further information, refer to sections 184.108.40.206 through 17.2.2 in RFC 3261.
Defaults to: T1 = 2000ms -- T2 = 4000ms -- T4 = 5000ms
The T4 timer is the client transaction timeout (on the UAS side of the B2BUA) and the vsp/static-stack-settings/max-udp-session-linger is the server transaction timeout (on the UAC side of the B2BUA)
The next item, the "max-retransmissions" setting, limits the T timer retransmissions.
Specifies the maximum number of times the Net-Net OS-E / Net-Net 2600 SBC attempts to retransmit SIP messages at the transaction level.
By setting this value through the session-config, you can apply different retransmission values to different message types.
For example, you might want a higher number of retransmissions for a REGISTER message, and a lower number (faster response) for an INVITE. This value does not apply to OPTIONS messages.
Use the settings max-options-retransmissions property to control OPTIONS retransmissions.
This timeout specifies how long an INVITE session can stay in the authentication state (i.e. from the transmission of a 401/407 response until the receipt of a subsequent request; typically this subsequent request would include an auth digest).
Defaults to 0 (disabled) - something like 30 seconds is more then enough in more environments
This period overlaps with the middle portion of the session-timeout, if a 401/407 response is part of the communication.
This timeout applies from the receipt or transmission of a 18x message until the receipt or transmission of a 200OK message; effectively governing the "Ringing" time.
Defaults to 0, something like 90 is more then enough in most environments.
This period overlaps the tail-end of the session-timeout.
This timeout applies from when a session is created (e.g. the receipt or transmission of an INVITE) until it is established (i.e. an ACK is received) - this defaults to 300 which could likely be lowered in most environments.
Defaults to 300, and this seems to be more then enough in most environments.
This period overlaps the session-provisional-timeout.
This applies after a session has been established (i.e. the receipt or transmission of the ACK) and runs without interruption indefinitely (i.e. until the timer itself has elapsed).
Note that this setting will apply to every dialog/session starting SIP Method other then the MESSAGE method.
Currently set to 0, this should be set longer then the longest expected call. In some environments this is set as low as two hours (7200) and as high as 48 hours (172800) - so this is something that will be very unique to each SIP network.
However, it is strongly recommended to set this to a non-zero number to keep sessions from potentially existing indefinitely.
This timer is effectively the same as the "session-duration-max" timer, but specifically for the SIP MESSAGE method. The receipt/transmission of a MESSAGE creates a session on the CXC. This timer starts when a MESSAGE is received and is reset upon the receipt of another MESSAGE on the same session. Without this timer, such a session would never be torn down; as such there is a non-zero default for this setting.
Defaults to 1800 seconds. This is a reasonable setting, but like the session-duration-max this has to be evaluated as it will very likely need to be changed depending on the unique needs of each SIP network.
This setting is actually found in the "media" container within a session-config (see above description for areas where a session-config may be found):
This timeout applies when a session is anchored and there is no RTP traffic seen in either direction.
If the media->anchor setting in the applicable session-config is set to "auto" (which means the CXC doesn't always anchor each call) then this setting will be applicable to every call.
Defaults to 0. The most common setting in this area is usually somewhere around (or less then) 300 seconds; 5 minutes.
This is due to the fact that if a call is anchored, and there are no RTP packets seen in either direction for that duration, it is very likely that the call is no longer a legitimate call.
For further reference, these settings are documented in the Acme Packet online help and the product documentation.