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: |
| ||||
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). |