Suggested to add call timeouts?
Posted: Thu Feb 19, 2009 2:52 pmHi my new sip trunk provider has a lot of calls in the CDR's showing really long times. Over 200 calls showing 4 hours. He suggest I add call timeouts so this doesnt happen again. It hasnt happened before by the way. Also what was wierd was that we ran for six hours pretty heavy and this happened only during the last half hour. Seemingly it could have been induced from something else, Memory, cache??? I am not sure any suggestions would be great. Here is a little snip it of what they sent.
1) For many of your calls, the upstream gateways were sending back BYEs
after relatively long periods of time compared to your usual traffic
patterns. This left long-running calls in the "answered" state until the
BYEs were finally received from upstream.
2) Your switches/user agents were not hanging up the calls from your
end. If you are using an automated dialer, then this problem could be
avoided by using call timeouts to ensure that answered calls cannot be
left open indefinitely when the callee does not hang up.
I am running the following
VERSION: 2.0.4-121 BUILD: 80424-0442
Processors 2
Model Intel(R) Xeon(R) CPU 3040 @ 1.86GHz
CPU Speed 1.87 GHz
Cache Size 2.00 MB
Memory Usage
Type Percent Capacity Free Used Size
Physical Memory 95% 52.67 MB 958.13 MB 1010.79 MB
- Kernel + applications 19% 191.46 MB
- Buffers 13% 129.40 MB
- Cached 63% 637.26 MB
Disk Swap 0% 1.94 GB 3.15 MB 1.95 GB
Mounted Filesystems
Mount Type Partition Percent Capacity Free Used Size
/boot ext3 /dev/sda1 16% (1%) 77.73 MB 15.89 MB 98.72 MB
/ ext3 /dev/sda3 5% 199.81 GB 12.20 GB 223.55 GB
/dev/shm tmpfs tmpfs 0% (1%) 505.39 MB 0.00 KB 505.39 MB
Totals : 5% 200.38 GB 12.22 GB 224.14 GB
I watched the load during the campaign and it seemed to range from .5-4.0.
We were dialing at a 50 to 1 agent ratio with 5 agents logged in.
Thanks in advance with your help
1) For many of your calls, the upstream gateways were sending back BYEs
after relatively long periods of time compared to your usual traffic
patterns. This left long-running calls in the "answered" state until the
BYEs were finally received from upstream.
2) Your switches/user agents were not hanging up the calls from your
end. If you are using an automated dialer, then this problem could be
avoided by using call timeouts to ensure that answered calls cannot be
left open indefinitely when the callee does not hang up.
I am running the following
VERSION: 2.0.4-121 BUILD: 80424-0442
Processors 2
Model Intel(R) Xeon(R) CPU 3040 @ 1.86GHz
CPU Speed 1.87 GHz
Cache Size 2.00 MB
Memory Usage
Type Percent Capacity Free Used Size
Physical Memory 95% 52.67 MB 958.13 MB 1010.79 MB
- Kernel + applications 19% 191.46 MB
- Buffers 13% 129.40 MB
- Cached 63% 637.26 MB
Disk Swap 0% 1.94 GB 3.15 MB 1.95 GB
Mounted Filesystems
Mount Type Partition Percent Capacity Free Used Size
/boot ext3 /dev/sda1 16% (1%) 77.73 MB 15.89 MB 98.72 MB
/ ext3 /dev/sda3 5% 199.81 GB 12.20 GB 223.55 GB
/dev/shm tmpfs tmpfs 0% (1%) 505.39 MB 0.00 KB 505.39 MB
Totals : 5% 200.38 GB 12.22 GB 224.14 GB
I watched the load during the campaign and it seemed to range from .5-4.0.
We were dialing at a 50 to 1 agent ratio with 5 agents logged in.
Thanks in advance with your help