Random call transfers disconnected or call back

Asterisk 1.4.18
FreePBX 2.4.0.0

Good Afternoon,

There has been an issue going on at our site for the last few months. I am not aware of any changes made on the server or network (no one has fessed up to any changes made at least). The problem is as follows:
We have several ring groups that point to individual cell phone numbers (i.e., one ring group points to one cell phone number). This way we can transfer calls to our techs who are in the field. Over the last few months, calls that are transferred to these ring groups have been seemingly randomly dropping or the calls ring back to the extension that the call was transferred from (random in that we cannot pinpoint the cause yet).

*One constant is that every time there is a failed transfer, we get a “hangup request, cause 57” (and we don’t get these errors any other time)- this made me wonder if the issue has something to do with our provider or our connection to our provider. It always has to do with requesting transfer capability SPEECH.

*There are also alot of “Avoiding initial deadlock” errors, but from what I saw online, these only seem to be an issue if you are having resource issues, which we are not. Of course, I would not rule it out without more knowledge.

*Lastly, I noticed alot of these errors:
“Found no match for SIP option: from-change (Please file bug report!)” I assume in following versions this bug might have been fixed b/c I see noting about this particular issue on the web. Also, I am not sure that it is related as it does not seem to occur around the same time as the transfer issues.

I have verbosity set to 3 and debug set to 3. Should I set these lower to avoid posting a massive log on the forums? I will post just a little bit of the log at first- I can always post more later.
Thanks, Joe

[Feb 24 08:00:07] VERBOSE[25180] logger.c: – Requested transfer capability: 0x00 - SPEECH
[Feb 24 08:00:07] DEBUG[25180] devicestate.c: Notification of state change to be queued on device/channel Zap/2-1
[Feb 24 08:00:07] DEBUG[2866] devicestate.c: Changing state for Zap/2-1 - state 0 (Unknown)
[Feb 24 08:00:07] DEBUG[2896] app_queue.c: Device ‘Zap/2-1’ changed to state ‘0’ (Unknown) but we don’t care because they’re not a member of any queue.
[Feb 24 08:00:07] DEBUG[25180] devicestate.c: Notification of state change to be queued on device/channel Zap/2
[Feb 24 08:00:07] DEBUG[2866] channel.c: Avoiding initial deadlock for channel ‘0xb733af58’
[Feb 24 08:00:07] DEBUG[2866] channel.c: Failure, could not lock ‘0xb733af58’ after 9 retries!
[Feb 24 08:00:07] DEBUG[2866] channel.c: Avoiding initial deadlock for channel ‘0xb733af58’
[Feb 24 08:00:07] DEBUG[2866] devicestate.c: Changing state for Zap/2 - state 2 (In use)
[Feb 24 08:00:07] DEBUG[2896] app_queue.c: Device ‘Zap/2’ changed to state ‘2’ (In use) but we don’t care because they’re not a member of any queue.
[Feb 24 08:00:07] VERBOSE[25180] logger.c: – Called g0/19802759008
[Feb 24 08:00:07] DEBUG[2874] chan_zap.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/2 span 1
[Feb 24 08:00:07] VERBOSE[25180] logger.c: – Zap/2-1 is proceeding passing it to Local/[email protected],2
[Feb 24 08:00:07] DEBUG[25180] rtp.c: Channel ‘Local/[email protected],2’ has no RTP, not doing anything
[Feb 24 08:00:07] VERBOSE[25173] logger.c: – Local/[email protected],1 is proceeding passing it to Zap/1-1
[Feb 24 08:00:07] VERBOSE[2874] logger.c: – Channel 0/2, span 1 got hangup request, cause 57
[Feb 24 08:00:07] VERBOSE[2898] logger.c: Retransmitting #1 (NAT) to 192.168.5.125:1024:

Hey All, does anyone have any ideas or suggestions?

Thanks

You have not updated your system in six years? . I don’t think anyone will bother to help you until you do so. You will need to be at least asterisk 1.8 (12 is latest), dahdi not zaptel (latest is 12.9), libpri (latest is 1.4.14), FreePBX at least 2.10 to get close to the current experience of Asterisk/FreePBX users here. All these are needed for bug and security fixes and extra function. Currently you are just inviting a huge and unexpected phone bill.

Perhaps it is time to rebuild your system from scratch.