05-09-2011 11:02 PM - edited 03-17-2019 10:17 PM
Hi,
Does anyone know the TCP timeout on a C- or a Ex- Series system?
Jordan: I saw your post in the "old" Tandberg forum. Therefore the post here.
I would really like to the timeouts for all three if you have them. SIP, H323 and HTTP.
Rgs
Niklas
05-16-2011 12:13 AM
Does anyone know about this?
//Niklas
05-24-2011 12:04 PM
Niklas,
There is no TCP timeout coded into any Cisco codec. There is not even a maximum call duration, except for ISDN on the MXP line of codecs. Are you having a problem with something?
Thanks,
Justin
05-24-2011 04:25 PM
If there would be no timeouts it would be a bad thing, how should it ever clean out dropped connections, ...
If I see it right these are the generic timeouts on a TC4.1 system:
icmp_timeout:30
tcp_timeout_close:10
tcp_timeout_close_wait:60
tcp_timeout_established:432000
tcp_timeout_fin_wait:120
tcp_timeout_last_ack:30
tcp_timeout_max_retrans:300
tcp_timeout_syn_recv:60
tcp_timeout_syn_sent:120
tcp_timeout_time_wait:120
tcp_timeout_unacknowledged:300
udp_timeout:30
udp_timeout_stream:180
tcp_max_retrans:3
If everything works fine you will not experience these as you do not need to care as
the upper layers take care that it will either not expire or reestablish a new connection.
So the main question here is why Niklas asks and if which problem he experiences.
If any timeout or disconnect occurs its most likely a firewall or an other "clever" Layer3 device.
Please remember to rate helpful responses and identify
05-24-2011 07:52 PM
After all, these codecs all run a Linux kernel. Use sysctl command to see stack parameters.
From and ex90...
[ex90-01-rtp:/extra/sbin] $ sysctl -a | grep tcp
fs.nfs.nlm_tcpport = 0
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
error: permission denied on key 'net.ipv4.route.flush'
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 4096
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 47520 63360 95040
net.ipv4.tcp_wmem = 4096 16384 2027520
net.ipv4.tcp_rmem = 4096 87380 2027520
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 2
net.ipv4.tcp_frto_response = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = reno
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_available_congestion_control = reno
net.ipv4.tcp_allowed_congestion_control = reno
net.ipv4.tcp_max_ssthresh = 0
05-24-2011 11:08 PM
Hi,
And thanks for the replies. My issue is/was that the calls dropped for no apparent reason. And I had to explore every possibility. The traffic flow went throught several firewalls and routers. So after triyng everything else I thought I would check the timeouts as well, even if I did not accually thought that the timeout would be the thing that caused my problem.
But before I could get ahold of thease timeouts TAC told me to try and switch switch of "Enable ad-hoc conference discovery" in the TMS. That did the trick.
So my issue is resolved short term anyway.
Cheers
Niklas
05-25-2011 08:58 AM
Niklas,
Thanks for the update, thats an odd setting to cause the problem you were seeing though.
For everyone else :)
As I stated, there are no 'User' configurable time outs in any of the codecs. Second the pre-defined timeouts would only occur if the network was not functioning properly and the codec was not getting packets back in the correct amount of time.
Thanks,
Justin
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide