External Call Just randomly Drops

We get random dropped calls, no specific time for drops involved sometimes after seconds and sometime minutes. As far as for monitoring its only happening with a specific #.

Hopefully The Logs help.

It looks like the hangup was done on the far side.

116430	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] bridge_channel.c: Channel SIP/GXW1_copy_1-00000003 left 'simple_bridge' basic-bridge <9b939088-45ca-4aad-b106-057b8b14fffd>	
116431	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] app_macro.c: Spawn extension (macro-dial-one, s, 56) exited non-zero on 'SIP/GXW1_copy_1-00000003' in macro 'dial-one'	
116432	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on 'SIP/GXW1_copy_1-00000003' in macro 'exten-vm'	
116433	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] pbx.c: Spawn extension (ext-local, 106, 3) exited non-zero on 'SIP/GXW1_copy_1-00000003'	
116434	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] pbx.c: Executing [[email protected]:1] Macro("SIP/GXW1_copy_1-00000003", "hangupcall,") in new stack	
116435	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] pbx.c: Executing [[email protected]:1] GotoIf("SIP/GXW1_copy_1-00000003", "1?theend") in new stack	
116436	[2021-11-18 16:52:38] VERBOSE[8577][C-00000004] pbx_builtins.c: Goto (macro-hangupcall,s,3)	
116437	[2021-11-18 16:52:38] VERBOSE[8591][C-00000004] bridge_channel.c: Channel SIP/106-00000004 left 'simple_bridge' basic-bridge <9b939088-45ca-4aad-b106-057b8b14fffd>	

Look at the SIP signaling to actually confirm who sent the bye

@PitzKey How do I look at the sip signaling.
I can confirm that it definitely wasn’t the caller who ended the call(Assuming that is what u meant by far side) because this was a test call I made.

If you can reproduce, then:

asterisk -rvvvvv
sip set debug on

Paste the output to pastebin.freepbx.org

@PitzKey https://pastebin.freepbx.org/view/2813d2c9

This log is very puzzling. It shows the SIP trace to/from extension 106, but shows no sip traffic to or from the GXW1, which is what would be interesting. It seems pretty clear that the trunk to the GXW is chan_sip, and while it’s possible to ‘sip set debug ip’ or ‘sip set debug peer’, doing ‘sip set debug on’ should show all chan_sip traffic. Did you filter the log somehow? Or do a sip debug command that captures only to/from the extension?

In any case, I suspect that the GXW detected a call drop and sent a BYE, possibly cause by a false disconnect tone detection or a false loop current drop detection. If the failure is reasonably consistent, you could temporarily disable one or the other to confirm. Or, look at syslog from the GXW.

I agree with Stewart1 about the strange lack of protocol logging for the trunk, in spite of logging that the call was progressing.

No there was no filtering, I just used the command that @PitzKey recommended. I will try getting some logs again to see if there is any difference (That’s if I can reproduce a dropped call because its so random).

I forgot to mention that this only started happening after I did the line analysis over. Reason being I’ve gone the route of creating trunks for each of my lines.


Here is another log for a dropped call. Hopefully this one has more info.

The GXW terminated it giving a reason of FX call terminated (and a rather bogus looking indication that this was a SIP event).


This is most likely a false disconnect tone detection. To confirm, temporarily disable it in the GXW and test the failing outgoing call.

If the call does not drop: If your carrier supports loop current disconnect, just leave it disabled and you should be good to go. If not, try setting the call progress tones back to their old values. If that still fails (the call still drops, or real disconnects don’t get detected), post details.

If the call still drops with disconnect tone detection disabled, the GXW syslog feature may give a clue as to why.

My carrier does not support current disconnect. So I am playing around with the tone settings but still have not found the right one. I’m not to sure how to monitor the GXW syslog.

See the Syslog Setup info on pp. 14-15 of the User Manual. Set Syslog Server to the LAN address of a PC to capture the data. You can run a dedicated syslog server, but IMO it’s easier to just run Wireshark and type ‘syslog’ (without the quotes) into the display filter field.

Sorry, I know nothing about interpreting the results, but there are several members here who are Grandstream experts. The Grandstream forum or their support may also be useful.