Dropped Calls


(HawkEye) #1

Hi, getting complaints about dropped calls. When given the time and extension looked in /var/log/asterisk/full log and see the following entry which was one of the reported dropped calls:

[2020-02-12 11:28:36] NOTICE[5602] chan_sip.c: Disconnecting call ‘SIP/227-00004dbe’ for lack of RTP activity in 31 seconds

The person complaining about the dropped call had said there was conversation going on and then it dropped.

Is there something we can do to fix this ?
Thanks,.


(Joshua C. Colp) #2

That means no audio was received for 31 seconds. You’d have to examine outside of Asterisk to see what is up. Network issues, etc.


(HawkEye) #3

Hi Jcolp, thanks for replying. I have smokeping running on the clients router and on a few of the phones but not the extension noted in the disconnection.

Since it dropped @ 11:28, the graph shows it was fine at that time.


(Joshua C. Colp) #4

That doesn’t explain why Asterisk didn’t receive RTP traffic at the time, so you’ll need to investigate that.


(HawkEye) #5

Could you possibly suggest things we could do to find out ?


(Joshua C. Colp) #6

A packet capture recording all traffic and then correlating the time to the call and RTP stream, seeing if it went away.


(HawkEye) #7

So if I understand correctly, you’re saying run a tcpdump for the whole day since these dropped calls are infrequent.


(Joshua C. Colp) #8

Yes, you need to further isolate the problem using process of elimination. The message tells you that Asterisk didn’t receive media for a period of time and thus disconnected the call, so using that basis you isolate it further by ruling out segments to further isolate things and rule things out.


#9

If you are “getting complaints” then likely you will know who is complaining at what time and what endpoints were involved, given those data points

will save you a huge amount of time isolating the exact point when the RTP disappeared. It wont tell you why but you will likely see dropped packets, perhaps out of order, perhaps delayed packets, this can help further diagnosing network problems.


(HawkEye) #10

Thanks Dicko. Thanks for suggesting pcapsipdump. Downloaded it and will try it out. Also in SIP SETTINGS the RTP timeout is set to 30. If I change it to 60 would that help in the meantime? I spoke to the person at the extension with the dropped calls for more than 10 minutes. That call did not drop.


(Joshua C. Colp) #11

It would alter the time that no audio is required before disconnecting the call. If the drop is temporary and below 60 seconds then it would not disconnect. Whether that would help depends on what exactly is happening.


(HawkEye) #12

Usage of pcapsipdump states:
pcapsipdump [-fpUt] [-i | -r ] [-d ]
[-v level] [-R filter] [-m filter] [-n filter] [-l filter]
[-B size] [-t trigger:action:param] [expression]

If pcapsipdump is run as:
pcapsipdump -v 2 -i eth0 -d /var/tmp/ -R rtp port 5060 or portrange 10000-20000
it fails with:
Capturing on interface: port
Couldn’t get netmask for interface port: SIOCGIFADDR: port: No such device
Couldn’t open interface ‘port’: port: No such device exists (SIOCGIFHWADDR: No such device)

Tried moving the port 5060 part closer to command pcapsipdump but that doesn’t help.


#13

Option -R is much simpler, leave it at default (rtp+rtcp)

http://pcapsipdump.sourceforge.net/