Asterisk disconnects incoming calls the moment we pickup

Asterisk Asterisk Support
1

… sometimes.

It goes like this:

A call comes in via chan_zap. It will ring until we pick it up from a sip phone. At that moment the call will be disconnected.

The event log was off, and the message log was unremarkable.

I turned on the event log and added debugging info to the message log.

I just upgraded from 1.4.21 to 1.4.23.1 today, and upgraded zaptel. Libpri and addons are still at 1.4.7, and no updates are available for the sangoma driver.

Ideally someone reading this will know what the problem is, and point me to a solution, but in case that doesn’t happen: what else can I do to put myself in a position to find a solution to exorcise this demon?

Ideally, I’d like to put myself in a position to file a bug report the next time this happens, but from experience I know that if there is no crash / dump I will have little support on the bug tracker.

So what’s the next best thing?

P.S. I’ve had an asterisk server since 1.0.X at this location, I’ve gone through 3-4 motherboards in that time, went from TDM400P to Sangoma hardware, 64-bit to 32-bit linux, reinstalled gentoo perhaps 7 times, and swapped all kinds of other hardware that comprises the platform. None of those upgrades, downgrade, or changes have allowed me to achieve my modest goal: 30 days of uptime with no issues like these (and there are others).

2

Hi

Ok, Did it work OK before you upgraded ?
Why did you upgrade ?
Why do yo think its a Bug ?

Now what to do. Turn up full logging to the max. and test it to make it fail then go through the logs.

Ian

3

Thanks for the response.

This problem started before I upgraded.

To see if I could fix this and other issues that I’ve been having lately.

I’ve had it happen three times in a row to the same caller. If it were a problem with the PSTN lines I don’t think the call dropping would coincide so perfectly with the moment we answer the call.

[quote=“ianplain”]
Now what to do. Turn up full logging to the max. and test it to make it fail then go through the logs.
Ian[/quote]

I’ve turned logging up, and I’m waiting for it to happen again.

4

Perhaps I’m being too quick in blaming Asterisk.

One thing I have noticed is that I loose some packets when I traceroute, mostly at the gateway at that location. Sometimes it’s worse than others. For instance, when I was posting about this on Thursday I lost my ssh connection several times. However I haven’t lost it since.

Since Friday, here are my traceroute results for the ‘bad location’:

[code]Host Loss% Snt Drop Last Avg

  1. up4.linode.com 0.0% 21271 26 0.4 0.3
  2. vl1.dsr01.dllstx2.theplanet 0.0% 21271 42 0.4 0.3
  3. te9-4.dsr01.dllstx3.theplan 0.0% 21271 1 0.5 0.5
  4. et5-1.ibr03.dllstx3.theplan 0.0% 21271 6 0.5 0.4
  5. 68.86.88.49 0.0% 21271 2 1.4 1.1
  6. pos-0-8-0-0-cr01.atlanta.ga 0.0% 21271 2 22.4 22.3
  7. pos-1-9-0-0-cr01.chicago.il 0.0% 21271 2 43.6 43.1
  8. 65.19.100.165 0.0% 21271 42 43.6 43.5
  9. ???
  10. ???
  11. ???
  12. ool-4353f80e.dyn.optonline. 0.0% 21271 3 56.8 56.1
  13. ubr202-ge1-0-0.cmts.nwrknj. 0.0% 21271 4 57.1 56.3
  14. ool-4354d123.dyn.optonline. 0.2% 21271 334 62.8 61.2
    [/code]

.2% packetloss may not seem like a lot, but compare that to my ‘good location’ which has dropped 2230% less packets (15).

5

are you using the DADHI interface in native mode or are you still “spoofing” as ZAP? watch the call with “core show channels” from CLI and see what happens.

6

I’m still using zap (as in dial zap/1/blah). I’ll have to look into DAHDI, and whether it will work with my sangoma.

7

I spoke with soome people on the IPCOP forum, and they’ve assured me that communication between two clients on my LAN is not likely to be affected by the performance of the router.

Since the issue happens on inbound ZAP calls, anything on the WAN wouldn’t be to blame.

That leaves me with RTP Debug and the logs. I’ve instructed my users to call me the moment it happens next.