The Sippy Softswitch has multiple layers of timeouts that are configurable to control the flow and quality of your calls. Timeouts provide multiple benefits to you as a Sippy operator, including quality assurance, the provision of an added layer of logic for routing optimization, and call redirection accommodating user preferences.


Timeouts are imposed on outbound/upstream traffic to ensure the quality of your connections is delivered. Route forwarding occurs within your routing table to attempt to terminate the call through successive Routing Entries in the event that a gateway (Vendor > Connection) cannot be reached for any number of reasons. Adjusting multiple timeouts is possible with Sippy to empower you to configure routing preferences that are better suited to your network characteristics.


Inbound traffic timeouts depict the call flow of the call through your customer's preferred termination points and the total time that the originating caller waits. Inbound timeouts empower the control over Call Forwarding attempts to multiple selections, Voicemail, and a total time for all termination attempts.


Outbound/Upstream traffic timeouts and their order


Outbound traffic is the calls that have originated at your customer's UA or IP that are sent to your Sippy Softswitch for terminating through your destinations. Calls are Authenticated to an Account, billed by the Tariff associated to the Account's Balance, and routed according to the Routing Entries that are configured in your Routing Group. The calls are passed to your Vendor/Supplier for termination.

  1. Reply Timeout, Sec - Configured on Vendor > Connection, the time that Sippy waits for the 100 reply search. Also known as 100 timeout. The default value is 5 seconds, which is configurable in your Vendor > Connection - Reply Timeout, Sec.
  2. 1xx Timeout, sec - The time that Sippy waits for any session progress response from the Vendor > Connection. The default 1xx Timeout is 10 seconds, which is configurable in your Destination Set > Route - the specific route for your prefix.
  3. 2xx Timeout, sec - The time that Sippy waits for the call to be answered resulting in a 2xx—Successful Response and the call to begin. The default 2xx Timeout is 60 seconds, which is configurable in your Destination Set > Route - the specific route for your prefix.
  4. Final 2xx Timeout, sec - this parameter allows setting the 2xx timeout for the last routing entry in the Routing Entries/Follow Me Entry, by default it's set to 300 seconds, meaning that Sippy will be waiting for 200OK message on the INVITE up to this Final 2xx Timeout. The timeout is applied to the last routing entry in the routing group/last Follow Me Entry only. Since 4.5 version of Sippy on Routing Group preferences the new item has been added:


Note: All three timers (1xx, 2xx, and Final 2xx) are fired just after sending the INVITE to the vendor. E.g. with 2xx timeout = 10 seconds, case the vendor/connection is not able to connect the call (send 200OK message to us) within 10 seconds, we're dropping that vendor/connection from the call flow, and either try another vendor or drop the call. This is applied even if the vendor replied with the first 1xx message at the 9th second of the call.

        

        Let's consider that timeouts are set as below: 
Vendor/connection --> Reply timeout (100 Trying timeout) = 5 sec 

            Destination set --> Route --> 1xx timeout = 10 sec 

            Destination set --> Route --> 2xx timeout = 2 sec 


Next step, a user makes a call and 100 Trying is delayed for 4 sec. 

           As a result, the call is dropped in 2 sec due to 2xx timeout because all timeouts are fired simultaneously. In our case, the first timeout is 2xx which runs out in 2 sec and it doesn't matter that the system should wait for 100 Trying within 4 sec.


Starting from Sippy2020 it's possible to alter the 2xx timeout behavior - instead of starting the count after sending INVITE to Vendor, Sippy can start the count for 2xx timeout after receiving any 1xx response from Vendor. This will help in scenario above and is manageable through System Parameters:

  • for 2020 version find 2xx Timeout Starts in System Management - System Parameters, SIP section
  • for 2021 version find 2xx Timeout Starts in System Management - System Parameters - SIP, Media, LRN - SIP section 

Setting parameter 2xx Timeout Starts to value When Vendor is Tried corresponds to old behavior, When Vendor Sends 1xx to the new.


        5. Max Session Time - The total duration of a call that is allowed once setup has been completed and the call has begun. This parameter is configured on each Account under Advanced Parameters. The Max Session Time affects inbound, outbound, and On-Net calls alike. More information can be found at the linked documents at the foot of this page.


Inbound traffic timeouts and their order

  1. Follow Me timeout - The "Follow Me" feature empowers each Account within Sippy to forward calls to another specified CLD after a trying attempt has been made for a configurable timeframe. Applicable if Account has Follow Me enabled, in Follow Me options.
  2. VM Timeout, secs - The Voicemail timeout determines the point in time at which the call is directed to an Account's configured Voicemail. Applicable if Account has VM Enabled enabled, in Account's preferences.
    NOTE: "VM Enabled" checkbox is selected by default on Account creation (4.5) with a "VM Timeout, secs" of 30 as a default timeout enabled.
  3. Max Session Time - The total duration of a call that is allowed once setup has been completed and the call has begun. This parameter is configured in Account's preferences. The Max Session Time affects inbound, outbound, and Onnet calls alike and has a default value of 3600 seconds. 
  4. Final 2xx Timeout, sec - this parameter allows setting the 2xx timeout for the last routing entry in the Routing Entries/Follow Me Entry, by default it's set to 300 seconds, meaning that Sippy will be waiting for 200OK message on the INVITE up to this Final 2xx Timeout. The timeout is applied to the last routing entry in the routing group/last Follow Me Entry only. Configurable in Routing Group preferences.


Note: More information can be found at the linked documents at the foot of this page.



On-Net calls timeout

  • On-Net timeout - The hardcoded Sippy timeout for Onnet calls is 15 seconds (for 5.0 see below). This affects calls that are made from Account to Account in the Sippy Softswitch with the Timeout initiated when an action is not taken by the receiving Account.


          From 5.0 Sippy introduced 3 additional on-net timeouts (that were hard-coded till 5.0) that are configurable for each routing group, namely a:

onnet_timeout_100  (default value 5 sec)
onnet_timeout_1xx  (default value 10 sec)
onnet_timeout_2xx  (default value 60 sec)

         Parameters are available in Routing Group if in On-Net Routing parameter Use Connection is not set to Disabled:


Hardcoded RFC timeouts

  • A timeout of 32 seconds is a hard-coded as a default timer compliant to RFC 3261 relating to incomplete transactions or unreliable transports: https://tools.ietf.org/html/rfc3261#page-114
  • A hardcoded timeout of 300 seconds is employed in the scenario that there is no 200 OK from the last routing entry gateway within 300 seconds. The call is dropped on 487 Request Expired from the Sippy Softswitch.



RTP Timeout


The default value for Sippy's built-in RTP timer is 60 seconds. There are several features regarding the RTP timeout:

  • It works only in the scenario that media traffic is passing via the server, through Sippy's built-in RTPproxy media proxy.
  • RTP packets are sent by Sippy without a response from the callee's side.
  • The duration of the call will be adjusted for 60 seconds (RTP timer value) once the RTP timer is activated.


Troubleshooting and Identifying calls that are affected by timeouts


Most often, a call that has been ended as a result of a timeout will be interrupted by Sippy with a CANCEL SIP message. By capturing a specific Call ID of an affected call and running a SIP Log Viewer within Sippy's Tools, the SIP Log will display a CANCEL after the specified length of time, as can be seen in the following image. The CANCEL was sent by the originating switch, in this case, identifying a timeout of 15 seconds which is an Onnet call timeout.




More documentation/information:


API application manipulation documentation: