|Summary:||ASTERISK-19918: MoH (Music on Hold) is stopped after call in a queue is terminated|
|Reporter:||Eduardo Abad (eabad)||Labels:|
|Date Opened:||2012-05-28 11:18:44||Date Closed:||2012-11-13 12:18:16.000-0600|
|Versions:||220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199||Frequency of|
|Environment:||CentOS 5.7 64bits Kernel 2.6.18-238||Attachments:||( 0) myDebugLog|
( 1) queues_additional.conf
( 2) sip_additional.conf
|Description:||We have seen a problem in asterisk 1.8.11, 1.8.12, 1.8.13, 1.8.14, 1.8.15, 1.8.16, 1.8.17, and 1.8.18 where Music On Hold is stopped after call in a queue is terminated.
To reproduce the bug you have to login as an agent to wait for incoming calls in a queue (Music On Hold will be playing to him as normal), then when a call comes into the queue, the agent will get connected to the call and can handle it normally. The problem comes when the call is terminated, in MOST OCCASIONS the MoH (that should normally be reproduced to him again waiting for the next call to arrive) will only play for half a second and then get stopped, asterisk's CLI will even show the line
-- Stopped music on hold on SIP/...
We have not been able to reproduce this in asterisk 1.8.7
|Comments:||By: Eduardo Abad (eabad) 2012-05-28 11:30:16.896-0500|
Configuration files for analysis of bug purposes
By: Rusty Newton (rnewton) 2012-06-02 18:39:12.052-0500
We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
Please provide a full log, including DEBUG and VEBOSE levels of at least 5, covering the entire time the issue happens. Please attach the debug to the issue as a text file and do not post it in-line.
By: Eduardo Abad (eabad) 2012-06-05 11:48:37.147-0500
Requested debugging log uploaded (attached)
As it can be seen, there is a line near the end of the log file stating that the music on hold is stopped:
[Jun 5 11:45:33] VERBOSE res_musiconhold.c: -- Stopped music on hold on SIP/300-0000000a
This occurs AFTER the call has been terminated (ie, when the agent is free again and waiting for further calls to arrive, moment in which normally music on hold should be continuously playing to him)
By: Eduardo Abad (eabad) 2012-06-05 11:57:58.909-0500
The requested 'myDebugLog' file has been uploaded, please see comments regarding that file in the Comments section.
Also worth mentioning, the issue is also present in Asterisk 1.8.13 (until now it has been reproduced in 1.8.11 , 1.8.12 , and 1.8.13 ; in 1.8.7 we have not been able to reproduce)
By: Matt Jordan (mjordan) 2012-06-08 09:33:03.222-0500
Since no one has attempted to address this issue, I wouldn't expect the behavior to change.
By: Matt Jordan (mjordan) 2012-06-08 09:41:31.388-0500
If you can, can you please produce another DEBUG log, this time with 'sip set debug on' as well? I'm curious what SIP messages were involved when SIP/300 had their MOH stopped on them.
By: Eduardo Abad (eabad) 2012-06-08 09:59:58.024-0500
Sure, the attached "myDegubLog" contains the SIP messages ('sip set debug on' was executed before getting that log file)
By: Eduardo Abad (eabad) 2012-06-14 11:04:35.690-0500
I think a mistake has been made since now I am being presented as the 'Assignee' for this bug where I should only be presented as the Reporter (I just noticed and reported the bug, I am not a developer)
By: David Woolley (davidw) 2012-06-15 05:21:47.286-0500
JIRA is working correctly, although personally I think the feature is not working from a human factors point of view.
When an issue is put into feedback status, it becomes assigined to the reporter. Until the reporter releases it from feeback status, by indicating that their response is the final bit of feedback, it will generally be ignored by bug marshalls, etc. Other people are not allowed to comment in this state, unless they cheat.
I think the behaviour is broken, because:
1) my impression is that most reporters don't realise then need to release control;
2) it locks out helpful comments from third parties until the reporter has released control.
However it is the intended behaviour of JIRA.
By: Eduardo Abad (eabad) 2012-06-15 09:42:31.240-0500
I see, thank you for the explanation!
By: Eduardo Abad (eabad) 2012-07-02 10:42:13.088-0500
Is anybody addressing the issue? Thanks
By: Eduardo Abad (eabad) 2012-07-12 17:46:06.702-0500
Keeps occurring in 1.8.14
By: Eduardo Abad (eabad) 2012-08-14 16:17:05.720-0500
Keeps occurring in 1.8.15
By: Matt Jordan (mjordan) 2012-08-14 17:44:15.847-0500
Your issue is in queue, please be patient, and we will get to it as time permits and developer resources become available.
By: Brent Eagles (beagles) 2012-10-05 08:26:20.961-0500
Do you have transmit_silence enabled in asterisk.conf?
By: Eduardo Abad (eabad) 2012-10-05 10:18:57.113-0500
parameter is not set inside the asterisk.conf file. But the
parameter is set to 'yes' (Note: calls are not being recorded though)