[asterisk-bugs] [JIRA] (ASTERISK-25240) bridge_native_rtp: Direct media wrongfully started when completing attended transfer

Matt Jordan (JIRA) noreply at issues.asterisk.org
Sun Jul 26 11:54:44 CDT 2015


     [ https://issues.asterisk.org/jira/browse/ASTERISK-25240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-25240:
-----------------------------------

    Target Release Version/s: 13.5.0

> bridge_native_rtp: Direct media wrongfully started when completing attended transfer
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25240
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25240
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp
>    Affects Versions: 13.4.0
>            Reporter: Joshua Colp
>            Assignee: Joshua Colp
>      Target Release: 13.5.0
>
>
> The bridge_native_rtp module adds a frame hook to channels which are in a native RTP bridge. This frame hook is used to intercept when a hold or unhold frame traverses the bridge so native RTP can be stopped or started as appropriate. This is expected but exposes a specific bug when attended transfers are involved.
> Upon completion of an attended transfer an unhold frame is queued up to take one of the channels involved off hold. After this is done the channel is moved between bridges.
> When the frame hook is involved in this case for the unhold it releases the channel lock and acquires the bridge lock. This allows the bridge core to step in and move the channel (potentially changing the bridging techology) from another thread. Once completed the bridge lock is released by the bridge core. The frame hook is then able to acquire the bridge lock and wrongfully starts native RTP again, despite the channel no longer being in the bridge or needing to start native RTP. In fact at this point the frame hook is no longer attached to the channel.
> This results in a weird audio path as one channel may be directly sending media to another place while the other is sending through Asterisk.



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



More information about the asterisk-bugs mailing list