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
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Applications/app_queue
Versions:	1.8.11.1 1.8.12.0 1.8.12.2 1.8.13.0 1.8.13.1 1.8.14.0 1.8.15.0 1.8.16.0 1.8.17.0 1.8.18.0	Frequency of Occurrence	Frequent
Related Issues:
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[5589] 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 The "transmit_silence" parameter is not set inside the asterisk.conf file. But the "transmit_silence_during_record" parameter is set to 'yes' (Note: calls are not being recorded though)