Queue gets about 1000 calls per day. 50-100 of those will drop on answer. Phones dont lose registration. 25 seconds on qualify. 25 second keep alives on phones.
-I thought the issue was with calls coming in too fast. Added agent wrap up times.
-Set RTP keep alive to 15 seconds. This appeared to help. Also turned keep alive option off on aastras. This really seemed to help. Still some randoms on yealinks. Havent turned keep alive off on them yet.
Dropped calls down to 4 yesterday. So 50-100 down to 4 is an improvement.
Aastras appear to use the same port 3000 for rtp. Which means the nat has to keep nat table. Rtp debug shows rtp always going to 3000 on them.
Just seeing if anyone has thoughts. No SIP ALG. Registrations 60 seconds. I need to recheck udp timeouts.
Did you look at the logs why it’s happening?
Yes logs and packet captures galore. Captures show normal call hangup from the phone side but call just drops. I think it only affects calls in a ring all call queue. I wonder if its because how audio is bridged in a call queue. I looked at other pbxes. Searched for calls answered 0-6 seconds with destination of the queue and sure enough its on all of them. Ive seen lots of posts on this in 3CX forum. Havent found a cause yet.
As root, run a command like this to capture all SIP and RTP:
tcpdump -s 0 -C 100 -W 100 -w rbuf -Z root &
This writes a ring buffer of 100 files of 100MB each (rbuf00, rbuf01, …, rbuf99). (Be sure you have 10 GB available disk space.)
Assuming that your peak hour is ~200 calls and average call duration is ~2 minutes, you would have ~6 concurrent calls, which is about 50 minutes of captured data. When a dropped call is reported, before the buffer gets overwritten, find the file with the bad call (look at times last modified), copy it to your PC and analyze with Wireshark. (Also save the previous one, in case the call overlapped two files.)
OK, so we assume that the agent hung up because s/he didn’t hear anything. Confirm that first. At the time of hangup, what RTP was flowing to the phone (none, all zeros, silent but with 1-2 LSBs of noise, normal speech)? Find the corresponding RTP on the trunk side and look at / listen to it also. Report what you find there.
Possibly, there is nothing wrong – 4 dropped calls out of a thousand could simply be that the caller abandoned the call at about the time the agent answered. What kind of trunks do you have?
To echo something @Stewart1 said - if you are using a predictive dialer, a 10% drop-on-connect rate would be about normal. Most people are getting savvy to the “ring; silence; hello?; hello?; hang up” sequence that allows your system to connect your agents, but not before the call is abandoned.
Another thing you can try is to Force Recording of all calls and drop the minimum length setting down from 15 (I think) seconds down to 5. This way, you might also be able to hear the recipient of the call answer and abandon your calls.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.