summaryrefslogtreecommitdiff
path: root/include/asterisk/channel.h
AgeCommit message (Collapse)Author
2018-03-19core: Remove additional symbols.Corey Farrell
Remove symbols that are depreacated and replaced: * ast_channel_datastore_alloc * ast_channel_datastore_free * ast_channel_cmpwhentohangup * ast_channel_setwhentohangup * config_text_file_save * devstate2str * ast_device_state_changed * ast_device_state_changed_literal * ast_verbose_get_by_module Remove unused symbols: * channelreloadreason2txt (last used in Asterisk 12). Remove unused ast_options flags: * AST_OPT_FLAG_END_CDR_BEFORE_H_EXTEN / ast_opt_end_cdr_before_h_exten * AST_OPT_FLAG_VERBOSE_MODULE / ast_opt_verb_module * AST_OPT_FLAG_INITIATED_SECONDS Change-Id: I841255995d195f8efc1ed47af9c7a2f131c08645
2018-03-13core: Remove incorrect usage of attribute_malloc.Corey Farrell
GCC documentation states that when __attribute__((malloc)) is used it should not return storage which contains any valid pointers. It specifically mentions that realloc functions should not have the malloc attribute, but this also means that complex initializers which could contain initialized pointers should not use this attribute. Change-Id: If507f33ffb3ca3b83b702196eb0e8215d27fc7d2
2017-08-22channel: Fix topology API locking.Richard Mudgett
* ast_channel_request_stream_topology_change() must not be called with any channel locks held. * ast_channel_stream_topology_changed() must be called with only the passed channel lock held. ASTERISK-27212 Change-Id: I843de7956d9f1cc7cc02025aea3463d8fe19c691
2017-07-19Merge "core: Add digit filtering to ast_waitfordigit_full"Joshua Colp
2017-07-12core: Add digit filtering to ast_waitfordigit_fullCorey Farrell
This adds a parameter to ast_waitfordigit_full which can be used to only stop waiting when certain expected digits are received. Any unexpected DTMF digits are simply ignored. This also creates a new dialplan application WaitDigit. ASTERISK-27129 #close Change-Id: Id233935ea3d13e71c75a0861834c5936c3700ef9
2017-07-11bridge/core_unreal: Fix SFU bugs with forwarding frames.Joshua Colp
This change fixes a few things uncovered during SFU testing. 1. Unreal channels incorrectly forwarded video frames when no video stream was present on them. This caused a crash when they were read as the core requires a stream to exist for the underlying media type. The Unreal channel will now ensure a stream exists for the media type before forwarding the frame and if no stream exists then the frame is dropped. 2. Mapping of frames during bridging from the stream number of the underlying channel to the stream number of the bridge was done in the wrong location. This resulted in the frame getting dropped. This mapping now occurs on reading of the frame from the channel. 3. Bridging was using the wrong ast_read function resulting in it living in a non-multistream world. 4. In bridge_softmix when adding new streams to existing channels the wrong stream topology was copied resulting in no streams being added. Change-Id: Ib7445722c3219951d6740802a0feddf2908c18c8
2017-07-05core: Remove 'Data Retrieval API'Sean Bright
This API was not actively maintained, was not added to new modules (such as res_pjsip), and there exist better alternatives to acquire the same information, such as the ARI. Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83
2017-05-16asterisk: Audit locking of channel when manipulating flags.Joshua Colp
When manipulating flags on a channel the channel has to be locked to guarantee that nothing else is also manipulating the flags. This change introduces locking where necessary to guarantee this. It also adds helper functions that manipulate channel flags and lock to reduce repeated code. ASTERISK-26789 Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
2017-05-04bridge: Fix returning to dialplan when executing Bridge() from AMI.Joshua Colp
When using the Bridge AMI action on the same channel multiple times it was possible for the channel to return to the wrong location in the dialplan if the other party hung up. This happened because the priority of the channel was not preserved across each action invocation and it would fail to move on to the next priority in other cases. This change makes it so that the priority of a channel is preserved when taking control of it from another thread and it is incremented as appropriate such that the priority reflects where the channel should next be executed in the dialplan, not where it may or may not currently be. The Bridge AMI action was also changed to ensure that it too starts the channels at the next location in the dialplan. ASTERISK-24529 Change-Id: I52406669cf64208aef7252a65b63ade31fbf7a5a
2017-05-03bridge_simple: Added support for streamsKevin Harwell
This patch is the first cut at adding stream support to the bridging framework. Changes were made to the framework that allows mapping of stream topologies to a bridge's supported media types. The first channel to enter a bridge initially defines the media types for a bridge (i.e. a one to one mapping is created between the bridge and the first channel). Subsequently added channels merge their media types into the bridge's adding to it when necessary. This allows channels with different sized topologies to map correctly to each other according to media type. The bridge drops any frame that does not have a matching index into a given write stream. For now though, bridge_simple will align its two channels according to size or first to join. Once both channels join the bridge the one with the most streams will indicate to the other channel to update its streams to be the same as that of the other. If both channels have the same number of streams then the first channel to join is chosen as the stream base. A topology change source was also added to a channel when a stream toplogy change request is made. This allows subsystems to know whether or not they initiated a change request. Thus avoiding potential recursive situations. ASTERISK-26966 #close Change-Id: I1eb5987921dd80c3cdcf52accc136393ca2d4163
2017-04-27Merge "channel: Add ability to request an outgoing channel with stream ↵Jenkins2
topology."
2017-04-27channel: Add ability to request an outgoing channel with stream topology.Joshua Colp
This change extends the ast_request functionality by adding another function and callback to create an outgoing channel with a requested stream topology. Fallback is provided by either converting the requested stream topology into a format capabilities structure if the channel driver does not support streams or by converting the requested format capabilities into a stream topology if the channel driver does support streams. The Dial application has also been updated to request an outgoing channel with the stream topology of the calling channel. ASTERISK-26959 Change-Id: Ifa9037a672ac21d42dd7125aa09816dc879a70e6
2017-04-24core: Use eventfd for alert pipes on Linux when possibleSean Bright
The primary win of switching to eventfd when possible is that it only uses a single file descriptor while pipe() will use two. This means for each bridge channel we're reducing the number of required file descriptors by 1, and - if you're using timerfd - we also now have 1 less file descriptor per Asterisk channel. The API is not ideal (passing int arrays), but this is the cleanest approach I could come up with to maintain API/ABI. I've also removed what I believe to be an erroneous code block that checked the non-blocking flag on the pipe ends for each read. If the file descriptor is 'losing' its non-blocking mode, it is because of a bug somewhere else in our code. In my testing I haven't seen any measurable difference in performance. Change-Id: Iff0fb1573e7f7a187d5211ddc60aa8f3da3edb1d
2017-03-30Forward declare 'struct ast_json' in asterisk.hCorey Farrell
The ast_json structure is used in many Asterisk headers and is often the only part of json.h used. This adds a forward declaration to asterisk.h and removes the include of json.h from many headers. The declaration has been left in endpoints.h and stasis.h to avoid problems with source files that use ast_json functions without directly including json.h. ari.h continues to include json.h as it uses enum ast_json_encoding_format. Change-Id: Id766aabce6bed56626d27e8d29f559b5e687b769
2017-03-27channel: Remove old epoll support and fixed max number of file descriptors.Joshua Colp
This change removes the old epoll support which has not been used or maintained in quite some time. The fixed number of file descriptors on a channel has also been removed. File descriptors are now contained in a growable vector. This can be used like before by specifying a specific position to store a file descriptor at or using a new API call, ast_channel_fd_add, which adds a file descriptor to the channel and returns its position. Tests have been added which cover the growing behavior of the vector and the new API call. ASTERISK-26885 Change-Id: I1a754b506c009b83dfdeeb08c2d2815db30ef928
2017-03-07core: Add stream topology changing primitives with tests.Joshua Colp
This change adds a few things to facilitate stream topology changing: 1. Control frame types have been added for use by the channel driver to notify the application that the channel wants to change the stream topology or that a stream topology change has been accepted. They are also used by the indicate interface to the channel that the application uses to indicate it wants to do the same. 2. Legacy behavior has been adopted in ast_read() such that if a channel requests a stream topology change it is denied automatically and the current stream topology is preserved if the application is not capable of handling streams. Tests have also been written which confirm the multistream and non-multistream behavior. ASTERISK-26839 Change-Id: Ia68ef22bca8e8457265ca4f0f9de600cbcc10bc9
2017-03-01stream: Unit tests for stream read and tweaks frameworkGeorge Joseph
* Removed the AST_CHAN_TP_MULTISTREAM tech property. We now rely on read_stream being set to indicate a multi stream channel. * Added ast_channel_is_multistream convenience function. * Fixed issue where stream and default_stream weren't being set on a frame retrieved from the queue. * Now testing for NULL being returned from the driver's read or read_stream callback. * Fixed issue where the dropnondefault code was crashing on a NULL f. * Now enforcing that if either read_stream or write_stream are set when ast_channel_tech_set is called that BOTH are set. * Added the unit tests. ASTERISK-26816 Change-Id: If7792b20d782e71e823dabd3124572cf0a4caab2
2017-02-24channel: Add ast_read_stream function for reading frames from all streams.Joshua Colp
This change introduces an ast_read_stream function and callback in the channel technology which allows reading frames from all streams and not just the default streams. The stream number has also been added to frames. This is to allow the case where frames are queued onto the channel instead of being read directly from the driver. This change does impose a restriction on reading though: a chain of frames can only contain frames from the same stream. ASTERISK-26816 Change-Id: I5d7dc35e86694df91fd025126f6cfe0453aa38ce
2017-02-23channel: Add support for writing to a specific stream.Joshua Colp
This change adds an ast_write_stream function which allows writing a frame to a specific media stream. It also moves ast_write() to using this underneath by writing media frames provided to it to the default streams of the channel. Existing functionality (such as audiohooks, framehooks, etc) are limited to being applied to the default stream only. Unit tests have also been added which test the behavior of both non-multistream and multistream channels to confirm that the write() and write_stream() callbacks are invoked appropriately. ASTERISK-26793 Change-Id: I4df20d1b65bd4d787fce0b4b478e19d2dfea245c
2017-02-14stream: Add stream topology to channelGeorge Joseph
Adds topology set and get to channel. ASTERISK-26790 Change-Id: Ic379ea82a9486fc79dbd8c4d95c29fa3b46424f4
2017-02-02res_agi: Prevent an AGI from eating frames it should not. (Re-do)Richard Mudgett
A dialplan intercept routine is equivalent to an interrupt routine. As such, the routine must be done quickly and you do not have access to the media stream. These restrictions are necessary because the media stream is the responsibility of some other code and interfering with or delaying that processing is bad. A possible future dialplan processing architecture change may allow the interception routine to run in a different thread from the main thread handling the media and remove the execution time restriction. * Made res_agi.c:run_agi() running an AGI in an interception routine run in DeadAGI mode. No touchy channel frames. ASTERISK-25951 ASTERISK-26343 ASTERISK-26716 Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43
2017-02-02Frame deferral: Revert API refactoring.Richard Mudgett
There are several issues with deferring frames that are caused by the refactoring. 1) The code deferring frames mishandles adding a deferred frame to the deferred queue. As a result the deferred queue can only be one frame long. 2) Deferrable frames can come directly from the channel driver as well as the read queue. These frames need to be added to the deferred queue. 3) Whoever is deferring frames is really only doing the __ast_read() to collect deferred frames and doesn't care about the returned frames except to detect a hangup event. When frame deferral is completed we must make the normal frame processing see the hangup as a frame anyway. As such, there is no need to have varying hangup frame deferral methods. We also need to be aware of the AST_SOFTHANGUP_ASYNCGOTO hangup that isn't real. That fake hangup is to cause the PBX thread to break out of loops to go execute a new dialplan location. 4) To properly deal with deferrable frames from the channel driver as pointed out by (2) above, means that it is possible to process a dialplan interception routine while frames are deferred because of the AST_CONTROL_READ_ACTION control frame. Deferring frames is not implemented as a re-entrant operation so you could have the unsupported case of two sections of code thinking they have control of the media stream. A worse problem is because of the bad implementation of the AMI PlayDTMF action. It can cause two threads to be deferring frames on the same channel at the same time. (ASTERISK_25940) * Rather than fix all these problems simply revert the API refactoring as there is going to be only autoservice and safe_sleep deferring frames anyway. ASTERISK-26343 ASTERISK-26716 #close Change-Id: I45069c779aa3a35b6c863f65245a6df2c7865496
2016-12-14MESSAGE: Flush Message/ast_msg_queue channel alert pipe.Richard Mudgett
ASTERISK-25083 Change-Id: Id54baa57a8dbca84e29f28bcd2ffc0a5ac12d8b2
2016-11-30chan_pjsip: fix switching sending codec when asymmetric_rtp_codec=noAlexei Gradinari
The sending codec is switched to the receiving codec and then is switched back to the best native codec on EVERY receiving RTP packets. This is because after call of ast_channel_set_rawwriteformat there is call of ast_set_write_format which calls set_format which sets rawwriteformat to the best native format. This patch adds a new function ast_set_write_format_path which set specific write path on channel and uses this function to switch the sending codec. ASTERISK-26603 #close Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d
2016-11-16Merge "channel: Fix issues in hangup scenarios caused by frame deferral"George Joseph
2016-11-16Merge "Revert "Revert "Add API for channel frame deferral."""George Joseph
2016-11-14channel: Fix issues in hangup scenarios caused by frame deferralGeorge Joseph
ASTERISK-26343 Change-Id: I06dbf7366e26028251964143454a77d017bb61c8 (cherry picked from commit 0be46aaf6b8b9eb5b0160ec591cdc2c6e1802a6d)
2016-11-14Revert "Revert "Add API for channel frame deferral.""George Joseph
This reverts commit fa749866c17f91860d3e9f89742eab3e6f03ecbc. Change-Id: Idcd1b88fa0766b1326dcc87d8905dbc314c71bd7
2016-11-14res_ari: Add support for channel variables in ARI events.Sebastien Duthil
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
2016-11-10Revert "Add API for channel frame deferral."George Joseph
This reverts commit f073f648b87d45e4729969fd2d83695c300757d1. Multiple testsuite failures were detected after the fact. Change-Id: I968c380418bf65c7166f6ecff30fe8e247ea6682
2016-11-08Add API for channel frame deferral.Mark Michelson
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
2016-10-20ARI: Detect duplicate channel IDsMark Michelson
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
2016-10-12Merge "Binaural synthesis (confbridge): interleaved two-channel audio."zuul
2016-10-03Binaural synthesis (confbridge): interleaved two-channel audio.frahaase
Asterisk only supports mono audio at the moment. This patch adds interleaved two-channel audio to Asterisk's channels. ASTERISK-26292 Change-Id: I7a547cea0fd3c6d1e502709d9e7e39605035757a
2016-08-25res_fax: Fix deadlock in ast_channel_get_t38_state().Richard Mudgett
ast_channel_get_t38_state() calls ast_channel_queryoption() with AST_OPTION_T38_STATE. If the passed in channel is a local channel then a deadlock can happen if a channel lock is held when called. * Made ast_channel_get_t38_state() callers not hold a channel lock before calling. * Update ast_channel_get_t38_state() doxygen to note that no channel locks can be held when calling the function. ASTERISK-26203 #close Reported by: Etienne Lessard ASTERISK-24822 #close Reported by: David Brillert ASTERISK-22732 #close Reported by: Richard Mudgett Change-Id: I49fd76fa9af628b4198009b5c0b82c8b03681214
2016-02-29channel api: Create is_t38_active accessor functions.Richard Mudgett
ASTERISK-25582 Change-Id: I69451920b122de7ee18d15bb231c80ea7067a22b
2015-11-05Increase account code maximum length to 80.Corey Farrell
This increases the maximum length of account code's to match extensions. This ensures it is always possible to set an accountcode to ${EXTEN} without truncation. ASTERISK-23904 Reported by: Ben Merrills Change-Id: If122602304ce03362722eb213a3111b32da5eeb9
2015-05-02Remove unneeded uses of optional_api providers.Corey Farrell
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
2015-04-30include/asterisk/channel.h: Fix typoRodrigo Ramírez Norambuena
Change-Id: Ie584b85e16a94c255e60d0b1732ef9686464fef3
2015-04-27Astobj2: Allow reference debugging to be enabled/disabled by config.Corey Farrell
* 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
2015-04-10chan_pjsip/res_pjsip/bridge_softmix/core: Improve translation path choices.Richard Mudgett
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
2015-03-13Logger: Convert 'struct ast_callid' to unsigned int.Corey Farrell
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
2015-02-11HTTP: Stop accepting requests on final system shutdown.Richard Mudgett
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
2015-01-23Fix typo's (retrieve, specified, address).Walter Doekes
........ Merged revisions 430996 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 430998 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-22presencestate: Allow channel drivers to provide presence state informationMatthew Jordan
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
2014-12-08Stasis: Fix StasisStart/End order and missing eventsKinsey Moore
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
2014-09-05main/cdrs: Preserve context/extension when executing a Macro or GoSubMatthew Jordan
The context/extension in a CDR is generally considered the destination of a call. When looking at a 2-party call CDR, users will typically be presented with the following: context exten channel dest_channel app data default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20 However, if the Dial actually takes place in a Macro, the current behaviour in 12 will result in the following CDR: context exten channel dest_channel app data macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20 The same is true of a GoSub: context exten channel dest_channel app data subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20 This generally makes the context/exten fields less than useful. It isn't hard to preserve these values in the CDR state machine; however, we need to have something that informs us when a channel is executing a subroutine. Prior to this patch, there isn't anything that does this. This patch solves this problem by adding a new channel flag, AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a Macro or a GoSub. The CDR engine looks for this value when updating a Party A snapshot; if the flag is present, we don't override the context/exten on the main CDR object. In a funny quirk, executing a hangup handler must *not* abide by this logic, as the endbeforehexten logic assumes that the user wants to see data that occurs in hangup logic, which includes those subroutines. Since those execute outside of a typical Dial operation (and will typically have their own dedicated CDR anyway), this is unlikely to cause any heartburn. Review: https://reviewboard.asterisk.org/r/3962/ ASTERISK-24254 #close Reported by: tm1000, Tony Lewis Tested by: Tony Lewis ........ Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 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-24accountcode: Slightly change accountcode propagation.Richard Mudgett
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
2014-07-22ARI: Fix endpoint/channel subscription issues; allow for subscriptions to techMatthew Jordan
This patch serves two purposes: (1) It fixes some bugs with endpoint subscriptions not reporting all of the channel events (2) It serves as the preliminary work needed for ASTERISK-23692, which allows for sending/receiving arbitrary out of call text messages through ARI in a technology agnostic fashion. The messaging functionality described on ASTERISK-23692 requires two things: (1) The ability to send/receive messages associated with an endpoint. This is relatively straight forwards with the endpoint core in Asterisk now. (2) The ability to send/receive messages associated with a technology and an arbitrary technology defined URI. This is less straight forward, as endpoints are formed from a tech + resource pair. We don't have a mechanism to note that a technology that *may* have endpoints exists. This patch provides such a mechanism, and fixes a few bugs along the way. The first major bug this patch fixes is the forwarding of channel messages to their respective endpoints. Prior to this patch, there were two problems: (1) Channel caching messages weren't forwarded. Thus, the endpoints missed most of the interesting bits (such as channel creation, destruction, state changes, etc.) (2) Channels weren't associated with their endpoint until after creation. This resulted in endpoints missing the channel creation message, which limited the usefulness of the subscription in the first place (a major use case being 'tell me when this endpoint has a channel'). Unfortunately, this meant another parameter to ast_channel_alloc. Since not all channel technologies support an ast_endpoint, this patch makes such a call optional and opts for a new function, ast_channel_alloc_with_endpoint. When endpoints are created, they will implicitly create a technology endpoint for their technology (if one does not already exist). A technology endpoint is special in that it has no state, cannot have channels created for it, cannot be created explicitly, and cannot be destroyed except on shutdown. It does, however, have all messages from other endpoints in its technology forwarded to it. Combined with the bug fixes, we now have Stasis messages being properly forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar), where bar has a single channel associated with it and foo has two channels associated with it. The messages would be forwarded as follows: channel PJSIP/foo-1 -- \ --> endpoint PJSIP/foo -- / \ channel PJSIP/foo-2 -- \ ---- > endpoint PJSIP / channel PJSIP/bar-1 -----> endpoint PJSIP/bar -- ARI, through the applications resource, can: - subscribe to endpoint:PJSIP/foo and get notifications for channels PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo - subscribe to endpoint:PJSIP/bar and get notifications for channels PJSIP/bar-1 and endpoint PJSIP/bar - subscribe to endpoint:PJSIP and get notifications for channels PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar Note that since endpoint PJSIP never changes, it never has events itself. It merely provides an aggregation point for all other endpoints in its technology (which in turn aggregate all channel messages associated with that endpoint). This patch also adds endpoints to res_xmpp and chan_motif, because the actual messaging work will need it (messaging without XMPP is just sad). Review: https://reviewboard.asterisk.org/r/3760/ ASTERISK-23692 ........ Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3