By default when a SIP Invite is sent from a SIP endpoint to the Acme Packet SBC, the default expires timer is used to determine when the Invite will timeout based on no response. Changing this globally may not produce the desired result as this impacts all Invites to all devices across all realms. In the case of routing calls to a PSTN peering provider where there are two or more destinations provided in the Contact header, it may be desirable to shorten the timer to reduce post dial delay in the event the first Contact an Invite is sent to is experiencing an issue that is impacting call processing. This assume the device (session agent) is still responding to SIP OPTIONS PING messages and is therefore in-service, but unable to complete calls.
If the ITSP does not respond to the Invite the SBC will wait 32 seconds before the Invite will timeout. More than likely the calling party will abandon the call before waiting 32 seconds which means sending further Invites to secondary or tertiary gateways won’t do much good. In the event there is more than one Contact in the Contact header or the SBC is set to perform Load Balancing using a Session Agent Group (SAG), it is best to change the trans-expire timer on the SIP Interface communicating with the ITSP to a value that is more feasible.
In the above scenario the SIP Interface that peers with the ITSP has a trans-expire value of 5. This means once the Invite is sent to the first Contact, the SBC will wait for a response for 5 seconds. If no response is received a new Invite is sent to the next Contact address (or Session Agent in the SAG). This helps reduce post-dial delay and provides a more acceptable timer for failover to an secondary or tertiary destination. Setting the timer on the SIP Interface helps keep the behavior unique to a particular destination.
Hey Mark,
I ran into a problem a customer location recently where we set trans-expire to 4 seconds. This value created an issue where the SD cancelled the outbound call after it received the 100 trying, but no 18x. As a result, we had to back this timer off to a less agressive value. However, searching solutions I recently found that the SD transitions to Timer C after receipt of any provisional response *except* 100 Trying. So this means that the SD must see a 18x message to stop the initial timer (controlled by trans-expire). We have the ability to override this default behavior by adding the aptly named sip-config option “set-inv-exp-at-100-resp”. This will force the SD to transition to Timer C upon receipt of a 100 Trying as well, therefor not canceling the call after a 100 was received.
However, this could create a situation where the call may never failover, because timer C is 180 seconds.
So in the end, I think setting trans-expire to a less aggressive time is a better option, but the value needs to be carefully chosen! In my case 4 seconds was too agressive. I also just did a turn-up with Level 3 and they were set to 5 seconds, and my customer had call failures on CFW calls. So Level 3 had to back of trans-expire for my customer. I would advocate for a slightly higher value than 5 seconds.
Great Blog.
-Aaron