Determine what's ends a call

We are experiencing dropped calls periodically and we are working with the SIP provider to see where the issue lies. The one example from today the provider is stating the RTP stream ended from our end and then the remote end hung up. The CD-R report shows the remote end exiting the bridge then us. On our end the user was talking, lost communication with the caller then the call ended. I need to see where the stream is getting lost. The trunk never goes offline.

You can enable SIP debug on Asterisk CLI and trace messages. So capture the message that terminates the call and the reason.

Will that work on calls that have already transpired or does it have to be a live debug?

You’ll see all live calls flow.

Is there a way to capture that? Or is there a call log with the same info? I’m not usually on site so it would be better to either log for a day or to look at a log of the previous day when I have some info about what calls they had issues with.

Sorry it’s late! And I’ve been working on this system for most of the day. I just found the sip debug log file location. I’ll turn it on for tonight. Thanks for the help!

Yes. you can access to the logs : /var/log/asterisk/full
Just enable SIP debug:
Asterisk CLI : sip set debug on

I took a look at the log for today and isolated the call that dropped. Found a “Timeout on non-critical invite” which i am assuming is the cause of the call drop. Also found this post with the same issue:

Our SIP trunk connection goes from our PBX network card into the WAN port of the ISP supplied router which is controlled and configured but the ISP (SIP Provider). The phones are run into a PoE switch which in turn is connected to another network connection on our PBX. eth0 for the phones is 192.168.1.x and the SIP is on eth1 at 10.185.85.x. There is no firewall, no other additional router etc for these invites to get lost in as far as i can see. I have NAT enabled with the external address being the address of eth1 (10.185.85.x) and the 192.168.1.x network under the local networks.

What else can i do to fix this?

@psdk is this timeout error the Asterisk system not receiving the confirmation from the provider side or our side not sending it? The provider is still claiming an issue on our end but we have tried every config i can think of and nothing seems to be correcting the calls dropping.

In the log the call continues for 31 seconds each time until the caller side exits the bridge. this leaves a total of 37 seconds every time a call drops. I have looked for a way to extend the time out for the invite but cant seem to find any setting that will allow to extend this. I’m assuming that the 37 seconds is the total allowable time for invites and retransmissions before Asterisk assumes no connection and rejects the call.