From: kharwell Date: Wed, 3 Feb 2016 22:14:42 +0000 (-0500) Subject: ChangeLog: Updated for certified/13.1-cert3 X-Git-Tag: certified/13.1-cert3 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9931aa6c6ff8554881f52d83108e9ffada85e184;p=thirdparty%2Fasterisk.git ChangeLog: Updated for certified/13.1-cert3 --- diff --git a/ChangeLog b/ChangeLog index af0dd05077..0eb801852d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4797 @@ +2016-02-03 22:14 +0000 Asterisk Development Team + + * asterisk certified/13.1-cert3 Released. + +2016-02-03 16:05 +0000 [2142c74a02] Kevin Harwell + + * .version: Update for certified/13.1-cert3 + +2016-02-03 16:04 +0000 [07c95d33bd] Kevin Harwell + + * .lastclean: Update for certified/13.1-cert3 + +2016-02-03 16:04 +0000 [ce314be09d] Kevin Harwell + + * realtime: Add database scripts for certified/13.1-cert3 + +2016-02-03 12:05 +0000 [b50d584022] Joshua Colp + + * AST-2016-001 http: Provide greater control of TLS and set modern defaults. + + This change exposes the configuration of various aspects of the TLS + support and sets the default to the modern standards. + + The TLS cipher is now set to the best values according to the + Mozilla OpSec team, different TLS versions can now be disabled, and + the cipher order can be forced to be that of the server instead of + the client. + + ASTERISK-24972 #close + + Change-Id: I8635470e722ce6d47951a5045ae9ef348271d395 +2015-12-07 12:46 +0000 [4fe2aa9a20] Richard Mudgett + + * AST-2016-003 udptl.c: Fix uninitialized values. + + Sending UDPTL packets to Asterisk with the right amount of missing + sequence numbers and enough redundant 0-length IFP packets, can make + Asterisk crash. + + ASTERISK-25603 #close + Reported by: Walter Doekes + + ASTERISK-25742 #close + Reported by: Torrey Searle + + Change-Id: I97df8375041be986f3f266ac1946a538023a5255 +2015-09-28 17:07 +0000 [c7ab026196] Richard Mudgett + + * AST-2016-002 chan_sip.c: Fix retransmission timeout integer overflow. + + Setting the sip.conf timert1 value to a value higher than 1245 can cause + an integer overflow and result in large retransmit timeout times. These + large timeout times hold system file descriptors hostage and can cause the + system to run out of file descriptors. + + NOTE: The default sip.conf timert1 value is 500 which does not expose the + vulnerability. + + * The overflow is now detected and the previous timeout time is + calculated. + + ASTERISK-25397 #close + Reported by: Alexander Traud + + Change-Id: Ia7231f2f415af1cbf90b923e001b9219cff46290 +2016-01-25 09:35 +0000 [7d581b32e9] Joshua Colp + + * config: Allow options to register when documentation is unavailable. + + The config options framework is strict in that configuration options must + be documented unless XML documentation support is not available. In + practice this is useful as it ensures documentation exists however in + off-nominal cases this can cause strange problems. + + If it is expected that a config option has a non-zero or non-empty + default value but the config option documentation is unavailable + this reasonable expectation will not be met. This can cause obscure + crashes and weirdness depending on how the code handles it. + + This change tweaks the behavior to ensure that the config option + is still allowed to register, apply default values, and be set when + devmode is not enabled. If devmode is enabled then the option can + NOT be set. + + This also does not remove the initial documentation error message that + is output on load when registering the configuration option. + + ASTERISK-25725 #close + + Change-Id: Iec42fca6b35f31326c33fcdc25473f6fd7bc8af8 + (cherry picked from commit f22074e5d9ed1882be976299311b8e093d25e1da) + +2016-01-25 16:51 +0000 [22eb1b48c0] Mark Michelson + + * res_pjsip_pubsub: Prevent crash from AMI command on freed subscription. + + A test recently uncovered that running an ill-timed AMI command to show + inbound subscriptions could cause a crash since Asterisk will try to + operate on a freed subscription. + + The fix for this is to remove the subscription tree from the list of + subscriptions at the time that we are sending our final NOTIFY request + out. This way, as the subscription is in the process of dying, it is + inaccessible from AMI. + + Change-Id: Ic0239003d8d73e04c47c12dd2a7e23867e5b5b23 + (cherry picked from commit b073244c511f9634de57ea401ab9dbebcf2390e8) + +2016-01-19 18:20 +0000 [826ff1d7a3] Richard Mudgett + + * res/res_pjsip/presence_xml.c: Add missing 2nd call presence state case. + + ASTERISK-25712 #close + Reported by: Richard Mudgett + + Change-Id: I70634df24f8c6c3a2c66c45af61d021e4999253f + +2016-01-14 14:42 +0000 [6e18a60a47] Kevin Harwell + + * bridge_basic: don't cache xferfailsound during an attended transfer + + The xferfailsound was read from the channel at the beginning of the transfer, + and that value is "cached" for the duration of the transfer. Therefore, changing + the xferfailsound on the channel using the FEATURE() dialplan function does + nothing once the transfer is under way. + + This makes it so the transfer code instead gets the xferfailsound configuration + options from the channel when it is actually going to be used. + + This patch also fixes a potential memory leak of the props object as well as + making sure the condition variable gets initialized before being destroyed. + + ASTERISK-25696 #close + + Change-Id: Ic726b0f54ef588bd9c9c67f4b0e4d787934f85e4 + +2015-12-28 14:02 +0000 [f63fb0e337] Joshua Colp + + * test_time: Provide a timeout when waiting. + + The test_timezone_watch unit test is written to expect a + condition to be signaled when the inotify daemon thread runs. + There exists a small window where the test_timezone_watch + thread can signal the inotify daemon thread while it is not + reading on the underlying file descriptor. If this occurs + the test_timezone_watch thread will wait indefinitely for a + signal that will never arrive. + + This change adds a timeout to the condition so it will return + regardless after a period of time. + + Change-Id: Ifed981879df6de3d93acd3ee0a70f92546517390 + (cherry picked from commit c8499b8d5adc805efadb91b483d9d987f62891ff) + +2016-01-12 11:14 +0000 [def98bb996] Joshua Colp + + * app: Queue hangup if channel is hung up during sub or macro execution. + + This issue was exposed when executing a connected line subroutine. + When connected or redirected subroutines or macros are executed it is + expected that the underlying applications and logic invoked are fast + and do not consume frames. In practice this constraint is not enforced + and if not adhered to will cause channels to continue when they shouldn't. + This is because each caller of the connected or redirected logic does not + check whether the channel has been hung up on return. As a result the + the hung up channel continues. + + This change makes it so when the API to execute a subroutine or + macro is invoked the channel is checked to determine if it has hung up. + If it has then a hangup is queued again so the caller will see it + and stop. + + ASTERISK-25690 #close + + Change-Id: I1f9a8ceb1487df0389f0d346ce0f6dcbcaf476ea + +2016-01-08 15:22 +0000 [bb29802615] Kevin Harwell + + * pbx: Deadlock between contexts container and context_merge locks + + Recent changes (ASTERISK-25394 commit 2bd27d12223fe33b58c453965ed5c6ed3af7c4f5) + introduced the possibility of a deadlock. Due to the mentioned modifications + ast_change_hints now needs to keep both merge/delete and state callbacks from + occurring while it executes. Unfortunately, sometimes ast_change_hints can be + called with the contexts container locked. When this happens it's possible for + another thread to grab the context_merge_lock before the thread calling into + ast_change_hints does and then try to obtain the contexts container lock. This + of course causes a deadlock between the two threads. The thread calling into + ast_change_hints waits for the other thread to release context_merge_lock and + the other thread is waiting on that one to release the contexts container lock. + + Unfortunately, there is not a great way to fix this problem. When hints change, + the subsequent state callbacks cannot run at the same time as a merge/delete, + nor when the usual state callbacks do. This patch alleviates the problem by + having those particular callbacks (the ones run after a hint change) occur in a + serialized task. By moving the context_merge_lock to a task it can now safely be + attempted or held without a deadlock occurring. + + ASTERISK-25640 #close + Reported by: Krzysztof Trempala + + Change-Id: If2210ea241afd1585dc2594c16faff84579bf302 + +2016-01-07 15:37 +0000 [ca869878b4] Mark Michelson + + * PJSIP: Prevent deadlock due to dialog/transaction lock inversion. + + A deadlock was observed where the monitor thread was stuck, therefore + resulting in no incoming SIP traffic being processed. + + The problem occurred when two 200 OK responses arrived in response to a + terminating NOTIFY request sent from Asterisk. The first 200 OK was + dispatched to a threadpool worker, who locked the corresponding + transaction. The second 200 OK arrived, resulting in the monitor thread + locking the dialog. At this point, the two threads are at odds, because + the monitor thread attempts to lock the transaction, and the threadpool + thread loops attempting to try to lock the dialog. + + In this case, the fix is to not have the monitor thread attempt to hold + both the dialog and transaction locks at the same time. Instead, we + release the dialog lock before attempting to lock the transaction. + + There have also been some debug messages added to the process in an + attempt to make it more clear what is going on in the process. + + ASTERISK-25668 #close + Reported by Mark Michelson + + Change-Id: I4db0705f1403737b4360e33a8e6276805d086d4a + +2015-12-10 11:44 +0000 [4e5aec3f0a] Jonathan Rose + + * chan_sip: Add TCP/TLS keepalive to TCP/TLS server + + Adds the TCP Keep Alive option to TCP and TLS server sockets. Previously + this option was only being set on session sockets. + http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/ + According to the link above, the SO_KEEPALIVE option is useful for knowing + when a TCP connected endpoint has severed communication without indicating + it or has become unreachable for some reason. Without this patch, keep + alive is not set on the socket listening for incoming TCP sessions and + in Komatsu's report this resulted in the thread listening for TCP becoming + stuck in a waiting state. + + ASTERISK-25364 #close + Reported by: Hiroaki Komatsu + + Change-Id: I7ed7bcfa982b367dc64b4b73fbd962da49b9af36 +2015-06-26 10:36 +0000 [4d10ed67d0] Richard Mudgett + + * PJSIP FAX: Fix T.38 automatic reject timer NULL channel pointer dereferences. + + When a caller calls a FAX number and then hangs up right after the call is + answered then the T.38 re-INVITE automatic reject timer may still be + running after the channel goes away. + + * Added session NULL channel checks on the code paths that get executed by + t38_automatic_reject() to prevent a crash when the T.38 re-INVITE + automatic reject timer expires. + + ASTERISK-25168 + Reported by: Carl Fortin + + Change-Id: I07b6cd23815aedce5044f8f32543779e2f7a2403 + (cherry picked from commit 8ea214aed782424a884b9a2f67d6dca270854e83) + +2015-12-01 16:11 +0000 [1ec791a3ba] Jonathan Rose + + * Unset BRIDGEPEER when leaving a bridge + + Currently if a channel is transferred out of a bridge, the BRIDGEPEER + variable (also BRIDGEPVTCALLID) remain set even once the channel is + out of the bridge. This patch removes these variables when leaving + the bridge. + + ASTERISK-25600 #close + Reported by: Mark Michelson + + Change-Id: I753ead2fffbfc65427ed4e9244c7066610e546da + +2015-11-30 16:42 +0000 [a164f2ce7f] Richard Mudgett + + * sched.c: Make not return a sched id of 0. + + According to the API doxygen a sched ID of 0 is valid. Unfortunately, 0 + was never returned historically and several users incorrectly coded usage + of the returned sched ID assuming that 0 was invalid. + + ASTERISK-25476 + + Change-Id: Ib19c7ebb44ec9fd393ef6646dea806d4f34e3a20 + +2015-11-25 12:23 +0000 [a24db35ae3] Richard Mudgett + + * Audit improper usage of scheduler exposed by 5c713fdf18f. (v13 additions) + + chan_sip.c: + * Initialize mwi subscription scheduler ids earlier because of ASTOBJ to + ao2 conversion. + + * Initialize register scheduler ids earlier because of ASTOBJ to ao2 + conversion. + + chan_skinny.c: + * Fix more scheduler usage for the valid 0 id value. + + ASTERISK-25476 + + Change-Id: If9f0e5d99638b2f9d102d1ebc9c5a14b2d706e95 + +2015-11-24 12:44 +0000 [bea904e001] Richard Mudgett + + * Audit improper usage of scheduler exposed by 5c713fdf18f. + + 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 + +2015-11-23 14:27 +0000 [f5a6060707] Richard Mudgett + + * res_sorcery_realtime.c: Fix crash from NULL sorcery object type. + + If the sorcery object type is not found a NULL is returned. + Unfortunately, sorcery_realtime_filter_objectset() will crash after + complaining about not finding the object type and saying to expect errors. + + * Use ao2_cleanup() instead of ao2_ref() to prevent the crash. + + ASTERISK-25165 + Reported by Corey Farrell + + Change-Id: Ic3b64453ea3058cb68d5c26d97d4fe7b8eea2e97 + +2015-05-05 18:17 +0000 [de43ae38b4] Richard Mudgett + + * features: Fix crash when transferee hangs up during DTMF attended transfer. + + A crash happens with this sequence of steps: + 1) Party A is connected to party B. + 2) Party B starts a DTMF attended transfer. + 3) Party A hangs up while party B is dialing party C. + + When party A hangs up the bridge that party A and party B are in is + dissolved and party B is kicked out of the bridge. When party B finishes + dialing party C he attempts to move to the new bridge with party C. Since + party B is no longer in a bridge the attempted move dereferences a NULL + bridge_channel pointer and crashes. + + * Made the hold(), unhold(), ringing(), and the bridge_move() functions + tolerant of the channel not being in a bridge. The assertion that party B + is always in a bridge is not true if the bridged peer of party B hangs up + and dissolves the bridge. Being tolerant of not being in a bridge allows + the peer hangup stimulus to be processed by the FSM. + + * Made the bridge_move() function return void since where the return value + for a failed move was checked generated a FSM coding ERROR message for a + normal off-nominal condition. + + * Eliminated most uses of RAII_VAR in bridge_basic.c. + + ASTERISK-25003 #close + Reported by: Artem Volodin + + Change-Id: Ie2c1b14e5e647d4ea6de300bf56d69805d7bcada + (cherry picked from commit be1260a35f88faea4fa029d59343b124d250a8a6) + +2015-11-16 04:29 +0000 [457d8dc124] Alec Davis + + * app_queue: (try_calling): mutex 'qe->chan' freed more times than we've locked! + + commit aae45acbd (Mark Michelson 2015-04-15 10:38:02 -0500 6525) + refer ASTERISK-24958 + + above commit removed ast_channel_lock(qe->chan); + but failed to remove corresponding ast_channel_unlock(qe->chan); + + ASTERISK-25561 #close + Reported Alec Davis + + Change-Id: Ie05f4e2d08912606178bf1fded57cc022c7a2e1a + +2015-11-13 14:03 +0000 [c4751171a0] Mark Michelson + + * Confbridge: Add a user timeout option + + This option adds the ability to specify a timeout, in seconds, for a + participant in a ConfBridge. When the user's timeout has been reached, + the user is ejected from the conference with the CONFBRIDGE_RESULT + channel variable set to "TIMEOUT". + + The rationale for this change is that there have been times where we + have seen channels get "stuck" in ConfBridge because a network issue + results in a SIP BYE not being received by Asterisk. While these + channels can be hung up manually via CLI/AMI/ARI, adding some sort of + automatic cleanup of the channels is a nice feature to have. + + ASTERISK-25549 #close + Reported by Mark Michelson + + Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98 + +2015-11-13 14:19 +0000 [c0a7df1021] Mark Michelson + + * Taskprocessors: Increase high-water mark + + In practical tests, we have seen certain taskprocessors, specifically + Stasis subscription taskprocessors, cross the recently-added high-water + mark and emit a warning. This high-water mark warning is only intended + to be emitted when things have tanked on the system and things are + heading south quickly. In the practical tests, the Stasis taskprocessors + sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in + any danger at all. + + As such, this ups the high-water mark to 500 tasks instead. It also + redefines the SIP threadpool request denial number to be a multiple of + the taskprocessor high-water mark. + + Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce + +2015-11-12 11:17 +0000 [2fc3267677] Mark Michelson + + * res_pjsip distributor: Don't send 503 response to responses. + + When the SIP threadpool is backed up with tasks, we send 503 responses + to ensure that we don't try to overload ourselves. The problem is that + we were not insuring that we were not trying to send a 503 to an + incoming SIP response. + + This change makes it so that we only send the 503 on incoming requests. + + Change-Id: Ie2b418d89c0e453cc6c2b5c7d543651c981e1404 + +2015-11-11 04:16 +0000 [d760c21038] Steve Davies + + * Further fixes to improper usage of scheduler + + When ASTERISK-25449 was closed, a number of scheduler issues mentioned in + the comments were missed. These have since beed raised in ASTERISK-25476 + and elsewhere. + + This patch attempts to collect all of the scheduler issues discovered so + far and address them sensibly. + + ASTERISK-25476 #close + + Change-Id: I87a77d581e2e0d91d33b4b2fbff80f64a566d05b + (cherry picked from commit 07583c288828a496cd7730b55112128fea31eaef) + +2015-11-11 17:11 +0000 [287cab1a53] Mark Michelson + + * res_pjsip: Deny requests when threadpool queue is backed up. + + We have observed situations where the SIP threadpool may become + deadlocked. However, because incoming traffic is still arriving, the SIP + threadpool's queue can continue to grow, eventually running the system + out of memory. + + This change makes it so that incoming traffic gets rejected with a 503 + response if the queue is backed up too much. + + Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816 + +2015-11-11 11:04 +0000 [d073cb4b6d] Joshua Colp + + * threadpool: Handle worker thread transitioning to dead when going active. + + This change adds handling of dead worker threads when moving them + to be active. When this happens the worker thread is removed from + both the active and idle threads container. If no threads are able + to be moved to active then the pool grows as configured. + + A unit test has also been added which thrashes the idle timeout + and thread activation to exploit any race conditions between the + two. + + ASTERISK-25546 #close + + Change-Id: I6c455f9a40de60d9e86458d447b548fb52ba1143 + +2015-11-03 16:19 +0000 [b9713354dc] Jonathan Rose + + * taskprocessor: Add high water mark warnings + + If a taskprocessor's queue grows large, this can indicate that there + may be a problem with tasks not leaving the processor or else that + the number of available task processors for a given type of task is + too low. This patch makes it so that if a taskprocessor's task queue + grows above 100 queued tasks that it will emit a warning message. + Warning messages are emitted only once per task processor. + + ASTERISK-25518 #close + Reported by: Jonathan Rose + + Change-Id: Ib1607c35d18c1d6a0575b3f0e3ff5d932fd6600c + +2015-06-23 11:21 +0000 [ac9432fdb6] Joshua Colp + + * app_dial: Hold reference to calling channel formats when dialing outbound. + + Currently when requesting a channel the native formats of the + calling channel are provided to the core for usage when dialing + the outbound channel. This occurs without holding the channel lock + or keeping a reference to the formats. This is problematic as + the channel driver may end up changing the formats during this time. + In the case of chan_sip this happens when an SDP negotiation + completes. + + This change makes it so app_dial keeps a reference to the native + formats of the calling channel which guarantees that they will + remain valid for the period of time needed. + + ASTERISK-25172 #close + + Change-Id: I2f0a67bd0d5d14c3bdbaae552b4b1613a283f0db + (cherry picked from commit 3b2b004d699b8cc7b808f62536bb2bc4db8b4e0e) + +2015-11-04 14:31 +0000 [385e26efe2] Matt Jordan + + * main/dial: Protect access to the format_cap structure of the requesting channel + + When a dial attempt is made that involves a requesting channel, we previously + were not: + a) Protecting access to the native format capabilities structure on the + requesting channel. That is inherently unsafe. + b) Reference bumping the lifetime of the format capabilities structure. + + In both cases, something else could sneak in, blow away the format + capabilities, and we'd be holding onto an invalid format_cap structure. When + the newly created channel attempts to construct its format capabilities, things + go poorly. + + This patch: + a) Ensures that we get a reference to the native format capabilities while + the requesting channel is locked + b) Holds a reference to the native format capabilities during the creation + of the new channel. + + ASTERISK-25522 #close + + Change-Id: I0bfb7ba8b9711f4158cbeaae96edf9626e88a54f + +2015-11-02 17:19 +0000 [62799fe778] Mark Michelson + + * res_pjsip: Set threadpool max size default to 50. + + During a stress test of subscriptions, a huge blast of + subscription-related traffic resulted in the threadpool expanding to a + ridiculous number of threads. The balooning of threads resulted in an + increase of memory, which led to a crash due to being out of memory. + + An easy fix for the particular test was to limit the size of the + threadpool, thus reining in the amount of memory that would be used. It + was decided that there really is no downside to having a non-infinite + default value for the maximum size of the threadpool, so this change + introduces 50 threads as the maximum threadpool size for the SIP + threadpool. + + ASTERISK-25513 #close + Reported by John Bigelow + + Change-Id: If0b9514f1d9b172540ce1a6e2f2ffa1f2b6119be + +2015-10-23 16:53 +0000 [6eda60936a] Kevin Harwell + + * alembic: Bad down revision in add_default_from_user script + + The down revision wasn't set correct in the add_default_from_user script. + This patch points it to the correct revision. + + Change-Id: Ied45786db265a1d4fb350ef0dd33b4d043c9a74d + +2015-10-21 12:35 +0000 [c425e26595] Kevin Harwell + + * res_pjsip_outbound_registration: registration stops due to fatal 4xx response + + During outbound registration it is possible to receive a fatal (any permanent/ + non-temporary 4xx, 5xx, 6xx) response from the registrar that is simply due + to a problem with the registrar itself. Upon receiving the failure response + Asterisk terminates outbound registration for the given endpoint. + + This patch adds an option, 'fatal_retry_interval', that when set continues + outbound registration at the given interval up to 'max_retries' upon receiving + a fatal response. + + ASTERISK-25485 #close + + Change-Id: Ibc2c7b47164ac89cc803433c0bbe7063bfa143a2 + +2015-10-22 17:07 +0000 [b95101aab0] Mark Michelson + + * format_cap: Detect vector allocation failures. + + A crash was seen on a system that ran out of memory due to Asterisk not + checking for vector allocation failures in format_cap.c. With this + change, if either of the AST_VECTOR_INIT calls fail, we will return a + value indicating failure. + + Change-Id: Ieb9c59f39dfde6d11797a92b45e0cf8ac5722bc8 + +2015-10-02 15:32 +0000 [dd4d4e40e5] Mark Michelson + + * res_pjsip_pubsub: Prevent sending NOTIFY on destroyed dialog. + + A certain situation can result in our attempting to send a NOTIFY on a + destroyed dialog. Say we attempt to send a NOTIFY to a subscriber, but + that subscriber has dropped off the network. We end up retransmitting + that NOTIFY until the appropriate SIP timer says to destroy the NOTIFY + transaction. When the pjsip evsub code is told that the transaction has + been terminated, it responds in kind by alerting us that the + subscription has been terminated, destroying the subscription, and then + removing its reference to the dialog, thus destroying the dialog. + + The problem is that when we get told that the subscription is being + terminated, we detect that we have not sent a terminating NOTIFY + request, so we queue up such a NOTIFY to be sent out. By the time that + queued NOTIFY gets sent, the dialog has been destroyed, so attempting to + send that NOTIFY can result in a crash. + + The fix being introduced here is actually a reintroduction of something + the pubsub code used to employ. We hold a reference to the dialog and + wait to decrement our reference to the dialog until our subscription + tree object is destroyed. This way, we can send messages on the dialog + even if the PJSIP evsub code wants to terminate earlier than we would + like. + + In doing this, some NULL checks for subscription tree dialogs have been + removed since NULL dialogs are no longer actually possible. + + Change-Id: I013f43cddd9408bb2a31b77f5db87a7972bfe1e5 + +2015-09-29 14:53 +0000 [bda0a24206] Mark Michelson + + * res_pjsip_pubsub: Ensure dialog lock balance. + + When sending a NOTIFY, we lock the dialog and then unlock the dialog + when finished. A recent change made it so that the subscription tree's + dialog pointer will be set NULL when sending the final NOTIFY request + out. This means that when we attempt to unlock the dialog, we pass a + NULL pointer to pjsip_dlg_dec_lock(). The result is that the dialog + remains locked after we think we have unlocked it. When a response to + the NOTIFY arrives, the monitor thread attempts to lock the dialog, but + it cannot because we never released the dialog lock. This results in + Asterisk being unable to process incoming SIP traffic any longer. + + The fix in this patch is to use a local pointer to save off the pointer + value of the subscription tree's dialog when locking and unlocking the + dialog. This way, if the subscription tree's dialog pointer is NULLed + out, the local pointer will still have point to the proper place and the + dialog lock will be unlocked as we expect. + + Change-Id: I7ddb3eaed7276cceb9a65daca701c3d5e728e63a + +2015-09-28 16:36 +0000 [7a22fc27fb] Mark Michelson + + * res_pjsip_pubsub: Prevent crashes on final NOTIFY. + + The SIP dialog is removed from the subscription tree when the final + NOTIFY is sent. However, after the final NOTIFY is sent, the persistence + update function still attempts to access the cseq from the dialog, + resulting in a crash. + + This fix removes the subscription persistence at the same time that the + dialog is removed from the subscription tree. This way, there is no + attempt to update persistence when the subscription is being destroyed. + + Change-Id: Ibb46977a6cef9c51dc95f40f43446e3d11eed5bb + +2015-09-17 17:28 +0000 [7fc9a998b1] Mark Michelson + + * res_pjsip_pubsub: Remove serializer when sending final NOTIFY. + + There have been crashes seen where a taskprocessor's listener is NULL + unexpectedly. + + Looking at backtraces, the problem was specifically seen in PJSIP + serializers. + + Subscriptions make the mistake of removing a serializer from a dialog + during subscription tree destruction. Since subscription trees are + reference-counted, guaranteeing the circumstances behind the destruction + are not possible. This makes it so that the dialog serializer can be + removed while not holding the dialog lock. This makes it possible for + the distributor to get a pointer to the dialog serializer and have that + serializer get freed out from under it. + + The fix for this is to remove the serializer from a subscription dialog + when sending the final NOTIFY. This guarantees that the serializer is + removed with the dialog lock held. By doing this, we guarantee that if + the distributor gains access to the dialog's serializer, it will not be + possible for the serializer to get freed by another thread. + + Change-Id: I21f5dac33529f65cec45679bdace60670800ff66 + +2015-09-02 09:14 +0000 [7a47ab77c1] Mark Michelson + + * res_pjsip_pubsub: Fix crash on destruction of empty subscription tree. + + If an old persistent subscription is recreated but then immediately + destroyed because it is out of date, the subscription tree will have no + leaf subscriptions on it. This was resulting in a crash when attempting + to destroy the subscription tree. + + A simple NULL check fixes this problem. + + Change-Id: I85570b9e2bcc7260a3fe0ad85904b2a9bf36d2ac + +2015-09-01 15:47 +0000 [8def38f6a2] Mark Michelson + + * res_pjsip_pubsub: Solidify lifetime and ownership of objects. + + There have been crashes and general instability seen in the pubsub code, + so this patch introduces three changes to increase the stability. + + First, the ownership model for subscriptions has been modified. Due to + RLS, subscriptions are stored in memory as a tree structure. Prior to my + patch, the PJSIP subscription was the owner of the subscription tree. + When the PJSIP subscription told us that it was terminating, we started + destroying the subscription tree along with all of the individual leaf + subscriptions that belong to the tree. The problem with this model is + that the two actors in play here, the PJSIP subscription and the + individual leaf subscriptions, need to have joint ownership of the + subscription tree. So now, the PJSIP subscription and the individual + leaf subscriptions each have a reference to the subscription tree. This + way, we will not actually free memory until no players are left that + care. The PJSIP subscription is a bigger stakeholder, in that if the + PJSIP subscription's reference to the subscription tree is removed, the + subscription tree instructs the leaf subscriptions to shut down and drop + their references to the subscription tree when possible. The individual + leaf subscriptions, upon being told to shut down, can drop their stasis + subscriptions or whatever they use to learn of new state, and then drop + their reference to the subscription tree once they are ready to die. + + Second, the lifetime of a PJSIP subscription's reference to our + subscription tree has been altered. As I learned from doing a deep dive, + the PJSIP evsub code can tell Asterisk multiple times that the + subscription has been terminated, and not all of these times + are especially helpful. I have altered the message flow that we use for + SIP subscriptions such that we will always drop the PJSIP subscription's + reference to the subscription tree when we send the NOTIFY that + terminates a SIP subscription. This also means that we will now queue + NOTIFY requests to be sent after responding to incoming SUBSCRIBEs so + that we can have predictable state changes from the PJSIP evsub code. + + Third, the synchronization of operations has been improved. PJSIP can + call into our code from a serializer thread (e.g. upon receiving an + incoming request) or from the monitor thread (e.g. when a subscription + times out). Because of this, there is the possibility of competing + threads stepping on each other. PJSIP attempts to do some + synchronization on its own by always keeping the dialog lock held when + it calls into us. However, since we end up pushing tasks into the + serializer, the result was that serialized operations were not grabbing + the dialog lock and could, as a result, step on something that was being + attempted by a different thread. Now we ensure that serialized + operations grab the dialog lock, then check for extenuating + circumstances, then proceed with their operation if they can. + + Change-Id: Iff2990c40178dad9cc5f6a5c7f76932ec644b2e5 + +2015-04-20 14:30 +0000 [16afb39aec] Mark Michelson + + * res_pjsip_pubsub: Set the endpoint on SUBSCRIBE dialogs. + + When SUBSCRIBE dialogs were established, we never associated + the endpoint that created the subscription with the dialog + we end up creating. In most cases, this ended up not causing + any problems. + + The actual bug that was observed was that when a device that + was behind NAT established a subscription with Asterisk, Asterisk + would end up sending in-dialog NOTIFY requests to the device's + private IP addres instead of the public address of the NAT router. + + When Asterisk receives the initial SUBSCRIBE from the device, + res_pjsip_nat rewrites the contact to the public address on which the + SUBSCRIBE was received. This allows for the dialog to have its target + address set to the proper public address. Asterisk then would send a 200 + OK response to the SUBSCRIBE, then a NOTIFY with the initial + subscription state. The device would then send a 200 OK response to + Asterisk's NOTIFY. + + Here's where things went wrong. When the 200 OK arrived, res_pjsip_nat + did not rewrite the address in the Contact header. Then, when the PJSIP + dialog layer processed the 200 OK, PJSIP would perform a comparison + between the IP address in the Contact header and its saved target + address for the dialog. Since they differed, PJSIP would update the + target dialog address to be the address in the Contact header. From this + point, if Asterisk needed to send a NOTIFY to the device, the result was + that the NOTIFY would be sent to the private address that the device + placed in the Contact header. + + The reason why res_pjsip_nat did not rewrite the address when it + received the 200 OK response was that it could not associate the + incoming response with a configured endpoint. This is because on a + response, the only way to associate the response to an endpoint is by + finding the dialog that the response is associated with and then finding + the endpoint that is associated with that dialog. We do not perform + endpoint lookups on responses. res_pjsip_pubsub skipped the step of + associating the endpoint with the dialog we created, so res_pjsip_nat + could not find the associated endpoint and therefore couldn't rewrite + the contact. + + This commit message is like 50x longer than the actual fix. + + ASTERISK 24981 #close + Reported by Mark Michelson + + Change-Id: I2b963c58c063bae293e038406f7d044a8a5377cd + +2015-10-19 15:27 +0000 [78e4783572] Richard Mudgett + + * Add missing failure checks to ast_str_set_va() callers. + + Change-Id: I0c2cdcd53727bdc6634095c61294807255bd278f + +2015-10-21 11:44 +0000 [43323995ba] Joshua Colp + + * res_pjsip: Move URI validation to use time. + + In a realtime based system with a limited number of threadpool threads + it is possible for a deadlock to occur. This happens when permanent + endpoint state is updated, which will cause database queries to be done. + These queries may result in URI validation being done which is done + synchronously using a PJSIP thread. If all PJSIP threads are in use + processing traffic they themselves may be blocked waiting to get the + permanent endpoint container lock when identifying an endpoint. + + This change moves URI validation to occur at use time instead of + configuration time. While this comes at a cost of not seeing a problem + until you use it it does solve the underlying deadlock problem. + + ASTERISK-25486 #close + + Change-Id: I2d7d167af987d23b3e8199e4a68f3359eba4c76a + +2015-03-26 17:19 +0000 [cdd2d5b484] Corey Farrell + + * 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 + + Change-Id: I6a67336050dea74327d79cdd6f7c7ea34d0b473e + git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433497 + +2015-10-19 19:59 +0000 [b5cfcfc427] Matt Jordan + + * contrib/scripts/autosupport: Update for Asterisk 13 + + This patch adds some minor tweaks for autosupport to update it for Asterisk 13. + This includes: + * Finally removing most references to Zaptel + * Adding support for some additional 'core' commands, and fixing nomenclature + that generally hasn't been used for some time + * Adding some PJSIP/SIP commands to gather endpoints/peers and active channels + + Change-Id: Ic997b418cbd9313588b6608e50f47b0ce6f4f1f1 + (cherry picked from commit 9fc9777fa34753fb38991d42d8dbed516e907ca2) + +2015-06-05 15:37 +0000 [813b743baa] Richard Mudgett + + * res_pjsip: Need to use the same serializer for a pjproject SIP transaction. + + All send/receive processing for a SIP transaction needs to be done under + the same threadpool serializer to prevent reentrancy problems inside + pjproject and res_pjsip. + + * Add threadpool API call to get the current serializer associated with + the worker thread. + + * Pick a serializer from a pool of default serializers if the caller of + res_pjsip.c:ast_sip_push_task() does not provide one. + + This is a simple way to ensure that all outgoing SIP request messages are + processed under a serializer. Otherwise, any place where a pushed task is + done that would result in an outgoing out-of-dialog request would need to + be modified to supply a serializer. Serializers from the default + serializer pool are picked in a round robin sequence for simplicity. + + A side effect is that the default serializer pool will limit the growth of + the thread pool from random tasks. This is not necessarily a bad thing. + + * Made pjsip_distributor.c save the thread's serializer name on the + outgoing request tdata struct so the response can be processed under the + same serializer. + + This is a cherry-pick from master. + + **** ASTERISK-25115 Change-Id: Iea71c16ce1132017b5791635e198b8c27973f40a + + NOTE: session_inv_on_state_changed() is disassociating the dialog from the + session when the invite dialog becomes PJSIP_INV_STATE_DISCONNECTED. + Unfortunately this is a tad too soon because our BYE request transaction + has not completed yet. + + This is a cherry-pick from v13. + + ASTERISK-25183 #close + Reported by: Matt Jordan + + Change-Id: I8bad0ae1daf18d75b8c9e55874244b7962df2d0a + +2015-10-02 17:05 +0000 [78ab76b46c] Richard Mudgett + + * Fix issue with AST_THREADSTORAGE_RAW when DEBUG_THREADLOCALS is enabled. + + When DEBUG_THREADLOCALS is enabled it causes the threadlocal cleanup to be + called as a function. This causes a compile error with raw threadstorage as + it uses NULL for cleanup. This fix uses a macro that provides NULL when + DEBUG_THREADLOCALS is disabled, and replaces the call to "c_cleanup(data);" + with "{};" when DEBUG_THREADLOCALS is enabled. + + ASTERISK-24975 #close + Reported by: Ashley Sanders + + **** ASTERISK-24975 Change-Id: I3ef7428ee402816d9fcefa1b3b95830c00d5c402 + + Cherry-pick from v13 with additional definitions of + AST_THREADSTORAGE_RAW(), ast_threadstorage_get_ptr() and + ast_threadstorage_set_ptr() from + commit d01706ce1ee518118456d5673f529204bdac73bb. + + Change-Id: I3222102d005f76744561b95a3b97700d82a5ee58 + +2015-10-12 11:21 +0000 [47a9452780] Richard Mudgett + + * config.c: Fix off-nominal memory leak. + + Change-Id: I06e346e9a5c63cc5071e7eda537310c4b43bffe0 + +2015-10-12 11:20 +0000 [728a2b7013] Richard Mudgett + + * config.c: Fix potential memory corruption after [section](+). + + The memory corruption could happen if the [section](+) is the last section + in the file with trailing comments. In this case process_text_line() has + left *last_cat is set to newcat and newcat is destroyed. + + Change-Id: I0d1d999f553986f591becd000e7cc6ddfb978d93 + +2015-10-12 11:21 +0000 [6c11fa2277] Richard Mudgett + + * config.c: Fix #include after [section](+). + + An #include right after a [section](+) would associate any variable + assignments before a new section in the #include with the wrong section. + + * Fix section association by setting the current section to the appended + section. + + * Fix '+' and '!' section flag interaction corner case depending upon + which flag came first. If the '!' came first then it would be ignored. + If the '!' came after then it would affect the appended section. The '!' + will now no longer be ignored. + + ASTERISK-25461 #close + Reported by: Sean Pimental + + Change-Id: Ic9d3191c8758048e2cbce6432f854b32531731c3 + +2015-10-06 20:43 +0000 [0fe83cad51] Matt Jordan + + * res/res_rtp_asterisk: Fix assignment after ao2 decrement + + When we decide we will no longer schedule an RTCP write, we remove the + reference to the RTP instance, then assign -1 to the stored scheduler ID + in case something else comes along and wants to see if anything is scheduled. + + That scheduler ID is on the RTP instance. After 60a9172d7ef2 was merged to + fix the regression introduced by 3cf0f29310, this improper assignment on a + potentially destroyed object started getting tripped on the build agents. + + Frankly, this should have been crashing a lot more often earlier. I can only + assume that the timing was changed just enough by both changes to start + actually hitting this problem. + + As it is, simply moving the assignment prior to the ao2 deference is sufficient + to keep the RTP instance from being referenced when it is very, truly, + aboslutely dead. + + (Note that it is still good practice to assign -1 to the scheduler ID when we + know we won't be scheduling it again, as the ao2 deref *may* not always destroy + the ao2 object.) + + ASTERISK-25449 + + Change-Id: Ie6d3cb4adc7b1a6c078b1c38c19fc84cf787cda7 + +2015-10-05 16:53 +0000 [c4f63952fc] Richard Mudgett + + * chan_pjsip: Fix crash on reINVITE before initial INVITE completes. + + Apparently some endpoints attempt to send a reINVITE before completing the + initial INVITE transaction. In this case PJSIP responds appropriately to + the reINVITE with a 491 INVITE request pending. Unfortunately chan_pjsip + is using the initial INVITE transaction state to determine if an INVITE is + the initial INVITE or a reINVITE. Since the initial INVITE transaction + has not been confirmed yet chan_pjsip thinks the reINVITE is an initial + INVITE and starts another PBX thread on the channel. The extra PBX thread + ensures that hilarity ensues. + + * Fix checks for a reINVITE on incoming requests to look for the presence + of a to-tag instead of the initial INVITE transaction state. + + * Made caller_id_incoming_request() determine what to do if there is a + channel on the session or not. After a channel is created it is too late + to just store the new party id on the session because the session's party + id has already been copied to the channel's caller id. + + ASTERISK-25404 #close + Reported by: Chet Stevens + + Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be + +2015-10-05 21:34 +0000 [d61da57428] Matt Jordan + + * Fix improper usage of scheduler exposed by 5c713fdf18f + + When 5c713fdf18f was merged, it allowed for scheduled items to have an ID of + '0' returned. While this was valid per the documentation for the API, it was + apparently never returned previously. As a result, several users of the + scheduler API viewed the result as being invalid, causing them to reschedule + already scheduled items or otherwise fail in interesting ways. + + This patch corrects the users such that they view '0' as valid, and a returned + ID of -1 as being invalid. + + Note that the failing HEP RTCP tests now pass with this patch. These tests + failed due to a duplicate scheduling of the RTCP transmissions. + + ASTERISK-25449 #close + + Change-Id: I019a9aa8b6997584f66876331675981ac9e07e39 +2015-09-30 17:28 +0000 [5d12653d2a] Richard Mudgett + + * res_sorcery_memory_cache.c: Fix deadlock with scheduler. + + A deadlock can happen when a sorcery object is being expired from the + memory cache when at the same time another object is being placed into the + memory cache. There are a couple other variations on this theme that + could cause the deadlock. Basically if an object is being expired from + the sorcery memory cache at the same time as another thread tries to + update the next object expiration timer the deadlock can happen. + + * Add a deadlock avoidance loop in expire_objects_from_cache() to check if + someone is trying to remove the scheduler callback from the scheduler. + + ASTERISK-25441 #close + + Change-Id: Iec7b0bdb81a72b39477727b1535b2539ad0cf4dc + +2015-10-01 14:30 +0000 [b35b9a9e32] Richard Mudgett + + * res_sorcery_memory_cache.c: Replace inline code with function. + + Make sorcery_memory_cache_close() call remove_all_from_cache() instead of + partially inlining it. + + ASTERISK-25441 + + Change-Id: I1aa6cb425b1a4307096f3f914d17af8ec179a74c + +2015-10-01 14:27 +0000 [9ec52447bd] Richard Mudgett + + * res_sorcery_memory_cache.c: Shutdown in a less crash potential order. + + Basically you should shutdown in the opposite order of how you setup since + later setup pieces likely depend on earlier setup pieces. e.g., + Registering your external API with the rest of the system should be the + last thing setup and the first thing unregistered during shutdown. + + Change-Id: I5715765b723100c8d3c2642e9e72cc7ad5ad115e + +2015-09-30 17:27 +0000 [110927bacc] Richard Mudgett + + * res_sorcery_memory_cache.c: Misc tweaks. + + Change-Id: I8cd32dffbb4f33bb0c39518d6e4c991e73573160 + +2015-09-30 17:27 +0000 [14ac763ab3] Richard Mudgett + + * res_sorcery_memory_cache.c: Made use OBJ_SEARCH_MASK. + + Change-Id: Ibca6574dc3c213b29cc93486e01ccd51f5caa46c + +2015-04-09 10:42 +0000 [39fe210fd9] yaron nahum (License 6676) + + * res/res_pjsip_dlg_options: Add a module to handle in-dialog OPTIONS requests + + This patch adds a new session supplement that handles in-dialog OPTIONS + requests. Said OPTIONS requests are sent a 200 OK, as an endpoint lookup + for the OPTIONS request would already have been done by the time the + session supplement receives the inbound request. + + ASTERISK-24862 #close + Reported by: yaron nahum + patches: + res_pjsip_dlg_options.c submitted by yaron nahum (License 6676) + + Change-Id: Iefc901a7c5c88d9d4b853188f85092d9eb7b6ada + +2015-09-24 14:56 +0000 [00be2f6b4f] Richard Mudgett + + * app_queue.c: Force COLP update if outgoing channel name changed. + + * When a call is answered and the outgoing channel name has changed then + force a connected line update because the channel is no longer the same. + The channel was masqueraded into by another channel. This is usually + because of a call pickup. + + Note: Forwarded calls are handled in a controlled manner so the original + channel name is replaced with the forwarded channel. + + ASTERISK-25423 #close + Reported by: John Hardin + + Change-Id: Ie275ea9e99c092ad369db23e0feb08c44498c172 + +2015-09-24 14:20 +0000 [bd43638622] Richard Mudgett + + * app_queue.c: Factor out a connected line update routine. + + Replace inlined code with update_connected_line_from_peer(). + + ASTERISK-25423 + Reported by: John Hardin + + Change-Id: I33bbd033596fcb0208d41d8970369b4e87b806f3 + +2015-09-24 13:27 +0000 [f5a935f9d1] Richard Mudgett + + * app_dial.c: Make 'A' option pass COLP updates. + + While the 'A' option is playing the announcement file allow the caller and + peer to exchange COLP update frames. + + ASTERISK-25423 + Reported by: John Hardin + + Change-Id: Iac6cf89b56d26452c6bb88e9363622bbf23895f9 + +2015-09-24 12:59 +0000 [91f754cb89] Richard Mudgett + + * app_dial.c: Force COLP update if outgoing channel name changed. + + * When a call is answered and the outgoing channel name has changed then + force a connected line update because the channel is no longer the same. + The channel was masqueraded into by another channel. This is usually + because of a call pickup. + + Note: Forwarded calls are handled in a controlled manner so the original + channel name is replaced with the forwarded channel. + + ASTERISK-25423 + Reported by: John Hardin + + Change-Id: I2e01f7a698fbbc8c26344a59c2be40c6cd98b00c + +2015-09-24 12:37 +0000 [9792b21720] Richard Mudgett + + * app_dial.c: Factor out a connected line update routine. + + Replace inlined code with update_connected_line_from_peer(). + + ASTERISK-25423 + Reported by: John Hardin + + Change-Id: Ia14f18def417645cd7fb453e1bdac682630a5091 + +2015-09-24 14:49 +0000 [7a4581a41b] Mark Michelson + + * 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 + +2015-09-22 17:08 +0000 [86eee104be] Richard Mudgett + + * app_page.c: Fix crash when forwarding with a predial handler. + + Page uses the async method of dialing with the dial API. When a call gets + forwarded there is no calling channel available. If the predial handler + was set then the calling channel could not be put into auto-service + for the forwarded call because it doesn't exist. A crash is the result. + + * Moved the callee predial parameter string processing to before the + string is passed to the dial API rather than having the dial API do it. + There are a few benefits do doing this. The first is the predial + parameter string processing doesn't need to be done for each channel + called by the dial API. The second is in async mode and the forwarded + channel is to have the predial handler executed on it then the + non-existent calling channel does not need to be present to process the + predial parameter string. + + * Don't start auto-service on a non-existent calling channel to execute + the predial handler when the dial API is in async mode and forwarding a + call. + + ASTERISK-25384 #close + Reported by: Chet Stevens + + Change-Id: If53892b286d29f6cf955e2545b03dcffa2610981 + +2015-06-18 13:16 +0000 [deccd2ef3c] Mark Michelson + + * Resolve race conditions involving Stasis bridges. + + This resolves two observed race conditions. + + First, a bit of background on what the Stasis application does: + + 1a Creates a stasis_app_control structure. This structure is linked into + a global container and can be looked up using a channel's unique ID. + 2a Puts the channel in an event loop. The event loop can exit either + because the stasis_app_control structure has been marked done, or + because of some other factor, such as a hangup. In the event loop, the + stasis_app_control determines if any specific ARI commands need to be + run on the channel and will run them from this thread. + 3a Checks if the channel is bridged. If the channel is bridged, then + ast_bridge_depart() is called since channels that are added to Stasis + bridges are always imparted as departable. + 4a Unlink the stasis_app_control from the container. + + When an ARI command is received by Asterisk, the following occurs + 1b A thread is spawned to handle the HTTP request + 2b The stasis_app_control(s) that corresponds to the channel(s) in the + request is/are retrieved. If the stasis_app_control cannot be + retrieved, then it is assumed that the channel in question has exited + the Stasis app or perhaps was never in Stasis in the first place. + 3b A command is queued onto the stasis_app_control, and the channel's + event loop thread is signaled to run the command. + 4b While most ARI commands do nothing further, some, such as adding or + removing channels from a bridge, will block until the command they + issued has been completed by the channel's event loop. + + The first race condition that is solved by this patch involves a crash + that can occur due to faulty detection of the channel's bridged status + in step 3a. What can happen is that in step 2a, the event loop may run + the ast_bridge_impart() function to asynchronously place the channel + into a bridge, then immediately exit the event loop because the channel + has hung up. In step 3a, we would detect that the channel was not + bridged and would not call ast_bridge_depart(). The reason that the + channel did not appear to be bridged was that the depart_thread that is + spawned by ast_bridge_impart() had not yet started. That is the thread + where the channel is marked as being bridged. Since we did not call + ast_bridge_depart(), the Stasis application would exit, and then the + channel would be destroyed Then the depart_thread would start up and + try to manipulate the destroyed channel, causing a crash. + + The fix for this is to switch from using ast_channel_is_bridged() to + checking the NULLity of ast_channel_internal_bridge_channel() to + determine if ast_bridge_depart() needs to be called. The channel's + internal bridge_channel is set when ast_bridge_impart() is called and + is NULLed by the call to ast_bridge_depart(). If the channel's internal + bridge_channel is non-NULL, then the channel must have been imparted + into the bridge and needs to be departed, even if the actual bridging + operation has not yet started. By departing the channel when necessary, + the thread that is running the Stasis application will block until the + bridge gives the okay that the depart_thread has exited. + + The second race condition that is solved by this patch involves a leak + of HTTP handler threads. The problem was that step 2b would successfully + retrieve a stasis_app_control structure. Then step 2a would exit the + channel from the event loop due to a hangup. Steps 3a and 4a would + execute, and then finally steps 3b and 4b would. The problem is that at + step 4b, when attempting to add a channel to a bridge, the thread would + block forever since the channel would never execute the queued command + since it was finished with the event loop. This meant that the HTTP + handling thread would be leaked, along with any references that thread + may have owned (in my case, I was seeing bridges leaked). + + The fix for this is to hone in better on when the channel has exited the + event loop. The stasis_app_control structure has an is_done field that + is now set at each point where the channel may exit the event loop. If + step 2b retrieves a valid stasis_app_control structure but the control + is marked as done, then the attempted operation exits immediately since + there will be nothing to service the attempted command. + + ASTERISK-25091 #close + Reported by Ilya Trikoz + + Change-Id: If66265b73b4c9f8f58599124d777fedc54576628 + +2015-09-21 18:06 +0000 [43e6804b0c] Kevin Harwell + + * app_record: RECORDED_FILE variable not being populated + + The RECORDED_FILE variable is empty unless a '%d' is specified in the filename. + This patch makes it so the variable is always set to the filename. + + ASTERISK-25410 #close + + Change-Id: I4ec826d8eb582ae2ad184e717be8668b74d37653 + +2015-09-16 08:22 +0000 [ca401c6842] Joshua Colp + + * pbx: Update device and presence state when changing a hint extension. + + When changing a hint extension without removing the hint first the + device state and presence state is not updated. This causes the state + of the hint to be that of the previous extension and not the current + one. This state is kept until a state change occurs as a result of + something (presence state change, device state change). + + This change updates the hint with the current device and presence + state of the new extension when it is changed. Any state callbacks + which may have been added before the hint extension is changed are + also informed of the new device and presence state if either have + changed. + + ASTERISK-25394 #close + + Change-Id: If268f1110290e502c73dd289c9e7e7b27bc8432f + +2015-09-16 17:36 +0000 [20702e0cf2] Mark Michelson + + * res_pjsip_pubsub: Eliminate race during initial NOTIFY. + + There is a slim chance of a race condition occurring where two threads + can both attempt to manipulate the same area. + + Thread A can be handling an incoming initial SUBSCRIBE request. Thread A + lets the specific subscription handler know that the subscription has + been established. + + At this point, Thread B may detect a state change on the subscribed + resource and queue up a notification task on Thread C, the subscription + serializer thread. + + Now Thread A attempts to generate the initial NOTIFY request to send to + the subscriber at the same time that Thread C attempts to generate a + state change NOTIFY request to send to the subscriber. + + The result is that Threads A and C can step on the same memory area, + resulting in a crash. The crash has been observed as happening when + attempting to allocate more space to hold the body for the NOTIFY. + + The solution presented here is to queue the subscription establishment + and initial NOTIFY generation onto the subscription serializer thread + (Thread C in the above scenario). This way, there is no way that a state + change notification can occur before the initial NOTIFY is sent, and if + there is a quick succession of NOTIFYs, we can guarantee that the two + NOTIFY requests will be sent in succession. + + Change-Id: I5a89a77b5f2717928c54d6efb9955e5f6f5cf815 + +2015-09-10 17:19 +0000 [3ef74244a4] Mark Michelson + + * scheduler: Use queue for allocating sched IDs. + + It has been observed that on long-running busy systems, a scheduler + context can eventually hit INT_MAX for its assigned IDs and end up + overflowing into a very low negative number. When this occurs, this can + result in odd behaviors, because a negative return is interpreted by + callers as being a failure. However, the item actually was successfully + scheduled. The result may be that a freed item remains in the scheduler, + resulting in a crash at some point in the future. + + The scheduler can overflow because every time that an item is added to + the scheduler, a counter is bumped and that counter's current value is + assigned as the new item's ID. + + This patch introduces a new method for assigning scheduler IDs. Instead + of assigning from a counter, a queue of available IDs is maintained. + When assigning a new ID, an ID is pulled from the queue. When a + scheduler item is released, its ID is pushed back onto the queue. This + way, IDs may be reused when they become available, and the growth of ID + numbers is directly related to concurrent activity within a scheduler + context rather than the uptime of the system. + + Change-Id: I532708eef8f669d823457d7fefdad9a6078b99b2 + +2015-09-10 09:49 +0000 [8826e6c416] Mark Michelson + + * res_pjsip: Copy default_from_user to avoid crash. + + The default_from_user retrieval function was pulling the + default_from_user from the global configuration struct in an unsafe way. + If using a database as a backend configuration store, the global + configuration struct is short-lived, so grabbing a pointer from it + results in referencing freed memory. + + The fix here is to copy the default_from_user value out of the global + configuration struct. + + Thanks go to John Hardin for discovering this problem and proposing the + patch on which this fix is based. + + ASTERISK-25390 #close + Reported by Mark Michelson + + Change-Id: I6b96067a495c1259da768f4012d44e03e7c6148c + +2015-04-23 09:16 +0000 [943d5c0c99] gtjoseph + + * res_pjsip: Validate that contact uris start with sip: or sips: + + Currently we use pjsip_parse_hdr to validate contact uris but it + appears that it allows uris without a scheme if there's a port + supplied. I.E myexample.com will fail but myexample.com:5060 will + pass even though it has no scheme. This causes SEGVs later on + whenever the uri is used. + + To prevent this, permanent_contact_validate has been updated to check + that the scheme is either 'sip' or 'sips'. + + 2 uses of possibly-null endpoint have also been fixed in + create_out_of_dialog_request. + + ASTERISK-24999 + + Change-Id: Ifc17d16a4923e1045d37fe51e43bbe29fa556ca2 + Reported-by: Brad Latus + (cherry picked from commit 75666ad7c608ad9968a216a8f0a5832bf85b785c) + +2015-09-03 14:07 +0000 [7b5bcbeebe] Jonathan Rose + + * ParkAndAnnounce: Add variable inheritance + + In Asterisk 11, the announcer channel would receive channel variables + from the channel being parked by means of normal channel inheritance. + This functionality was lost during the big res_parking project in + Asterisk 12. This patch restores that functionality. + + ASTERISK-25369 #close + Review: https://gerrit.asterisk.org/#/c/1180/ + + Change-Id: Ie47e618330114ad2ea91e2edcef1cb6f341eed6e + +2015-08-29 10:36 +0000 [0901a82adb] Joshua Colp + + * taskprocessor: Fix race condition between unreferencing and finding. + + When unreferencing a taskprocessor its reference count is checked + to determine if it should be unlinked from the taskprocessors + container and its listener shut down. In between the time when the + reference count is checked and unlinking it is possible for + another thread to jump in, find it, and get a reference to it. If + the thread then uses the taskprocessor it may find that it is not + in the state it expects. + + This change locks the taskprocessors container during almost the + entire unreference operation to ensure that any other thread which + may attempt to find the taskprocessor has to wait. + + ASTERISK-25295 + + Change-Id: Icb842db82fe1cf238da55df92e95938a4419377c + (cherry picked from commit a676ba2aad5525926ae31b8317b95ae52cbbabbb) + +2015-09-04 14:40 +0000 [500856b4f0] Mark Michelson + + * res_pjsip: Change default from user value. + + When Asterisk sends an outbound SIP request, if there is no direct + reason to place a specific value for the username in the From header, + Asterisk would generate a UUID. For example, this would happen when + sending outbound OPTIONS requests when qualifying or when sending + outbound INVITE requests when originating (if no explicit caller ID were + provided). The issue is that some SIP providers reject these sorts of + requests with a "Name too long" error response. + + This patch aims to fix this by changing the default outbound username in + From headers to "asterisk". This value can be overridden by changing the + default_from_user option in the global options if desired. + + ASTERISK-25377 #close + Reported by Mark Michelson + + Change-Id: I6a4d34a56ff73ff4f661b0075aeba5461b7f3190 + +2015-05-13 15:41 +0000 [42c40b59b6] Jonathan Rose + + * Message.c: Clear message channel frames on cleanup + + The message channel is a special channel that doesn't actually process frames. + However, certain actions can cause frames to be placed in the channel's read + queue including the Hangup application which is called on the channel after + each message is processed. Since the channel will continually be reused for + many messages, it's necessary to flush these frames at some point. + + ASTERISK-25083 #close + Reported by: Jonathan Rose + + Change-Id: Idf18df73ccd8c220be38743335b5c79c2a4c0d0f + (cherry picked from commit 02c513058905dae19f28393ea840a47ae4a9e66d) + +2015-09-02 17:26 +0000 [a1e1d8e815] Mark Michelson + + * res_pjsip: Fix contact refleak on stateful responses. + + When sending a stateful response, creation of the transaction can fail, + most commonly because we are trying to create a transaction from a + retransmitted request. When creation of the transaction fails, we end up + leaking a reference to a contact that was bumped when the response was + created. + + This patch adds the missing deref and fixes the reference leak. + + Change-Id: I2f97ad512aeb1b17e87ca29ae0abacb4d6395f07 + +2015-09-02 12:41 +0000 [9f5e1c0e56] Joshua Colp + + * pbx: Fix crash when issuing "core show hints" with long pattern match. + + When issuing the "core show hints" CLI command a combination of both + the hint extension and context is created. This uses a fixed size + buffer expecting that the extension will not exceed maximum extension + length. When the extension is actually a pattern match this constraint + does not hold true, and the extension may exceed the maximum extension + length. In this case extra characters are written past the end of the + fixed size buffer. + + This change makes it so the construction of the combined hint extension + and context can not exceed the size of the buffer. + + ASTERISK-25367 #close + + Change-Id: Idfa1b95d0d4dc38e675be7c1de8900b3f981f499 + +2015-07-02 14:51 +0000 [1c89230e2a] Richard Mudgett + + * PJSIP XML, XPIDF: Fix buffer size overwrite memory corruption error. + + When res_pjsip body generator modules were generating XML or XPIDF + response bodies, there was a chance that the generated body would be the + exact size of the supplied buffer. Adding the nul string terminator would + then write beyond the end of the buffer and potentially corrupt memory. + + * Fix MALLOC_DEBUG high fence violations caused by adding a nul string + terminator on the end of a buffer for XML or XPIDF response bodies. + + * Made calls to pj_xml_print() safer if the XML prolog is requested. Due + to a bug in pjproject, the return value could be -1 _or_ + AST_PJSIP_XML_PROLOG_LEN if the supplied buffer is not large enough. + + * Updated the doxygen comment of AST_PJSIP_XML_PROLOG_LEN to describe the + return value of pj_xml_print() when the supplied buffer is not large + enough. + + ASTERISK-25168 + Reported by: Carl Fortin + + Change-Id: Id70e1d373a6a2b2bd9e678b5cbc5e55b308981de + +2015-09-01 09:05 +0000 [2f2c35e91d] Mark Michelson + + * res_pjsip_pubsub: re-re-fix persistent subscription storage. + + A recent change to res_pjsip_pubsub switched to using pjsip_msg_print as + a means of writing an appropriate packet to persistent storage. While + this partially solved the issue, it had its own problems. + pjsip_msg_print will always add a Content-Length header to the message + it prints. Frequent restarts of Asterisk can result in persistent + subscriptions being written with five or more Content-Length headers. In + addition, sometimes some apparent corruption of individual headers could + be seen. + + This aims to fix the problem by not running a parsed message through an + interpreter but rather by taking the raw message and saving it. The + logic for what to save is going to be different depending on whether a + SUBSCRIBE was received from the wire or if it was pulled from + persistence. When receiving a packet from the wire, when using a + streaming transport, the rdata->pkt_info.packet may contain multiple SIP + messages or fragments. However, the rdata->msg_info.msg_buf will always + contain the current SIP message to be processed. When pulling from + persistence, though, the rdata->msg_info.msg_buf will be NULL since no + transport actually handled the packet. However, since we know that we + will always ever pull one SIP message from persistence, we are free to + save directly from rdata->pkt_info.packet instead. + + ASTERISK-25365 #close + Reported by Mark Michelson + + Change-Id: I33153b10d0b4dc8e3801aaaee2f48173b867855b + +2015-08-31 15:24 +0000 [88ee3b3ef2] Mark Michelson + + * Fix deadlock on presence state changes. + + A deadlock was observed where three threads were competing for different + locks: + + * One thread held the hints lock and was attempting to lock a specific + hint. + * One thread was holding the specific hint's lock and was attempting to + lock the contexts lock + * One thread was holding the contexts lock and attempting to lock the + hints lock. + + Clearly the second thread was doing the wrong thing here. The fix for + this is to make sure that the hint's lock is not held on presence state + changes. Something similar is already done (and commented about) for + device state changes. + + ASTERISK-25362 #close + Reported by Mark Michelson + + Change-Id: I15ec2416b92978a4c0c08273b2d46cb21aff97e2 + +2015-08-28 20:22 +0000 [8842637d8f] Joshua Colp + + * res_pjsip_sdp_rtp: Fix multiple keepalive scheduled items. + + The keepalive support in res_pjsip_sdp_rtp currently assumes + that a stream will only be negotiated once. This is false. + If the stream is replaced and later added back it can be + negotiated again causing multiple keepalive scheduled items + to exist. This change explicitly deletes the existing + keepalive scheduled item before adding the new one. + + The res_pjsip_sdp_rtp module also does not stop RTP + keepalives or timeout timer if the stream has been + replaced. This change adds a callback to the session media + interface to allow a media stream to be stopped without + the resources being destroyed. This allows the scheduled + items and RTP to be stopped when the stream no longer + exists. + + ASTERISK-25356 #close + + Change-Id: Ibe6a7cc0927c87326fd5f1c0d4ad889dbfbea1de + +2015-08-28 19:57 +0000 [06d42fede3] Joshua Colp + + * sched: ast_sched_del may return prematurely due to spurious wakeup + + When deleting a scheduled item if the item in question is currently + executing the ast_sched_del function waits until it has completed. + This is accomplished using ast_cond_wait. Unfortunately the + ast_cond_wait function can suffer from spurious wakeups so the + predicate needs to be checked after it returns to make sure it has + really woken up as a result of being signaled. + + This change adds a loop around the ast_cond_wait to make sure that + it only exits when the executing task has really completed. + + ASTERISK-25355 #close + + Change-Id: I51198270eb0b637c956c61aa409f46283432be61 + +2015-07-23 13:11 +0000 [74d6ae20cb] Mark Michelson + + * Local channels: Alternate solution to ringback problem. + + Commit 54b25c80c8387aea9eb20f9f4f077486cbdf3e5d solved an issue where a + specific scenario involving local channels and a native local RTP bridge + could result in ringback still being heard on a calling channel even + after the call is bridged. + + That commit caused many tests in the testsuite to fail with alarming + consequences, such as not sending DialBegin and DialEnd events, and + giving incorrect hangup causes during calls. + + This commit reverts the previous commit and implements and alternate + solution. This new solution involves only passing AST_CONTROL_RINGING + frames across local channels if the local channel is in AST_STATE_RING. + Otherwise, the frame does not traverse the local channels. By doing + this, we can ensure that a playtones generator does not get started on + the calling channel but rather is started on the local channel on which + the ringing frame was initially indicated. + + ASTERISK-25250 #close + Reported by Etienne Lessard + + Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39 + +2015-08-26 05:40 +0000 [54a09e4cb5] Joshua Colp + + * chan_sip: Allow call pickup to set the hangup cause. + + The call pickup implementation in chan_sip currently sets the channel + hangup cause to "normal clearing" if call pickup is successfully + performed. This action overwrites the "answered elsewhere" hangup cause + set by the call pickup code and can result in the SIP device in + question showing a missed call when it should not. + + This change sets the hangup cause to "normal clearing" as a + default initially but allows the call pickup to change it as + needed. + + ASTERISK-25346 #close + + Change-Id: I00ac2c269cee9e29586ee2c65e83c70e52a02cff + +2015-08-25 07:17 +0000 [942d0ba96f] Joshua Colp + + * res_pjsip: Add common ast_sip_get_host_ip API. + + Modules commonly used the pj_gethostip function for retrieving the + IP address of the host. This function does not cache the result and may + result in a DNS lookup occurring, or additional work. If the DNS + server is unreachable or network issues arise this can cause the + pj_gethostip function to block for a period of time. + + This change adds an ast_sip_get_host_ip and ast_sip_get_host_ip_string + function which does the same thing but caches the host IP address at + module load time. This results in no additional work being done each + time the local host IP address is needed. + + ASTERISK-25342 #close + + Change-Id: I3205deb679b01fa5ac05a94b623bfd620a2abe1e + +2015-08-24 06:21 +0000 [ad4e895928] Joshua Colp + + * bridge: Kick channel from bridge if hung up during action. + + When executing an action in a bridge it is possible for the + channel to be hung up without the bridge becoming aware of it. + This is most easily reproducible by hanging up when the bridge + is streaming DTMF due to a feature timeout. This change makes + it so after action execution the channel is checked to determine + if it has been hung up and if it has it is kicked from the bridge. + + ASTERISK-25341 #close + + Change-Id: I6dd8b0c3f5888da1c57afed9e8a802ae0a053062 + +2015-08-24 11:04 +0000 [4083e543fd] Joshua Colp + + * res_pjsip_pubsub: On recreated notify fail deleted sub_tree is referenced + + When recreating a subscription it is possible for a freed sub_tree + to be referenced when the initial NOTIFY fails to be created. + + Change-Id: I681c215309aad01b21d611c2de47b3b0a6022788 + +2015-04-16 13:20 +0000 [0b04269e73] Scott Griepentrog + + * res_pjsip_pubsub: On notify fail deleted sub_tree is then referenced + + This change makes the send_notify of the sub_tree + not happen when the sub_tree has been deleted due + to the notify call failing, which avoids a crash. + + ASTERISK-24970 #close + + Change-Id: I1f20ffc08b192f59c457293b218025a693992cbf + (cherry picked from commit 8d4ce7cc2b87317005588e700b278a8cca7005c8) + +2015-08-14 15:46 +0000 [f049ad951b] Mark Michelson + + * res_pjsip_sdp_rtp: Restore removed NULL check. + + When sending an RTP keepalive, we need to be sure we're not dealing with + a NULL RTP instance. There had been a NULL check, but the commit that + added the rtp_timeout and rtp_hold_timeout options removed the NULL + check. + + Change-Id: I2d7dcd5022697cfc6bf3d9e19245419078e79b64 + +2015-08-13 12:22 +0000 [fb347a4ded] Richard Mudgett + + * audiohook.c: Fix MixMonitor crash when using the r() or t() options. + + The built frame format in audiohook_read_frame_both() is now set to a + signed linear format before the rx and tx frames are duplicated instead of + only for the mixed audio frame duplication. + + ASTERISK-25322 #close + Reported by Sean Pimental + + Change-Id: I86f85b5c48c49e4e2d3b770797b9d484250a1538 + +2015-08-12 12:59 +0000 [a5049df640] Kevin Harwell + + * chan_sip.c: wrong peer searched in sip_report_security_event + + In chan_sip, after handling an incoming invite a security event is raised + describing authorization (success, failure, etc...). However, it was doing + a lookup of the peer by extension. This is fine for register messages, but + in the case of an invite it may search and find the wrong peer, or a non + existent one (for instance, in the case of call pickup). Also, if the peers + are configured through realtime this may cause an unnecessary database lookup + when caching is enabled. + + This patch makes it so that sip_report_security_event searches by IP address + when looking for a peer instead of by extension after an invite is processed. + + ASTERISK-25320 #close + + Change-Id: I9b3f11549efb475b6561c64f0e6da1a481d98bc4 +2015-08-13 05:26 +0000 [7089472637] Joshua Colp + + * res_http_websocket: When shutting down a session don't close closed socket + + Due to the use of ast_websocket_close in session termination it is + possible for the underlying socket to already be closed when the + session is terminated. This occurs when the close frame is attempted + to be written out but fails. + + Change-Id: I7572583529a42a7dc911ea77a974d8307d5c0c8b +2015-08-11 05:24 +0000 [128d2348e6] Joshua Colp + + * res_http_websocket: Forcefully terminate on write errors. + + The res_http_websocket module will currently attempt to close + the WebSocket connection if fatal cases occur, such as when + attempting to write out data and being unable to. When the + fatal cases occur the code attempts to write a WebSocket close + frame out to have the remote side close the connection. If + writing this fails then the connection is not terminated. + + This change forcefully terminates the connection if the + WebSocket is to be closed but is unable to send the close frame. + + ASTERISK-25312 #close + + Change-Id: I10973086671cc192a76424060d9ec8e688602845 + +2015-08-10 13:43 +0000 [6b219a866c] Richard Mudgett + + * chan_dahdi.c: Flush the DAHDI write buffer after starting DTMF. + + Pressing DTMF digits on a phone to go out on a DAHDI channel can result in + the digit not being recognized or even heard by the peer. + + Phone -> Asterisk -> DAHDI/channel + + Turns out the DAHDI behavior with DTMF generation (and any other generated + tones) is exposed by the "buffers=" setting in chan_dahdi.conf. When + Asterisk requests to start sending DTMF then DAHDI waits until its write + buffer is empty before generating any samples for the DTMF tones. When + Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI + immediately stops generating the DTMF samples. As a result, the more + samples there are in the DAHDI write buffer the shorter the time DTMF + actually gets sent on the wire. If there are more samples in the write + buffer than the time DTMF is supposed to be sent then no DTMF gets sent on + the wire. With the "buffers=12,half" setting and each buffer representing + 20 ms of samples then the DAHDI write buffer is going to contain around + 120 ms of samples. For DTMF to be recognized by the peer the actual sent + DTMF duration needs to be a minimum of 40 ms. Therefore, the intended + duration needs to be a minimum of 160 ms for the peer to receive the + minimum DTMF digit duration to recognize it. + + A simple and effective solution to work around the DAHDI behavior is for + Asterisk to flush the DAHDI write buffer when sending DTMF so the full + duration of DTMF is actually sent on the wire. When someone is going to + send DTMF they are not likely to be talking before sending the tones so + the flushed write samples are expected to just contain silence. + + * Made dahdi_digit_begin() flush the DAHDI write buffer after requesting + to send a DTMF digit. + + ASTERISK-25315 #close + Reported by John Hardin + + Change-Id: Ib56262c708cb7858082156bfc70ebd0a220efa6a + +2015-08-05 14:21 +0000 [fc4455216a] Richard Mudgett + + * chan_dahdi.c: Lock private struct for ast_write(). + + There is a window of opportunity for DTMF to not go out if an audio frame + is in the process of being written to DAHDI while another thread starts + sending DTMF. The thread sending the audio frame could be past the + currently dialing check before being preempted by another thread starting + a DTMF generation request. When the thread sending the audio frame + resumes it will then cause DAHDI to stop the DTMF tone generation. The + result is no DTMF goes out. + + * Made dahdi_write() lock the private struct before writing to the DAHDI + file descriptor. + + ASTERISK-25315 + Reported by John Hardin + + Change-Id: Ib4e0264cf63305ed5da701188447668e72ec9abb + +2015-08-10 18:23 +0000 [739fca6084] Richard Mudgett + + * res_pjsip.c: Fix crash from corrupt saved SUBSCRIBE message. + + If the saved SUBSCRIBE message is not parseable for whatever reason then + Asterisk could crash when libpjsip tries to parse the message and adds an + error message to the parse error list. + + * Made ast_sip_create_rdata() initialize the parse error rdata list. The + list is checked after parsing to see that it remains empty for the + function to return successful. + + ASTERISK-25306 + Reported by Mark Michelson + + Change-Id: Ie0677f69f707503b1a37df18723bd59418085256 + +2015-08-06 12:48 +0000 [bfb15bea06] Mark Michelson + + * res_pjsip_pubsub: More accurately persist packet. + + The pjsip_rx_data structure has a pkt_info.packet field on it that is + the packet that was read from the transport. For datagram transports, + the packet read from the transport will correspond to the SIP message + that arrived. For streamed transports, however, it is possible to read + multiple SIP messages in one packet. + + In a recent case, Asterisk crashed on a system where TCP was being used. + This is because at some point, a read from the TCP socket resulted in a + 200 OK response as well as an incoming SUBSCRIBE request being stored in + rdata->pkt_info.packet. When the SUBSCRIBE was processed, the + combination 200 OK and SUBSCRIBE was saved in persistent storage. Later, + a restart of Asterisk resulted in the crash because the persistent + subscription recreation code ended up building the 200 OK response + instead of a SUBSCRIBE request, and we attempted to access + request-specific data. + + The fix here is to use the pjsip_msg_print() function in order to + persist SUBSCRIBE requests. This way, rather than using the raw socket + data, we use the parsed SIP message that PJSIP has given us. If we + receive multiple SIP messages from a single read, we will be sure only + to save off the relevant SIP message. There also is a safeguard put in + place to make sure that if we do end up reconstructing a SIP response, + it will not cause a crash. + + ASTERISK-25306 #close + Reported by Mark Michelson + + Change-Id: I4bf16f7b76a2541d10b55de82bcd14c6e542afb2 + +2015-08-04 16:12 +0000 [9e93ad109b] Joshua Colp + + * res_pjsip: Ensure sanitized XML is NULL terminated. + + The ast_sip_sanitize_xml function is used to sanitize + a string for placement into XML. This is done by examining + an input string and then appending values to an output + buffer. The function used by its implementation, strncat, + has specific behavior that was not taken into account. + If the size of the input string exceeded the available + output buffer size it was possible for the sanitization + function to write past the output buffer itself causing + a crash. The crash would either occur because it was + writing into memory it shouldn't be or because the resulting + string was not NULL terminated. + + This change keeps count of how much remaining space is + available in the output buffer for text and only allows + strncat to use that amount. + + Since this was exposed by the res_pjsip_pidf_digium_body_supplement + module attempting to send a large message the maximum allowed + message size has also been increased in it. + + A unit test has also been added which confirms that the + ast_sip_sanitize_xml function is providing NULL terminated + output even when the input length exceeds the output + buffer size. + + ASTERISK-25304 #close + + Change-Id: I743dd9809d3e13d722df1b0509dfe34621398302 + +2015-02-13 11:21 +0000 [f6dcbd9707] Richard Mudgett + + * res_pjsip_session: Fix double re-INVITE collision crash. + + A multi-asterisk box setup with direct media enabled would occasionally + crash when two re-INVITE collisions on a call leg happen in a row. + + The re-INVITE logic only had one timer struct to defer the re-INVITE. + When the second collision happens the timer struct is overwritten and put + into the timer heap again. Resources for the first timer are leaked and + the heap has two positions occupied by the same timer struct. Now the + heap ordering is potentially corrupted, the timer will fire twice, and any + resources allocated for the second timer will be released twice. + + * The solution is to put the collided re-INVITE into the delayed requests + queue with all the other delayed requests and cherry pick the next request + that can come off the queue when an event happens. + + * Changed to put delayed BYE requests at the head of the delayed queue. + There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE + has been requested. + + * Made the start of a BYE request flush the delayed requests queue to + prevent a delayed request from overlapping the BYE transaction. I saw a + few cases where a delayed re-INVITE got started after the BYE transaction + started. + + * Changed the delayed_request struct to use an enum instead of a string + for the request method. Cherry picking the queue is easier with an enum + than string comparisons and the compiler can warn if a switch statement + does not cover all defined enum values. + + * Improved the debug output to give more information. It helps to know + which channel is involved with an endpoint. Trunks can have many channels + associated with the endpoint at the same time. + + ASTERISK-24727 #close + Reported by: Mark Michelson + + Review: https://reviewboard.asterisk.org/r/4414/ + + Change-Id: Ib05700c3a13ceac53b17d66099ef0d296a5e1863 + +2015-01-16 16:12 +0000 [4350fd22c8] Mark Michelson + + * Fix problem where a hung channel could occur on a failed blind transfer. + + Different clients react differently to being told that a blind transfer + has failed. Some will simply send a BYE and be done with it. Others will + attempt to reinvite themselves back onto the call. + + In the latter case, we were creating a new channel and then leaving it to + sit forever doing nothing. With this code change, that new channel will + not be created and the dialog with the transferring channel will be cleaned + up properly. + + ASTERISK-24624 #close + Reported by Zane Conkle + + Review: https://reviewboard.asterisk.org/r/4339 + + Change-Id: I76e440e08e603c1eea40a14951e7b171c0472a55 + +2015-07-18 11:16 +0000 [fae081ad5b] Joshua Colp + + * pjsip: Add rtp_timeout and rtp_timeout_hold endpoint options. + + This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold' + endpoint options. These allow the channel to be hung up if RTP + is not received from the remote endpoint for a specified number of + seconds. + + ASTERISK-25259 #close + + Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9 + +2015-07-09 14:17 +0000 [d66abb6746] Mark Michelson + + * res_pjsip: Add rtp_keepalive endpoint option. + + This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the + chan_sip option, this specifies an interval, in seconds, at which we + will send RTP comfort noise frames. This can be useful for keeping RTP + sessions alive as well as keeping NAT associations alive during lulls. + + ASTERISK-25242 #close + Reported by Mark Michelson + + Change-Id: I683bdc206c8c7def586ecaa64dcf2b86550be3bf + +2015-07-16 09:46 +0000 [1b744ab684] Joshua Colp + + * chan_pjsip: Don't change formats when frame of unsupported format is received. + + Receipt of an RTP packet currently causes the formats on an PJSIP channel to + change to the format of the RTP packet. In some off-nominal cases it's possible + for this to be a format that has not been configured or negotiated. This change + makes it so only formats explicitly configured on the endpoint are allowed. + + ASTERISK-25258 #close + + Change-Id: If93d641fb6418a285928839300d7854cab8c1020 + +2015-07-15 15:40 +0000 [147b86a8d1] Richard Mudgett + + * strings.h: Fix issues with escape string functions. + + Fixes for issues with the ASTERISK-24934 patch. + + * Fixed ast_escape_alloc() and ast_escape_c_alloc() if the s parameter is + an empty string. If it were an empty string the functions returned NULL + as if there were a memory allocation failure. This failure caused the AMI + VarSet event to not get posted if the new value was an empty string. + + * Fixed dest buffer overwrite potential in ast_escape() and + ast_escape_c(). If the dest buffer size is smaller than the space needed + by the escaped s parameter string then the dest buffer would be written + beyond the end by the nul string terminator. The num parameter was really + the dest buffer size parameter so I renamed it to size. + + * Made nul terminate the dest buffer if the source string parameter s was + an empty string in ast_escape() and ast_escape_c(). + + * Updated ast_escape() and ast_escape_c() doxygen function description + comments to reflect reality. + + * Added some more unit test cases to /main/strings/escape to cover the + empty source string issues. + + ASTERISK-25255 #close + Reported by: Richard Mudgett + + Change-Id: Id77fc704600ebcce81615c1200296f74de254104 + +2015-07-14 14:36 +0000 [131f6ef8f5] Richard Mudgett + + * res_parking: Fix crash if ATTENDEDTRANSFER set empty before Park. + + setup_park_common_datastore() was assuming that a non-NULL string returned + for the ATTENDEDTRANSFER and BLINDTRANSFER channel variables are not empty + strings. Things got crashy as a result. + + * Made setup_park_common_datastore() treat the channel variable values the + same whether they are NULL or empty for ATTENDEDTRANSFER and + BLINDTRANSFER. + + ASTERISK-25254 #close + Reported by: Richard Mudgett + + Change-Id: I9a9c174b33f354f35f82cc6b7cea8303adbaf9c2 + +2015-07-09 09:18 +0000 [23b7b109c2] Joshua Colp + + * bridge_native_rtp.c: Don't start native RTP bridging after attended transfer. + + The bridge_native_rtp module adds a frame hook to channels which are in + a native RTP bridge. This frame hook is used to intercept when a hold + or unhold frame traverses the bridge so native RTP can be stopped or + started as appropriate. This is expected but exposes a specific bug + when attended transfers are involved. + + Upon completion of an attended transfer an unhold frame is queued up + to take one of the channels involved off hold. After this is done + the channel is moved between bridges. + + When the frame hook is involved in this case for the unhold it + releases the channel lock and acquires the bridge lock. This + allows the bridge core to step in and move the channel + (potentially changing the bridging techology) from another thread. + Once completed the bridge lock is released by the bridge core. + The frame hook is then able to acquire the bridge lock and + wrongfully starts native RTP again, despite the channel no longer + being in the bridge or needing to start native RTP. In fact at + this point the frame hook is no longer attached to the channel. + + This change makes it so the native RTP bridge data is available to + the frame hook when it is invoked. Whether the frame hook has + been detached or not is stored on the native RTP bridge data and + is checked by the frame hook before starting or stopping native + RTP bridging. If the frame hook has been detached it does nothing. + + ASTERISK-25240 #close + + Change-Id: I13a73186a05f4e5a764f81e5cd0ccec1ed1891d2 + +2015-05-26 07:44 +0000 [0fcc530dc7] Joshua Colp + + * sorcery: Fix cache creation callback. + + The cache creation callback function expects to receive a sorcery_details + structure and not just a standalone object. + + Change-Id: Id2a9e5f271c466686e6d0def461fa50c8b2cae53 + +2015-07-08 14:39 +0000 [c8d53f2372] Mark Michelson + + * res_sorcery_memory_cache: Remove ASTERISK_REGISTER_FILE() macro. + + This was part of the backport of res_sorcery_memory_cache from master + but will not compile in 13. + + Change-Id: I27b3d833acda9dd1770fdbe594964197b93779b0 + +2015-07-06 09:24 +0000 [a72cf6ce81] Joshua Colp + + * res_sorcery_memory_cache: Execute stale unit test last. + + In Jenkins there is currently a sporadic test failure of a + variable number of sorcery memory cache unit tests. I have not + been able to reproduce this on the build agents themselves or + on my development machine. + + My working theory is that the stale unit test is causing a + sorcery instance to persist longer than expected, causing subsequent + tests to fail when setting up and initializing the next + sorcery instance. + + To see if this is the case this change moves the stale unit test + to execute last so no subsequent unit tests can have issues + initializing their sorcery instance. + + Change-Id: Ifd6550a949613be774b75fa5db12c02110f82c4a + +2015-06-17 07:00 +0000 [e0cd8216bb] Joshua Colp + + * res_sorcery_memory_cache: Remove 'prefetch' option. + + To prevent confusion I am removing the prefetch option until such + time as it is implemented. All other functionality, however, has + been implemented. + + ASTERISK-25067 + + Change-Id: I9ce6aa3e5c6c5bc3c5baa8ff90fa036d73939895 + +2015-06-02 10:20 +0000 [8b2bad7740] Joshua Colp + + * test_sorcery_memory_cache_thrash: Add unit tests for thrashing the memory cache. + + This change adds a CLI command which can perform memory cache thrashing as well + as unit tests which perform thrashing under the following configurations: + + 1. Low number of unique objects that go stale after 1 second + 2. Low number of unique objects that expire after 1 second + 3. Low number of unique objects which are constantly updated + 4. Large number of unique objects which exceed a defined cache size + 5. Large number of unique objects which exceed a defined cache size + that also expire and go stale rapidly + 6. Large number of unique objects which expire and go stale rapidly + 7. Large number of unique objects + + For all of the above there are a large number of threads constantly + attempting to retrieve random objects and each test runs for a few + seconds. + + ASTERISK-25067 + Reported by: Matt Jordan + + Change-Id: I8c8ceff977332c80ed4a31f10d694d48552b2f78 + +2015-06-04 13:11 +0000 [8575c4f18d] Joshua Colp + + * res_sorcery_memory_cache: Implement expire_on_reload option. + + This change implements the expire_on_reload option for memory caches. + If enabled and a reload is performed all objects within the cache + will be expired and the cache emptied. + + ASTERISK-25067 + Reported by: Matt Jordan + + Change-Id: Id46aa1957d660556700e689e195eed57c989b85e + +2015-06-04 05:33 +0000 [da52527136] Joshua Colp + + * res_sorcery_memory_cache: Add test event when a refresh occurs. + + This change adds a testsuite event for when a refresh occurs. + This is useful as it provides a guaranteed mechanism of knowing when + it has occurred instead of waiting an arbitrary amount of time. + + ASTERISK-25067 + Reported by: Matt Jordan + + Change-Id: Iaa6b8d2d6bab7f99ee08e1c8908b8272a8987e65 + +2015-05-26 07:34 +0000 [f596b4a85c] Joshua Colp + + * res_sorcery_memory_cache: Add CLI commands and AMI actions. + + This change adds the following CLI commands and AMI actions: + + sorcery memory cache show + sorcery memory cache dump + sorcery memory cache expire + sorcery memory cache stale + + SorceryMemoryCacheExpire + SorceryMemoryCacheExpireObject + SorceryMemoryCacheStale + SorceryMemoryCacheStaleObject + + These allow both examination and manipulation of sorcery memory + caches from external sources. + + Cached objects can be explicitly expired from a cache or marked + as stale. If expired they are immediately removed. If marked as + stale they will be background refreshed when next retrieved. + + ASTERISK-25067 + Reported by Matt Jordan + + Change-Id: I68e03cfd8c34b5e07f4b6ee4fd93a3f4a00a3d9e + +2015-05-26 13:01 +0000 [9c2de310be] Mark Michelson + + * res_sorcery_memory_cache: Add support for refreshing stale objects. + + This change introduces a check of object_lifetime_stale when retrieving + cached objects. If the amount of time the object has been in the cache + exceeds the lifetime, then a task is scheduled to update the cached + object based on an object retrieved from other sorcery wizards instead. + + To prevent the cached object from being retrieved during a refresh, + thread-local storage is used to mark the thread as being a stale object + update. This results in the cache returning no object, leading to + sorcery querying other wizards for the object instead. + + A test has been added for stale objects as well. This test ensures that + stale objects are retrieved the same as freshly-cached objects. The test + also ensures that after an object is stale, changes in the backend are + reflected in the cache, to include if the object has been deleted from + the backend. + + ASTERISK-25067 + Reported by Matt Jordan + + Change-Id: I9bd7c049adf6939bfe2899f393c2bfbbf412d217 + +2015-05-20 17:35 +0000 [9a7fccc50c] Joshua Colp + + * res_sorcery_memory_cache: Add support for object_lifetime_maximum. + + This makes the "object_lifetime_maximum" option operational. + + On the addition of an object to an empty memory cache a scheduled + task is created which, when invoked, expires objects from the cache + which have exceeded their lifetime. If more objects have been added + the remaining life of the oldest object is used to schedule the + next invocation of the scheduled task. + + If the oldest object is removed from the cache before it can be + expired automatically the scheduled task is cancelled, if possible, + and the lifetime of the next oldest is used to schedule the task. + + If during these two operations no additional objects exist in the + cache then no task is scheduled. + + An additional unit test has been added which verifies this + functionality. + + ASTERISK-25067 + Reported by: Matt Jordan + + Change-Id: I87409674674a508e7717ee20739ca15cec6ba7b6 + +2015-05-20 15:19 +0000 [9ae9221d2b] Mark Michelson + + * res_sorcery_memory_cache: Add support for maximum_objects. + + This makes the "maximum_objects" option operational. + + A heap has been added alongside the hash table in the cache. When + objects are added to the cache, they are also added to the heap. + Similarly, when objects are removed from the cache, they are removed + from the heap. + + The heap's use comes into play when an item is to be added to a "full" + cache. When the cache is full, the oldest item is removed from the + cache, using the heap to determine the oldest item. + + A unit test has been added that verifies that the maximum_objects option + works as expected and that the oldest object is removed from the cache + when an object beyond the maximum is added. + + ASTERISK-25067 #close + Reported by Matt Jordan + + Change-Id: I490658830e9c4cbf0b3051e4cdc4913cf9f1b73a + +2015-05-16 17:02 +0000 [e4d42119b5] Joshua Colp + + * res_sorcery_memory_cache: Add basic module implementation. + + This change adds a basic res_sorcery_memory_cache module which implements + configuration option parsing, configuration file parsing for threading, + sorcery interface implementation, and unit tests. + + Objects can be added, updated, deleted, and retrieved from the memory + cache. Automatic expiration and stale handling will be added in the + future. + + Note that unit tests exist within the module itself in case the + threading done as a result of expiration results in asynchronous + actions (which it likely will). Providing access and a notification + mechanism for an external test module would be complicated and + not worth it. + + ASTERISK-25067 #close + Reported by: Matt Jordan + + Change-Id: Id8a6a357ef5a83d466f81eee56a67d13eeb118b9 + +2015-07-02 17:03 +0000 [49a37f22e1] Jonathan Rose + + * app: Add functions to swap vm function table + + This patch adds function-mocking methods for testing voicemail + features in external modules. It is being pulled over from r432556 + on SVN because DPMA won't presently compile with TEST_FRAMEWORK + set in Asterisk 13.1 certified. + + Change-Id: I1c2cf6d5a8589104154a86538ecd3f62a2694681 +2015-04-22 16:22 +0000 [f58c0acfa2] gtjoseph + + * res/res_corosync: Always decline module load, instead of failing + + Returns a 'failure' from the module load routine indicates to Asterisk + that it should abort loading completely. This is rarely - in fact, + really, never - a good option. Aborting load of Asterisk from a dynamic + module implies that the core, and the rest of the dynamic modules, don't + matter: we should abandon all processing. + + res_corosync is really not that important. + + This patch updates the module such that, if it fails to load, it + politely declines (emitting ERROR messages along the way), and allows + Asterisk to continue to function. + + Note that this issue was keeping Asterisk unit tests from running on + certain build agents. + + Change-Id: I252249e81fb9b1a68e0da873f54f47e21d648f0f + +2015-06-29 12:45 +0000 [9cbd76630a] Mark Michelson + + * res_sorcery_realtime: Fix leak of sorcery object type. + + This prevents a leak of a sorcery object type when realtime sorcery + objects are retrieved by fields or when multiple objects are retrieved. + + The extent of this leak is that sorcery object types would be leaked. + These are allocated whenever an object type is registered with sorcery, + meaning that on module shutdown, these objects would be leaked. This + could be problematic if many reloads were performed, but it is not as + severe as if every sorcery object retrieved from realtime were being + leaked. + + ASTERISK-25165 #close + Reported by Corey Farrell + + Change-Id: I625c3b50eee4576670b7eeb013c81ad043b4b4f8 + +2015-06-26 16:12 +0000 [8ba3de43ad] Mark Michelson + + * res_pjsip_nat: Adjust when contact should be rewritten. + + A previous change made the contact only get rewritten if the dialog's + route set was not marked frozen. Unfortunately, while the intent of this + is correct, the dialog's route set actually gets marked as frozen + earlier than expected, especially for UAS dialogs. + + Instead, the idea is that the contact needs to not be rewritten if there + is a pre-existing route set on the dialog. This is now accomplished by + checking the dialog's route set list instead of checking if the route + set is frozen. + + Doing this causes some broken tests to begin passing again. + + ASTERISK-25196 + Reported by Mark Michelson + + Change-Id: I525ab251fd40a52ede327a52a2810a56deb0529e + +2015-06-26 10:41 +0000 [20f50131d7] Mark Michelson + + * res_pjsip_refer: Prevent sending duplicate headers. + + res_pjsip_refer will attempt to add Referred-By or Replaces headers to + outbound INVITEs at times. If the INVITE gets challenged for + authentication, then we will resend the INVITE. Prior to this patch, the + Referred-By or Replaces header would be re-added to the outbound INVITE, + resulting in duplicated headers. + + ASTERISK-25204 #close + Reported by Mark Michelson + + Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d + +2015-06-23 17:43 +0000 [0d535df734] Mark Michelson + + * res_pjsip_nat: Rewrite route set when required. + + When performing some provider testing, the rewrite_contact option was + interfering with proper construction of a route set when sending an ACK + after receiving a 200 OK response to an INVITE. + + The initial INVITE was sent to address sip:foo. The 200 OK had a Contact + header with URI sip:bar. In addition, the 200 OK had Record-Route + headers for sip:baz and sip:foo, in that order. Since the Record-Route + headers had the lr parameter, the result should have been: + + * Set R-URI of the ACK to sip:bar. + * Add Route headers for sip:foo and sip:baz, in that order. + + However, the rewrite_contact option resulted in our rewriting the + Contact header on the 200 OK to sip:foo. The result was: + + * R-URI remained sip:foo. + * We added Route headers for sip:foo and sip:baz, in that order. + + The result was that sip:bar was not indicated in the ACK at all, so the + far end never received our ACK. The call eventually dropped. + + The intention of rewrite_contact is to rewrite the most immediate + destination of our SIP request to be the same address on which we + received a request or response. In the case of processing a SIP response + with Record-Route headers, this means that instead of rewriting the + Contact header, we should instead rewrite the bottom-most Record-Route + header. In the case of processing a SIP request with Record-Route + headers, this means we rewrite the top-most Record-route header. + Like when we rewrite the Contact header, we also ensure to update + the dialog's route set if it exists. + + ASTERISK-25196 #close + Reported by Mark Michelson + + Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f +2015-06-23 14:34 +0000 [3332869b48] Richard Mudgett + + * AMI: Add Linkedid to the standard channel snapshot AMI event headers. + + ASTERISK-25189 #close + Reported by: John Hardin + + Change-Id: I2b1778c3fdc1dca0ed55db4e3a639eddfb16c2ac + +2015-06-17 05:04 +0000 [a35d6feae2] Joshua Colp + + * res_pjsip_mwi: Set up unsolicited MWI upon registration. + + The res_pjsip_mwi previously required a reload to set up the proper + subscriptions to allow unsolicited MWI to work. This change + makes it so the act of registering will also cause this to occur. + This is particularly useful if realtime is involved as no reload + needs to occur within Asterisk to cause the MWI information + to get sent. + + ASTERISK-25180 #close + + Change-Id: Id847b47de4b8b3ab8858455ccc2f07b0f915f252 + +2015-06-10 18:28 +0000 [75589c4a3b] Joshua Colp + + * bridge: When performing a blonde transfer update connected line information. + + When performing a blonde transfer the code uses the old masquerade + mechanism to move a channel around. As a result of this certain information, + such as connected line, is moved between the channels involved. Upon + completion of the move a frame is queued which is supposed to update the + connected line information on the channel. This does not occur as the + code considers it a redundant update since the masquerade operation + updated the channel (but did not inform it of the new connected line + information). The code also does not queue a connected line update + to be handled by the thread handling the channel. Without this any + other channel that may be loosely involved does not know it is + talking to a different caller. + + This change does the following to resolve this: + + 1. The indicated connected line information is cleared upon + completion of the masquerade operation when doing a blonde transfer. + This prevents the connected line update from being considered + redundant. + + 2. A connected line update frame is now queued upon the completion + of the masquerade operation so any other channel loosely involved + knows that there is a different caller. + + ASTERISK-25157 #close + Reported by: Joshua Colp + + Change-Id: Ibb8798184a1dab3ecd35299faecc420034adbf20 + +2015-06-11 14:39 +0000 [8142b922ab] Richard Mudgett + + * app_directory: Fix crash when using the alias option 'a'. + + The voicemail.conf mailbox key/value pair is defined as: + =[[,[,[,[,]]]]] + Where all fields in the value including the field values are optional. + + Since the parsing code for the mailbox key/value pair is sloppy, this + patch tightens the parsing for the directory information. + + * Renamed the 'pos' and 'bufptr' variables to 'name' and 'options' + respectively in search_directory_sub(). Those names make more sense. + + * Made sure that search_directory_sub() is dealing with the voicemail.conf + mailbox options field if it even exists when looking for the 'hidefromdir' + and 'alias' options. + + * Fix crash if a voicemail.conf mailbox is just + =, when the 'a' option is used. If there were no + fields after the name then the 'options' pointer was not checked for NULL. + + * Fix users.conf alias processing if the 'a' option is used. The wrong + variable was used. + + ASTERISK-25087 #close + Reported by: Chet Stevens + + Change-Id: I86052ea77307beddddba5279824d39dc0d593374 + +2015-06-08 12:28 +0000 [ca2174bb23] Matt Jordan + + * .version: Update for certified/13.1-cert3-rc1 + +2015-06-08 12:28 +0000 [2ef2c12fae] Matt Jordan + + * .lastclean: Update for certified/13.1-cert3-rc1 + +2015-06-08 12:28 +0000 [5032390639] Matt Jordan + + * realtime: Add database scripts for certified/13.1-cert3-rc1 + +2015-06-08 09:43 +0000 [2bf6fd263a] Kevin Harwell + + * AMI: Escape string values. + + So this issue is a bit complicated. Since it is possible to pass values to AMI + that contain a '\r\n' (or other similar sequences) these values need to be + escaped. One way to solve this is to escape the values and then pass the escaped + values to the AMI variable parameter string building function. However, this + puts the onus on the pre-build function to escape all string values. This + potentially requires a fair amount of changes along with a lot of string + allocations/freeing for all values. + + Surely there is a way to push this complexity down a level into the string + building function itself? This of course is possible, but ends up requiring a + way to distinguish between strings that need to be escaped and those that don't. + The best way to handle this is by introducing a new format specifier in the + format string. For instance a %s (no escape) and %S (escape). However, that is + a bit weird and unexpected. + + So faced with those possibilities this patch implements a limited version of the + first option. Instead of attempting to escape all string values this patch only + escapes those values that make sense. This approach limits the number of changes + and doesn't suffer from the odd format specifier problem. + + ASTERISK-24934 #close + Reported by: warren smith + + Change-Id: Ib55a5b84fe0481b0f2caaaab68c566f392c0aac0 + +2015-06-03 17:41 +0000 [5f954e1e00] Mark Michelson + + * res_pjsip: Prevent access of NULL channels. + + It is possible to receive incoming requests or responses after the channel + on an ast_sip_session has been destroyed and NULLed out. Handlers of these + sorts of requests or responses need to be prepared for the possibility + that the channel is NULL or else they could cause a crash. + + While several places have been amended to deal with NULL channels, there + were still a couple of places that needed updating. + + res_pjsip_dtmf_info.c: When handling incoming INFO requests, we need to + return early if there is no channel on the session. + + res_pjsip_session.c: When handling a 302 response, we need to stop the + redirecting attempt if there is no channel on the session. + + ASTERISK-25148 #close + reported by Mark Michelson + + Change-Id: Id1a75ffc3d0eaa168b0b28188fb54d6cf9fc47a9 + +2015-02-17 09:34 +0000 [c994a3bfa0] Richard Mudgett + + * res_pjsip_refer: Fix crash from a REFER and BYE collision. + + Analyzing a one-off crash on a busy system showed that processing a REFER + request had a NULL session channel pointer. The only way I can think of + that could cause this is if an outgoing BYE transaction overlapped the + incoming REFER transaction in a collision. Asterisk sends a BYE while the + phone sends a REFER to complete an attended transfer. + + * Made check the session channel pointer before processing an incoming + REFER request in res_pjsip_refer. + + * Fixed similar crash potential for res_pjsip supplement incoming request + processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE, + res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER + messages. + + * Made res_pjsip_messaging respond to a message body too large with a 413 + instead of ignoring it. + + ASTERISK-24700 #close + Reported by: Zane Conkle + + Review: https://reviewboard.asterisk.org/r/4417/ + ........ + + Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13 + + Change-Id: I57878adc0846dd942a699ad36dcec9cba5e57994 + +2015-04-06 14:23 +0000 [1e98fcac6b] Kevin Harwell + + * res_pjsip: config option 'timers' can't be set to 'no' + + When setting the configuration option 'timers' equal to 'no' the bit flag was + not properly negated. This patch clears all associated flags and only sets the + specified one. pjsip will handle any necessary flag combinations. Also went + ahead and did similar for the '100rel' option. + + ASTERISK-24910 #close + Reported by: Ray Crumrine + Review: https://reviewboard.asterisk.org/r/4582/ + ........ + + Merged revisions 434131 from http://svn.asterisk.org/svn/asterisk/branches/13 + + Change-Id: Ibbc25d4592aabf7596ef473447d630961f88c217 + +2015-05-26 13:56 +0000 [bd32327353] Richard Mudgett + + * res_pjsip_session: Fix in-dialog authentication. + + When the remote peer requires authentication for in-dialog requests then + re-INVITEs to the peer cause the call to be disconnected and other + in-dialog requests to the peer like MESSAGE just don't go through. + + * Made session_inv_on_tsx_state_changed() handle in-dialog authentication + for re-INVITEs and other methods. Initial INVITEs cannot be handled here + because the INVITE transaction must be restarted earlier. + + * Pulled needed code from res/res_pjsip/pjsip_outbound_auth.c in + preparation for removing the file. The generic outbound authentication + code did not work as well as anticipated. + + * Created outbound_invite_auth() to only handle initial outbound INVITEs. + Re-INVITEs cannot be handled here. The re-INVITE transaction is still in + progress and the PJSIP library cannot handle the overlapping INVITE + transactions. Other method types should not be handled here as this code + only works on outgoing calls and we need to handle incoming and outgoing + calls. + + ASTERISK-25131 #close + Reported by: Richard Mudgett + + Change-Id: I12bdd7ddccc819b4ce4b091e826d1e26334601b0 + +2015-05-12 17:45 +0000 [b81353a0ec] Jonathan Rose + + * app_voicemail: fix moving when old messages full + + When completing voicemail playback of a message in the 'INBOX', the + message gets moved to the 'Old' messages folder. Without this patch, if + the 'Old' folder is already at its set limit, then the 'INBOX' message will + simply be deleted. With this patch, the flag to delete the message will be + removed if the save_to_folder function indicates that the message could + not be moved due to a full folder. + + ASTERISK-25082 #close + Reported by: Jonathan Rose + Review: https://gerrit.asterisk.org/#/c/448/ + + Change-Id: I2be440a09f42e2d06d50975c40d1ad7f836ecb3f + +2015-05-12 17:34 +0000 [523fab02d8] Richard Mudgett + + * chan_dahdi/sig_pri: Fix crash on ISDN call hangup collision. + + If an ISDN call is hungup by both sides at the same time a crash could + happen. + + * Added missing NULL checks for the owner channel after calling + pri_queue_pvt_cause_data() in two places. Code after those calls need to + check the owner channel pointer for NULL before use because + pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the + owner and the owner may get hung up. + + ASTERISK-21893 #close + Reported by: Alexandr Gordeev + + Change-Id: Ica3e266ebc7a894b41d762326f08653e1904bb9a + +2015-04-16 10:51 +0000 [b764454d4d] Kevin Harwell + + * bridge.c: NULL app causes crash during attended transfer + + Due to a race condition there was a chance that during an attended transfer the + channel's application would return NULL. This, of course, would cause a crash + when attempting to access the memory. This patch retrieves the channel's app + at an earlier time in processing in hopes that the app name is available. + However, if it is not then "unknown" is used instead. Since some string value + is now always present the crash can no longer occur. + + ASTERISK-24869 #close + Reported by: viniciusfontes + Review: + + Change-Id: I5134b84c4524906d8148817719d76ffb306488ac + +2015-05-06 13:24 +0000 [6433b697ae] Joshua Colp + + * res_pjsip_exten_state: Fix race condition between sending NOTIFY and termination + + The res_pjsip_exten_state module currently has a race condition between + processing the extension state callback from the PBX core and processing + the subscription shutdown callback from res_pjsip_pubsub. There is currently + no synchronization between the two. This can present a problem as while + the SIP subscription will remain valid the tree it points to may not. + This is in particular a problem as a task to send a NOTIFY may get queued + which will try to use the tree that may no longer be valid. + + This change does the following to fix this problem: + + 1. All access to the subscription tree is done within the task that + sends the NOTIFY to ensure that no other thread is modifying or + destroying the tree. This task executes on the serializer for the + subscriptions. + + 2. A reference to the subscription serializer is kept to ensure it + remains valid for the lifetime of the extension state subscription. + + 3. The NOTIFY task has been changed so it will no longer attempt + to send a NOTIFY if the subscription has already been terminated. + + ASTERISK-25057 #close + Reported by: Matt Jordan + + Change-Id: I0b3cd2fac5be8d9b3dc5e693aaa79846eeaf5643 + +2015-01-19 07:18 +0000 [bf31a486cb] Joshua Colp + + * res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions. + + The first thing this patch fixes is UAS dialogs. Previously if a transport was + configured on an endpoint and an inbound session was created there was no guarantee + that requests sent on the dialog would use the correct transport and address + information. This has now been fixed so an explicitly configured transport + is taken into account. + + The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed + module attempts to determine what transport a message should go out on and what + addressing information should go into the message itself. In a scenario where + multiple transports exist bound to the same IP address but a different port the + code would incorrectly alter the transport and change the message to the wrong + transport. This change makes the res_pjsip_multihomed module smarter so it will + only change the transport and address information in the message when it is + possible and makes sense. + + ASTERISK-24615 #close + Reported by: David Justl + + Change-Id: I5b57362201cc8c6555834ec8707e9fbddeff7904 + +2015-05-04 12:16 +0000 [7c687c8e54] Joshua Colp + + * stasis: Fix dial masquerade datastore lifetime + + A recent change went into Asterisk which added reference counts to the + channels stored in a dial masquerade datastore. Unfortunately this + included a reference to the caller in a dialing operation. While all + of the dialed targets have the datastore removed from them upon dialing + completion this did not occur for the caller, causing it to have a + reference to itself that could go never go away (as it depended on + the destruction of the datastore which only happened when the channel + was destroyed). This resulted in the caller channel remaining on the + system despite it having hung up. + + This change does the following to fix this issue: + + 1. The dial masquerade datastore is now removed from the caller upon + dialing completion, just like the dialed targets. + 2. Upon destruction of the caller all the dialed targets are also + removed from the dial masquerade datastore (just in case). + 3. The reference to the caller has been removed as it should not be + possible for the datastore to now be valid/useful after the lifetime + of the caller has ended. + + ASTERISK-25025 #close + + Change-Id: I1ef4ca5ca04980028604cc2af5d2992ac3431b3f + +2015-04-29 14:29 +0000 [0602409c89] Richard Mudgett + + * chan_dahdi: Add the chan_dahdi.conf force_restart_unavailable_chans option. + + Some telco switches occasionally ignore ISDN RESTART requests. The fix + for ASTERISK-19608 added an escape clause for B channels in the restarting + state if the telco ignores a RESTART request. If the telco fails to + acknowledge the RESTART then Asterisk will assume the telco acknowledged + the RESTART on the second call attempt requesting the B channel by the + telco. The escape clause is good for dealing with RESTART requests in + general but it does cause the next call for the restarting B channel to be + rejected if the telco insists the call must go on that B channel. + + chan_dahdi doesn't really need to issue a RESTART request in response to + receiving a cause 44 (Requested channel not available) code. Sending the + RESTART in such a situation is not required (nor prohibited) by the + standards. I think chan_dahdi does this for historical reasons to deal + with buggy peers to get channels unstuck in a similar fashion as the + chan_dahdi.conf resetinterval option. + + * Add the chan_dahdi.conf force_restart_unavailable_chans compatability + option that when disabled will prevent chan_dahdi from trying to RESTART + the channel in response to a cause 44 code. + + ASTERISK-25034 #close + Reported by: Richard Mudgett + + Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65 + +2015-04-30 15:20 +0000 [c6c06bbe70] Mark Michelson + + * Prevent potential crash on blond transfer. + + Scenario: + Alice calls Bob. Bob performs a blond transfer to Carol. Carol rejects + the incoming call (or some other immediate circumstance causes Carol not + to answer the call) + + What occurs in this case is that when the bridge between Alice and Bob + breaks, Alice is told to masquerade into Bob's channel that had placed + the call to Carol. The actual masquerade goes down without a hitch. + However, a channel fixup callback that attempts to publish dial events + over Stasis has a crash. The reason for this crash is that the datastore + on Bob's channel that placed the outbound call to Carol only had a bare + pointer to Carol's channel. Since Carol rejected the incoming call, + Carol's channel has been hung up and freed, meaning accessing her + channel results in a crash. + + The fix here is simple. The dial fixup code has been altered to hold + references to the involved channels and to drop those references when + freeing data. + + ASTERISK-25025 #close + Reported by Chet Stevens + + Change-Id: I54eedda207b8ec7a69263353b43abe5746aea197 + +2015-04-30 14:09 +0000 [08a4cf3237] Mark Michelson + + * res_pjsip_outbound_authenticator_digest: Add missing outbound authenticator callback. + + The Asterisk 13 version of the fix for outbound registration was missing + a key component that set the outbound authenticator's callback that + creates an authenticated request based on an old request. This was + picked up by some outbound registration tests failing in the testsuite. + + Change-Id: I5ca9379698c606da36bc38eaffccedaf64211ce3 +2015-04-30 06:04 +0000 [47df4e031c] Joshua Colp + + * res_pjsip_outbound_registration: Fix double unref on error return. + + When the PJSIP pjsip_regc_send function is invoked and an error + status returned the caller currently decrements the reference count + of the client state that it just incremented, assuming the + registration callback would not have been invoked. In practice + this is not correct. If the failure happens after the transaction + has been set up the callback will still be invoked. This will + cause the reference count to be incorrectly decremented twice, once + by the registration callback and second by the caller of + pjsip_regc_send. + + This change makes it so that whether the callback is invoked or + not is known by the caller of pjsip_regc_send. Depending on + this it can know whether it is responsible for decrementing the + reference count of the client state or not. + + ASTERISK-25037 #close + Reported by: Joshua Colp + + Change-Id: I749dc12f3a22115c49c5d7d95ff42a5fa45319de + +2015-04-27 16:56 +0000 [11d85ea251] Mark Michelson + + * res_pjsip_outbound_registration: Don't fail on delayed processing: 13. + + This is the Asterisk 13 version of a change to master that allows for + registration responses to be processed successfully potentially after + the original transaction has timed out. The main difference between this + and the master change is that the master version has API changes that + are unacceptable for 13. For 13, this is worked around by adding a new + API call that the outbound registration code uses instead. + + The following is the text from the master version of this commit: + + Odd behaviors have been observed during outbound registrations. The most + common problem witnessed has been one where a request with + authentication credentials cannot be created after receiving a 401 + response. Other behaviors include apparently processing an incorrect SIP + response. + + Inspecting the code led to an apparent issue with regards to how we + handle transactions in outbound registration code. When a response to a + REGISTER arrives, we save a pointer to the transaction and then push a + task onto the registration serializer. Between the time that we save the + pointer and push the task, it's possible for the transaction to be + destroyed due to a timeout. It's also possible for the address to be + reused by the transaction layer for a new transaction. + + To allow for authentication of a REGISTER request to be authenticated + after the transaction has timed out, we now also hold a reference to the + original REGISTER request instead of the transaction. The function for + creating a request with authentication has been altered to take the + original request instead of the transaction where the original request + was sent. + + ASTERISK-25020 + Reported by Mark Michelson + + Change-Id: If1ee5f601be839479a219424f0358a229f358f7c + +2015-04-27 14:44 +0000 [0037ca59a6] Mark Michelson + + * res_pjsip_outbound_registration: Add debugging messages. + + When problems occur regarding outbound registrations, it currently + is difficult to debug. Most off-nominal paths had warning messages, + but sometimes we want to know what's going on before hitting the + off-nominal path. This patch adds lots of debugging output that + should give a clearer picture of what is happening with regards + to outbound registrations. + + ASTERISK-25020 + Reported by Mark Michelson + + Change-Id: I577bde7860be0a6c872b5bcb4d5047340bf45d45 + +2015-04-11 10:10 +0000 [e84fcb2464] Juergen Spies (License 6698) + + * res/res_pjsip_t38: Add missing initialization of t38faxmaxdatagram + + Prior to this patch, the far_max_datagram value on the UDPTL structure would + remain -1 if the remote endpoint fails to provide the SDP media attribute + T38FaxMaxDatagram. This can result in the INVITE request being rejected. With + this patch, we will now properly initialize the value with either the default + value or with the value provided by pjsip.conf's t38_udptl_maxdatagram + parameter. + + Review: https://reviewboard.asterisk.org/r/4589 + + ASTERISK-24928 #close + Reported by: Juergen Spies + Tested by: Juergen Spies + patches: + pjsipT38patch20150331.txt submitted by Juergen Spies (License 6698) + + git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434688 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + Change-Id: I15bde169fd59a224a02005fec9a439f0679a375e + +2015-04-23 12:54 +0000 [008076ecf4] Mark Michelson + + * res_pjsip_t38: Don't crash on authenticated reinvite after originated T.38 FAX. + + When Asterisk originates a channel to an application, the channel is + hung up once the application finishes executing. When the application + in question is SendFax, the Asterisk PJSIP code will attempt to reinvite + the T.38 session to audio after the FAX completes. The hangup of the + channel happens in the midst of this reinvite transaction. In most + circumstances, this works out okay because the BYE is delayed until the + reinvite transaction can complete. + + However, if the reinvite that Asterisk sends receives a 401/407 + response, then Asterisk's attempt to re-send the reinvite with + authentication will fail. This is because the session supplement in + res_pjsip_t38 makes the assumption that the channel on the session will + always be non-NULL. Since the channel has been hung up, though, the + channel is now NULL. Attempting to operate on the channel causes a + crash. + + This patch fixes the issue by ensuring that the channel on the session + is not NULL before attempting to mess with the T.38 framehook. + + This patch also contains some corrections for comments that were + incorrect and really confused me when I first started looking at the + code. + + ASTERISK-25004 #close + Reported by Mark Michelson + + Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0 + +2015-04-15 10:38 +0000 [1bb6122f35] Mark Michelson + + * 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 + +2015-04-15 16:08 +0000 [cb67aae596] gtjoseph + + * More .gitignore updates + + Added .pyc and .sha1 to the top-level .gitignore. + + Change-Id: I7dfc4f554d54d22947b38140d3305007503cc16a + Tested-by: George Joseph + +2015-04-13 19:06 +0000 [70fab74baf] gtjoseph + + * .gitignore updates for master/13 + + Added products of ./bootstrap + + Added nmenuselect and gmenuselect to menuselect/ + + Change-Id: Ied658463958bafc04a9aff9ebc28e40c116a6e35 + +2015-04-13 09:54 +0000 [735bea479a] Matt Jordan + + * build_tools/make_version: Update version parsing for Git migration + + External systems - such as the Asterisk Test Suite - require knowledge of the + upstream branch. Unfortunately, after moving to Git, the Asterisk version + currently consists of only a 'GIT" prefix followed by an object blob, + e.g., GIT-as08d7. This makes it difficult for such systems to know what + features are available in a particular check out of Asterisk. + + This patch fixes this by hardcoding the branch in a variable in the + make_version script. Since the mainline branches are not changed often - + typically only once a year - this is a reasonable approach to solving + the problem, and is more reliable than parsing the output of 'git branch + -vv'. Branches that track off of an upstream primary branch will then get the + benefit of knowing which mainline branch they are currently based off + of. + + ASTERISK-24954 #close + + Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799 + +2015-04-12 12:59 +0000 [7d64479748] Matt Jordan + + * git migration: Remove support for file versions + + 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: + * main/asterisk: + - Refactor the file_version structure to reflect that it no longer + tracks a version field. + - Alter the "core show file version" CLI command such that it always + reports the version of Asterisk. The file version is no longer + available. + + * main/manager: The Version key now always reports the Asterisk version. + + * UPGRADE: Add notes for: + - Modification to the ModuleCheck AMI Action. + - Modification of the "core show file version" CLI command. + + Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28 + +2015-04-12 06:12 +0000 [9237e8b11e] Corey Farrell + + * main/editline: Add .gitignore. + + This patch adds a .gitignore for main/editline to ignore all build results. + + Change-Id: I68c7bf375ea46282689e5a706534b69fca233b5d + +2015-04-11 23:22 +0000 [630dbcb8b4] Matt Jordan + + * .gitignore: Ignore tarballs (*.gz) + + This patch updates the root .gitignore file to ignore files with a .gz + extension. This will cause git to ignore downloaded sound tarballs in + the the sounds/ directory. + + Change-Id: I1e42fbfa02a8884231507b683e8e49ac3e278aaa + +2015-04-11 13:20 +0000 [e4892f9aa4] gtjoseph + + * Add .gitignore and .gitreview files + + Add the .gitignore and .gitreview files to the asterisk repo. + + NB: You can add local ignores to the .git/info/exclude file + without having to do a commit. + + Common ignore patterns are in the top-level .gitignore file. + Subdirectory-specific ignore patterns are in their own .gitignore + files. + + Change-Id: I4c8af3b8e3739957db545f7368ac53f38e99f696 + Tested-by: George Joseph + +2015-04-14 14:04 +0000 [677898f839] Joshua Colp + + * res_pjsip_mwi: Send unsolicited MWI NOTIFY on startup and when endpoint registers. + + Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon + a mailbox state change (such as a new message being left, or one being deleted). + In practice this is not sufficient to keep clients aware of the current MWI status. + + This change makes the module send unsolicited MWI NOTIFY on startup so that + clients are guaranteed to have the most up to date MWI information. It also makes + clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware + of the current MWI status they receive it. + + ASTERISK-24982 #close + Reported by: Joshua Colp + + Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58 + +2015-04-08 13:19 +0000 [918ca7dd36] Jonathan Rose + + * res_pjsip_t38: Fix FAX failures when using PJSIP with authentication + + Without this patch, if a PJSIP endpoint with udptl enabled and authentication + set attempted to use sendFax, the FAX session would fail during setup. This + was because the invite issued in response to being auth challenged would cause + the PJSIP channel performing the FAX to receive a second T38 framehook and + this would cause frames to be consumed in an inappropriate manner. + + ASTERISK-24933 #close + Reported by: Jonathan Rose + Review: https://reviewboard.asterisk.org/r/4577/ + ........ + + Merged revisions 434425 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434428 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-08 12:24 +0000 [08945a5c77] Maciej Szmigiero (license 6085) + + * Security/tcptls: MitM Attack potential from certificate with NULL byte in CN. + + When registering to a SIP server with TLS, Asterisk will accept CA signed + certificates with a common name that was signed for a domain other than the + one requested if it contains a null character in the common name portion of + the cert. This patch fixes that by checking that the common name length + matches the the length of the content we actually read from the common name + segment. Some certificate authorities automatically sign CA requests when + the requesting CN isn't already taken, so an attacker could potentially + register a CN with something like www.google.com\x00www.secretlyevil.net + and have their certificate signed and Asterisk would accept that certificate + as though it had been for www.google.com - this is a security fix and is + noted in AST-2015-003. + + ASTERISK-24847 #close + Reported by: Maciej Szmigiero + Patches: + asterisk-null-in-cn.patch submitted by mhej (license 6085) + ........ + + Merged revisions 434337 from http://svn.asterisk.org/svn/asterisk/branches/1.8 + ........ + + Merged revisions 434338 from http://svn.asterisk.org/svn/asterisk/branches/11 + ........ + + Merged revisions 434384 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434418 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-07 10:35 +0000 [45f09898e9] Mark Michelson + + * Do not queue message requests that we do not respond to. + + If we receive a MESSAGE request that we cannot send a response + to, we should not send the incoming MESSAGE to the dialplan. + + This commit should help the bouncing message_retrans test to + pass consistently. + ........ + + Merged revisions 434218 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@434220 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-03 16:59 +0000 [42b7ebdd4d] Mark Michelson + + * res_pjsip_messaging: Serialize outbound SIP MESSAGEs + + Outbound SIP MESSAGEs had the potential to be sent out + of order from how they were specified in a set of + dialplan steps. + + This change creates a serializer for sending outbound + MESSAGE requests on. This ensures that the MESSAGEs are + sent by Asterisk in the same order that they were sent + from the dialplan. + + ASTERISK-24937 #close + Reported by Mark Michelson + + Review: https://reviewboard.asterisk.org/r/4579 + ........ + + Merged revisions 433968 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433970 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-01 15:32 +0000 [b6fff2719d] Mark Michelson + + * core: avoid possible asterisk -r crash from long id + + 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/ + + AFS-254 + ........ + + Merged revisions 429223 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433918 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-01 11:29 +0000 [8ae3670781] Ashley Sanders + + * stasis: set a channel variable on websocket disconnect error + + Resolve compile errors caused by r433863 by fixing the + documentation xml to comply with the schema. + ........ + + Merged revisions 433888 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433890 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-31 22:39 +0000 [259227eb1a] Ashley Sanders + + * stasis: set a channel variable on websocket disconnect error + + Resolve compile errors caused by r433839 by included the missing + header file, pbx.h. + ........ + + Merged revisions 433863 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433864 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-31 17:34 +0000 [758fead630] Ashley Sanders + + * stasis: set a channel variable on websocket disconnect error + + When an error occurs while writing to a web socket, the web socket is + disconnected and the event is logged. A side-effect of this, however, is that + any application on the other side waiting for a response from Stasis is left + hanging indefinitely (as there is no mechanism presently available for + notifying interested parties about web socket error states in Stasis). + + To remedy this scenario, this patch introduces a new channel variable: + STASISSTATUS. + + The possible values for STASISSTATUS are: + SUCCESS - The channel has exited Stasis without any failures + FAILED - Something caused Stasis to croak. Some (not all) possible + reasons for this: + - The app registry is not instantiated; + - The app requested is not registered; + - The app requested is not active; + - Stasis couldn't send a start message + + ASTERISK-24802 + Reported By: Kevin Harwell + Review: https://reviewboard.asterisk.org/r/4519/ + ........ + + Merged revisions 433839 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433842 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-27 15:55 +0000 [b5b44876c2] Mark Michelson + + * Add stateful PJSIP response API call, and use it for out-of-dialog responses. + + Asterisk had an issue where retransmissions of MESSAGE requests resulted in + Asterisk processing the retransmission as if it were a new MESSAGE request. + + This patch fixes the issue by creating a transaction in PJSIP on the incoming + request. This way, if a retransmission arrives, the PJSIP transaction layer + will resend the response and Asterisk will not ever see the retransmission. + + ASTERISK-24920 #close + Reported by Mark Michelson + + Review: https://reviewboard.asterisk.org/r/4532/ + ........ + + Merged revisions 433619 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433621 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-27 15:25 +0000 [66b8c7cab4] Richard Mudgett + + * res_pjsip_registrar_expire.c: Cleanup scheduler leaks on unload/shutdown. + + Contact expiration object refs were leaked when the module was unloaded. + + * Made empty the scheduler of entries before destroying it to release the + object ref held by the scheduler entry. + + Review: https://reviewboard.asterisk.org/r/4523/ + ........ + + Merged revisions 433596 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433618 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-20 14:57 +0000 [fb7062afca] Richard Mudgett + + * Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks. + + Valgrind found some memory leaks associated with + ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending + responses to OPTIONS requests, processing MESSAGE requests, and + res_pjsip supplements implementing the incoming_request callback. + + * Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in + res/res_pjsip.c:supplement_on_rx_request(), + res/res_pjsip/pjsip_options.c:send_options_response(), + res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and + res/res_pjsip_messaging.c:send_response(). + + * Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in + res/res_pjsip_nat.c:nat_on_rx_message(). + + * Fixed inconsistent but benign return value in + res/res_pjsip/pjsip_options.c:options_on_rx_request(). + + Review: https://reviewboard.asterisk.org/r/4511/ + ........ + + Merged revisions 433222 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433224 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-20 14:04 +0000 [cf9799845f] Richard Mudgett + + * res_pjsip_sdp_rtp,sorcery: Fix invalid access and memory leak respectively. + + Valgrind found a memory leak and invalid access. + + * Fix invalid access by sscanf() being fed a non-nul terminated string of + digits in res/res_pjsip_sdp_rtp.c:get_codecs(). + + * Fix memory leak in main/sorcery.c:sorcery_object_field_destructor(). + + * Fix potential NULL pointer dereference in + main/xmldoc.c:xmldoc_get_syntax_config_option(). + + Review: https://reviewboard.asterisk.org/r/4513/ + ........ + + Merged revisions 433199 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433201 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-17 16:56 +0000 [90fc65da62] Richard Mudgett + + * Audit ast_sockaddr_resolve() usage for memory leaks. + + Valgrind found some memory leaks associated with ast_sockaddr_resolve(). + Most of the leaks had already been fixed by earlier memory leak hunt + patches. This patch performs an audit of ast_sockaddr_resolve() and found + one more. + + * Fix ast_sockaddr_resolve() memory leak in + apps/app_externalivr.c:app_exec(). + + * Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs + parameter for safety so the pointer will never be uninitialized on return. + The same goes for res/res_pjsip_acl.c:extract_contact_addr(). + + * Made functions that call ast_sockaddr_resolve() with RAII_VAR() + controlling the addrs variable use ast_free instead of ast_free_ptr to + provide better MALLOC_DEBUG information. + + Review: https://reviewboard.asterisk.org/r/4509/ + ........ + + Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11 + ........ + + Merged revisions 433057 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433059 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-17 13:44 +0000 [e0b644ddb7] Kevin Harwell + + * res_pjsip: Allow configuration of endpoint identifier query order + + Updated some documentation stating that endpoint identifiers registered without + a name are place at the front of the lookup list. Also renamed register method + 'ast_sip_register_endpoint_identifier_by_name' to + 'ast_sip_register_endpoint_identifier_with_name' + + ASTERISK-24840 + Reported by: Mark Michelson + ........ + + Merged revisions 433031 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433034 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-17 13:43 +0000 [d7c8041f6b] Kevin Harwell + + * res_pjsip: Allow configuration of endpoint identifier query order + + This patch fixes previously reverted code that caused binary incompatibility + problems with some modules. And like the original patch it makes sure that + no matter what order the endpoint identifier modules were loaded, priority is + given based on the ones specified in the new global 'endpoint_identifier_order' + option. + + ASTERISK-24840 + Reported by: Mark Michelson + Review: https://reviewboard.asterisk.org/r/4489/ + ........ + + Merged revisions 433028 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433033 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-17 11:25 +0000 [cd4e18c4cc] Richard Mudgett + + * Multiple revisions 431583,433005 + + ........ + r431583 | sgriepentrog | 2015-02-06 15:26:12 -0600 (Fri, 06 Feb 2015) | 10 lines + + various: cleanup issues found during leak hunt + + In this collection of small patches to prevent + Valgrind errors are: fixes for reference leaks + in config hooks, evaluating a parameter beyond + bounds, and accessing a structure after a lock + where it could have been already free'd. + + Review: https://reviewboard.asterisk.org/r/4407/ + ........ + r433005 | rmudgett | 2015-03-17 11:10:39 -0500 (Tue, 17 Mar 2015) | 1 line + + res_pjsip: Add reason comment. + ........ + + Merged revisions 431583,433005 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@433025 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-13 10:51 +0000 [6cd70450fd] Kevin Harwell + + * Revert - res_pjsip: Allow configuration of endpoint identifier query order + + Due to a break in binary compatibility with some other modules these changes + are being reverted until the issue can be resolved. + + ASTERISK-24840 + Reported by: Mark Michelson + ........ + + Merged revisions 432868 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432888 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-09 11:44 +0000 [4eb1dd4b35] Kevin Harwell + + * res_pjsip: Allow configuration of endpoint identifier query order + + It's possible to have a scenario that will create a conflict between endpoint + identifiers. For instance an incoming call could be identified by two different + endpoint identifiers and the one chosen depended upon which identifier module + loaded first. This of course causes problems when, for example, the incoming + call is expected to be identified by username, but instead is identified by ip. + This patch adds a new 'global' option to res_pjsip called + 'endpoint_identifier_order'. It is a comma separated list of endpoint + identifier names that specifies the order by which identifiers are processed + and checked. + + ASTERISK-24840 #close + Reported by: Mark Michelson + Review: https://reviewboard.asterisk.org/r/4455/ + ........ + + Merged revisions 432638 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432658 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-04 12:53 +0000 [52366a423c] Matt Jordan + + * translate: Prevent invalid memory accesses on fast shutdown + + When a 'core restart now' or 'core stop now' is executed and a channel is + currently in a media operation, the translator matrix can be destroyed while a + channel is currently blocked on getting the best translation choice + (see ast_translator_best_choice). When the channel gets the mutex, the + translation matrix now has invalid memory, and Asterisk crashes. + + This patch does two things: + (1) We now only clean up the translation matrix on a graceful shutdown. In that + case, there are no channels, and so there is no risk of this occurring. + (2) We also now set the __matrix and __indextable to NULL. In some initial + backtraces when this occurred, it looked as if there was a memory corruption + occurring, and it wasn't until we determined that something had restarted + Asterisk that the issue became clear. By setting these to NULL on shutdown, + it becomes a bit easier to determine why a crash is occurring. + + Note that we could litter the code with NULL checks on the __matrix, but the + act of making the translation matrix cleaned up on shutdown should preclude + this issue from occurring in the first place, and this part of the code needs + to be as fast as possible. + + Review: https://reviewboard.asterisk.org/r/4457/ + ........ + + Merged revisions 432453 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432454 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-03-02 13:15 +0000 [b17d0953b6] Matt Jordan + + * res/res_pjsip_sdp_rtp: Revert portion of r432195 + + Unfortunately, while initial testing with ConfBridge did not reproduce the + audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing + did show that bridge_softmix and/or ConfBridge has a severe problem bridging + two or more participants at different sampling rates. Sometimes, it even picks + odd sampling rates that cause hideous audio problems. + + This patch backs out the offending portion of the code until the issues in + the affected bridging modules can be more properly analyzed. + + ASTERISK-24841 + ........ + + Merged revisions 432423 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@432424 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-26 11:15 +0000 [3b4ba353f0] Kevin Harwell + + * 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/certified/branches/13.1@432365 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-24 16:01 +0000 [33c73ffeaa] Matt Jordan + + * 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/certified/branches/13.1@432197 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-11 12:04 +0000 [3ad393b043] Kevin Harwell + + * res_pjsip: dtls_handler causes Asterisk to crash + + There have been a couple of times where a crash occurred in the dtls_handler + section of the code for res_pjsip. Unfortunately, in working this issue the + problem was unable to be reproduced. After looking at the backtraces and + through the code the current best guess as to why this happened might be due + to a reentrance problem and the strtok function. So, the current fix is to + convert the strtok function into the reentrant version of the function, + strtok_r. + + ASTERISK-24741 #close + Reported by: Zane Conkle + Review: https://reviewboard.asterisk.org/r/4409/ + ........ + + Merged revisions 431698 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431700 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-11 11:52 +0000 [8be00450b9] Kevin Harwell + + * res_http_websocket: websocket write timeout fails to fully disconnect + + When writing to a websocket if a timeout occurred the underlying socket did not + get closed/disconnected. This patch makes sure the websocket gets disconnected + on a write timeout. Also a notice is logged stating that the websocket was + disconnected. + + ASTERISK-24701 #close + Reported by: Matt Jordan + Review: https://reviewboard.asterisk.org/r/4412/ + ........ + + Merged revisions 431669 from http://svn.asterisk.org/svn/asterisk/branches/11 + ........ + + Merged revisions 431670 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431697 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-11 11:48 +0000 [340588c721] Richard Mudgett + + * 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/certified/branches/13.1@431696 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-11 10:19 +0000 [69dc8f9ec2] Kevin Harwell + + * pjsip_options: Fix continued qualifies after endpoint/aor deletion + + If you remove an endpoint/aor from pjsip.conf then do a core reload, + qualifies will continue even though the object are gone. This happens + because nothing clears out the qualify tasks. + + This patch unschedules all existing qualify tasks before scheduling + new ones on reload. + + Tested-by: George Joseph + + Review: https://reviewboard.asterisk.org/r/4290/ + ........ + + Merged revisions 430064 from http://svn.asterisk.org/svn/asterisk/branches/13 + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431667 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-02-05 09:50 +0000 [2125e1b2de] Mark Michelson + + * Add Asterisk 13 revision 431420 that fixes disabling 100rel option on PJSIP endpoints. + + + + git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/13.1@431573 65c4cc65-6c06-0410-ace0-fbb531ad65f3 + +2015-04-08 Asterisk Development Team + + * Certified Asterisk 13.1-cert2 Released. + + * Mitigate MitM attack potential from certificate with NULL byte in CN. + + When registering to a SIP server with TLS, Asterisk will accept CA + signed certificates with a common name that was signed for a domain + other than the one requested if it contains a null character in the + common name portion of the cert. This patch fixes that by checking + that the common name length matches the the length of the content we + actually read from the common name segment. Some certificate + authorities automatically sign CA requests when the requesting CN + isn't already taken, so an attacker could potentially register a CN + with something like www.google.com\x00www.secretlyevil.net and have + their certificate signed and Asterisk would accept that certificate + as though it had been for www.google.com. + + ASTERISK-24847 #close + Reported by: Maciej Szmigiero + patches: + asterisk-null-in-cn.patch uploaded by mhej (license 6085) + + AST-2015-003 + +2015-01-30 Asterisk Development Team + + * Certified Asterisk 13.1-cert1 Released. + +2015-01-30 17:53 +0000 [r431494] Richard Mudgett + + * apps/app_agent_pool.c, /: app_agent_pool: Fix initial module load + agent device state reporting. When the app_agent_pool module + initially loads there is a race condition between the thread + loading agents.conf and the device state internal processing + thread. If the device state internal processing thread handles + the agent creation state updates before the thread that loaded + agents.conf registers the device state provider callback then the + cached agent state is "Invalid". When a consumer module like + app_queue asks for the agent state it gets the cached "Invalid" + state instead of the real state from the provider. * Moved + loading the agents.conf configuration to the last thing setup by + app_agent_pool in load_module(). Now the device state provider + callback is registered before the config is loaded so the agent + creation state updates are guaranteed to get the initial device + state. * Removed some now redundant config cleanup on error in + load_config(). * Added lock protection when accessing the device + state in agent_pvt_devstate_get() and eliminated the RAII_VAR() + usage. ASTERISK-24737 #close Reported by: Steve Pitts Review: + https://reviewboard.asterisk.org/r/4390/ ........ Merged + revisions 431492 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-30 16:50 +0000 [r431470] Mark Michelson + + * main/stasis_channels.c, channels/chan_pjsip.c, main/xmldoc.c, + res/res_pjsip_refer.c, main/pbx.c, main/manager.c, + pbx/pbx_spool.c, /, main/bridge_after.c: Fix some memory leaks. + These memory leaks were found and fixed by John Hardin. I'm just + committing them for him. ASTERISK-24736 #close Reported by Mark + Michelson Review: https://reviewboard.asterisk.org/r/4389 + ........ Merged revisions 431468 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-30 16:41 +0000 [r431467] Jonathan Rose + + * main/manager.c, /: Merge r431153 from asterisk/branches/13 + r431153 | jrose | 2015-01-27 11:22:52 -0600 (Tue, 27 Jan 2015) | + 9 lines Manager: Fix Manager Action ModuleLoad to give correct + response when reloading Prior to this patch, ModuleLoad would + respond with an error indicating that the requested module wasn't + found in spite of finding and reloading the module. Review: + https://reviewboard.asterisk.org/r/4373/ ASTERISK-24721 #close + +2015-01-28 21:53 +0000 [r431326-431334] Mark Michelson + + * funcs/func_curl.c, /: Multiple revisions 431297-431298 ........ + r431297 | mmichelson | 2015-01-28 11:05:26 -0600 (Wed, 28 Jan + 2015) | 17 lines Mitigate possible HTTP injection attacks using + CURL() function in Asterisk. CVE-2014-8150 disclosed a + vulnerability in libcURL where HTTP request injection can be + performed given properly-crafted URLs. Since Asterisk makes use + of libcURL, and it is possible that users of Asterisk may get + cURL URLs from user input or remote sources, we have made a patch + to Asterisk to prevent such HTTP injection attacks from + originating from Asterisk. ASTERISK-24676 #close Reported by Matt + Jordan Review: https://reviewboard.asterisk.org/r/4364 + AST-2015-002 ........ r431298 | mmichelson | 2015-01-28 11:12:49 + -0600 (Wed, 28 Jan 2015) | 3 lines Fix compilation error from + previous patch. ........ Merged revisions 431297-431298 from + http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged + revisions 431299 from + http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged + revisions 431301 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * res/res_pjsip_t38.c, res/res_pjsip_session.c, /, + res/res_pjsip_sdp_rtp.c: Fix file descriptor leak in RTP code. + SIP requests that offered codecs incompatible with configured + values could result in the allocation of RTP and RTCP ports that + would not get reclaimed later. ASTERISK-24666 #close Reported by + Y Ateya Review: https://reviewboard.asterisk.org/r/4323 + AST-2015-001 ........ Merged revisions 431300 from + http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged + revisions 431303 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-28 04:11 +0000 [r431244] Richard Mudgett + + * /, res/res_pjsip_outbound_registration.c, res/res_pjsip.c, + main/sorcery.c: res_pjsip_outbound_registration: Fix reload race + condition. Performing a CLI "module reload" command when there + are new pjsip.conf registration objects defined frequently failed + to load them correctly. What happens is a race condition between + res_pjsip pushing its reload into an asynchronous task processor + task and the thread that does the rest of the reloads when it + gets to reloading the res_pjsip_outbound_registration module. A + similar race condition happens between a reload and the CLI/AMI + show registrations commands. The reload updates the + current_states container and the CLI/AMI commands call + get_registrations() which builds a new current_states container. + * Made res_pjsip.c reload_module() use + ast_sip_push_task_synchronous() instead of ast_sip_push_task() to + eliminate two threads processing config reloads at the same time. + * Made get_registrations() not replace the global current_states + container so the CLI/AMI show registrations command cannot + interfere with reloading. You could never add/remove objects in + the container without the possibility of the container being + replaced out from under you by get_registrations(). * Added a + registration loaded sorcery instance observer to purge any dead + registration objects since get_registrations() cannot do this job + anymore. The struct ast_sorcery_instance_observer callbacks must + be used because the callback happens inline with the load + process. The struct ast_sorcery_observer callbacks are pushed to + a different thread. * Added some global current_states NULL + pointer checks in case the container disappears because of + unload_module(). * Made sorcery's struct + ast_sorcery_instance_observer.object_type_loaded callbacks + guaranteed to be called before any struct + ast_sorcery_observer.loaded callbacks will be called. * Moved the + check for non-reloadable objects to before the sorcery instance + loading callbacks happen to short circuit unnecessary work. + Previously with non-reloadable objects, the sorcery instance + loading/loaded callbacks would always happen, the individual + wizard loading/loaded would be prevented, and the non-reloadable + type logging message would be logged for each associated wizard. + ASTERISK-24729 #close Review: + https://reviewboard.asterisk.org/r/4381/ ........ Merged + revisions 431243 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-27 23:02 +0000 [r431200-431221] Kevin Harwell + + * main/tcptls.c, /: tcptls: Bad file descriptor error when + reloading chan_sip While running through some scenarios using + chan_sip and tcp a problem would occur that resulted in a flood + of bad file descriptor messages on the cli: tcptls.c:712 + ast_tcptls_server_root: Accept failed: Bad file descriptor The + message is received because the underlying socket has been + closed, so is valid. This is probably happening because unloading + of chan_sip is not atomic. That however is outside the scope of + this patch. This patch simply stops the logging of multiple + occurrences of that message. ASTERISK-24728 #close Reported by: + Thomas Thompson Review: https://reviewboard.asterisk.org/r/4380/ + ........ Merged revisions 431218 from + http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged + revisions 431219 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, channels/chan_sip.c: chan_sip: stale nonce causes failure When + refreshing (with a small expiration) a registration that was sent + to chan_sip the nonce would be considered stale and reject the + registration. What was happening was that the initial + registration's "dialog" still existed in the dialogs container + and upon refresh the dialog match algorithm would choose that as + the "dialog" instead of the newly created one. This occurred + because the algorithm did not check to see if the from tag + matched if authentication info was available after the 401. So, + it ended up assuming the original "dialog" was a match and + stopped the search. The old "dialog" of course had an old nonce, + thus the stale nonce message. This fix attempts to leave the + original functionality alone except in the case of a REGISTER. If + a REGISTER is received if searches for an existing "dialog" + matching only on the callid. If the expires value is low enough + it will reuse dialog that is there, otherwise it will create a + new one. ASTERISK-24715 #close Reported by: John Bigelow Review: + https://reviewboard.asterisk.org/r/4367/ ........ Merged + revisions 431187 from + http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged + revisions 431194 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-27 17:52 +0000 [r431162] Richard Mudgett + + * /, apps/confbridge/include/confbridge.h, apps/app_confbridge.c: + app_confbridge: Repeatedly starting and stopping recording ref + leaks the recording channel. Starting and stopping conference + recording more than once causes the recording channels to be + leaked. For v13 the channels also show up in the CLI "core show + channels" output. * Reworked and simplified the recording channel + code to use ast_bridge_impart() instead of managing the recording + thread in the ConfBridge code. The recording channel's ref + handling easily falls into place and other off nominal code paths + get handled better as a result. ASTERISK-24719 #close Reported + by: John Bigelow Review: https://reviewboard.asterisk.org/r/4368/ + Review: https://reviewboard.asterisk.org/r/4369/ ........ Merged + revisions 431135 from + http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged + revisions 431160 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-27 17:35 +0000 [r431159] Joshua Colp + + * res/res_pjsip_sdp_rtp.c, main/bridge_channel.c, /: bridge / + res_pjsip_sdp_rtp: Fix issues with media not being reinvited + during direct media. This change fixes two issues: 1. During a + swap operation bridging added the new channel before having the + swap channel leave. This was not handled in bridge_native_rtp and + could result in a channel not getting reinvited back to Asterisk. + After this change the swap channel will leave first and the new + channel will then join. 2. If a re-invite was received after a + session had been established any upstream elements (such as + bridge_native_rtp) were not notified that they may want to + re-evaluate things. After this change an UPDATE_RTP_PEER control + frame is queued when this situation occurs and upstream can + react. AST-1524 #close Review: + https://reviewboard.asterisk.org/r/4378/ ........ Merged + revisions 431157 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-27 17:18 +0000 [r431140] Matthew Jordan + + * /, apps/confbridge/include/confbridge.h, + apps/confbridge/conf_config_parser.c: app_confbridge: Restore + user's menu name to CLI output of 'confbridge list' When issuing + a 'confbridge list XXXX' CLI command, the resulting output no + longer displays the menu associated with a ConfBridge + participant. The issue was caused by ASTERISK-22760. When that + patch was done, it removed the copying of the menu name + associated with the user from the actual user profile. This patch + fixes the issue by copying the menu name over to the user profile + when the menu hooks are applied to the user. Since that function + now does a little bit more than just apply the hooks, the name of + the function has been changed to cover the copying of the menu + name over as well. In addition, there is a disparity between the + menu name length as it is stored on the conf_menu structure and + the confbridge_user structure; this patch makes the lengths match + so that a strcpy can be used. Review: + https://reviewboard.asterisk.org/r/4372/ ASTERISK-24723 #close + Reported by: Steve Pitts ........ Merged revisions 431134 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-27 11:48 +0000 [r431116] Joshua Colp + + * res/parking/parking_manager.c, /: res_parking: Fix crash due to + race condition when unloading. There is currently a race + condition when unloading the res_parking module. Depending on the + will of the universe the subscription invocation may occur AFTER + the module is unloaded. This is because the module does NOT use + stasis_unsubscribe_and_join when terminating the subscription. It + merely uses stasis_unsubscribe. This change makes it use + stasis_unsubscribe_and_join which is documented for usage in this + exact scenario. AST-1520 #close Review: + https://reviewboard.asterisk.org/r/4375/ ........ Merged + revisions 431114 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-23 15:24 +0000 [r431016] Kevin Harwell + + * res/res_ari_events.c, include/asterisk/stasis_app.h, + res/res_pjsip_mwi.c, res/parking/parking_applications.c, + channels/chan_iax2.c, res/res_pjsip/pjsip_global_headers.c, + res/res_pjsip_pubsub.c, res/res_ari_channels.c, res/res_stasis.c, + rest-api-templates/param_parsing.mustache, /, + res/res_ari_endpoints.c: Investigate and fix memory leaks in + Asterisk Fixed memory leaks that were found in Asterisk. + ASTERISK-24693 #close Reported by: Kevin Harwell Review: + https://reviewboard.asterisk.org/r/4347/ ........ Merged + revisions 430999 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-21 19:47 +0000 [r430898] Richard Mudgett + + * CHANGES, /, res/res_pjsip_outbound_registration.c: Multiple + revisions 430223,430373,430395 ........ r430223 | gtjoseph | + 2015-01-06 11:35:21 -0600 (Tue, 06 Jan 2015) | 24 lines + outbound_registration: Add 'pjsip send register' and update 'send + unregister' The current behavior of 'pjsip send unregister' is to + send the unregister (REGISTER with 0 exp) but let the next + scheduled register proceed normally. I don't think that's a good + idea. If you unregister, it should stay unregistered until you + decide to start registrations again. So this patch just adds a + cancel_registration call to the current unregister_task to cancel + the timer. Of course, now you need a way to start registration + again so I've added a 'pjsip send register' command that + unregisters and cancels any existing registration (the same as + send unregister), then sends an immediate registration and starts + the timer back up again. Both changes also ripple to AMI. There's + a new PJSIPRegister command. There's no harm in calling either + command repeatedly. They don't care about the actual state. + Tested-by: George Joseph Review: + https://reviewboard.asterisk.org/r/4301/ ........ r430373 | + gtjoseph | 2015-01-08 11:48:29 -0600 (Thu, 08 Jan 2015) | 25 + lines res_pjsip_outbound_registration: Fix several reload issues + There are 2 issues with reloading registrations... 1. The + 'can_reuse_registration' test wasn't considering the intervals or + expiration in its determination of whether a registration changed + or not so if you changed any of the intervals or the expiration + and reloaded, the object would get reloaded but the actual timers + wouldn't change. can_reuse_registration now does a sorcery diff + on the old and new objects instead of discretely testing certain + fields. Now if you change expiration for instance, and reload, + the timer is updated and re-registration will occur on the new + value. 2. If you mung up your password on an outbound + registration you get a permanent failure. If you fix the password + (on the outbound_auth object) and reload, nothing tells + outbound_registration to try again because the registration + itself didn't change. This patch adds an observer on the "auth" + object type and if any auth changes, existing registration states + are searched and those in a REJECTED_PERMANENT state are retried. + Tested-by: George Joseph Review: + https://reviewboard.asterisk.org/r/4304/ ........ r430395 | + gtjoseph | 2015-01-08 15:37:42 -0600 (Thu, 08 Jan 2015) | 14 + lines res_pjsip_outbound_registration: Fix reference leak. Every + time a registration started, + sip_outbound_registration_response_cb bumps the ref count on + client_state then pushes a handle_registration_response task. + handle_registration_response never unreffed it though. So every + time a registration goes out, the ref count goes up by one. This + patch adds the unreffs to handle_registration_response. + Tested-by: George Joseph Review: + https://reviewboard.asterisk.org/r/4303/ ........ Merged + revisions 430223,430373,430395 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-21 13:36 +0000 [r430843-430865] Matthew Jordan + + * /, channels/chan_sip.c: channels/chan_sip: Fix registration leak + during reload When the SIP registrations were migrated to using + ao2 in what was then trunk, the explicit destruction of the + registrations on module reload was removed and not replaced with + an ao2 equivalent. Debugging done by Stefan Engström, the issue + reporter, on ASTERISK-24673 confirmed that the reference in the + registry_list container was being leaked. Since the purpose of + cleanup_all_regs is to prep a registration for destruction, this + function now calls an ao2_callback function callback with the + OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the + registrations. This cleans up each registration, and also removes + it from the registration container registry_list. Review: + https://reviewboard.asterisk.org/r/4355/ ASTERISK-24640 #close + Reported by: Max Man ASTERISK-24673 #close Reported by: Stefan + Engström Tested by: Stefan Engström ........ Merged revisions + 430864 from http://svn.asterisk.org/svn/asterisk/branches/13 + + * apps/app_dial.c, /: apps/app_dial: Don't publish DialEnd twice on + unexpected GoSub/Macro values The Dial application has some + interesting options with the mid-call Macro (M) and GoSub (U) + options. If the MACRO_RESULT/GOSUB_RESULT returns specific + values, the Dial application will take some action upon the + channels involved in the dial operation (such as hanging up a + particular party, etc.) The Dial application ensures that a + Stasis message is published in the event that + MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial + operation, so that there is a corresponding DialEnd event + published in AMI/ARI for the DialBegin event that preceeded it. A + bug exists where that same DialEnd event will be published on + Stasis even if the value returned in MACRO_RESULT/GOSUB_RESULT is + not one that the Dial application cares about. This causes two + DialEnd events to be published - one with the + MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is + all sorts of wrong. This patch fixes the bug by ensuring that we + only publish a DialEnd message to Stasis if the Dial + application's mid-call Macro/GoSub returns something that Dial + cares about. Review: https://reviewboard.asterisk.org/r/4336 + ASTERISK-24682 #close Reported by: Matt Jordan ........ Merged + revisions 430842 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-19 18:18 +0000 [r430782] Mark Michelson + + * main/pbx.c, /: Call extension state callbacks at hint creation. + 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 + +2015-01-15 12:11 +0000 [r430666] Joshua Colp + + * /, res/res_pjsip_outbound_registration.c: + res_pjsip_outbound_registration: Fix race condition when + reloading and listing registrations. Due to the split of outbound + registration state from configuration it is possible during a + reload for a "pjsip show registrations" CLI command to be + executed which gets an older snapshot of the configuration. This + configuration may include outbound registrations which have been + removed due to a reload operation occurring at the same time. The + code for printing the outbound registration did not take this + into account but now it does. AST-1506 #close Review: + https://reviewboard.asterisk.org/r/4338/ ........ Merged + revisions 430664 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-07 03:29 +0000 [r430253-430293] Matthew Jordan + + * utils/conf2ael.c, apps/app_waitforring.c, formats/format_vox.c, + res/res_timing_pthread.c, pbx/pbx_ael.c, + cel/cel_sqlite3_custom.c, res/res_hep_rtcp.c, + formats/format_jpeg.c, apps/app_jack.c, apps/app_adsiprog.c, + cdr/cdr_sqlite3_custom.c, res/res_snmp.c, channels/chan_sip.c, + cel/cel_tds.c, apps/app_dictate.c, apps/app_festival.c, + agi/eagi-test.c, res/res_hep_pjsip.c, apps/app_alarmreceiver.c, + apps/app_image.c, channels/chan_console.c, apps/app_getcpeid.c, + apps/app_talkdetect.c, channels/chan_oss.c, + channels/chan_misdn.c, apps/app_mp3.c, channels/chan_alsa.c, + pbx/pbx_dundi.c, channels/chan_nbs.c, utils/extconf.c, + apps/app_zapateller.c, cel/cel_pgsql.c, res/res_config_pgsql.c, + utils/muted.c, apps/app_test.c, utils/smsq.c, + apps/app_morsecode.c, apps/app_ices.c, cdr/cdr_csv.c, + channels/chan_phone.c, funcs/func_pitchshift.c, + funcs/func_audiohookinherit.c, + res/res_pjsip_phoneprov_provider.c, apps/app_minivm.c, + res/res_statsd.c, apps/app_sms.c, res/res_config_ldap.c, + utils/streamplayer.c, utils/check_expr.c, cel/cel_radius.c, + apps/app_nbscat.c, res/res_hep.c, apps/app_waitforsilence.c, + apps/app_dahdiras.c, pbx/pbx_lua.c, res/res_ael_share.c, + cdr/cdr_radius.c, cdr/cdr_tds.c, utils/stereorize.c, + apps/app_osplookup.c, channels/chan_skinny.c, + funcs/func_frame_trace.c, apps/app_amd.c, pbx/pbx_realtime.c, + apps/app_url.c, apps/app_externalivr.c, cdr/cdr_odbc.c, + res/res_timing_kqueue.c, channels/chan_mgcp.c, + channels/chan_unistim.c, res/res_phoneprov.c, utils/astman.c, + cdr/cdr_pgsql.c, res/res_config_sqlite.c: Disable extended + support modules + + * /, + contrib/ast-db-manage/config/versions/371a3bf4143e_add_user_eq_phone_option_to_pjsip.py: + contrib/ast-db-manage: Correct down_revision path for + user_eq_phone When the user_eq_phone patch was backported to 13, + it referenced the downward revision that the PJSIP optimistic + encryption option also references. This creates a multi-path + upgrade Exception when generating the SQL files. This patch + corrects this in the 13 branch. Note that trunk, which already + contained both of these features, is unaffected by this problem. + ........ Merged revisions 430252 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2015-01-06 19:53 +0000 [r430245] Scott Griepentrog + + * main/bridge_basic.c, /: bridge: avoid leaking channel during + blond transfer pt2 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 + +2014-12-24 15:27 +0000 [r430085-430094] Matthew Jordan + + * res/res_agi.c, /: res/res_agi: Make Verbose message for 'stream + file' match other playbacks The Verbose message displayed when a + file is played back via 'stream file' was formatted differently + than other playbacks: * It didn't include the channel name * It + didn't include the channel language It does, however, include the + playback offset as well as any escape digits. That information + was kept; however, this patch updates the formatting to more + closely match the Verbose messages displayed when a file is + played back by 'control stream file', Playback, ControlPlayback, + or any other file playback operation. ........ Merged revisions + 429519 from http://svn.asterisk.org/svn/asterisk/branches/13 + + * contrib/ast-db-manage/config/versions/371a3bf4143e_add_user_eq_phone_option_to_pjsip.py + (added), /, res/res_pjsip.c: res_pjsip: Backport missing commits + for user_eq_phone This backports the following from trunk, which + were missed: r427257 | file | 2014-11-04 16:31:16 -0600 (Tue, 04 + Nov 2014) | 2 lines res_pjsip: Allow + at the beginning of a + phone number when user_eq_phone is enabled. r427259 | file | + 2014-11-04 16:51:32 -0600 (Tue, 04 Nov 2014) | 2 lines res_pjsip: + Apply the 'user_eq_phone' setting to the To header as well. It + also adds the Alembic script for the option. ASTERISK-24643 + ........ Merged revisions 430092 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, tests/test_stasis_channels.c: Stasis: Update unittest for + channel snapshots This adjusts the unit test for channel + snapshots to take the new language key into account. ........ + Merged revisions 429352 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * CHANGES, res/res_pjsip.c, include/asterisk/res_pjsip.h, + res/res_pjsip_keepalive.c (added), res/res_pjsip/config_global.c, + /, configs/samples/pjsip.conf.sample: res_pjsip_keepalive: Add + runtime configurable keepalive module for connection-oriented + transports. Note that this is backport from trunk of r425825. + This change adds a module which is configurable using the + keep_alive_interval setting in the global section that will send + a CRLF keep alive to all active connection-oriented transports at + the provided interval. This is useful because it can help keep + connections open through NATs. This functionality also exists + within PJSIP but can not be controlled at runtime and requires + recompiling it. Review: https://reviewboard.asterisk.org/r/4084/ + ASTERISK-24644 #close ........ Merged revisions 430084 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, res/res_pjsip/pjsip_configuration.c, + res/res_pjsip_caller_id.c, CHANGES, res/res_pjsip.c, + include/asterisk/res_pjsip.h: res_pjsip: Add 'user_eq_phone' + option to add a 'user=phone' parameter when applicable. Note that + this is a backport of r425804 from trunk. This change adds a + configuration option which adds a 'user=phone' parameter if the + user portion of the request URI or the From URI is determined to + be a number. Review: https://reviewboard.asterisk.org/r/4073/ + ASTERISK-24643 #close ........ Merged revisions 430083 from + http://svn.asterisk.org/svn/asterisk/branches/13 + +2014-12-22 21:22 +0000 [r430030-430046] Richard Mudgett + + * main/bridge_basic.c, /: DTMF atxfer: Setup recall channels as if + the transferee initiated the call. 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 + + * include/asterisk/_private.h, main/asterisk.c, /, main/logger.c: + queue_log: Post QUEUESTART entry when Asterisk fully boots. 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 + +2014-12-22 18:35 +0000 [r430007-430008] bebuild : + + * /, res/res_pjsip/pjsip_options.c: Multiple revisions + 429128,429246 ........ r429128 | kmoore | 2014-12-09 08:00:50 + -0600 (Tue, 09 Dec 2014) | 12 lines PJSIP: Stagger outbound + qualifies This change staggers initiation of outbound qualify + (OPTIONS) attempts to reduce instantaneous server load and + prevent network congestion. Review: + https://reviewboard.asterisk.org/r/4246/ ASTERISK-24342 #close + Reported by: Richard Mudgett ........ Merged revisions 429127 + from http://svn.asterisk.org/svn/asterisk/branches/12 ........ + r429246 | kmoore | 2014-12-10 07:14:56 -0600 (Wed, 10 Dec 2014) | + 8 lines PJSIP: Fix assert on initial mass qualify This fixes the + MWI test regressions caused by r429127 and ensures that contacts + have non-zero qualify_frequency before attempting scheduling. + ........ Merged revisions 429245 from + http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged + revisions 429128,429246 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * main/manager.c, /: Prevent possible race condition on dual + redirect of channels in the same bridge. 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 + +2014-12-19 21:52 +0000 [r429855-429892] bebuild : + + * CHANGES, res/res_ari_channels.c, res/ari/resource_channels.h, /, + rest-api/api-docs/channels.json, res/ari/resource_channels.c: + ari: Add support for specifying an originator channel when + originating. If an originator channel is specified when + originating a channel the linked ID of it will be applied to the + newly originated outgoing channel. This allows an association to + be made between the two so it is known that the originator has + dialed the originated channel. ASTERISK-24552 #close Reported by: + Matt Jordan Review: https://reviewboard.asterisk.org/r/4243/ + ........ Merged revisions 429153 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * res/ari/ari_model_validators.c, main/manager_channels.c, + res/ari/ari_model_validators.h, /, main/stasis_channels.c, + rest-api/api-docs/channels.json: ARI/AMI: Include language in + standard channel snapshot output 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 + + * res/res_pjsip_session.c, /: res_pjsip_session: Fix issue where a + declined media stream in a re-INVITE would fail SDP negotiation. + In the past the SDP negotiation within res_pjsip_session was made + more tolerant of certain situations. The only case where SDP + negotiation will fail is when a major error occurs during + negotiation. Receiving an already declined media stream is not + considered a major error. When producing the local SDP the logic + took this into account so on the initial INVITE the declined + media stream did not cause an SDP negotiation failure. + Unfortunately the logic for handling media streams with a handler + did not mirror this logic and considered an already declined + media stream an error and thus failed the SDP negotiation. This + change makes the logic between both situations match so only + under major errors will the SDP negotiation fail. ASTERISK-24607 + #close Reported by: Matt Jordan Review: + https://reviewboard.asterisk.org/r/4254/ ........ Merged + revisions 429407 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * include/asterisk/format.h, main/format.c, /, main/codec.c: media: + Fix crash when determining sample count of a frame during + shutdown. 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 + + * /, res/res_pjsip_outbound_registration.c: Prevent potential + infinite outbound authentication loops in registration. Prior to + this patch, Asterisk would always respond to 401 responses to + registration attempts by trying to provide a registration with + authentication credentials. Even if subsequent attempts were + rejected with 401 responses, Asterisk would continue this + behavior. If authentication credentials were incorrect, this + could continue forever. With this patch, we keep track of whether + we have attempted authentication on an outbound registration + attempt. If we already have, we don not try again until the next + attempt. This prevents the infinite loop scenario. Review: + https://reviewboard.asterisk.org/r/4273 ........ Merged revisions + 429761 from http://svn.asterisk.org/svn/asterisk/branches/13 + + * res/res_pjsip_outbound_publish.c, /: res_pjsip_outbound_publish: + stack overflow when using non-default sorcery wizard When using a + non-default sorcery wizard (in this instance realtime) for + outbound publishes Asterisk will crash after a stack overflow + occurs due to the code infinitely recursing. The fix entails + removing the outbound publish state dependency from the outbound + publish sorcery object and instead keeping an in memory container + that can be used to lookup the state when needed. ASTERISK-24514 + #close Reported by: Mark Michelson Review: + https://reviewboard.asterisk.org/r/4178/ ........ Merged + revisions 429175 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, res/res_pjsip_sdp_rtp.c: PJSIP: Allow use of 'inactive' + streams for hold This allows use of the 'inactive' stream + direction identifier to be used for hold where 'sendonly' is + normally used. Some Seimens phones use 'inactive' and this change + allows music on hold to operate properly. Review: + https://reviewboard.asterisk.org/r/4252/ Reported by: Steve Pitts + ........ Merged revisions 429432 from + http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged + revisions 429433 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * channels/chan_pjsip.c, res/res_pjsip_session.c, + include/asterisk/res_pjsip_session.h, /, + res/res_pjsip_session.exports.in: res_pjsip_session: Delay + sending BYE if a re-INVITE transaction is in progress. Given the + scenario where a PJSIP channel is in a native RTP bridge with + direct media and the channel is then hung up the code will + currently re-INVITE the channel back to Asterisk and send a BYE + at the same time. Many SIP implementations dislike this greatly. + This change makes it so that if a re-INVITE transaction is in + progress the BYE is queued to occur after the completion of the + transaction (be it through normal means or a timeout). Review: + https://reviewboard.asterisk.org/r/4248/ ........ Merged + revisions 429409 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, channels/chan_pjsip.c: chan_pjsip: Race between channel answer + and bridge setup when using direct media When direct media is + enabled and a pjsip channel is answered a race would occur + between the handling of the answer and bridge setup. Sometimes + the media negotiation would take place after the native bridge + was setup. This resulted in a NULL media address, which in turn + resulted in Asterisk using its address as the remote media + address when sending a reinvite. This patch makes the chan_pjsip + answer handler synchronous thus alleviating the race condition + (the bridge won't start setting things up until after it + returns). ASTERISK-24563 #close Reported by: Steve Pitts Review: + https://reviewboard.asterisk.org/r/4257/ ........ Merged + revisions 429477 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * main/rtp_engine.c, /, channels/chan_sip.c, + include/asterisk/rtp_engine.h, res/res_rtp_asterisk.c: Direct + Media calls within private network sometimes get one way audio + 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 + + * channels/pjsip/dialplan_functions.c, /: Ensure the correct value + is returned for CHANNEL(pjsip, secure) Prior to this patch, we + were using the PJSIP dialog's secure flag to determine if a + secure transport was being used. Unfortunately, the dialog's + secure flag was only set if a SIPS URI were in use, as required + by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested in + is not dialog security, but transport security. This code change + switches to a model where we use the dialog's target URI to + determine what transport would be used to communicate, and then + check if that transport is secure. AST-1450 #close Reported by + John Bigelow Review: https://reviewboard.asterisk.org/r/4277 + ........ Merged revisions 429739 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * channels/chan_dahdi.c, /: chan_dahdi: Don't ignore setvar when + using configuration section scheme. When the configuration + section scheme of chan_dahdi.conf is used (keyword dahdichan + instead of channel) all setvar= options are completely ignored. + No variable defined this way appears in the created DAHDI + channels. * Move the clearing of setvar values to after the + deferred processing of dahdichan. AST-1378 #close Reported by: + Guenther Kelleter Patch by: Guenther Kelleter ........ Merged + revisions 429825 from + http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged + revisions 429829 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, include/asterisk/lock.h, main/lock.c: DEBUG_THREADS: Fix + regression and lock tracking initialization problems. 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 ........ Merged + revisions 429540 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, res/res_pjsip_pubsub.c: Activate persistent subscriptions when + they are recreated. Prior to this change, recreating persistent + subscriptions would create the subscription but would not + activate it. This led to subscriptions being listed in the "NULL" + state by diagnostics and not sending NOTIFYs when expected. + Review: https://reviewboard.asterisk.org/r/4261 ........ Merged + revisions 429571 from + http://svn.asterisk.org/svn/asterisk/branches/13 + + * /, asterisk-13.1.0-summary.html (removed), + asterisk-13.1.0-summary.txt (removed): Update properties; remove + old summaries + + * / (added): Create Certified Asterisk 13.1 branch + 2014-12-15 Asterisk Development Team * Asterisk 13.1.0 Released.