asterisk

Commit Graph

Author	SHA1	Message	Date
Joshua Colp	962b78bca1	bridge_native_rtp: Take the bridge type choice of both channels into account. The bridge_native_rtp module currently uses the bridge result of the first channel that joins a bridge as the ultimate result. This means that if the first channel has direct media enabled but the second does not a direct media bridge will still occur. This change makes it so that both sides are taken into account. If either side forbids the bridge or responds with a local bridge result then either a generic or local bridge occurs. ASTERISK-23541 #close Reported by: Justin E Review: https://reviewboard.asterisk.org/r/3577/ ........ Merged revisions 414975 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414976 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	42a1dee02d	Undo r414123 The Test Suite caught a few problems, undoing until those are resolved git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414138 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	17ff4d9282	bridge_native_rtp/bridge_channel: Fix direct media issues due to frame hook This patch fixes issues with direct media bridges that occur after a blind transfer. These issues were caught by the (currently failing) pjsip/transfers/blind_transfer/caller_direct_media test. The test currently fails primarily for two reasons: (1) When Bob and Charlie (the transfer target and the transfer destination) enter a bridge together, the framehook remains on the transfer target channel until both channels are in the bridge. As it consumes voice frames, the initial bridge type is a simple bridge. The framehook is removed when both channels are in the bridge; however, this does not currently cause the bridging framework to re-evaluate the bridge. This patch adds a AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a framehook is removed so the bridge can re-evaluate itself. (2) When a channel leaves a native RTP bridge, it may be leaving due to being hung up. Sending a re-INVITE to a channel that is about to be hung up is not nice - in fact, there's a good chance we'll send the BYE request before the channel has had a chance to send back a 200 OK. To be somewhat nicer, this patch adds a function to channel.h that allows the bridging framework to query for exactly why a channel is leaving a bridge via the channel's soft hangup flags. This allows it to only send the re-INVITE if there's a chance the channel will survive the native bridging experience. Review: https://reviewboard.asterisk.org/r/3535/ ........ Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414123 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	d134150be2	framehooks: Add callback for determining if a hook is consuming frames of a specific type. In the past framehooks have had no capability to determine what frame types a hook is actually interested in consuming. This has meant that code has had to assume they want all frames, thus preventing native bridging. This change adds a callback which allows a framehook to be queried for whether it is consuming a frame of a specific type. The native RTP bridging module has also been updated to take advantange of this, allowing native bridging to occur when previously it would not. ASTERISK-23497 #comment Reported by: Etienne Lessard ASTERISK-23497 #close Review: https://reviewboard.asterisk.org/r/3522/ ........ Merged revisions 413681 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413682 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	e2ed86e4ca	Undoing framehook support. Issues were uncovered by Bamboo. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413668 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	3b3e4b9b95	framehooks: Add callback for determining if a hook is consuming frames of a specific type. In the past framehooks have had no capability to determine what frame types a hook is actually interested in consuming. This has meant that code has had to assume they want all frames, thus preventing native bridging. This change adds a callback which allows a framehook to be queried for whether it is consuming a frame of a specific type. The native RTP bridging module has also been updated to take advantange of this, allowing native bridging to occur when previously it would not. ASTERISK-23497 #comment Reported by: Etienne Lessard ASTERISK-23497 #close Review: https://reviewboard.asterisk.org/r/3522/ ........ Merged revisions 413650 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413651 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	b5f8f56bd0	bridge_native_rtp: Fix crash involving masquerade It is possible for a channel to be masqueraded out of a bridge which means it may no longer have RTP glue to check upon leaving said bridge. If this situation occurred (it's possible at least during dial and call pickup) then Asterisk would crash. This change makes sure the glue is checked before use. (closes issue AST-1290) Reported by: John Bigelow ........ Merged revisions 409900 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409904 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kevin Harwell	84e1790beb	bridge_native_rtp: Deadlock during 4-way conference creation The change contains a slightly adjusted patch that was on the issue (submitted by kmoore). A fix was made by adding in a bridge lock while calling bridge_start/stop from the framehook callback. Since the framehook callback is not called from the bridging core the bridge is not locked, but needs to be before calling bridge_start. (closes issue ASTERISK-22749) Reported by: Kinsey Moore Review: https://reviewboard.asterisk.org/r/3066/ Patches: lock_inversion.diff uploaded by kmoore (license 6273) ........ Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	6c417b0475	bridge_native_rtp: Ensure bridge is torn down When a bridge transitions away from one tech to another, the tech going away is provided a dummy bridge with no channels in it to tear down. Currently this means that the teardown code exits prematurely and does not tear anything down. This change tears down RTP bridging for the channel provided in the leave bridge tech callback. This also reverts the majority of r400403 since it is now redundant. (closes issue ASTERISK-22628) (closes issue ASTERISK-22676) Reported by: John Bigelow Reported by: Kevin Harwell Tested by: John Bigelow Review: https://reviewboard.asterisk.org/r/2905/ Patches: native_rtp_fix.diff uploaded by Kinsey Moore (License 6273) ........ Merged revisions 402148 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402149 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	b11983d480	Fix assumption in bridge_native_rtp.c regarding number of participants in a bridge. When a party leaves a bridge, there may be more participants in the bridge than expected. As such, it is important not to make assumptions regarding the list of channels in a bridge. This change makes it so that when a party leaves a native RTP bridge, we unbridge it and the party it was bridged with. Previously, the first and last channels in the list were unbridged since it was assumed that these were the two channels that had been bridged. As previously stated, a new party had been inserted into the bridge, so this logic did not work properly. (closes issue ASTERISK-22615) reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/2899 ........ Merged revisions 400403 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400452 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	ee21eee7e0	Cache string values of formats on ast_format_cap() to save processing. Channel snapshots have string representations of the channel's native formats. Prior to this change, the format strings were re-created on ever channel snapshot creation. Since channel native formats rarely change, this was very wasteful. Now, string representations of formats may optionally be stored on the ast_format_cap for cases where string representations may be requested frequently. When formats are altered, the string cache is marked as invalid. When strings are requested, the cache validity is checked. If the cache is valid, then the cached strings are copied. If the cache is invalid, then the string cache is rebuilt and copied, and the cache is marked as being valid again. Review: https://reviewboard.asterisk.org/r/2879 ........ Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	212b6f668b	Fix refleaks of ast_rtp_instance structures. These refleaks were causing bridged calls not to close their RTP ports. Thus a call would leave open 4 ports (RTP for party A, RTCP for party A, RTP for party B, and RTCP for party B). This led to an eventual depletion of available RTP ports. ........ Merged revisions 399924 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399925 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	c13d0b7bdc	bridge_native_rtp: Fix hold chain bugs caused by native RTP bridge framehook Issuing hold/unhold would lead to odd behavior. Between two chan_sip devices, a hold could cause an endless chain of updates while with pjsip a similar chain would begin but then end somewhat randomly. This patch fixes that by no longer tweaking the RTP glue on both sides of the call for every HOLD/UNHOLD/UPDATE_RTP_PEER frame. (issue ASTERISK-22217) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2794/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397578 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	20bf856ba4	bridge_native_rtp: Remove some unnecessary NULL checks on c1. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396512 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	2feb049ba2	Fix hold/unhold in bridge_native_rtp, use tech_pvt instead of bridge_pvt, reduce bridging attempts, and fix breaking native RTP bridges. (closes issue ASTERISK-22128) (closes issue ASTERISK-22104) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395866 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	cafc115896	A great big renaming patch This patch renames the bridging* files to bridge. This may seem pedantic and silly, but it fits better in line with current Asterisk naming conventions: channel is not "channeling" * monitor is not "monitoring" etc. A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is the act of using a bridge on a set of channels - and the API that fulfills that role is more than just the action. (closes issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	7846c2c91d	Add missing line terminator to debug message. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395254 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	3a15fb4f47	Fix a check in bridge_native_rtp which determined if attaching the framehook failed or not. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395227 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	c780fd5498	Add some debug messages to make it clear what RTP bridging functionality is in use. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395205 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	e366c8c0a0	Fix some logic so native RTP bridge will occur when monitor, audiohooks, or framehooks are not present. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395203 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	2838683742	Extract a repeated test into ast_channel_has_audio_frame_or_monitor(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394825 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	1267c91315	Extract a useful routine from the softmix bridge technology. * Extract a useful routine from the softmix bridge technology for other technologies. Make other technologies use it if they can. * Made native and 1-1 bridges write to all parties if the bridge channel writing the frame into the bridge is NULL. Softmix will also do the same for frame types that make sense. * Tweak the bridge write routine return value meaning and adjust the bridge technologies to match. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	41e4282751	Fix memory leaks in stasis_channels and bridge_native_rtp This patch fixes two memory leaks: * A memory leak in packing channels into a multi-channel blob payload when publishing dial messages. The multi-channel blob payload does not steal the references - this approach was chosen because it works well with the RAII_VAR macro. Unfortunately, this does mean that you actually have to use the RAII_VAR macro (or manually deref it yourself) * RTP instances returned as a result of one of the glue operations are ref counted and have to be de-ref'd appropriately. We now do that, as saying that we should do it and then not would be silly. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	723a84dbd9	bridge_native_rtp: Fix native bridge tech being incompatible when it should be. When checking compatability for the native RTP bridge technology there is a race condition between clearing framehooks that are destroyed when leaving certain bridges with certain technologies (such as bridge_native_rtp) and joining bridges with the bridge_native_rtp technology. Yes, that means a channel in a native RTP bridge could move to another native RTP bridge and be considered incompatible with the new native RTP bridge causing it to revert to a simple bridge technology0. This fixes that bug by ignoring framehooks that have been marked for destruction when checking for compatibility with the bridge_native_rtp technology. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391453 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jonathan Rose	a1f45147c9	bridge_native_rtp: Fix possible segfaults on leaves/joins native_rtp_bridge_get can return any result from the ast_rtp_glue_result enumerator and the join/leave functions for bridge_native_rtp seem to assume that if the result wasn't local that it was remote. Meanwhile forbid can be returned by that function which can mean certain glue pointers are NULL. Then when the join/leave functions try to use members of that pointer, boom. Segfault. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391430 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	18338967c4	Add BUGBUG comment. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390440 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	dcf5990c56	Simple lock, assignment, unlock sandwich optimization. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390439 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	3d63833bd6	Merge in the bridge_construction branch to make the system use the Bridging API. Breaks many things until they can be reworked. A partial list: chan_agent chan_dahdi, chan_misdn, chan_iax2 native bridging app_queue COLP updates DTMF attended transfers Protocol attended transfers git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago

28 Commits (4308aa5648ef4d7332dd14f920b944b0806ec8fb)