summaryrefslogtreecommitdiff
path: root/main/bridge_channel.c
AgeCommit message (Collapse)Author
2014-11-06Bridge DTMF hooks: Made audio pass from the bridge while waiting for more ↵Richard Mudgett
matching digits. * Made collecting DTMF digits for the DTMF feature hooks pass frames from the bridge. * Made collecting DTMF digits possible by other bridge hooks if there is a need. ASTERISK-24447 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/4123/ ........ Merged revisions 427493 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427494 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427495 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-10-03chan_pjsip: Fix deadlock when masquerading PJSIP channels.Richard Mudgett
Performing a directed call pickup resulted in a deadlock when PJSIP channels were involved. A masquerade needs to hold onto the channel locks while it swaps channel information between the two channels involved in the masquerade. With PJSIP channels, the fixup routine needed to push a fixup task onto the PJSIP channel's serializer. Unfortunately, if the serializer was also processing a task that needed to lock the channel, you get deadlock. * Added a new control frame that is used to notify the channels that a masquerade is about to start and when it has completed. * Added the ability to query taskprocessors if the current thread is the taskprocessor thread. * Added the ability to suspend/unsuspend the PJSIP serializer thread so a masquerade could fixup the PJSIP channel without using the serializer. ASTERISK-24356 #close Reported by: rmudgett Review: https://reviewboard.asterisk.org/r/4034/ ........ Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-20chan_pjsip: Update media translation paths when new SDP negotiated.Richard Mudgett
On a SIP reinvite that changes media strams, the PJSIP channel driver was flooding the log with "Asked to transmit frame type %s, while native formats is %s" warnings. * Fixes PJSIP not setting up translation paths when the formats change on a reinvite. AFS-63 was effectively reintroduced because of the media formats work. res_pjsip_sdp_rtp.c:set_caps() * Improved the unexpected frame format WARNING message to include more information. * Added protective locking while altering formats on a channel. Reworked set_format() to simplify and protect the formats under manipulation. * Restored some code that got lost in the media_formats work. (channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps()) AFS-137 #close Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/3906/ ........ Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-08-13Bridges: Fix feature interruption/unintended kick caused by external actionsJonathan Rose
If a manager or CLI user attached a mixmonitor to a call running a dynamic bridge feature while in a bridge, the feature would be interrupted and the channel would be forcibly kicked out of the bridge (usually ending the call during a simple 1 to 1 call). This would also occur during any similar action that could set the unbridge soft hangup flag, so the fix for this was to remove unbridge from the soft hangup flags and make it a separate thing all together. ASTERISK-24027 #close Reported by: mjordan Review: https://reviewboard.asterisk.org/r/3900/ ........ Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-22core/bridge_channel: Substitute Variables In Features Application MapMichael L. Young
Say you wanted to include variables in an application map and have those variables substituted and passed along to the application being executed; currently this does not happen. This patch adds this ability to pass channel variable values to an application before being executed. ASTERISK-22608 #close Reported by: Michael L. Young patches: features_substitute_arguments_v2.diff uploaded by Michael L. Young (license 5026) Review: https://reviewboard.asterisk.org/r/3819/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-20media formats: re-architect handling of media for performance improvementsMatthew Jordan
In the old times media formats were represented using a bit field. This was fast but had a few limitations. 1. Asterisk was limited in how many formats it could handle. 2. Formats, being a bit field, could not include any attribute information. A format was strictly its type, e.g., "this is ulaw". This was changed in Asterisk 10 (see https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for notes on that work) which led to the creation of the ast_format structure. This structure allowed Asterisk to handle attributes and bundle information with a format. Additionally, ast_format_cap was created to act as a container for multiple formats that, together, formed the capability of some entity. Another mechanism was added to allow logic to be registered which performed format attribute negotiation. Everywhere throughout the codebase Asterisk was changed to use this strategy. Unfortunately, in software, there is no free lunch. These new capabilities came at a cost. Performance analysis and profiling showed that we spend an inordinate amount of time comparing, copying, and generally manipulating formats and their related structures. Basic prototyping has shown that a reasonably large performance improvement could be made in this area. This patch is the result of that project, which overhauled the media format architecture and its usage in Asterisk to improve performance. Generally, the new philosophy for handling formats is as follows: * The ast_format structure is reference counted. This removed a large amount of the memory allocations and copying that was done in prior versions. * In order to prevent race conditions while keeping things performant, the ast_format structure is immutable by convention and lock-free. Violate this tenet at your peril! * Because formats are reference counted, codecs are also reference counted. The Asterisk core generally provides built-in codecs and caches the ast_format structures created to represent them. Generally, to prevent inordinate amounts of module reference bumping, codecs and formats can be added at run-time but cannot be removed. * All compatibility with the bit field representation of codecs/formats has been moved to a compatibility API. The primary user of this representation is chan_iax2, which must continue to maintain its bit-field usage of formats for interoperability concerns. * When a format is negotiated with attributes, or when a format cannot be represented by one of the cached formats, a new format object is created or cloned from an existing format. That format may have the same codec underlying it, but is a different format than a version of the format with different attributes or without attributes. * While formats are reference counted objects, the reference count maintained on the format should be manipulated with care. Formats are generally cached and will persist for the lifetime of Asterisk and do not explicitly need to have their lifetime modified. An exception to this is when the user of a format does not know where the format came from *and* the user may outlive the provider of the format. This occurs, for example, when a format is read from a channel: the channel may have a format with attributes (hence, non-cached) and the user of the format may last longer than the channel (if the reference to the channel is released prior to the format's reference). For more information on this work, see the API design notes: https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite Finally, this work was the culmination of a large number of developer's efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the work in the Asterisk core, chan_sip, and was an invaluable resource in peer reviews throughout this project. There were a substantial number of patches contributed during this work; the following issues/patch names simply reflect some of the work (and will cause the release scripts to give attribution to the individuals who work on them). Reviews: https://reviewboard.asterisk.org/r/3814 https://reviewboard.asterisk.org/r/3808 https://reviewboard.asterisk.org/r/3805 https://reviewboard.asterisk.org/r/3803 https://reviewboard.asterisk.org/r/3801 https://reviewboard.asterisk.org/r/3798 https://reviewboard.asterisk.org/r/3800 https://reviewboard.asterisk.org/r/3794 https://reviewboard.asterisk.org/r/3793 https://reviewboard.asterisk.org/r/3792 https://reviewboard.asterisk.org/r/3791 https://reviewboard.asterisk.org/r/3790 https://reviewboard.asterisk.org/r/3789 https://reviewboard.asterisk.org/r/3788 https://reviewboard.asterisk.org/r/3787 https://reviewboard.asterisk.org/r/3786 https://reviewboard.asterisk.org/r/3784 https://reviewboard.asterisk.org/r/3783 https://reviewboard.asterisk.org/r/3778 https://reviewboard.asterisk.org/r/3774 https://reviewboard.asterisk.org/r/3775 https://reviewboard.asterisk.org/r/3772 https://reviewboard.asterisk.org/r/3761 https://reviewboard.asterisk.org/r/3754 https://reviewboard.asterisk.org/r/3753 https://reviewboard.asterisk.org/r/3751 https://reviewboard.asterisk.org/r/3750 https://reviewboard.asterisk.org/r/3748 https://reviewboard.asterisk.org/r/3747 https://reviewboard.asterisk.org/r/3746 https://reviewboard.asterisk.org/r/3742 https://reviewboard.asterisk.org/r/3740 https://reviewboard.asterisk.org/r/3739 https://reviewboard.asterisk.org/r/3738 https://reviewboard.asterisk.org/r/3737 https://reviewboard.asterisk.org/r/3736 https://reviewboard.asterisk.org/r/3734 https://reviewboard.asterisk.org/r/3722 https://reviewboard.asterisk.org/r/3713 https://reviewboard.asterisk.org/r/3703 https://reviewboard.asterisk.org/r/3689 https://reviewboard.asterisk.org/r/3687 https://reviewboard.asterisk.org/r/3674 https://reviewboard.asterisk.org/r/3671 https://reviewboard.asterisk.org/r/3667 https://reviewboard.asterisk.org/r/3665 https://reviewboard.asterisk.org/r/3625 https://reviewboard.asterisk.org/r/3602 https://reviewboard.asterisk.org/r/3519 https://reviewboard.asterisk.org/r/3518 https://reviewboard.asterisk.org/r/3516 https://reviewboard.asterisk.org/r/3515 https://reviewboard.asterisk.org/r/3512 https://reviewboard.asterisk.org/r/3506 https://reviewboard.asterisk.org/r/3413 https://reviewboard.asterisk.org/r/3410 https://reviewboard.asterisk.org/r/3387 https://reviewboard.asterisk.org/r/3388 https://reviewboard.asterisk.org/r/3389 https://reviewboard.asterisk.org/r/3390 https://reviewboard.asterisk.org/r/3321 https://reviewboard.asterisk.org/r/3320 https://reviewboard.asterisk.org/r/3319 https://reviewboard.asterisk.org/r/3318 https://reviewboard.asterisk.org/r/3266 https://reviewboard.asterisk.org/r/3265 https://reviewboard.asterisk.org/r/3234 https://reviewboard.asterisk.org/r/3178 ASTERISK-23114 #close Reported by: mjordan media_formats_translation_core.diff uploaded by kharwell (License 6464) rb3506.diff uploaded by mjordan (License 6283) media_format_app_file.diff uploaded by kharwell (License 6464) misc-2.diff uploaded by file (License 5000) chan_mild-3.diff uploaded by file (License 5000) chan_obscure.diff uploaded by file (License 5000) jingle.diff uploaded by file (License 5000) funcs.diff uploaded by file (License 5000) formats.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) bridges.diff uploaded by file (License 5000) mf-codecs-2.diff uploaded by file (License 5000) mf-app_fax.diff uploaded by file (License 5000) mf-apps-3.diff uploaded by file (License 5000) media-formats-3.diff uploaded by file (License 5000) ASTERISK-23715 rb3713.patch uploaded by coreyfarrell (License 5909) rb3689.patch uploaded by mjordan (License 6283) ASTERISK-23957 rb3722.patch uploaded by mjordan (License 6283) mf-attributes-3.diff uploaded by file (License 5000) ASTERISK-23958 Tested by: jrose rb3822.patch uploaded by coreyfarrell (License 5909) rb3800.patch uploaded by jrose (License 6182) chan_sip.diff uploaded by mjordan (License 6283) rb3747.patch uploaded by jrose (License 6182) ASTERISK-23959 #close Tested by: sgriepentrog, mjordan, coreyfarrell sip_cleanup.diff uploaded by opticron (License 6273) chan_sip_caps.diff uploaded by mjordan (License 6283) rb3751.patch uploaded by coreyfarrell (License 5909) chan_sip-3.diff uploaded by file (License 5000) ASTERISK-23960 #close Tested by: opticron direct_media.diff uploaded by opticron (License 6273) pjsip-direct-media.diff uploaded by file (License 5000) format_cap_remove.diff uploaded by opticron (License 6273) media_format_fixes.diff uploaded by opticron (License 6273) chan_pjsip-2.diff uploaded by file (License 5000) ASTERISK-23966 #close Tested by: rmudgett rb3803.patch uploaded by rmudgetti (License 5621) chan_dahdi.diff uploaded by file (License 5000) ASTERISK-24064 #close Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose rb3814.patch uploaded by rmudgett (License 5621) moh_cleanup.diff uploaded by opticron (License 6273) bridge_leak.diff uploaded by opticron (License 6273) translate.diff uploaded by file (License 5000) rb3795.patch uploaded by rmudgett (License 5621) tls_fix.diff uploaded by mjordan (License 6283) fax-mf-fix-2.diff uploaded by file (License 5000) rtp_transfer_stuff uploaded by mjordan (License 6283) rb3787.patch uploaded by rmudgett (License 5621) media-formats-explicit-translate-format-3.diff uploaded by file (License 5000) format_cache_case_fix.diff uploaded by opticron (License 6273) rb3774.patch uploaded by rmudgett (License 5621) rb3775.patch uploaded by rmudgett (License 5621) rtp_engine_fix.diff uploaded by opticron (License 6273) rtp_crash_fix.diff uploaded by opticron (License 6273) rb3753.patch uploaded by mjordan (License 6283) rb3750.patch uploaded by mjordan (License 6283) rb3748.patch uploaded by rmudgett (License 5621) media_format_fixes.diff uploaded by opticron (License 6273) rb3740.patch uploaded by mjordan (License 6283) rb3739.patch uploaded by mjordan (License 6283) rb3734.patch uploaded by mjordan (License 6283) rb3689.patch uploaded by mjordan (License 6283) rb3674.patch uploaded by coreyfarrell (License 5909) rb3671.patch uploaded by coreyfarrell (License 5909) rb3667.patch uploaded by coreyfarrell (License 5909) rb3665.patch uploaded by mjordan (License 6283) rb3625.patch uploaded by coreyfarrell (License 5909) rb3602.patch uploaded by coreyfarrell (License 5909) format_compatibility-2.diff uploaded by file (License 5000) core.diff uploaded by file (License 5000) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-17TEST_FRAMEWORK: Fix threewaytransfer reportingKinsey Moore
Ensure that three-way transfers can be reported even if featuremap is non-NULL. ........ Merged revisions 418810 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-15TEST_FRAMEWORK: Fix ref leak in feature activationKinsey Moore
This fixes two reference leaks that would occur when TEST_FRAMEWORK was enabled and features were successfully executed. ........ Merged revisions 418715 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-07-09ARI: Make mixing bridges propagate linkedids and accountcodes.Richard Mudgett
* Create a Stasis bridge sub-class to propagate linkedids and accountcodes. * Fixed the basic bridge sub-class to update peeraccount codes when the number of channels in the bridge drops back down to two parties. * Refactored ast_bridge_channel_update_accountcodes() to handle channels joining/leaving the bridge. * Fixed the basic bridge sub-class to not call the base bridge class pull method twice. AFS-105 #close ASTERISK-23852 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/3720/ ........ Merged revisions 418225 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-06-26Bridging: Allow channels to define bridging hooksKinsey Moore
This patch allows the current owner of a channel to define various feature hooks to be made available once the channel has entered a bridge. This includes any hooks that are setup on the ast_bridge_features struct such as DTMF hooks, bridge event hooks (join, leave, etc.), and interval hooks. Review: https://reviewboard.asterisk.org/r/3649/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-06-13stasis: Reduce creation of channel snapshots to improve performanceMatthew Jordan
During some performance testing of Asterisk with AGI, ARI, and lots of Local channels, we noticed that there's quite a hit in performance during channel creation and releasing to the dialplan (ARI continue). After investigating the performance spike that occurs during channel creation, we discovered that we create a lot of channel snapshots that are technically unnecessary. This includes creating snapshots during: * AGI execution * Returning objects for ARI commands * During some Local channel operations * During some dialling operations * During variable setting * During some bridging operations And more. This patch does the following: - It removes a number of fields from channel snapshots. These fields were rarely used, were expensive to have on the snapshot, and hurt performance. This included formats, translation paths, Log Call ID, callgroup, pickup group, and all channel variables. As a result, AMI Status, "core show channel", "core show channelvar", and "pjsip show channel" were modified to either hit the live channel or not show certain pieces of data. While this is unfortunate, the performance gain from this patch is worth the loss in behaviour. - It adds a mechanism to publish a cached snapshot + blob. A large number of publications were changed to use this, including: - During Dial begin - During Variable assignment (if no AMI variables are emitted - if AMI variables are set, we have to make snapshots when a variable is changed) - During channel pickup - When a channel is put on hold/unhold - When a DTMF digit is begun/ended - When creating a bridge snapshot - When an AOC event is raised - During Local channel optimization/Local bridging - When endpoint snapshots are generated - All AGI events - All ARI responses that return a channel - Events in the AgentPool, MeetMe, and some in Queue - Additionally, some extraneous channel snapshots were being made that were unnecessary. These were removed. - The result of ast_hashtab_hash_string is now cached in stasis_cache. This reduces a large number of calls to ast_hashtab_hash_string, which reduced the amount of time spent in this function in gprof by around 50%. #ASTERISK-23811 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3568/ ........ Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-06-08bridges/bridge_native_rtp: Reconfigure bridge on removal of framehookMatthew Jordan
This patch is a re-do of r414122. When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft hangup flags have a catastrophic effect on the pbx core if they leak out from the bridge layer: the channel gets hung up. With the number of threads involved in a blind transfer, and with the initial patch, it was likely that this would occur. This caused a large number of test failures This patch is nearly identical with the one proposed in r414122, save for the following changes: - We explicitly clear the UNBRIDGE flag when setting an after goto on a channel in a bridge - Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it https://reviewboard.asterisk.org/r/3585/ ........ Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-05-19Undo r414123Matthew Jordan
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
2014-05-18bridge_native_rtp/bridge_channel: Fix direct media issues due to frame hookMatthew Jordan
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
2014-05-09Allow Asterisk to compile under GCC 4.10Kinsey Moore
This resolves a large number of compiler warnings from GCC 4.10 which cause the build to fail under dev mode. The vast majority are signed/unsigned mismatches in printf-style format strings. ........ Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-17Fix stuck channel in ARI through the introduction of synchronous bridge actions.Mark Michelson
Playing back a file to a channel in an ARI bridge would attempt to wait until the playback concluded before returning. The method used involved signaling the waiting thread in the ARI custom playback function. The problem with this is that there were some corner cases that were not accounted for: * If a bridge channel could not be found, then we never would attempt the playback but would still attempt to wait for the playback to complete. * If the bridge playfile action failed to queue, we would still attempt to wait for the playback to complete. * If the bridge playfile action were queued but some circumstance caused the playback not to occur (the bridge dies, the channel is removed from the bridge), then we would never be notified. The solution to this is to move the waiting logic into the bridge code. A new bridge API function is added to queue a synchronous action on a bridge. The waiting thread is notified when the queued frame has been freed, either due to an error occurring or due to successful playback. As a failsafe, the waiting thread has a 10 minute timeout just in case there is a frame leak somewhere. Review: https://reviewboard.asterisk.org/r/3338 ........ Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-03-07uniqueid: channel linkedid, ami, ari object creation with id'sScott Griepentrog
Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-18channel locking: Add locking for channel snapshot creationKevin Harwell
Original commit message by mmichelson (asterisk 12 r403311): "This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such." The above was initially committed and then reverted at r403398. The problem was found to be in core_local.c in the publish_local_bridge_message function. The ast_unreal_lock_all function locks and adds a reference to the returned channels and while they were being unlocked they were not being unreffed when no longer needed. Fixed by unreffing the channels. Also in bridge.c a lock was obtained on "other->chan", but then an attempt was made to unlock "other" and not the previously locked channel. Fixed by unlocking "other->chan" (closes issue ASTERISK-22709) Reported by: John Bigelow ........ Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-05Reverting r403311. It's causing ARI tests to hang.David M. Lee
........ Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-12-03Add channel locking for channel snapshot creation.Mark Michelson
This adds channel locks around calls to create channel snapshots as well as other functions which operate on a channel and then end up creating a channel snapshot. Functions that expect the channel to be locked prior to being called have had their documentation updated to indicate such. ........ Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-23Add a test suite event to indicate when the atxfer 3-way feature is detectedJohn Bigelow
This adds a test suite event that indicates to tests when the attended transfer three-way call feature is detected. Review: https://reviewboard.asterisk.org/r/2912/ ........ Merged revisions 401578 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-22Bridging: Fix orphaned bridge if neither of the joining channels can join.Richard Mudgett
The original issue noted that the bridge is orphaned when res_parking.so is not loaded and a call uses the dial kK flags. A similar issue happens when only one of the park flags is used. In this case you have the bridge with one or the other channel left in it. The channel and bridge will stay around until the channel hangs up. * Fixed the initial bridge channel push failure to act as if the channel were kicked out of the bridge. The bridge then decides if it needs to be dissolved. (closes issue ASTERISK-22629) Reported by: Kevin Harwell Review: https://reviewboard.asterisk.org/r/2928/ ........ Merged revisions 401424 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-10-21Remove a noisy debug message from bridging code.Mark Michelson
This particular debug message, during a stress test, was logged so often that it appeared that there may be a memory leak in the logger code. In actuality, there was no memory leak, but the logger thread was having a hard time keeping up with the demands of the rest of the system. Since this debug message has no value at all, the best way to fix the problem was to just remove the message. (closes issue AST-1225) reported by John Bigelow Patches: spammy_log.diff uploaded by Mark Michelson (License #5049) ........ Merged revisions 401364 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-13Restore Dial, Queue, and FollowMe 'I' option support.Richard Mudgett
The Dial, Queue, and FollowMe applications need to inhibit the bridging initial connected line exchange in order to support the 'I' option. * Replaced the pass_reference flag on ast_bridge_join() with a flags parameter to pass other flags defined by enum ast_bridge_join_flags. * Replaced the independent flag on ast_bridge_impart() with a flags parameter to pass other flags defined by enum ast_bridge_impart_flags. * Since the Dial, Queue, and FollowMe applications are now the only callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the calling contract to require the initial COLP exchange to already have been done by the caller. * Made all callers of ast_bridge_impart() check the return value. It is important. As a precaution, I also made the compiler complain now if it is not checked. * Did some cleanup in parking_tests.c as a result of checking the ast_bridge_impart() return value. An independent, but associated change is: * Reduce stack usage in ast_indicate_data() and add a dropping redundant connected line verbose message. (closes issue ASTERISK-22072) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/2845/ ........ Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-26Better handle clearing the OUTGOING flag when a channel leaves a bridgeMatthew Jordan
When a channel with the OUTGOING flag leaves a bridge, and it will survive being pulled from the bridge (either because it will execute dialplan, go into another bridge, or live in a friendly autoloop), we have to clear the OUTGOING flag. This is the signal to the CDR engine that this channel is no longer a second class citizen, i.e., it is not "dialed". The soft hangup flags are only half the picture. If a channel is being moved from one bridge to another, the soft hangup flags aren't set; however, the state of the bridge_channel will not be hung up. Since the channel does not have one of the two hang up states, that implies that the channel is still technically alive. This patch modifies the check so that it checks both the soft hangup flags as well as the bridge_channel state. If either suggests that the channel is going to persist, we clear the OUTGOING flag. ........ Merged revisions 397690 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-26bridging: Fix a livelock with local channel optimization.Richard Mudgett
Use a better means of waking up the bridge channel thread. ........ Merged revisions 397650 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-23Blank line tweaks.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-23Add test events necessary for bridge tests to pass in the test suite.Mark Michelson
(closes issue AST-1200) reported by John Bigelow Review: https://reviewboard.asterisk.org/r/2790/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-23Handle DTMF and hold wrapup when a channel leaves the bridging system.Richard Mudgett
DTMF start/end and hold/unhold events have state because a DTMF begin event and hold event must be ended by something. The following cases need to be handled when a channel is moved around in the system. * When a channel leaves a bridge it may owe a DTMF end event to the bridge. * When a channel leaves a bridge it may owe an UNHOLD event to the bridge. (This case is explicitly ignored because things like transfers need explicit control over this.) * When a channel leaves the bridging system it may need to simulate a DTMF end event to the channel. * When a channel leaves the bridging system it may need to simulate an UNHOLD event to the channel. The patch also fixes the following: * Fixes playing a file and restarting MOH using the latest MOH class used. (closes issue ASTERISK-22043) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2791/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397577 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-22Bridge API: Set a cause code on a channel when it is ejected from a bridge.Richard Mudgett
The cause code needs to be passed from the disconnecting channel to the bridge peers if the disconnecting channel dissolves the bridge. * Made the call to an app_agent_pool agent disconnect with the busy cause code if the agent does not ack the call in time or hangs up before acking the call. (closes issue ASTERISK-22042) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2772/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-22Made the abstract jitter buffer resync on some more control frames.Richard Mudgett
Resync the abstract jitter buffer on the following additional control frames: AST_CONTROL_HOLD AST_CONTROL_UNHOLD AST_CONTROL_T38_PARAMETERS git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397440 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-21Deferred some more BUGBUG comments to a JIRA issue or XXX comment.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-21Fix several interrelated issues dealing with the holding bridge technology.Richard Mudgett
* Added an option flags parameter to interval hooks. Interval hooks now can specify if the callback will affect the media path or not. * Added an option flags parameter to the bridge action custom callback. The action callback now can specify if the callback will affect the media path or not. * Made the holding bridge technology reexamine the participant idle mode option whenever the entertainment is restarted. * Fixed app_agent_pool waiting agents needlessly starting and stopping MOH every second by specifying the heartbeat interval hook as not affecting the media path. * Fixed app_agent_pool agent alert from restarting the MOH after the alert beep. The agent entertainment is now changed from MOH to silence after the alert beep. * Fixed holding bridge technology to defer starting the entertainment. It was previously a mixture of immediate and deferred. * Fixed holding bridge technology to immediately stop the entertainment. It was previously a mixture of immediate and deferred. If the channel left the bridging system, any deferred stopping was discarded before taking effect. * Miscellaneous holding bridge technology rework coding improvements. Review: https://reviewboard.asterisk.org/r/2761/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-17Allow res_parking to be unloadableKinsey Moore
This change protects accesses of res_parking such that it can unload safely once transient uses of its registered functions are complete. The parking API has been restructured such that its consumers do not have access to the vtable exposed by the parking provider, but instead route through stubs to prevent consumers from holding on to function pointers. This adds calls to all the parking unload functions and moves application loading and unloading into functions in parking_applications.c similar to the rest of the parts of res_parking. Review: https://reviewboard.asterisk.org/r/2763/ (closes issue ASTERISK-22142) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-16Fix CLI "bridge kick <bridge> <channel>" to check if the bridge needs ↵Richard Mudgett
dissolving. SIP/foo -- Local;1==Local;2 -- .... -- Local;1==Local;2 -- SIP/bar Kick a ;1 channel and the chain toward SIP/foo goes away. Kick a ;2 channel and the chain toward SIP/bar goes away. This can leave a local channel chain between the kicked ;1 and ;2 channels that are orphaned until you manually request one of those channels to hangup or request the bridge to dissolve. * Added ast_bridge_kick() as a companion to ast_bridge_remove(). The functional difference is that ast_bridge_kick() may dissolve the bridge as a result of the channel leaving the bridge. * Made CLI "bridge kick <bridge> <channel>" use ast_bridge_kick() instead of ast_bridge_remove() so the bridge can dissolve if needed. * Renamed bridge_channel_handle_hangup() to ast_bridge_channel_kick() and made it accessible to other files. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-16Doxygen comment tweaks.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Bridge: Don't suspend/unspend the channel for interception routines.Richard Mudgett
By their nature, the connected line and redirecting interception routines are not supposed to affect the channel's media. Therefore, they should not suspend and unsuspend the channel while running. The suspend/unsuspend operations could be expensive depending upon the bridge and channel technology involved. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Remove early bridge BUGBUG comments. Remove some unneeded features.c comments.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Changed some BUGBUG tags to associated JIRA issue tags.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-15Fix Bridge API DTMF hook matching for begin and end DTMF events.Richard Mudgett
The Bridge API DTMF hook matching would not deal with DTMF end events only. It required a DTMF begin event to start matching the DTMF hooks. There are many places in Asterisk where code only generates DTMF end events without the corresponding begin event. One such place is the AMI action Atxfer. * Fixed DTMF hook matching if there is a string of DTMF frames in the read queue. We could potentially miss some of them before. * Fixed AMI Atxfer action documentation. (closes issue ASTERISK-22037) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2752/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-12Fix two race conditions and ref counting issue when joining a bridgeMatthew Jordan
These problems were all caught by a test in the Asterisk Test Suite that originated some Local channels and attempted to move the ;2 half of the Local channel into a bridge using the Bridge AMI action. (1) When originating a channel, the Newchannel event is emitted quickly; however, the ;2 channel will not have a pbx thread assigned to it until after the outbound 'dialing' for the ;1 is complete. Thus, there is a period of time where the outside world "knows" of the channel's existence and can influence it but Asterisk has not yet started the dialplan execution thread. If a Bridge AMI action is taken on the channel, the channel appears to be a Dialed channel with no PBX thread; hence, the channel will be imparted into the Bridge by first 'yanking' the channel. At the same time, a race condition can occur after the yank (but before entering the bridge) when ;1 answers and starts a PBX on the ;2. The end result currently is an assertion failure in the Bridging API, as a channel with a PBX is imparted into the Bridge. There's no way to prevent AMI from attempting to Bridge a channel immediately after creation; likewise, holding the channel lock through the entire Dial operation is unwise (and impossible). Instead of treating the presence of a PBX thread as an error, we simply bail out of the adding the channel to the bridge through ast_bridge_impart. The Bridge action will then fail - but we avoid a situation where the channel is both executing a PBX thread and simultaneously being given a separate thread in the bridging system (which would be a "bad thing"). Since imparting a channel with a PBX *can* occur and is not a programming error, the asserts have been removed. (2) When the first condition occurs, we have to take one of two actions: either hangup the yanked channel as it did not enter the bridge, or deref it because we don't own it. We can determine if we own it or not by testing for the presence of the PBX thread. If we hung it up directly, we'd crash. (3) bridge_find_channel does not increase the reference count of the ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel thus created a ticking time bomb in whatever bridge the channel moved into, as the destructor for the ast_bridge_channel object would be called. Review: https://reviewboard.asterisk.org/r/2741/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-09bridge_channel: Support the lonely flag and make ARI use it.Jonathan Rose
The lonely flag is an optional flag for bridge channels that will make them leave a bridge when a channel leaves if only lonely channels are in the bridge at that point. This is useful for things like ending recording and playback channels when they cease to be interacting with other channels in the bridge. (closes issue ASTERISK-22117) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2721/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-02Make a couple of changes to help AMI events to be more clear in what is ↵Mark Michelson
occurring. * BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable. * There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place. (closes issue ASTERISK-22193) reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/2712 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-08-01Support externally initiated parking requests; remove some dead codeMatthew Jordan
This patch does the following: * It adds support for externally initiated parking requests. In particular, chan_skinny has a protocol level message that initiates a call park. This patch now supports that option, as well as the protocol specific mechanisms in chan_dahdi/sig_analog and chan_mgcp. * A parking bridge features virtual table has been added that provides access to the parking functionality that the Bridging API needs. This includes requests to park an entire 'call' (with little or no additional information, thank you chan_skinny), perform a blind transfer to a parking extension, determine if an extension is a parking extension, as well as the actual "do the parking" request from the Bridging API. * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new functions * The removal of some - but not all - dead parking code from features.c This also fixed blind transferring a multi-party bridge to a parking lot (which was implemented, but had at least one code path where using the parking features kK might not have worked) Review: https://reviewboard.asterisk.org/r/2710 (closes issue ASTERISK-22134) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26Remove the unsafe bridge parameter from ast_bridge_hook_callback's.Richard Mudgett
Most hook callbacks did not need the bridge parameter. The pointer value could become invalid if the channel is moved to another bridge while it is executing. * Fixed some issues in feature_attended_transfer() as a result. * Reduce the bridge inhibit count in attended_transfer_properties_shutdown() after it has restored the bridge channel hooks. * Removed basic bridge requirement on feature_blind_transfer(). It does not require the basic bridge like feature_attended_transfer(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-26Add name argument to BridgeWait() so multiple holding bridges may be usedJonathan Rose
Changes arguments for BridgeWait from BridgeWait(role, options) to BridgeWait(bridge_name, role, options). Now multiple holding bridges may be created and referenced by this application. (closes issue ASTERISK-21922) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2642/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-07-25A great big renaming patchMatthew Jordan
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 18:28:32 +0000