+2016-02-03 22:14 +0000 Asterisk Development Team <asteriskteam@digium.com>
+
+ * asterisk certified/13.1-cert3 Released.
+
+2016-02-03 16:05 +0000 [2142c74a02] Kevin Harwell <kharwell@lunkwill>
+
+ * .version: Update for certified/13.1-cert3
+
+2016-02-03 16:04 +0000 [07c95d33bd] Kevin Harwell <kharwell@lunkwill>
+
+ * .lastclean: Update for certified/13.1-cert3
+
+2016-02-03 16:04 +0000 [ce314be09d] Kevin Harwell <kharwell@lunkwill>
+
+ * realtime: Add database scripts for certified/13.1-cert3
+
+2016-02-03 12:05 +0000 [b50d584022] Joshua Colp <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <sivad.a@paradise.net.nz>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <steve@one47.co.uk>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * Add missing failure checks to ast_str_set_va() callers.
+
+ Change-Id: I0c2cdcd53727bdc6634095c61294807255bd278f
+
+2015-10-21 11:44 +0000 [43323995ba] Joshua Colp <jcolp@digium.com>
+
+ * 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 <git@cfware.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * config.c: Fix off-nominal memory leak.
+
+ Change-Id: I06e346e9a5c63cc5071e7eda537310c4b43bffe0
+
+2015-10-12 11:20 +0000 [728a2b7013] Richard Mudgett <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * res_sorcery_memory_cache.c: Misc tweaks.
+
+ Change-Id: I8cd32dffbb4f33bb0c39518d6e4c991e73573160
+
+2015-09-30 17:27 +0000 [14ac763ab3] Richard Mudgett <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <george.joseph@fairview5.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <scott@griepentrog.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <george.joseph@fairview5.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * app_directory: Fix crash when using the alias option 'a'.
+
+ The voicemail.conf mailbox key/value pair is defined as:
+ <mailbox>=[<password>[,<full-name>[,<email>[,<pager>[,<options>]]]]]
+ 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
+ <mailbox>=<password>,<name> 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 <mjordan@digium.com>
+
+ * .version: Update for certified/13.1-cert3-rc1
+
+2015-06-08 12:28 +0000 [2ef2c12fae] Matt Jordan <mjordan@digium.com>
+
+ * .lastclean: Update for certified/13.1-cert3-rc1
+
+2015-06-08 12:28 +0000 [5032390639] Matt Jordan <mjordan@digium.com>
+
+ * realtime: Add database scripts for certified/13.1-cert3-rc1
+
+2015-06-08 09:43 +0000 [2bf6fd263a] Kevin Harwell <kharwell@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <george.joseph@fairview5.com>
+
+ * More .gitignore updates
+
+ Added .pyc and .sha1 to the top-level .gitignore.
+
+ Change-Id: I7dfc4f554d54d22947b38140d3305007503cc16a
+ Tested-by: George Joseph <george.joseph@fairview5.com>
+
+2015-04-13 19:06 +0000 [70fab74baf] gtjoseph <george.joseph@fairview5.com>
+
+ * .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 <mjordan@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <git@cfware.com>
+
+ * 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 <mjordan@digium.com>
+
+ * .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 <george.joseph@fairview5.com>
+
+ * 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 <jcolp@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <mail@maciej.szmigiero.name> (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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <asanders@digium.com>
+
+ * 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 <asanders@digium.com>
+
+ * 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 <asanders@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <asteriskteam@digium.com>
+
+ * 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 <asteriskteam@digium.com>
+
+ * Certified Asterisk 13.1-cert1 Released.
+
+2015-01-30 17:53 +0000 [r431494] Richard Mudgett <rmudgett@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <jrose@digium.com>
+
+ * 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 <mmichelson@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * /, 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 <kharwell@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * /, 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 <jcolp@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * /, 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 <jcolp@digium.com>
+
+ * 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 <kharwell@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * /, 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 <mmichelson@digium.com>
+
+ * 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 <jcolp@digium.com>
+
+ * /, 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 <mjordan@digium.com>
+
+ * 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 <sgriepentrog@digium.com>
+
+ * 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 <mjordan@digium.com>
+
+ * 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 <rmudgett@digium.com>
+
+ * 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 <bebuild@localhost>:
+
+ * /, 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 <bebuild@localhost>:
+
+ * 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 <asteriskteam@digium.com>
* Asterisk 13.1.0 Released.
projects / thirdparty / asterisk.git / commitdiff
