ASTERISK-24195: bridge_native_rtp: Removing mixmonitor from a native RTP capable smart bridge doesn't cause the bridge to resume being a native rtp bridge

[Home]

Summary: ASTERISK-24195: bridge_native_rtp: Removing mixmonitor from a native RTP capable smart bridge doesn't cause the bridge to resume being a native rtp bridge

Reporter: Jonathan Rose (jrose) Labels:

Date Opened: 2014-08-08 17:32:04 Date Closed: 2014-10-03 14:37:19

Priority: Minor Regression? No

Status: Closed/Complete Components: Applications/app_mixmonitor Bridges/bridge_native_rtp

Versions: SVN 12.4.0 Frequency of
Occurrence Constant

Related
Issues:
is related to ASTERISK-24027 MixMonitor AMI action called during AGI execution from bridge feature causes channel to leave AGI has hung up

Environment: Attachments:

Description: So basically it's like this...

1. Start a PJSIP call from PJSIP/A to PJSIP/B without features or other hooks so that it can start a native RTP bridge

2. Start a mixmonitor on one of the two channels above. The bridge should change to a simple bridge.

3. Stop mixmonitor. Currently the bridge remains a simple bridge until the next time something occurs that would make the bridge re-evaluate.

I've already determined a simple fix (which I'm not 100% certain of the correctness of) for this problem where I simply apply an UNBRIDGE soft hangup flag to the channel when closing the MixMonitor. On the other hand, I'm in the middle of writing a patch right now that pulls the unbridge flag out of the soft hangup flags and into its own member of the structure, so the exact implementation of this would change a little anyway.

Comments: By: Matt Jordan (mjordan) 2014-08-09 11:00:38.067-0500

Using UNBRIDGE when removing the MixMonitor is the correct solution. We've done that elsewhere with other framehooks as well (namely, the PJSIP transfer framehook).