How to diagnose cause of call ending

[darcey]

I use FreePBX at home. One member of the household makes extended phone calls to family members and sometimes experiences disconnections. There’s no pattern to this, such as duration, so I suspect it is not a router/NAT issue. It may well be them accidentally hitting a button on the handset .
How do I read/configure logs so that I can distinguish a potential network/disconnect from an explicit user hangup? I have looked at the CEL and it is not clear to me how to differenciate the two. I’m using pjsip. Just to add this phenomenon can happen with an inbound or outbound call.
Many thanks.

[BlazeStudios (Tom Ray)]

@darcey

How do I read/configure logs so that I can distinguish a potential network/disconnect from an explicit user hangup?

You can’t. Nothing shows that the disconnect was due to a bad connection, a phone dying or someone hanging it up normally.

[david55]

You’d need the detailed protocol logging.

As you mention the internet, I assume you are using H.323, IAX, or SIP, and as you didn’t explicitly state H.323, or IAX, I’ll assume SIP, but that still leaves the old or new implementation of SIP in Asterisk.

If the far end clears, you may just see a BYE, in which case you can’t tell whether it was the technology or the user that ended the call, but sometimes there will be a Reason header, with more information.

[darcey]

Thanks @david55 and @BlazeStudios
There’s a gigaset N300 with two handsets. Each handset connected to the N300 is registered its own extension in FreePBX. All extensions, as well as the single trunk, are PJSIP.
Can I log all SIP messages to a dedicated file? I could run a continuous/complete packet capture of all SIP traffic otherwise.

[Stewart1 (Stewart)]

If it’s important that you find the trouble in the least number of failures, I recommend the complete capture; see

Random Dropped Calls

On a problematic system, I start a capture with a command like: tcpdump -s 0 -C 100 -W 10 -w rbuf -Z root & This writes all network traffic into a series of files rbuf0, rbuf1, …, rbuf9. Each is limited to 100 MB and after filling rbuf9, it continues, overwriting rbuf0. You can let this run 24/7, since it won’t use more than 1 GB of disk. When you get a report of a problematic call, copy the file with the proper time range to a temporary and transfer it to your PC. Open it in Wireshark and…

OTOH, if you want to start with easy, turn on pjsip logger and look at the Asterisk log for the next failed call.

[darcey]

Many thanks. I will try pjsip logging and see if, as david55 mentions, there’s anything in the headers to differenciate a purported disconnected call vs a normal one.

[BlazeStudios (Tom Ray)]

That isn’t going to help. An answered call is an answered call. When that call disconnects for what ever reason it will be cause code 16 normal call clearing because it would either be sending a BYE or receiving a BYE.

If Asterisk stops receiving audio from the far side it will end the call normally for lack of RTP. If Asterisk sends a reINVITE during the call and that doesn’t get a response Asterisk will end the call normally with a BYE

The reason header won’t be the right way to determine this

[darcey]

Would there be anything, in the logs, that distinguishes a call as having been explicitly ended by the user?
There’s something else I found that may help. The N300 base has a hidden syslog config that allows logging to a remote host, including SIP events. I may be able to glean something from that. It seems odd not to be able to determine if a user/device explicitly ended a call, vs getting disconnected some other way.

[BlazeStudios (Tom Ray)]

@darcey

It seems odd not to be able to determine if a user/device explicitly ended a call, vs getting disconnected some other way.

If the user/device explicitly ended the call it would send a BYE message to the server to indicate the call has been terminated. This means the user hung up the call or disconnected the call in some normal way like hitting the End Call softkey, etc.

As explained previously, if there was an issue with the Internet connection (being dead, poor firewall/NAT rules) then Asterisk will notice that RTP isn’t being received from the far side (usually about 30 seconds) and will end the call by sending a BYE to the device. There will be an error in the logs about RTP inactivity.

As well, if Asterisk sends a reINVITE which it should do a random times during the call (thus the longer the call the more reINVITEs happen) and the firewall/NAT on the far side is messed up and Asterisk doesn’t get responses it will end the call by sending a BYE.

So if you want to rule out this being a network issue, you need to run captures on the network and look at what is happening when a call disconnects. Since this is sporadic it means you’ll need to keep the captures running for some time until it happens.

[darcey]

@BlazeStudios appreciate the help, thanks. In the first instance I want to rule out whether it’s the user inadvertently ending the call. So this helps. If there’s a BYE from the ‘endpoint’, I know that’s the case. That, or the N300 dect base experienced a connection issue and terminated the call with the local asterisk server (also with a BYE). I now have something to watch for. Cheers.