[cisco-voip] CUBE SIP TCP connection timeout

Daniel Pagan dpagan at fidelus.com
Thu Feb 5 16:46:31 EST 2015 

Since we're on the topic of SIP timers, timeouts, etc., I figured why not share some additional information with the list. Below is a write-up of SIP timers T1 and Timer-B I wrote some time ago. Hopefully someone will this useful at some point.

This isn’t mentioned in CUCM service parameter descriptions, but really the SIP TRYING timer represents what’s called the SIP T1 timer. T1 is a baseline value used by another timer called Timer-A, and it’s what controls the intervals which our INVITEs are sent when no response is received. There's also Timer-B, which determines how long to wait, in total, before the request itself should expire, and is calculated by 64 * T1. So if our T1 (TRYING) timer is 500ms, then our Timer-B value is 32 seconds. Note this does not impact SIP over TCP when the TCP socket itself fails to establish since a three-way handshake would first be required.

The important part about the SIP T1 timer and INVITE requests is that T1 does not exactly define how long to wait between re-transmissions. Instead, we multiply T1 to determine how long to wait between INVITE retry attempts. Here’s an excerpt from RFC 3261 describing this:

"If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions).  For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). When timer A fires [expires], the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1.  ……. 

When timer A fires [expires] 2 x T1 seconds later, the request MUST be retransmitted again. This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the "calling" state."

The default value for T1 is 500 ms.  T1 is an estimate of the RTT between the client and server transactions.

What does this mean? Let’s use the default of 500 msecs TRYING and retry INVITE value of 6 as an example:

Time: 0 msecs passed | Start Timer-A (or… Trying timer) – value 500 msecs
INVITE -->
No response received and Trying timer expires.

Time: 500 msecs passed | Start Trying timer – new value 1000 msecs
INVITE -->
No response received and Trying timer expires.

Time: 1500 msecs passed | Start Trying timer – new value 2000 msecs
INVITE -->
No response received and Trying timer expires.

Time: 3500 msecs passed | Start Trying timer – new value 4000 msecs
INVITE -->
No response received and Trying timer expires.

Time: 7500 msecs passed | Start Trying timer – new value 8000 msecs
INVITE -->
No response received and Trying timer expires.

Time: 15500 msecs passed | Start Trying timer – new value 16000 msecs
INVITE -->
No response received and Trying timer expires.
Time required for time-out of our INVITE attempts = 31500 msecs 

In other words, the Trying timer will double again and again until either the INVITE retry value is reached or Timer-B expires. With a default of six INVITE retries and a T1/Trying timer of 500 msecs, our total time required until our INVITE retries are exhausted is ~32 seconds. It’s at this point that RouteListControl attempts to route the call through our next Route Group member or Route Group (assuming we're talking about CUCM). If CUBE, then the next preference dial-peer.

Note that SIP over TCP transport still uses these timers, but a reliable transport protocol ensures that a 3-way handshake is performed before delivering the request to the transport layer. CUCM still uses these timers even for SIP requests over TCP despite RFC 3261 saying that Timer-A should not be used for TCP but it’s okay – it doesn’t say it must not be used so it's fair game.

You can read more about this in sections 17.1.1.1 and 17.1.1.2 in RFC 3261 here:
http://www.ietf.org/rfc/rfc3261.txt 

In addition to the RFC, there’s an easy to follow article that also describes this process in detail: http://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/

Hope this helps.

- Dan

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Thursday, February 05, 2015 2:33 PM
To: gentoo at ucpenguin.com; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUBE SIP TCP connection timeout

If we're talking about transport level timeout, it looks like the command is available in CUBE SP Edition:

"In addition to the SIP protocol-level timers, Cisco Unified Border Element (SP Edition) also allows modification of transport-related timer commands: tcp-connect-timeout (how long TCP SYN will wait for the reply) and tcp-idle-timeout (how long TCP connection should stay active while idle). Although these timers are transport-level values, Cisco IOS XE Release 2.4 supports these timers in SIP only, but not in H.323, nor H.248"

For the tcp-connect-timeout command: "Configures the time (in milliseconds) that SBC waits for a SIP TCP connection to a remote peer to complete before failing that connection. The default timeout interval is 1000 milliseconds."

In practice, specifically at UCM, I wouldn't expect to see a transmitted INVITE in situations where the TCP socket cannot be established, so I'm not sure how well the sip-ua timers below would help. 

If it's an option, perhaps using UDP and modifying the retry invite value and TRYING timer as  ucpenguin mentioned below. I'm sure you know of the options keepalive method. One last thing would be to mention the TRYING timer doubles for each INVITE sent without a response until the retry INVITE value is reached (I've seen this cause up to 32 seconds of delay with default values). 

Hope this helps.

- Dan

-----Original Message-----
From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of gentoo at ucpenguin.com
Sent: Thursday, February 05, 2015 1:49 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUBE SIP TCP connection timeout

Not sure why this didn't hit the list the first time I sent it, maybe its just slow.

Anyways:

sip-ua
  retry invite 2
  timers trying 100

On 2015-02-05 12:32, Brian Meade wrote:
> Hey all,
> 
> Does anyone know a SIP equivalent of "h225 timeout tcp establish"?
> 
> The default SIP TCP timeout is 5 seconds:
> 
> 001306: Feb  4 20:44:34.164: %VOICE_IEC-3-GW: SIP: Internal Error 
> (Socket error): IEC=1.1.186.7.7.4 on callID 3254
> GUID=5BBD7EFBAC0F11E4997499045654EBE2
> 001307: Feb  4 20:44:39.167: %VOICE_IEC-3-GW: SIP: Internal Error 
> (Socket error): IEC=1.1.186.7.7.4 on callID 3255
> GUID=5BBD7EFBAC0F11E4997499045654EBE2
> 
> This results in failover to a 3rd dial-peer taking 10 seconds when our 
> main DC is down.
> 
> There's nothing under the "sip-ua" configuration that will change the 
> TCP timeout.  It looks like this may not be configurable.
> 
> Anyone have any ideas?
> 
> Thanks,
> Brian Meade
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

More information about the cisco-voip mailing list