[asterisk-bugs] [JIRA] (ASTERISK-24408) Issue with MOH on transfers introduced in version 1.8.27

[Carlos Oliva (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=222977#comment-222977 ] 

Carlos Oliva commented on ASTERISK-24408:
-----------------------------------------

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

> Issue with MOH on transfers introduced in version 1.8.27
> --------------------------------------------------------
>
>                 Key: ASTERISK-24408
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24408
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: . I did not set the category correctly.
>    Affects Versions: 1.8.27.0, 1.8.28.0, 1.8.29.0, 1.8.30.0, 1.8.31.0
>         Environment: Debian 7.6, asterisk compiled from tar.gz
>            Reporter: Carlos Oliva
>            Severity: Minor
>
> 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



--
This message was sent by Atlassian JIRA
(v6.2#6252)