[asterisk-bugs] [JIRA] (ASTERISK-25641) bridge: GOTO_ON_BLINDXFR doesn't work on transfer initiated channel
Joshua Colp (JIRA)
noreply at issues.asterisk.org
Tue Dec 22 06:11:32 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-25641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua Colp updated ASTERISK-25641:
-----------------------------------
Assignee: Dmitry Melekhov
Status: Waiting for Feedback (was: Triage)
Why don't you use the new multi-party bridge ability in 13? If you perform a DTMF based attended transfer hitting *3 (this is configurable in features.conf) will turn it into a multi-party conference. Would this accomplish what you are wanting to do?
> bridge: GOTO_ON_BLINDXFR doesn't work on transfer initiated channel
> -------------------------------------------------------------------
>
> Key: ASTERISK-25641
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-25641
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Bridging/bridge_basic
> Affects Versions: 13.6.0
> Environment: Centos 7 x86-64
> Reporter: Dmitry Melekhov
> Assignee: Dmitry Melekhov
> Attachments: blind-ast11, blind-ast13
>
>
> Hello!
> I'm trying to get n-way call on asterisk according to instructions here
> http://habrahabr.ru/sandbox/52259/
> although it is in russian, dialplan is quite obvious, and it works in asterisk 11,
> but doesn't work in asterisk 13 because GOTO_ON_BLINDXFR macro is executed only for one channel, namely another side of transfer, but no for channel initiated transfer.
> As I know, this change is not documented, so I assume this is bug.
> I'll attach console output for asterisk 11 and asterisk 13.
> Thank you!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list