Summary:	ASTERISK-24408: Issue with MOH on transfers introduced in version 1.8.27
Reporter:	Carlos Oliva (coliva)	Labels:
Date Opened:	2014-10-10 04:39:21	Date Closed:	2014-10-16 01:54:05
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	1.8.27.0 1.8.28.0 1.8.29.0 1.8.30.0 1.8.31.0	Frequency of Occurrence	Constant
Related Issues:	is caused by ASTERISK-19499 ConfBridge MOH is not working for transferee after attended transfer
Environment:	Debian 7.6, asterisk compiled from tar.gz	Attachments:
Description:	Issue with MOH on transfers introduced in asterisk version 1.8.27 and still present in version 1.8.31 How to reproduce: Incoming call to asterisk (from RTB via Cisco SIP Gateway) The call goes to an extension. This extension is diverted to another (via asterisk, not a 302 header from the phone) who answer the call. After answer the call, the callee wants to make an assisted transfer to another extension. When it makes the transfer, the caller (the incoming call from RTB) still hears the MOH, but the final callee hear the caller. We make the divert using local channels, the diference between a direct call and a diverted call is that the diverted call traverses two local channels, and the direct call use only one local channel. We always use the parameters "nbm" in local channels. This issue happens from version 1.8.27 to 1.8.31, the version 1.8.26 don't have the issue. I think the review request #3226 can be the responsible of this, cause this patch seems to be related and introduced in 1.8.27, but maybe I'm wrong. I'll make more tests with the patches applied in 1.8.27 and publish here the results
Comments:	By: Carlos Oliva (coliva) 2014-10-10 05:32:59.558-0500 I can confirm that the patch of #3226 introduces the issue. I applied the patch of https://reviewboard.asterisk.org/r/3226/diff/raw/ to version 1.8.26 and can reproduce the problem. By: Carlos Oliva (coliva) 2014-10-10 05:53:19.009-0500 an aditional hint: if I UNapply this part of the patch: @@ -24048,7 +24050,6 @@ ast_do_masquerade(target.chan1); - ast_indicate(target.chan1, AST_CONTROL_UNHOLD); if (target.chan2) { ast_indicate(target.chan2, AST_CONTROL_UNHOLD); } I can confirm that the issue NOT happens. Deleting this line is the responsible of the problem, but i'm not sure if deleting it will have another implications. I change the severity from Minor to Major because is affecting the calls that can not be continued if the caller still hears the MOH By: Matt Jordan (mjordan) 2014-10-10 08:57:06.334-0500 Unfortunately the patch was needed to solve the bug in ASTERISK-19499, even if it did cause this problem. Removing it isn't the correct solution. Please provide a full debug log showing the problem, using the instructions on the wiki: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Carlos Oliva (coliva) 2014-10-16 01:10:32.533-0500 After making some tests more, I could not be able to reproduce the issue. I don't understand because in my other tests it happens 100% of the time. There must be something that I am not seeing. Please mark this bug as invalid because I can not reproduce. If It happens again and can take more debug info, I will reopen it again. Thanks By: Walter Doekes (wdoekes) 2014-10-16 01:54:05.391-0500 Thanks for the feedback. Closing as invalid/irreproducible.