summaryrefslogtreecommitdiff
path: root/main
AgeCommit message (Collapse)Author
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
2015-01-22Bridge core: Pass a ref with the swap channel when joining a bridge.Richard Mudgett
When code imparts a channel into a bridge to swap with another channel, a ref needs to be held on the swap channel to ensure that it cannot dissapear before finding it in the bridge. * The ast_bridge_join() swap channel parameter now always steals a ref for the swap channel. This is the only change to the bridge framework's public API semantics. * bridge_channel_internal_join() now requires the bridge_channel->swap channel to pass in a ref. ASTERISK-24649 Reported by: John Bigelow Review: https://reviewboard.asterisk.org/r/4354/ ........ Merged revisions 430975 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-21main/rtp_engine: Format NTP timestamps as unsigned longsMatthew Jordan
When the RTCP reports are created, the NTP timestamps are stored as strings, as JSON does not have an integer type long enough to store the value. However, on 32-bit systems, a signed long may overflow for some portion of the timestamp. This patch corrects the overflow by formatting the timestamps as unsigned longs. ........ Merged revisions 430840 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-19Call extension state callbacks at hint creation.Mark Michelson
When a hint gets created, any subsequent device or presence state changes result in extension status events getting sent out to interested parties. However, at the time of hint creation, no such event gets sent out, so watchers of extension state are potentially left in the dark until the first state change after hint creation. Patch contributed by John Hardin (License #6512) ........ Merged revisions 430776 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-17REVERTING res_pjsip: make it unloadableKevin Harwell
Due to the original patch causing memory corruptions the patch is being removed until the problem can be resolved. ........ Merged revisions 430734 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-14res_pjsip: make it unloadableKevin Harwell
The res_pjsip module was previously unloadable. With this patch it can now be unloaded. This patch is based off the original patch on the issue (listed below) by Corey Farrell with a few modifications. Namely, removed a few changes not required to make the module unloadable and also fixed a bug that would cause asterisk to crash on unloading. This patch is the first step (should hopefully be followed by another/others at some point) in allowing res_pjsip and the modules that depend on it to be unloadable. At this time, res_pjsip and some of the modules that depend on res_pjsip cannot be unloaded without causing problems of some sort. The goal of this patch is to get res_pjsip and only res_pjsip to be able to unload successfully and/or shutdown without incident (crashes, leaks, etc...). Other dependent modules may still cause problems on unload. Basically made sure, with the patch applied, that res_pjsip (with no other dependent modules loaded) could be succesfully unloaded and Asterisk could shutdown without any leaks or crashes that pertained directly to res_pjsip. ASTERISK-24485 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4311/ patches: pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909) ........ Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-12AMI: Revert non-backwards compatible changes from earlier commit.Richard Mudgett
* Reverted the change to astman_send_listack() to not use the listflag parameter and always set the value to "Start" so the start capitalization is consistent. Unfortunately changing the case of a returned value is not a backward compatible change so for now FAXSessions is going to have to remain inconsistent with all of the other AMI list actions. * Reverted the minor protocol error fix in action_getconfig() when no requested categories are found. Each line needs to be formatted as "Header: text". Caught by the testsuite. ASTERISK-24049 ........ Merged revisions 430528 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-12Revert -r430452 It needs to be redone for the next major AMI version change ↵Richard Mudgett
instead. ASTERISK-24049 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-12main/syslog: Allow dynamic logs, such as security events, to log to the syslogMatthew Jordan
The security event log uses a dynamic log level (SECURITY) that is registered with the Asterisk logging core. Unfortunately, the syslog would ignore log statements that had a dynamic log level associated with them. Because the syslog cannot handle ad hoc dynamic log levels, this patch treats any dynamic log entries sent to the syslog as logs with a level of NOTICE. ASTERISK-20744 #close Reported by: Michael Keuter Tested by: Michael L. Young, Jacek Konieczny patches: asterisk-20744-syslog-dynamic-logging_trunk.diff uploaded by Michael L. Young (license 5026) ........ Merged revisions 430506 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 430507 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-09app_bridge: return to the next dialplan priorityScott Griepentrog
When app_bridge grabs a channel and puts it into a bridge, the channel should then continue where it left off in the dialplan after the bridge has ended. Although it stores the current dialplan location as an after bridge goto on the channel, it was executing the same priority again instead of going to the next priority. By swapping the "specific" version of bridge_set_after_goto with bridge_set_after_go_on, the next priority in the dialplan is executed instead. ASTERISK-24637 #close Review: https://reviewboard.asterisk.org/r/4322/ Reported by: John Bigelow ........ Merged revisions 430467 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-09AMI: Remove no longer used parameter from astman_send_listack().Richard Mudgett
Follow-up issue to -r430435 from reviewboard review. ASTERISK-24049 Review: https://reviewboard.asterisk.org/r/4315/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-09AMI: Make AMI actions that generate event lists consistent.Richard Mudgett
* Made the following AMI actions use list API calls for consistency: Agents BridgeInfo BridgeList BridgeTechnologyList ConfbridgeLIst ConfbridgeLIstRooms CoreShowChannels DAHDIShowChannels DBGet DeviceStateList ExtensionStateList FAXSessions Hangup IAXpeerlist IAXpeers IAXregistry MeetmeList MeetmeListRooms MWIGet ParkedCalls Parkinglots PJSIPShowEndpoint PJSIPShowEndpoints PJSIPShowRegistrationsInbound PJSIPShowRegistrationsOutbound PJSIPShowResourceLists PJSIPShowSubscriptionsInbound PJSIPShowSubscriptionsOutbound PresenceStateList PRIShowSpans QueueStatus QueueSummary ShowDialPlan SIPpeers SIPpeerstatus SIPshowregistry SKINNYdevices SKINNYlines Status VoicemailUsersList * Incremented the AMI version to 2.7.0. * Changed astman_send_listack() to not use the listflag parameter and always set the value to "Start" so the start capitalization is consistent. i.e., The FAXSessions used "Start" while the rest of the system used "start". The corresponding complete event always used "Complete". * Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the AMI ActionID for all of its list events. * Fixed off-nominal AMI protocol error in manager_bridge_info(), manager_parking_status_single_lot(), and manager_parking_status_all_lots(). Use of astman_send_error() after responding to the original AMI action request violates the action response pattern by sending two responses. * Fixed minor protocol error in action_getconfig() when no requested categories are found. Each line needs to be formatted as "Header: text". * Fixed off-nominal memory leak in manager_build_parked_call_string(). * Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail(). ASTERISK-24049 #close Reported by: Jonathan Rose Review: https://reviewboard.asterisk.org/r/4315/ ........ Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-07config: Add option to NOT preserve effective context when changing a templateGeorge Joseph
Let's say you have a template T with variable VAR1 = ON and you have a context C(T) that doesn't specify VAR1. If you read C, the effective value of VAR1 is ON. Now you change T VAR1 to OFF and call ast_config_text_file_save. The current behavior is that the file gets re-written with T/VAR1=OFF but C/VAR1=ON is added. Personally, I think this is a bug. It's preserving the effective state of C even though I didn't specify C/VAR1 in th first place. I believe the behavior should be that if I didn't specify C/VAR1 originally, then the effective value of C/VAR1 should continue to follow the inherited state. Now, if I DID explicitly specify C/VAR1, the it should be preserved even if the template changes. Even though I think the existing behavior is a bug, it's been that way forever so I'm not changing it. Instead, I've created ast_config_text_file_save2() that takes a bitmask of flags, one of which is to preserve the effective context (the current behavior). The original ast_config_text_file_save calls *2 with the preserve flag. If you want the new behavior, call *2 directly without a flag. I've also updated Manager UpdateConfig with a new parameter 'PreserveEffectiveContext' whose default is 'yes'. If you want the new behavior with UpdateConfig, set 'PreserveEffectiveContext: no'. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4297/ ........ Merged revisions 430295 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-07Fix dev-mode build on recent gccKinsey Moore
........ Merged revisions 430274 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430275 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-01-05bridge: avoid leaking channel during blond transfer pt2Scott Griepentrog
A blond transfer to a failed destination, when followed by a recall attempt, lead to a leak of the reference to the destination channel. In addition to correcting the regression on the previous attempt (r429826) this fixes the leak and two additional reference leaks on failures of bridge_import. ASTERISK-24513 #close Review: https://reviewboard.asterisk.org/r/4302/ ........ Merged revisions 430199 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 430200 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-31rtp_engine: keep payload types in correct rangeScott Griepentrog
In r428708 additional codecs were added including a payload type of 128 which is outside of nominal range of 0-127. This change moves changes 128 to 96 to avoid causing a pjsip assertion when making a call to an endpoint configured with allow=all. ASTERISK-24367 #close Review: https://reviewboard.asterisk.org/r/4286/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-24main/pbx.c: Fix double lock of contexts lock introduced by r429967Matthew Jordan
We only need to hold the context_merge_lock once. Locking it twice will make many other parts of Asterisk very sad. ASTERISK-24641 #close git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-22DTMF atxfer: Setup recall channels as if the transferee initiated the call.Richard Mudgett
After the initial DTMF atxfer call attempt to the transfer target fails to answer during a blonde transfer, the recall callback channels do not get setup with information from the initial transferrer channel. As a result, the recall callback to the transferrer does not have callid, channel variables, datastores, accountcode, peeraccount, COLP, and CLID setup. A similar situation happens with the recall callback to the transfer target but it is less visible. The recall callback to the transfer target does not have callid, channel variables, datastores, accountcode, peeraccount, and COLP setup. * Added missing information to the recall callback channels before initiating the call. callid, channel variables, datastores, accountcode, peeraccount, COLP, and CLID * Set callid of the transferrer channel on the DTMF atxfer controller thread attended_transfer_monitor_thread(). * Added missing channel unlocks and props unref to off nominal paths in attended_transfer_properties_alloc(). ASTERISK-23841 #close Reported by: Richard Mudgett Review: https://reviewboard.asterisk.org/r/4259/ ........ Merged revisions 430034 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-22queue_log: Post QUEUESTART entry when Asterisk fully boots.Richard Mudgett
The QUEUESTART log entry has historically acted like a fully booted event for the queue_log file. When the QUEUESTART entry was posted to the log was broken by the change made by ASTERISK-15863. * Made post the QUEUESTART queue_log entry when Asterisk fully boots. This restores the intent of that log entry and happens after realtime has had a chance to load. AST-1444 #close Reported by: Denis Martinez Review: https://reviewboard.asterisk.org/r/4282/ ........ Merged revisions 430009 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 430010 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430011 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-20acl: Fix reloading of configuration if configuration file does not exist at ↵Joshua Colp
startup. The named ACL code incorrectly destroyed the config options information if loading of the configuration file failed at startup. This would result in reloading also failing even if a valid configuration file was put in place. ASTERISK-23733 #close Reported by: Richard Kenner ........ Merged revisions 429893 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 429894 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-19bridge: avoid leaking channel during blond transferScott Griepentrog
After a blond transfer (start attended and hang up) to a destination that also hangs up without answer, the Local;1 channel was leaked and would show up on core show channels. This was happening because the attended state blond_nonfinal_enter() resetting the props->transfer_target to null while releasing it's own reference, which would later prevent props from releasing another reference during destruction. The change made here is simply to not assign the target to NULL. ASTERISK-24513 #close Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/4262/ ........ Merged revisions 429826 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429827 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-18Prevent possible race condition on dual redirect of channels in the same bridge.Mark Michelson
The AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT flag was created to prevent bridges from prematurely acting on orphaned channels in bridges. The problem with the AMI redirect action was that it was setting this flag on channels based on the presence of a PBX, not whether the channel was in a bridge. Whether a channel has a PBX is irrelevant, so the condition has been altered to check if the channel is in a bridge. ASTERISK-24536 #close Reported by Niklas Larsson Review: https://reviewboard.asterisk.org/r/4268 ........ Merged revisions 429741 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-17Fix printf problems with high ascii characters after r413586 (1.8).Walter Doekes
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings. Those fixes included things like: -out += sprintf(out, "%%%02X", (unsigned char) *ptr); +out += sprintf(out, "%%%02X", (unsigned) *ptr); That works for low ascii characters, but for the high range that yields e.g. FFFFFFC3 when C3 is expected. This changeset: - fixes those casts to use the 'hh' unsigned char modifier instead - consistently uses %02x instead of %2.2x (or other non-standard usage) - adds a few 'h' modifiers in various places - fixes a 'replcaes' typo - dev/urandon typo (in 13+ patch) Review: https://reviewboard.asterisk.org/r/4263/ ASTERISK-24619 #close Reported by: Stefan27 (on IRC) ........ Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-12loader: Move definition of ast_module_reload from _private.h to module.hGeorge Joseph
No functionality change. Just move the definition of ast_module_reload from _private.h to module.h so it can be public. Also removed the include of _private.h from manager.c since ast_module_load was the only reason for including it. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4251/ ........ Merged revisions 429542 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-12DEBUG_THREADS: Fix regression and lock tracking initialization problems.Richard Mudgett
This patch started with David Lee's patch at https://reviewboard.asterisk.org/r/2826/ and includes a regression fix introduced by the ASTERISK-22455 patch. The initialization of a mutex's lock tracking structure was not protected in a critical section. This is fine for any mutex that is explicitly initialized, but a static mutex may have its lock tracking double initialized if multiple threads attempt the first lock simultaneously. * Added a global mutex to properly serialize initialization of the lock tracking structure. The painful global lock can be mitigated by adding a double checked lock flag as discussed on the original review request. * Defer lock tracking initialization until first use. * Don't be "helpful" and initialize an uninitialized lock when DEBUG_THREADS is enabled. Debug code is not supposed to fix or change normal code behavior. We don't need a lock initialization race that would force a re-setup of lock tracking. Lock tracking already handles initialization on first use. * Properly handle allocation failures of the lock tracking structure. * No need to initialize tracking data in __ast_pthread_mutex_destroy() just to turn around and destroy it. The regression introduced by ASTERISK-22455 is the result of manipulating a pthread_mutex_t struct outside of the pthread library code. The pthread_mutex_t struct seems to have a global linked list pointer member that can get changed by other threads. Therefore, saving and restoring the contents of a pthread_mutex_t struct is a bad thing. Thanks to Thomas Airmont for finding this obscure regression. * Don't overwrite the struct ast_lock_track.reentr_mutex member to restore tracking data in __ast_cond_wait() and __ast_cond_timedwait(). The pthread_mutex_t struct must be treated as a read-only opaque variable. Miscellaneous other items fixed by this patch: * Match ast_suspend_lock_info() with ast_restore_lock_info() in __ast_cond_timedwait(). * Made some uninitialized lock sanity checks return EINVAL and try a DO_THREAD_CRASH. * Fix bad canlog initialization expressions. ASTERISK-24614 #close Reported by: Thomas Airmont Review: https://reviewboard.asterisk.org/r/4247/ Review: https://reviewboard.asterisk.org/r/2826/ ........ Merged revisions 429539 from http://svn.asterisk.org/svn/asterisk/branches/11 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-12media: Fix crash when determining sample count of a frame during shutdown.Joshua Colp
When shutting down Asterisk the codecs are cleaned up. As a result anything attempting to get a codec based on ID or details will find that no codec exists. This currently occurs when determining the sample count of a frame. This code did not take this situation into account. This change fixes this by getting the codec directly from the format and eliminates the lookup. This is both faster and also provides a guarantee that the codec will exist and will be valid. ASTERISK-24604 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4260/ ........ Merged revisions 429497 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-09core: avoid possible asterisk -r crash from long idScott Griepentrog
When connecting to the remote console, an id string is first provided that consts of the hostname, pid, and version. This is parsed by the remote instance using a buffer that may be too short, and can allow a buffer overrun because it is not terminated. This patch adds termination and a larger buffer. Review: https://reviewboard.asterisk.org/r/4182/ ........ Merged revisions 429223 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-09ARI/AMI: Include language in standard channel snapshot outputKevin Harwell
The channel "language" was already part of a channel snapshot, however is was not sent out over AMI or ARI. This patch makes it so the channel "language" is included in the appropriate AMI or ARI events. ASTERISK-24553 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4245/ ........ Merged revisions 429204 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429206 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-09Direct Media calls within private network sometimes get one way audioKevin Harwell
When endpoints with direct_media enabled, behind a firewall (Asterisk on a separate network) and were bridged sometimes Asterisk would send the ip address of the firewall in the sdp to one of the phones in the reinvite resulting in one way audio. When sending the reinvite Asterisk will retrieve the media address from the associated rtp instance, but if frames were being read this can be overwritten with another address (in this case the firewall's). This patch ensures that Asterisk uses the original device address when using direct media. ASTERISK-24563 Reported by: Steve Pitts Review: https://reviewboard.asterisk.org/r/4216/ ........ Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-08Add new AMI and ARI events for connected line changes on a channel.Mark Michelson
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
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-12-05sorcery: Add additional observer capabilities.George Joseph
Add new global, instance and wizard observers. instance_created wizard_registered wizard_unregistered instance_destroying instance_loading instance_loaded wizard_mapped object_type_registered object_type_loading object_type_loaded wizard_loading wizard_loaded Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4215/ ........ Merged revisions 428999 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 429000 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-04main/test: Fix compilation issue on 32-bit systemsMatthew Jordan
On a 32-bit system, a type of intmax_t will result in a compilation warning when formatted as a 'long int'. Use the format specifier of %jd (which was what was used originally in manager.c) to format the JSON extracted integer on both 32-/64-bit systems. ........ Merged revisions 428972 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428973 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-04main/test: Fix race condition between AMI topic and Test Suite topicMatthew Jordan
This patch fixes a race condition between the raising of test AMI events (which drive many tests in the Asterisk Test Suite) and other AMI events. Prior to this patch, the Stasis messages published to the test topic were not forwarded to the AMI topic. Instead, the code in manager had a dedicated handler for test messages that was independent of the topics forwarded to the AMI topic. This results in no synchronization between the test messages and the rest of the Stasis messages published out over AMI. In some test with very tight timing constraints, this can result in out of order messages and spurious test failures. Properly forwarding the Test Suite topic to the AMI topic ensures that the messages are synchronized properly. This patch does that, and moves the message handling to the Stasis definition of the Test Suite message in test.c as well. Review: https://reviewboard.asterisk.org/r/4221/ ........ Merged revisions 428945 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428946 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-02config: Create ast_variable_find_in_list()George Joseph
Add const char *ast_variable_find_in_list(const struct ast_variable *list, const char *variable); ast_variable_find() requires a config category to search whereas ast_variable_find_in_list() just needs the root list element which is useful if you don't have a category. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4217/ ........ Merged revisions 428733 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428734 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01rtp_engine: Add support for transporting signed linear at 12kHz, 24kHz, ↵Joshua Colp
32kHz, 44kHz, 48kHz, 96kHz, and 192kHz over RTP. This change adds mappings in the RTP engine layer for the remaining signed linear formats. ASTERISK-24274 #close Reported by: Frankie Chin Review: https://reviewboard.asterisk.org/r/4093/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01main/stasis: Allow subscriptions to use a threadpool for message deliveryMatthew Jordan
Prior to this patch, all Stasis subscriptions would receive a dedicated thread for servicing published messages. In contrast, prior to r400178 (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions shared a thread pool. It was discovered during some initial work on Stasis that, for a low subscription count with high message throughput, the threadpool was not as performant as simply having a dedicated thread per subscriber. For situations where a subscriber receives a substantial number of messages and is always present, the model of having a dedicated thread per subscriber makes sense. While we still have plenty of subscriptions that would follow this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into the following two categories: * Large number of subscriptions, specifically those tied to endpoints/peers. * Low number of messages. Some subscriptions exist specifically to coordinate a single message - the subscription is created, a message is published, the delivery is synchronized, and the subscription is destroyed. In both of the latter two cases, creating a dedicated thread is wasteful (and in the case of a large number of peers/endpoints, harmful). In those cases, having shared delivery threads is far more performant. This patch adds the ability of a subscriber to Stasis to choose whether or not their messages are dispatched on a dedicated thread or on a threadpool. The threadpool is configurable through stasis.conf. Review: https://reviewboard.asterisk.org/r/4193 ASTERISK-24533 #close Reported by: xrobau Tested by: xrobau ........ Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01channel: Extend size of buffer for codecs in "core show channeltype" CLI ↵Joshua Colp
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
2014-11-24DTMF hooks: Leaving channels need to push any collected digits into the bridge.Richard Mudgett
Any partially collected DTMF digits for a DTMF hook need to be pushed into the bridge when a channel leaves the bridging system as if there were a timeout. Review: https://reviewboard.asterisk.org/r/4199/ ........ Merged revisions 428601 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428602 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21manager: Fix could not extend string messages.Richard Mudgett
When shutting down Asterisk that has an active AMI connection, you get several "failed to extend from %d to %d" messages because use of the EVENT_FLAG_SHUTDOWN attempts to add all AMI permission strings to the event. * Created MAX_AUTH_PERM_STRING to use when creating stack based struct ast_str variables used with the authority_to_str() and user_authority_to_str() functions instead of a variety of magic numbers that could be too small. * Added a special check for EVENT_FLAG_SHUTDOWN to authority_to_str() so it will not attempt to add all permission level strings. Review: https://reviewboard.asterisk.org/r/4200/ ........ Merged revisions 428570 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428571 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428572 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21sorcery: Make is_object_field_registered handle field names that are regexes.George Joseph
As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime was tossing database fields that didn't have an exact match to a sorcery registered field. This broke the ability to use regexes as field names which manifested itself as a failure of res_pjsip_phoneprov_provider which uses this capability. It also broke handling of fields that start with '@' in realtime but I don't think anyone noticed. This patch does the following... * Modifies ast_sorcery_fields_register to pre-compile the name regex. * Modifies ast_sorcery_is_object_field_registered to test the regex if it exists instead of doing an exact strcmp. * Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work with realtime. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4185/ ........ Merged revisions 428543 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428544 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21main/bridge_basic: Fix features regressions introduced by r428165Matthew Jordan
In r428165, two bugs were introduced: * Prior to entering the features retry loop, the buffer that holds the collected digits is wiped. However, this inadvertently wipes out the first collected digit on the first pass through, which is obtained in ast_stream_and_wait. This caused all of the features tests to fail. * If ast_app_dtget returns a hangup (-1), the loop would retry incorrectly. If we detect a hangup, we have to stop trying the feature. This patch fixes both issues. Review: https://reviewboard.asterisk.org/r/4196/ ........ Merged revisions 428505 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20Fix error with mixed address family ACLs.Mark Michelson
Prior to this commit, the address family of the first item in an ACL was used to compare all incoming traffic. This could lead to traffic of other IP address families bypassing ACLs. ASTERISK-24469 #close Reported by Matt Jordan Patches: ASTERISK-24469-11.diff uploaded by Matt Jordan (License #6283) AST-2014-012 ........ Merged revisions 428402 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 428417 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428422 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428425 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19ast_str: Fix improper member access to struct ast_str members.Richard Mudgett
Accessing members of struct ast_str outside of the string manipulation API routines is invalid since struct ast_str is supposed to be treated as opaque. Review: https://reviewboard.asterisk.org/r/4194/ ........ Merged revisions 428244 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428245 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428246 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-17Allow for transferer to retry when dialing an invalid extension.Mark Michelson
This allows for a configurable number of attempts for a transferer to dial an extension to transfer the call to. For Asterisk 13, the default values are such that upgrading between versions will not cause a behaivour change. For trunk, though, the defaults will be changed to be more user-friendly. Review: https://reviewboard.asterisk.org/r/4167 ........ Merged revisions 428145 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Documentation: Revise explanation of cdr.conf option 'Unanswered'Jonathan Rose
ASTERISK-24279 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4109/ ........ Merged revisions 427901 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427902 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14stun: correct attribute string padding to match rfcScott Griepentrog
When sending the USERNAME attribute in an RTP STUN response, the implementation in append_attr_string passed the actual length, instead of padding it up to a multiple of four bytes as required by the RFC 3489. This change adds separate variables for the string and padded attributed lengths, and performs padding correctly. Reported by: Thomas Arimont Review: https://reviewboard.asterisk.org/r/4139/ ........ Merged revisions 427874 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427875 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427876 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Fix race condition that could result in ARI transfer messages not being sent.Mark Michelson
From reviewboard: "During blind transfer testing, it was noticed that tests were failing occasionally because the ARI blind transfer event was not being sent. After investigating, I detected a race condition in the blind transfer code. When blind transferring a single channel, the actual transfer operation (i.e. removing the transferee from the bridge and directing them to the proper dialplan location) is queued onto the transferee bridge channel. After queuing the transfer operation, the blind transfer Stasis message is published. At the time of publication, snapshots of the channels and bridge involved are created. The ARI subscriber to the blind transfer Stasis message then attempts to determine if the bridge or any of the involved channels are subscribed to by ARI applications. If so, then the blind transfer message is sent to the applications. The way that the ARI blind transfer message handler works is to first see if the transferer channel is subscribed to. If not, then iterate over all the channel IDs in the bridge snapshot and determine if any of those are subscribed to. In the test we were running, the lone transferee channel was subscribed to, so an ARI event should have been sent to our application. Occasionally, though, the bridge snapshot did not have any channels IDs on it at all. Why? The problem is that since the blind transfer operation is handled by a separate thread, it is possible that the transfer will have completed and the channels removed from the bridge before we publish the blind transfer Stasis message. Since the blind transfer has completed, the bridge on which the transfer occurred no longer has any channels on it, so the resulting bridge snapshot has no channels on it. Through investigation of the code, I found that attended transfers can have this issue too for the case where a transferee is transferred to an application." The fix employed here is to decouple the creation of snapshots for the transfer messages from the publication of the transfer messages. This way, snapshots can be created to reflect what they are at the time of the transfer operation. Review: https://reviewboard.asterisk.org/r/4135 ........ Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-13main/rtp_engine: Fix crash when processing more than one RTCP report info blockMatthew Jordan
Asterisk - in res_rtp_asterisk - only understands a single RTCP report info block. When the RTCP information was refactored in the RTP Engine to be pushed over the Stasis message bus, I put in the hooks into the engine to handle multiple RTCP report info blocks, in the hope that a future RTP implementation would be able to provide that data. Unfortunately, res_rtp_asterisk has a tendency to "lie": (1) It will send RTCP reports with a reception_report_count greater than 1 (which is pulled directly from the RTCP packet itself, so that part is correct) (2) It will only provide a single report block When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it looks for a report block that doesn't exist. This patch updates the rtp_engine to be a bit more skeptical about what it is presented with. While this could also be fixed in res_rtp_asterisk, this patch prefers to fix it in the engine for two reasons: (1) The engine is designed to work with multiple RTP implementation, and hence having it be more robust is a good thing (tm) (2) res_rtp_asterisk's handling of RTCP information is "fun". It should report the correct reception_report_count; ideally it should also be giving us all of the blocks - but it is *definitely* not designed to do that. Going down that road is a non-trivial effort. Review: https://reviewboard.asterisk.org/r/4158/ ASTERISK-24489 #close Reported by: Gregory Malsack Tested by: Gregory Malsack ASTERISK-24498 #close Reported by: Beppo Mazzucato Tested by: Beppo Maazucato ........ Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-06 10:56:01 +0000