Music on Hold stops playing for some callers in the queue

On PBXact 15.0.23 Version 12.7.8-2203-2.sng7
Some callers in the queue report that the music on hold stops playing but they are still connected.
Caller says he was in queue 45min and was first in line. Then the music stopped and line stayed open
for 35min after that. He tried pressing 8,but nothing happened. The ivr is programmed to press 8 to leave a message.
Max wait time for the queue is 45 minutes so he should have went to voicemail. The Max wait time mode is Loose. The fail over destination
is set to general mailbox. I ran module and system updates with no change. Where do I start troubleshooting?

This is still a problem. There were 4 of those calls today, 1 on Wednesday, 8 on Tuesday, and 18 on Monday.

one caller told me that he waited about 5 or 10 minutes until the hold music stopped. Then it sounded like someone picked up the line, but everything stayed quiet for about 20 minutes. At that point he was transferred to voicemail.

Others have similar reports, while it seems that still others hold longer, and are dumped into the mailbox pretty much as soon as the music stops. All this I have gathered simply by listening to what ppl say when they leave a voicemail – some don’t even realize that’s what they are doing and would skip a few colorful details if they knew :blush:

So I’m working on SIP debugging, here’s the pastebin of the one voicemail left at 10:49 am https://pastebin.freepbx.org/view/77d101b1#L11552

I noticed a stopped musiconhold here but then it starts again:

  1. [2022-05-27 10:44:35] VERBOSE[29125][C-00000d98] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“Local/109@from-queue-0001a959;2”, “”) in new stack

  2. [2022-05-27 10:44:35] VERBOSE[29125][C-00000d98] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘Local/109@from-queue-0001a959;2’ in macro ‘hangupcall’

  3. [2022-05-27 10:44:35] VERBOSE[29125][C-00000d98] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘Local/109@from-queue-0001a959;2’

  4. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] res_musiconhold.c: Stopped music on hold on SIP/Voip_Innovations_In-000072ac

  5. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Hold time for 801 is 12 minute(s) 0 seconds

  6. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Told SIP/Voip_Innovations_In-000072ac in 801 their queue position (which was 1)

  7. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] res_musiconhold.c: Started music on hold, class ‘default’, on channel ‘SIP/Voip_Innovations_In-000072ac’

  8. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Called Local/113@from-queue/n

  9. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Called Local/102@from-queue/n

  10. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Called Local/108@from-queue/n

  11. [2022-05-27 10:44:50] VERBOSE[28043][C-00000d98] app_queue.c: Called Local/109@from-queue/n

And then here the music stopped again:

  1. [2022-05-27 10:48:53] VERBOSE[1349][C-00000d98] pbx.c: Spawn extension (zulu-call, 90113, 3) exited non-zero on ‘Local/90113@zulu-call-0001ab17;2’

  2. [2022-05-27 10:48:53] VERBOSE[28043][C-00000d98] res_musiconhold.c: Stopped music on hold on SIP/Voip_Innovations_In-000072ac

  3. [2022-05-27 10:48:53] VERBOSE[28043][C-00000d98] pbx.c: Executing [8@ivr-14:1] Macro(“SIP/Voip_Innovations_In-000072ac”, “blkvm-clr,”) in new stack

  4. [2022-05-27 10:48:53] VERBOSE[1346][C-00000d98] app_stack.c: SIP/109-00007317 Internal Gosub(crm-hangup,s,1) start

  5. [2022-05-27 10:48:53] VERBOSE[1346][C-00000d98] pbx.c: Executing [s@crm-hangup:1] NoOp(“SIP/109-00007317”, “Sending Hangup to CRM”) in new stack

  6. [2022-05-27 10:48:53] VERBOSE[1346][C-00000d98] pbx.c: Executing [s@crm-hangup:2] NoOp(“SIP/109-00007317”, “HANGUP CAUSE: 16”) in new stack

  7. [2022-05-27 10:48:53] VERBOSE[28043][C-00000d98] pbx.c: Executing [s@macro-blkvm-clr:1] Set(“SIP/Voip_Innovations_In-000072ac”, “SHARED(BLKVM,SIP/Voip_Innovations_In-000072ac)=”) in new stack

  8. [2022-05-27 10:48:53] VERBOSE[1346][C-00000d98] pbx.c: Executing [s@crm-hangup:3] ExecIf(“SIP/109-00007317”, “0?Set(__CRM_VOICEMAIL=)”) in new stack

Does the Executing [8@ivr-14:1] mean the user pressed 8? The IVR is set so pressing 0 or 8 will send the call to voicemail.

It could also be the result of talk-off (the user’s voice spoof’s DTMF 8), or even a remote echo of the music on hold spoofing DTMF 8.

This is still a problem. One caller reported the problem twice on Friday Called in, was in queue for 30min then music stopped playing but call was still connected. I ran a sip debug on the call. Here’s the Pastebin Automatic Pastebin from Sangoma OS 7 - FreePBX Pastebin

And here’s another one from today. https://pastebin.freepbx.org/view/48056279 He was in queue for 23min.

This is still an ongoing problem:
“At least 3 of my callers said it was the 2nd time they called in. The first time they started at a high # a when it got to you are the next caller after bit it just went silent. One of them waited 10mins after it went quiet and had to call back in. So something is again not quite right with the system.”

Same problem with another caller. This call trace is much shorter because it happened soon after he entered the queue. Automatic Pastebin from Sangoma OS 7 - FreePBX Pastebin

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.