680 Commits (c6d755de11e98c1f6f33b1b35db9725f64f72053)

Author	SHA1	Message	Date
Sebastien Duthil	c6d755de11	res_ari: Add support for channel variables in ARI events. ... This works the same as for AMI manager variables. Set "channelvars=foo,bar" in your ari.conf general section, and then the channel variables "foo" and "bar" (along with their values), will appear in every Stasis websocket channel event. ASTERISK-26492 #close patches: ari_vars.diff submitted by Mark Michelson Change-Id: I5609ba239259577c0948645df776d7f3bc864229	9 years ago
George Joseph	fa749866c1	Revert "Add API for channel frame deferral." ... This reverts commit f073f648b8. Multiple testsuite failures were detected after the fact. Change-Id: I968c380418bf65c7166f6ecff30fe8e247ea6682	9 years ago
Mark Michelson	f073f648b8	Add API for channel frame deferral. ... There are several places in Asterisk that have duplicated logic for deferring important frames until later. This commit adds a couple of API calls to facilitate this automatically. ast_channel_start_defer_frames(): Future reads of deferrable frames on this channel will be deferred until later. ast_channel_stop_defer_frames(): Any frames that have been deferred get requeued onto the channel. ASTERISK-26343 Change-Id: I3e1b87bc6796f222442fa6f7d1b6a4706fb33641	9 years ago
Corey Farrell	a6e5bae3ef	Remove ASTERISK_REGISTER_FILE. ... ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes all traces of it. Previously exported symbols removed: * __ast_register_file * __ast_unregister_file * ast_complete_source_filename This also removes the mtx_prof static variable that was declared when MTX_PROFILE was enabled. This variable was only used in lock.c so it is now initialized in that file only. ASTERISK-26480 #close Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966	9 years ago
Mark Michelson	e459b8dadf	ARI: Detect duplicate channel IDs ... ARI and AMI allow for an explicit channel ID to be specified when originating channels. Unfortunately, there is nothing in place to prevent someone from using the same ID for multiple channels. Further complicating things, adding ID validation to channel allocation makes it impossible for ARI to discern why channel allocation failed, resulting in a vague error code being returned. The fix for this is to institute a new method for channel errors to be discerned. The method mirrors errno, in that when an error occurs, the caller can consult the channel errno value to determine what the error was. This initial iteration of the feature only introduces "unknown" and "channel ID exists" errors. However, it's possible to add more errors as needed. ARI uses this feature to determine why channel allocation failed and can return a 409 error during origination to show that a channel with the given ID already exists. ASTERISK-26421 Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06	9 years ago
zuul	8b58db0962	Merge "Binaural synthesis (confbridge): interleaved two-channel audio."	9 years ago
Michael Walton	7af7490e42	audiohooks: Remove redundant codec translations when using audiohooks ... The main frame read and write handlers in main/channel.c don't use the optimum placement in the processing flow for calling audiohooks callbacks, as far as codec translation is concerned. This change places the audiohooks callback code: * After the channel read translation if the frame is not linear before the translation, thereby increasing the chance that the frame is linear as required by audiohooks * Before the channel write translation if the frame is linear at this point This prevents the audiohooks code from instantiating additional translation paths to/from linear where a linear frame format is already available, saving valuable CPU cycles ASTERISK-26419 Change-Id: I6edd5771f0740e758e7eb42558b953f046c01f8f	9 years ago
frahaase	c455823657	Binaural synthesis (confbridge): interleaved two-channel audio. ... Asterisk only supports mono audio at the moment. This patch adds interleaved two-channel audio to Asterisk's channels. ASTERISK-26292 Change-Id: I7a547cea0fd3c6d1e502709d9e7e39605035757a	9 years ago
Alexander Traud	858fa5eb2c	channel: No hung-up on failing security requirements. ... In your Diaplan, if you specify same => n,Set(CHANNEL(secure_bridge_media)=1) same => n,Set(CHANNEL(secure_bridge_signaling)=1) only the SIP channel driver chan_sip supports this. All other channels drivers like res_pjsip fail. In case of failure, the original sRTP source code released the whole channel, even if not hung-up, yet. This change does not release the channel but instead hangs-up the channel. ASTERISK-26306 Change-Id: I0489f0cb660fab6673b0db8af027d116e70a66db	9 years ago
Corey Farrell	29b0f733a0	Add missing checks during startup. ... This ensures startup is canceled due to allocation failures from the following initializations. * channel.c: ast_channels_init * config_options.c: aco_init ASTERISK-26265 #close Change-Id: I911ed08fa2a3be35de55903e0225957bcdbe9611	9 years ago
Richard Mudgett	e739888d99	res_pjsip: Add fax_detect_timeout endpoint option. ... The new endpoint option allows the PJSIP channel driver's fax_detect endpoint option to timeout on a call after the specified number of seconds into a call. The new feature is disabled if the timeout is set to zero. The option is disabled by default. ASTERISK-26214 Reported by: Richard Mudgett Change-Id: Id5a87375fb2c4f9dc1d4b44c78ec8735ba65453d	9 years ago
Alexei Gradinari	3e8d523d88	core/dial: New channel variable FORWARDERNAME ... Added a new channel variable FORWARDERNAME which indicates which channel was responsible for a forwarding requests received on dial attempt. Fixed a bug in the app_queue: FORWARD_CONTEXT is not used. ASTERISK-26059 #close Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2	9 years ago
Richard Mudgett	c7d45b84f9	bridge core: Add owed T.38 terminate when channel leaves a bridge. ... The channel is now going to get T.38 terminated when it leaves the bridging system and the bridged peers are going to get T.38 terminated as well. ASTERISK-25582 Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7	9 years ago
Richard Mudgett	128c96456c	channel.c: Route all control frames to a channel through the same code. ... Frame hooks can conceivably return a control frame in exchange for an audio frame inside ast_write(). Those returned control frames were not handled quite the same as if they were sent to ast_indicate(). Now it doesn't matter if you use ast_write() to send an AST_FRAME_CONTROL to a channel or ast_indicate(). ASTERISK-25582 Change-Id: I5775f41421aca2b510128198e9b827bf9169629b	9 years ago
Richard Mudgett	fa20729032	Audit improper usage of scheduler exposed by 5c713fdf18. ... channels/chan_iax2.c: * Initialize struct chan_iax2_pvt scheduler ids earlier because of iax2_destroy_helper(). channels/chan_sip.c: channels/sip/config_parser.c: * Fix initialization of scheduler id struct members. Some off nominal paths had 0 as a scheduler id to be destroyed when it was never started. chan_skinny.c: * Fix some scheduler id comparisons that excluded the valid 0 id. channel.c: * Fix channel initialization of the video stream scheduler id. pbx_dundi.c: * Fix channel initialization of the packet retransmission scheduler id. ASTERISK-25476 Change-Id: I07a3449f728f671d326a22fcbd071f150ba2e8c8	10 years ago
Alexander Traud	cf79b62778	ast_format_cap_get_names: To display all formats, the buffer was increased. ... ASTERISK-25533 #close Change-Id: Ie1a9d1a6511b3f1a56b93d04475fbf8a4e40010a	10 years ago
Mark Michelson	f42084be09	Do not swallow frames on channels leaving bridges. ... When leaving a bridge, indications on a channel could be swallowed by the internal indication logic because it appears that the channel is on its way to be hung up anyway. One such situation where this is detrimental is when channels on hold are redirected out of a bridge. The AST_CONTROL_UNHOLD indication from the bridging code is swallowed, leaving the channel in question to still appear to be on hold. The fix here is to modify the logic inside ast_indicate_data() to not drop the indication if the channel is simply leaving a bridge. This way, channels on hold redirected out of a bridge revert to their expected "in use" state after the redirection. ASTERISK-25418 #close Reported by Mark Michelson Change-Id: If6115204dfa0551c050974ee138fabd15f978949	10 years ago
Mark Michelson	8fb8988fd4	Add a test event for inband ringing. ... This event is necessary for the bridge_wait_e_options test to be able to confirm that ringing is being played on the local channel that runs the BridgeWait() application with the e(r) option. ASTERISK-25292 #close Reported by Kevin Harwell Change-Id: Ifd3d3d2bebc73344d4b5310d0d55c7675359d72e	10 years ago
Jonathan Rose	687597ca8c	holding_bridge: ensure moh participants get frames ... Currently, if a blank musiconhold.conf is used, musiconhold will fail to start for a channel going into a holding bridge with an anticipation of getting music on hold. That being the case, no frames will be written to the channel and that can pose a problem for blind transfers in PJSIP which may rely on frames being written to get past the REFER framehook. This patch makes holding bridges start a silence generator if starting music on hold fails and makes it so that if no music on hold functions are installed that the ast_moh_start function will report a failure so that consumers of that function will be able to respond appropriately. ASTERISK-25271 #close Change-Id: I06f066728604943cba0bb0b39fa7cf658a21cd99 (cherry picked from commit 8458b8d441)	10 years ago
Joshua Colp	8d6cf667dc	channel: Remove ignore of answer on non-outgoing channels. ... Due to the way that channels can now be moved around inside of Asterisk it is possible for the outgoing flag of a channel to get cleared before it has been answered. This results in the bridge not receiving notification that the outgoing leg has been answered. This most easily exhibits itself with DTMF based blond transfers. Since the answer of the outgoing leg is ignored the other party continues to receive both a locally generated ringing and the media stream of the outgoing leg upon its answer. This results in no media being heard. This change removes the ignore of the answer and allows it to pass through. ASTERISK-25171 #close Change-Id: I82aedcec4f89f34a2e5472086dfc9a6c775bca8e	10 years ago
Corey Farrell	c3ec5da156	Remove unneeded uses of optional_api providers. ... A few cases exist where headers of optional_api provders are included but not needed. This causes unneeded calls to ast_optional_api_use. * Don't include optional_api.h from sip_api.h. * Move 'struct ast_channel_monitor' to channel.h. * Don't include monitor.h from chan_sip.c, channel.c or features.c. The move of struct ast_channel_monitor is needed since channel.c depends on it. This has no effect on users of monitor.h since channel.h is included from monitor.h. ASTERISK-25051 #close Reported by: Corey Farrell Change-Id: I53ea65a9fc9693c89f8bcfd6120649bfcfbc3478	10 years ago
Corey Farrell	5c1d07baf0	Astobj2: Allow reference debugging to be enabled/disabled by config. ... * The REF_DEBUG compiler flag no longer has any effect on code that uses Astobj2. It is used to determine if reference debugging is enabled by default. Reference debugging can be enabled or disabled in asterisk.conf. * Caller information is provided in logger errors for ao2 bad magic numbers. * Optimizes AO2 by merging internal functions with the public counterpart. This was possible now that we no longer require a dual ABI. ASTERISK-24974 #close Reported by: Corey Farrell Change-Id: Icf3552721fe999365ba8a8cf00a965aa6b897cc1	10 years ago
Mark Michelson	aae45acbda	Detect potential forwarding loops based on count. ... A potential problem that can arise is the following: * Bob's phone is programmed to automatically forward to Carol. * Carol's phone is programmed to automatically forward to Bob. * Alice calls Bob. If left unchecked, this results in an endless loops of call forwards that would eventually result in some sort of fiery crash. Asterisk's method of solving this issue was to track which interfaces had been dialed. If a destination were dialed a second time, then the attempt to call that destination would fail since a loop was detected. The problem with this method is that call forwarding has evolved. Some SIP phones allow for a user to manually forward an incoming call to an ad-hoc destination. This can mean that: * There are legitimate use cases where a device may be dialed multiple times, or * There can be human error when forwarding calls. This change removes the old method of detecting forwarding loops in favor of keeping a count of the number of destinations a channel has dialed on a particular branch of a call. If the number exceeds the set number of max forwards, then the call fails. This approach has the following advantages over the old: * It is much simpler. * It can detect loops involving local channels. * It is user configurable. The only disadvantage it has is that in the case where there is a legitimate forwarding loop present, it takes longer to detect it. However, the forwarding loop is still properly detected and the call is cleaned up as it should be. Address review feedback on gerrit. * Correct "mfgium" to "Digium" * Decrement max forwards by one in the case where allocation of the max forwards datastore is required. * Remove irrelevant code change from pjsip_global_headers.c ASTERISK-24958 #close Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23	10 years ago
Matt Jordan	4a58261694	git migration: Refactor the ASTERISK_FILE_VERSION macro ... Git does not support the ability to replace a token with a version string during check-in. While it does have support for replacing a token on clone, this is somewhat sub-optimal: the token is replaced with the object hash, which is not particularly easy for human consumption. What's more, in practice, the source file version was often not terribly useful. Generally, when triaging bugs, the overall version of Asterisk is far more useful than an individual SVN version of a file. As a result, this patch removes Asterisk's support for showing source file versions. Specifically, it does the following: * Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and remove passing the version in with the macro. Other facilities than 'core show file version' make use of the file names, such as setting a debug level only on a specific file. As such, the act of registering source files with the Asterisk core still has use. The macro rename now reflects the new macro purpose. * main/asterisk: - Refactor the file_version structure to reflect that it no longer tracks a version field. - Remove the "core show file version" CLI command. Without the file version, it is no longer useful. - Remove the ast_file_version_find function. The file version is no longer tracked. - Rename ast_register_file_version/ast_unregister_file_version to ast_register_file/ast_unregister_file, respectively. * main/manager: Remove value from the Version key of the ModuleCheck Action. The actual key itself has not been removed, as doing so would absolutely constitute a backwards incompatible change. However, since the file version is no longer tracked, there is no need to attempt to include it in the Version key. * UPGRADE: Add notes for: - Modification to the ModuleCheck AMI Action - Removal of the "core show file version" CLI command Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e	10 years ago
Richard Mudgett	c499cabf53	chan_pjsip/res_pjsip/bridge_softmix/core: Improve translation path choices. ... With this patch, chan_pjsip/res_pjsip now sets the native formats to the codecs negotiated by a call. * The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native formats to include all the negotiated audio codecs instead of only the initial preferred audio codec and later the currently received audio codec. * The audio frame handling in channel.c:ast_read() is more streamlined and will automatically adjust to changes in received frame formats. The new policy is to remove translation and pass the new frame format to the receiver except if the translation was to a signed linear format. A more long winded version is commented in ast_read() along with some caveats. * The audio frame handling in channel.c:ast_write() is more streamlined and will automatically adjust any needed translation to changes in the frame formats sent. Frame formats sent can change for many reasons such as a recording is being played back or the bridged peer changed the format it sends. Since it is a normal expectation that sent formats can change, the codec mismatch warning message is demoted to a debug message. * Removed the short circuit check in channel.c:ast_channel_make_compatible_helper(). Two party bridges need to make channels compatible with each other. However, transfers and moving channels among bridges can result in otherwise compatible channels having sub-optimal translation paths if the make compatible check is short circuited. A result of forcing the reevaluation of channel compatibility is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc options take effect consistently now. It is unfortunate that these two options are enabled by default and negate some of the benefits to the changes in channel.c:ast_read() by forcing translation through signed linear on a two party bridge. * Improved the softmix bridge technology to better control the translation of frames to the bridge. All of the incoming translation is now normally handled by ast_read() instead of splitting any translation steps between ast_read() and the slin factory. If any frame comes in with an unexpected format then the translation path in ast_read() is updated for the next frame and the slin factory handles the current frame translation. This is the final patch in a series of patches aimed at improving translation path choices. The other patches are on the following reviews: https://reviewboard.asterisk.org/r/4600/ https://reviewboard.asterisk.org/r/4605/ ASTERISK-24841 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4609/ ........ Merged revisions 434671 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434672 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Richard Mudgett	6f1a7fe05f	bridge_softmix.c,channel.c: Minor code simplification and cleanup. ... * Made code easier to follow in bridge_softmix.c:analyse_softmix_stats() and made some debug messages more helpful. * Made some debug and warning messages more helpful in channel.c:set_format(). Review: https://reviewboard.asterisk.org/r/4607/ ........ Merged revisions 434617 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434618 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Richard Mudgett	0b805cb875	translate.c: Only select audio codecs to determine the best translation choice. ... Given a source capability of h264 and ulaw, a destination capability of h264 and g722 then ast_translator_best_choice() would pick h264 as the best choice even though h264 is a video codec and Asterisk only supports translation of audio codecs. When the audio starts flowing, there are warnings about a codec mismatch when the channel tries to write a frame to the peer. * Made ast_translator_best_choice() only select audio codecs. * Restore a check in channel.c:set_format() lost after v1.8 to prevent trying to set a non-audio codec. This is an intermediate patch for a series of patches aimed at improving translation path choices for ASTERISK-24841. This patch is a complete enough fix for ASTERISK-21777 as the v11 version of ast_translator_best_choice() does the same thing. However, chan_sip.c still somehow tries to call ast_codec_choose() which then calls ast_best_codec() with a capability set that doesn't contain any audio formats for the incoming call. The remaining warning message seems to be a benign transient. ASTERISK-21777 #close Reported by: Nick Ruggles ASTERISK-24380 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4605/ ........ Merged revisions 434614 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434615 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434616 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	c2f50ba6f4	ARI: Add the ability to intercept hold and raise an event ... For some applications - such as SLA - a phone pressing hold should not behave in the fashion that the Asterisk core would like it to. Instead, the hold action has some application specific behaviour associated with it - such as disconnecting the channel that initiated the hold; only playing MoH to channels in the bridge if the channels are of a particular type, etc. One way of accomplishing this is to use a framehook to intercept the hold/unhold frames, raise an event, and eat the frame. Tasty. This patch accomplishes that using a new dialplan function, HOLD_INTERCEPT. In addition, some general cleanup of raising hold/unhold Stasis messages was done, including removing some RAII_VAR usage. Review: https://reviewboard.asterisk.org/r/4549/ ASTERISK-24922 #close ........ Merged revisions 434216 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434217 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	e9520dbe0d	clang compiler warnings: Fix -Wparantheses-equality warnings ... Clang will treat ((a == b)) as a warning, as it reasonably expects that the developer may have intended to write (a == b) or ((a = b)). This patch cleans up all instances where equality, not assignment, was intended between two parantheses. Review: https://reviewboard.asterisk.org/r/4531/ ASTERISK-24917 Repoted by: dkdegroot patches: rb4531.patch submitted by dkdegroot (License 6600) ........ Merged revisions 433687 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 433688 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433689 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Corey Farrell	3ddd92902a	Replace most uses of ast_register_atexit with ast_register_cleanup. ... Since 'core stop now' and 'core restart now' do not stop modules, it is unsafe for most of the core to run cleanups. Originally all cleanups used ast_register_atexit, and were only changed when it was shown to be unsafe. ast_register_atexit is now used only when absolutely required to prevent corruption and close child processes. Exceptions that need to use ast_register_atexit: * CDR: Flush records. * res_musiconhold: Kill external applications. * AstDB: Close the DB. * canary_exit: Kill canary process. ASTERISK-24142 #close Reported by: David Brillert ASTERISK-24683 #close Reported by: Peter Katzmann ASTERISK-24805 #close Reported by: Badalian Vyacheslav ASTERISK-24881 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4500/ Review: https://reviewboard.asterisk.org/r/4501/ ........ Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 433497 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Corey Farrell	c08fd275bf	Logger: Convert 'struct ast_callid' to unsigned int. ... Switch logger callid's from AO2 objects to simple integers. This helps in two ways. Copying integers is faster than referencing AO2 objects, so this will result in a small reduction in logger overhead. This also erases the possibility of an infinate loop caused by an invalid callid in threadstorage. ASTERISK-24833 #comment Committed callid conversion to trunk. Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4466/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kevin Harwell	d04fbb0f9d	app_chanspy, channel: fix frame leaks ... Fixed a couple of frame leaks that were found during testing. ASTERISK-24828 #close Reported by: John Hardin Review: https://reviewboard.asterisk.org/r/4445/ ........ Merged revisions 432362 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 432363 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432364 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	a528dfc9a7	ARI/PJSIP: Apply requesting channel's format cap to created channels ... This patch addresses the following problems: * ari/resource_channels: In ARI, we currently create a format capability structure of SLIN and apply it to the new channel being created. This was originally done when the PBX core was used to create the channel, as there was a condition where a newly created channel could be created without any formats. Unfortunately, now that the Dial API is being used, this has two drawbacks: (a) SLIN, while it will ensure audio will flows, can cause a lot of needless transcodings to occur, particularly when a Local channel is created to the dialplan. When no format capabilities are available, the Dial API handles this better by handing all audio formats to the requsted channels. As such, we defer to that API to provide the format capabilities. (b) If a channel (requester) is causing this channel to be created, we currently don't use its format capabilities as we are passing in our own. However, the Dial API will use the requester channel's formats if none are passed into it, and the requester channel exists and has format capabilities. This is the "best" scenario, as it is the most likely to create a media path that minimizes transcoding. Fixing this simply entails removing the providing of the format capabilities structure to the Dial API. * chan_pjsip: Rather than blindly picking the first format in the format capability structure - which actually *can* be a video or text format - we select an audio format, and only pick the first format if that fails. That minimizes the weird scenario where we attempt to transcode between video/audio. * res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure. Since ast_request already limits us down to one format capability once the format capabilities are passed along, there's no reason to squelch it here. * channel: Fixed a comment. The reason we have to minimize our requested format capabilities down to a single format is due to Asterisk's inability to convey the format to be used back "up" a channel chain. Consider the following: PJSIP/A => L;1 <=> L;2 => PJSIP/B g,u,a g,u,a g,u,a u That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local channel has inherited those format capabilities down the line; PJSIP/B supports only ulaw. According to these format capabilities, ulaw is acceptable and should be selected across all the channels, and no transcoding should occur. However, there is no way to convey this: when L;2 and PJSIP/B are put into a bridge, we will select ulaw, but that is not conveyed to PJSIP/A and L;1. Thus, we end up with: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B g g X u u Which causes g722 to be written to PJSIP/B. Even if we can convey the 'ulaw' choice back up the chain (which through some severe hacking in Local channels was accomplished), such that the chain looks like: PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B u u u u We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back with only 'ulaw'. This results in all the channel structures being set up correctly, but PJSIP/A *still* sending g722 and causing the chain to fall apart. There's a lot of difficulty just in setting this up, as there are numerous race conditions in the act of bridging, and no clean mechanism to pass the selected format backwards down an established channel chain. As such, the best that can be done at this point in time is clarifying the comment. Review: https://reviewboard.asterisk.org/r/4434/ ASTERISK-24812 #close Reported by: Matt Jordan ........ Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Richard Mudgett	e2d3215b83	HTTP: Stop accepting requests on final system shutdown. ... There are three CLI commands to stop and restart Asterisk each. 1) core stop/restart now - Hangup all calls and stop or restart Asterisk. New channels are prevented while the shutdown request is pending. 2) core stop/restart gracefully - Stop or restart Asterisk when there are no calls remaining in the system. New channels are prevented while the shutdown request is pending. 3) core stop/restart when convenient - Stop or restart Asterisk when there are no calls in the system. New calls are not prevented while the shutdown request is pending. ARI has made stopping/restarting Asterisk more problematic. While a shutdown request is pending it is desirable to continue to process ARI HTTP requests for current calls. To handle the current calls while a shutdown request is pending, a new committed to shutdown phase is needed so ARI applications can deal with the calls until the system is fully committed to shutdown. * Added a new shutdown committed phase so ARI applications can deal with calls until the final committed to shutdown phase is reached. * Made refuse new HTTP requests when the system has reached the final system shutdown phase. Starting anything while the system is actively releasing resources and unloading modules is not a good thing. * Split the bridging framework shutdown to not cleanup the global bridging containers when shutting down in a hurry. This is similar to how other modules prevent crashes on rapid system shutdown. * Moved ast_begin_shutdown(), ast_cancel_shutdown(), and ast_shutting_down(). You should not have to include channel.h just to access these system functions. ASTERISK-24752 #close Reported by: Matthew Jordan Review: https://reviewboard.asterisk.org/r/4399/ ........ Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	0c38276d6e	presencestate: Allow channel drivers to provide presence state information ... This patch adds the ability for channel drivers to supply presence information in a similar manner to device state. The patch does not provide any channel driver implementations, but it does provide the core infrastructure necessary for channel drivers to provide such information. The core handles multiple providers of presence state information. Ordering of presence state is as follows: INVALID < NOT_SET < AVAILABLE < UNAVAILABLE < CHAT < AWAY < XA < DND Each provider can trump the previous if it provides a presence state that supercedes a previous one. Review: https://reviewboard.asterisk.org/r/4050 ASTERISK-24363 #close Reported by: Gareth Palmer patches: chan_presencestate-428146.patch uploaded by Gareth Palmer (License 5169) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429967 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Mark Michelson	fe7671fee6	Add new AMI and ARI events for connected line changes on a channel. ... The AMI event is called NewConnectedLine and the ARI event is called ChannelConnectedLine. ASTERISK-24554 #close Reported by Matt Jordan Review: https://reviewboard.asterisk.org/r/4231 ........ Merged revisions 429064 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429084 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	4bb556a847	Stasis: Fix StasisStart/End order and missing events ... This corrects several bugs that currently exist in the stasis application code. * After a masquerade, the resulting channels have channel topics that do not match their uniqueids ** Masquerades now swap channel topics appropriately * StasisStart and StasisEnd messages are leaked to observer applications due to being published on channel topics ** StasisStart and StasisEnd publishing is now properly restricted to controlling apps via app topics * Race conditions exist where StasisStart and StasisEnd messages due to a masquerade may be received out of order due to being published on different topics ** These messages are now published directly on the app topic so this is now a non-issue * StasisEnds are sometimes missing when sent due to masquerades and bridge swaps into and out of Stasis() ** This was due to StasisEnd processing adjusting message-sent flags after Stasis() had already exited and Stasis() had been re-entered ** This was corrected by adjusting these flags prior to sending the message while the initial Stasis() application was still shutting down Review: https://reviewboard.asterisk.org/r/4213/ ASTERISK-24537 #close Reported by: Matt DiMeo ........ Merged revisions 429061 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429062 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429063 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	7db3d1642b	channel: Extend size of buffer for codecs in "core show channeltype" CLI command. ... The static buffer for codecs when invoking the "core show channeltype" CLI command did not have enough room for all codecs. This has been extended so it does. ASTERISK-24542 #close Reported by: snuffy patches: channeltype-tech.diff submitted by snuffy (license 5024) Review: https://reviewboard.asterisk.org/r/4204/ ........ Merged revisions 428632 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428633 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	f91cb1207c	AMI: Add missing VarSet events when a channel inherits variables. ... There should be AMI VarSet events when channel variables are inherited by an outgoing channel. Also local;2 should generate VarSet events when it gets all of its channel variables from channel local;1. ASTERISK-24415 #close Reported by: Richard Mudgett Patches: jira_asterisk_24415_v12.patch (license #5621) patch uploaded by Richard Mudgett Review: https://reviewboard.asterisk.org/r/4074/ ........ Merged revisions 425782 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 425783 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425784 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	0165c5f95a	chan_pjsip: Fix deadlock when masquerading PJSIP channels. ... 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	11 years ago
Matthew Jordan	64a9e5f001	main/channel: Unlock channel in off-nominal path ... In r423414 (13) / r423415 (trunk), an API call that determines if a format capability structure is empty was added. This returns true if the format capability structure is completely empty or "none". A check for this was added in channel.c's set_format call. Unfortunately, when this check was true, it returned from the function while still holding the channel lock. This caused the CDR unit tests - which have a tendency to create channels with no formats - to deadlock. Whoops. This patch unlocks the channel on the off-nominal path. ........ Merged revisions 423641 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423642 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	fa6313ad29	Add API call to determine if format capability structure is "empty". ... Empty here means that there are no formats in the format_cap structure or the only format in it is the "none" format. I've added calls to check the emptiness of a format_cap in a few places in order to short-circuit operations that would otherwise be pointless as well as to prevent some assertions from being triggered in cases where channels with no formats are used. ........ Merged revisions 423414 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423415 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	b7f98c3da4	chan_pjsip: Update media translation paths when new SDP negotiated. ... 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	11 years ago
Jonathan Rose	9b658b7c60	Bridging: Fix a behavioral change when checking if a channel is leaving a bridge ... r420934 introduced some failures in the test suite. Upon investigating, it was discovered that differences in the way we were evaluating whether a channel was in the process of leaving a bridge were causing some reinvites not to occur (mostly reinvites back to Asterisk when ending a call). This patch fixes that behavioral change. ASTERISK-24027 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3910/ ........ Merged revisions 421186 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 421187 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421195 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	e4b32731b9	channel_internal_api.c: Replace some code with ao2_replace(). ... Use ao2_replace() instead of ao2_cleanup(); ao2_bump(). ao2_replace() has the advantange of not altering the ref count if the replaced pointer is the same. Review: https://reviewboard.asterisk.org/r/3904/ ........ Merged revisions 420992 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420993 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Jonathan Rose	d4695774e7	Bridges: Fix feature interruption/unintended kick caused by external actions ... 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	11 years ago
Kinsey Moore	0ac7f96057	Stasis: Convey transfer information to applications ... This fixes a class of issues where Stasis applications were not made aware that their channels were being manipulated or replaced by external entitiessuch as transfers, AMI commands, or dialplan applications such as Bridge(). Inconsistent information such as StasisEnd events with unknown channels as a result of masquerades has also been corrected. To accomplish these fixes, several new fields were added to blind and attended transfer messages as well as StasisStart and BridgeAttendedTransfer Stasis events. ASTERISK-23941 #close Review: https://reviewboard.asterisk.org/r/3865/ Review: https://reviewboard.asterisk.org/r/3857/ Review: https://reviewboard.asterisk.org/r/3852/ Review: https://reviewboard.asterisk.org/r/3816/ Review: https://reviewboard.asterisk.org/r/3731/ Review: https://reviewboard.asterisk.org/r/3729/ Review: https://reviewboard.asterisk.org/r/3728/ ........ Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	f1036f40dc	Stasis: Allow message types to be blocked ... This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	2758cc76e5	datastores: Audit ast_channel_datastore_remove usage. ... Audit of v1.8 usage of ast_channel_datastore_remove() for datastore memory leaks. * Fixed leaks in app_speech_utils and func_frame_trace. * Fixed app_speech_utils not locking the channel when accessing the channel datastore list. Review: https://reviewboard.asterisk.org/r/3859/ Audit of v11 usage of ast_channel_datastore_remove() for datastore memory leaks. * Fixed leak in func_jitterbuffer. (Was not in v12) Review: https://reviewboard.asterisk.org/r/3860/ Audit of v12 usage of ast_channel_datastore_remove() for datastore memory leaks. * Fixed leaks in abstract_jb. * Fixed leak in ast_channel_unsuppress(). Used by ARI mute control and res_mutestream. * Fixed ref leak in ast_channel_suppress(). Used by ARI mute control and res_mutestream. Review: https://reviewboard.asterisk.org/r/3861/ ........ Merged revisions 419684 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 419685 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 419686 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419688 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	a2ce95d9d2	accountcode: Slightly change accountcode propagation. ... The previous behavior was to simply set the accountcode of an outgoing channel to the accountcode of the channel initiating the call. It was done this way a long time ago to allow the accountcode set on the SIP/100 channel to be propagated to a local channel so the dialplan execution on the Local;2 channel would have the SIP/100 accountcode available. SIP/100 -> Local;1/Local;2 -> SIP/200 Propagating the SIP/100 accountcode to the local channels is very useful. Without any dialplan manipulation, all channels in this call would have the same accountcode. Using dialplan, you can set a different accountcode on the SIP/200 channel either by setting the accountcode on the Local;2 channel or by the Dial application's b(pre-dial), M(macro) or U(gosub) options, or by the FollowMe application's b(pre-dial) option, or by the Queue application's macro or gosub options. Before Asterisk v12, the altered accountcode on SIP/200 will remain until the local channels optimize out and the accountcode would change to the SIP/100 accountcode. Asterisk v1.8 attempted to add peeraccount support but ultimately had to punt on the support. The peeraccount support was rendered useless because of how the CDR code needed to unconditionally force the caller's accountcode onto the peer channel's accountcode. The CEL events were thus intentionally made to always use the channel's accountcode as the peeraccount value. With the arrival of Asterisk v12, the situation has improved somewhat so peeraccount support can be made to work. Using the indicated example, the the accountcode values become as follows when the peeraccount is set on SIP/100 before calling SIP/200: SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200 acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200 peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100 If a channel already has an accountcode it can only change by the following explicit user actions: 1) A channel originate method that can specify an accountcode to use. 2) The calling channel propagating its non-empty peeraccount or its non-empty accountcode if the peeraccount was empty to the outgoing channel's accountcode before initiating the dial. e.g., Dial and FollowMe. The exception to this propagation method is Queue. Queue will only propagate peeraccounts this way only if the outgoing channel does not have an accountcode. 3) Dialplan using CHANNEL(accountcode). 4) Dialplan using CHANNEL(peeraccount) on the other end of a local channel pair. If a channel does not have an accountcode it can get one from the following places: 1) The channel driver's configuration at channel creation. 2) Explicit user action as already indicated. 3) Entering a basic or stasis-mixing bridge from a peer channel's peeraccount value. You can specify the accountcode for an outgoing channel by setting the CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue applications. Queue adds the wrinkle that it will not overwrite an existing accountcode on the outgoing channel with the calling channels values. Accountcode and peeraccount values propagate to an outgoing channel before dialing. Accountcodes also propagate when channels enter or leave a basic or stasis-mixing bridge. The peeraccount value only makes sense for mixing bridges with two channels; it is meaningless otherwise. * Made peeraccount functional by changing accountcode propagation as described above. * Fixed CEL extracting the wrong ie value for the peeraccount. This was done intentionally in Asterisk v1.8 when that version had to punt on peeraccount. * Fixed a few places dealing with accountcodes that were reading from channels without the lock held. AFS-65 #close Review: https://reviewboard.asterisk.org/r/3601/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago