[asterisk-commits] bebuild: tag certified-1.8.15-cert2 r384110 - /certified/tags/1.8.15-cert2/
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Wed Mar 27 13:32:10 CDT 2013
Author: bebuild
Date: Wed Mar 27 13:32:07 2013
New Revision: 384110
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=384110
Log:
Importing files for 1.8.15-cert2 release.
Added:
certified/tags/1.8.15-cert2/.lastclean (with props)
certified/tags/1.8.15-cert2/.version (with props)
certified/tags/1.8.15-cert2/ChangeLog (with props)
Added: certified/tags/1.8.15-cert2/.lastclean
URL: http://svnview.digium.com/svn/asterisk/certified/tags/1.8.15-cert2/.lastclean?view=auto&rev=384110
==============================================================================
--- certified/tags/1.8.15-cert2/.lastclean (added)
+++ certified/tags/1.8.15-cert2/.lastclean Wed Mar 27 13:32:07 2013
@@ -1,0 +1,3 @@
+39
+
+
Propchange: certified/tags/1.8.15-cert2/.lastclean
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: certified/tags/1.8.15-cert2/.lastclean
------------------------------------------------------------------------------
svn:keywords = none
Propchange: certified/tags/1.8.15-cert2/.lastclean
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: certified/tags/1.8.15-cert2/.version
URL: http://svnview.digium.com/svn/asterisk/certified/tags/1.8.15-cert2/.version?view=auto&rev=384110
==============================================================================
--- certified/tags/1.8.15-cert2/.version (added)
+++ certified/tags/1.8.15-cert2/.version Wed Mar 27 13:32:07 2013
@@ -1,0 +1,1 @@
+1.8.15-cert2
Propchange: certified/tags/1.8.15-cert2/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: certified/tags/1.8.15-cert2/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: certified/tags/1.8.15-cert2/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: certified/tags/1.8.15-cert2/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/certified/tags/1.8.15-cert2/ChangeLog?view=auto&rev=384110
==============================================================================
--- certified/tags/1.8.15-cert2/ChangeLog (added)
+++ certified/tags/1.8.15-cert2/ChangeLog Wed Mar 27 13:32:07 2013
@@ -1,0 +1,41706 @@
+2013-03-27 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Certified Asterisk 1.8.15-cert2 Released.
+
+2013-03-27 18:31 +0000 [r383991-384108] Matthew Jordan <mjordan at digium.com>
+
+ * main/http.c: AST-2013-002: Prevent denial of service in HTTP
+ server AST-2012-014, fixed in January of this year, contained a
+ fix for Asterisk's HTTP server for a remotely-triggered crash.
+ While the fix put in place fixed the possibility for the crash to
+ be triggered, a denial of service vector still exists with that
+ solution if an attacker sends one or more HTTP POST requests with
+ very large Content-Length values. This patch resolves this by
+ capping the Content-Length at 1024 bytes. Any attempt to send an
+ HTTP POST with Content-Length greater than this cap will not
+ result in any memory allocation. The POST will be responded to
+ with an HTTP 413 "Request Entity Too Large" response. This issue
+ was reported by Christoph Hebeisen of TELUS Security Labs (closes
+ issue ASTERISK-20967) Reported by: Christoph Hebeisen patches:
+ AST-2013-002-1.8.diff uploaded by mmichelson (License 5049)
+ AST-2013-002-10.diff uploaded by mmichelson (License 5049)
+ AST-2013-002-11.diff uploaded by mmichelson (License 5049)
+
+ * channels/sip/include/sip.h, channels/chan_sip.c: AST-2013-003:
+ Prevent username disclosure in SIP channel driver When
+ authenticating a SIP request with alwaysauthreject enabled,
+ allowguest disabled, and autocreatepeer disabled, Asterisk
+ discloses whether a user exists for INVITE, SUBSCRIBE, and
+ REGISTER transactions in multiple ways. The information is
+ disclosed when: * A "407 Proxy Authentication Required" response
+ is sent instead of a "401 Unauthorized" response * The presence
+ or absence of additional tags occurs at the end of "403
+ Forbidden" (such as "(Bad Auth)") * A "401 Unauthorized" response
+ is sent instead of "403 Forbidden" response after a
+ retransmission * Retransmission are sent when a matching peer did
+ not exist, but not when a matching peer did exist. This patch
+ resolves these various vectors by ensuring that the responses
+ sent in all scenarios is the same, regardless of the presence of
+ a matching peer. This issue was reported by Walter Doekes, OSSO
+ B.V. A substantial portion of the testing and the solution to
+ this problem was done by Walter as well - a huge thanks to his
+ tireless efforts in finding all the ways in which this setting
+ didn't work, providing automated tests, and working with Kinsey
+ on getting this fixed. (closes issue ASTERISK-21013) Reported by:
+ wdoekes Tested by: wdoekes, kmoore patches: AST-2013-003-1.8
+ uploaded by kmoore, wdoekes (License 6273, 5674) AST-2013-003-10
+ uploaded by kmoore, wdoekes (License 6273, 5674) AST-2013-003-11
+ uploaded by kmoore, wdoekes (License 6273, 5674)
+
+2013-03-04 20:54 +0000 [r382389] Jason Parker <jparker at digium.com>
+
+ * main/event.c: Fix comparison of presence state in event
+ subsystem. Several new IEs were not given types (or names),
+ causing the comparison function to improperly succeed. This adds
+ those. (closes issue AST-1128)
+
+2013-02-28 16:49 +0000 [r382228] Matthew Jordan <mjordan at digium.com>
+
+ * UPGRADE.txt, /, apps/app_meetme.c: Let channels joining a MeetMe
+ conference opt out of the denoiser For some channel drivers,
+ specifically those that have a varying rate in the number of
+ audio samples, the audio quality for a MeetMe conference can be
+ exceedingly poor. This is due to a unilateral application of the
+ DENOISE function in func_speex to channels joining the
+ conference. The denoiser function in the speex library is
+ initialized with the number of audio samples in each sample that
+ will be provided to it. If the number of audio samples changes,
+ the denoiser has to be thrown away and re-initialized. While this
+ could be worked around by removing func_speex, that doesn't help
+ if you actually use the denoiser with other channels on the
+ system. This patches does the following: * Checks for the
+ presence of func_speex as opposed to codec_speex when determining
+ if the DENOISE function is present (which is where the function
+ is actually implemented) * Adds an option to MeetMe 'n' that
+ causes the denoiser to not be applied to a channel when it joins.
+ This keeps the current behavior the default, but let's users
+ disable the denoiser if it causes problems on their system.
+ Review: https://reviewboard.asterisk.org/r/2358 (closes issue
+ AST-1062) Reported by: Thomas Arimont ........ Merged revisions
+ 382227 from http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2013-02-20 19:10 +0000 [r381834] Matthew Jordan <mjordan at digium.com>
+
+ * apps/app_voicemail.c: Let vm_mailbox_snapshot_create's combine
+ option apply to "Urgent" as well The vm_mailbox_snapshot_create
+ function has an option that combines the contents of INBOX and
+ Old into a single snapshot. The intent of this is that both 'new'
+ messages and 'deleted' messages are given in a single snapshot,
+ as some applications prefer this view of the voicemail world.
+ Unfortunately, the initial implementation ignored the "Urgent"
+ folder. The "Urgent" folder is a pseudo-INBOX, in that new
+ messages left with the 'U' flag will be placed in that folder as
+ opposed to INBOX. Thus, the option failed the intent with which
+ it was added. This patch makes it so that the "Urgent" folder is
+ included in the snapshot when that option is used.
+
+2013-01-14 15:17 +0000 [r379002] David M. Lee <dlee at digium.com>
+
+ * /, channels/chan_sip.c: Fix XML encoding of 'identity display' in
+ NOTIFY messages, continued. When r378933 was merged into 1.8, it
+ should have also escaped remote_display, since it will have the
+ same XML encoding problem when the caller/callee roles are
+ reversed. (closes issue ABE-2902) Reported by: Guenther Kelleter
+ ........ Merged revisions 379001 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2013-01-12 07:02 +0000 [r378936] David M. Lee <dlee at digium.com>
+
+ * main/utils.c, include/asterisk/utils.h, /, channels/chan_sip.c,
+ tests/test_xml_escape.c (added): Fix XML encoding of 'identity
+ display' in NOTIFY messages. XML encoding in chan_sip is
+ accomplished by naively building the XML directly from strings.
+ While this usually works, it fails to take into account escaping
+ the reserved characters in XML. This patch adds an
+ 'ast_xml_escape' function, which works similarly to
+ 'ast_uri_encode'. This is used to properly escape the
+ local_display attribute in XML formatted NOTIFY messages. Several
+ things to note: * The Right Thing(TM) to do would probably be to
+ replace the ast_build_string stuff with building an ast_xml_doc.
+ That's a much bigger change, and out of scope for the original
+ ticket, so I refrained myself. * It is with great sadness that I
+ wrote my own ast_xml_escape function. There's one in libxml2, but
+ it's knee-deep in libxml2-ness, and not easily used to one-off
+ escape a string. * I only escaped the string we know is causing
+ problems (local_display). At least some of the other strings are
+ URI-encoded, which should be XML safe. Rather than figuring out
+ what's safe and escaping what's not, it would be much cleaner to
+ simply build an ast_xml_doc for the messages and let the XML
+ library do the XML escaping. Like I said, that's out of scope.
+ (closes issue ABE-2902) Reported by: Guenther Kelleter Tested by:
+ Guenther Kelleter Review:
+ http://reviewboard.digium.internal/r/365/ ........ Merged
+ revision 378919 from
+ https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
+ ........ Merged revisions 378933 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2013-01-09 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Asterisk 1.8.15-cert1 Released.
+
+2013-01-02 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Asterisk 1.8.15-cert1-rc3 Released.
+
+ * AST-2012-015: Resolve crashes due to large stack allocations when
+ using TCP
+
+ Asterisk had several places where messages received over various
+ network transports may be copied in a single stack allocation. In
+ the case of TCP, since multiple packets in a stream may be
+ concatenated together, this can lead to large allocations that
+ overflow the stack.
+
+ This patch modifies those portions of Asterisk using TCP to either
+ favor heap allocations or use an upper bound to ensure that the
+ stack will not overflow:
+ * For SIP, the allocation now has an upper limit
+ * For HTTP, the allocation is now a heap allocation instead of a
+ stack allocation
+ * For XMPP (in res_jabber), the allocation has been eliminated
+ since it was unnecesary.
+
+ * AST-2012-014: Prevent exhaustion of system resources through
+ exploitation of event cache
+
+ Asterisk maintains an internal cache for devices in the event
+ subsystem. The device state cache holds the state of each device
+ known to Asterisk, such that consumers of device state information
+ can query for the last known state for a particular device, even if
+ it is not part of an active call. The concept of a device in Asterisk
+ can include entities that do not have a physical representation. One
+ way that this occurred was when anonymous calls are allowed in
+ Asterisk. A device was automatically created and stored in the cache
+ for each anonymous call that occurred; this was possible in the SIP
+ and IAX2 channel drivers and through channel drivers that utilized
+ the res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif).
+ These devices are never removed from the system, allowing anonymous
+ calls to potentially exhaust a system's resources.
+
+ This patch changes the event cache subsystem and device state
+ management to no longer cache devices that are not associated with a
+ physical entity.
+
+2012-11-19 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Asterisk 1.8.15-cert1-rc2 Released.
+
+ * Fix SendDTMF crash and channel reference leak using channel name
+ parameter.
+
+ The SendDTMF channel name parameter has two issues.
+ 1) Crashes if the channel name does not exist.
+ 2) Leaks a channel reference if the channel is the current channel.
+ Problem introduced by ASTERISK-15956.
+
+ * Updated SendDTMF documentation.
+
+ * Renamed app to senddtmf_name and tweaked the type.
+
+ * Fix Incrementing Sequence Number For Retransmitted DTMF End Packets
+
+ In Asterisk 1.4+, a fix was put in place to increment the sequence
+ number for retransmitted DTMF end packets. With the introduction
+ of the RTP engine API in 1.8, the sequence number was no longer being
+ incremented. This patch fixes this regression as well as cleans up a
+ few lines that were not doing anything.
+
+ * app_queue: Fix a lock that was being held forever caused by a merging
+ mistake
+
+ r375591 merged with conflicts and an oversight resulted in an unlock
+ being missed which resulted in a deadlock when updating realtime
+ members in queues. This patch adds that unlock back in.
+
+2012-11-02 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Asterisk 1.8.15-cert1-rc1 Released.
+
+2012-11-02 18:59 +0000 [r375630-375631] Richard Mudgett <rmudgett at digium.com>
+
+ * main/cel.c, /: Fix compiler warnings. gcc (GCC) 4.2.4 has
+ problems casting away constness. ........ Merged revisions 370275
+ from http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * channels/misdn/isdn_lib.c, channels/misdn/isdn_lib.h, /: Multiple
+ revisions 375519-375524 ........ r375519 | rmudgett | 2012-10-30
+ 16:06:15 -0500 (Tue, 30 Oct 2012) | 11 lines chan_misdn: Timer
+ primitives must be handled first. The frm->addr is a different
+ "address space" than the stack/instance address of other Lx
+ primitives. The test for B channel instance address could fail.
+ Patches: patch01_timers.diff (license #6372) patch uploaded by
+ Guenther Kelleter JIRA ABE-2888 ........ r375520 | rmudgett |
+ 2012-10-30 16:14:58 -0500 (Tue, 30 Oct 2012) | 10 lines
+ chan_misdn: Free memory in error paths and other memory leaks.
+ The one line commented with BUG is not easily fixable because
+ there is no de-init function one can call. Patches:
+ patch02_memory.diff (license #6372) patch uploaded by Guenther
+ Kelleter JIRA ABE-2888 ........ r375521 | rmudgett | 2012-10-30
+ 16:38:41 -0500 (Tue, 30 Oct 2012) | 14 lines chan_misdn: ISDN NT
+ L2 de-establish/establish * An NT-PTMP cannot de/establish L2
+ since it doesn't know the TEIs. * On NT-PTP L2 is started when L1
+ is finally active in handle_l1. * L2 deactivation logging
+ cleanup. * L2 aggregate link status is unknown for NT-PTMP, show
+ as "UNKN". * Removed unused functions and code for L2 handling.
+ Patches: patch03_L2estab.diff (license #6372) patch uploaded by
+ Guenther Kelleter Modified JIRA ABE-2888 ........ r375522 |
+ rmudgett | 2012-10-30 16:56:14 -0500 (Tue, 30 Oct 2012) | 22
+ lines chan_misdn: Fix broken upper_id/lower_id usage. Sending PH
+ prim via lower_id layer (3 or 1) simply does not work. For TE (3)
+ it returns an error (len=-6) which is not evaluated by
+ handle_l1(), so the L1 layer status ends up wrong. Instead PH
+ must be sent via L4, only then does it reach L1 without an error
+ message. And NT PH prims only reach L1 when they are sent to
+ layer 2 id. --> use upper_id to send PH primitives. * Check for
+ errors in PH_(DE)ACTIVATE | CONFIRM. * Debug messages are
+ improved. * The lower_id is now not used for anything, except:
+ Why is lower_id layer deleted when it wasn't created? I removed
+ this code since it looks very wrong. Patches:
+ patch04_l1activation.diff (license #6372) patch uploaded by
+ Guenther Kelleter JIRA ABE-2888 ........ r375523 | rmudgett |
+ 2012-10-30 17:29:15 -0500 (Tue, 30 Oct 2012) | 31 lines
+ chan_misdn: Fix loss of B channels if L1 is down. If you make 2
+ calls out an NT PTMP port which is not connected to any phone,
+ the B channel associated with that call becomes unusable until
+ Asterisk is restarted. The problem is the EVENT_SETUP is queued
+ when L1 is not up in misdn_lib_send_event(). If L1 cannot be
+ activated the event won't be dequeued. It gets even worse when
+ the call is hung up. The queued EVENT_SETUP will be overwritten
+ by an EVENT_DISCONNECT. The reserved B channel then will never be
+ freed. If later someone connects a phone to the port, L1 will
+ eventually activate and the queued EVENT_DISCONNECT is sent down
+ the stack. However, it is ignored because it is the wrong call
+ state. The real fix would be that activation and queueing for a
+ new SETUP is done by the NT stack. But since it doesn't, the
+ workaround must be removed because it doesn't always work. Fix:
+ The event is no longer queued but immediately sent to the stack.
+ If L1 cannot be activated, the L3 state machine that was started
+ by the EVENT_SETUP will do its work, i.e. a timeout will release
+ the B channel properly. The SETUP possibly cannot be sent the
+ first time but is resent by T303 in case L1 could be activated.
+ Patches: patch05_bchan-loss.diff (license #6372) patch uploaded
+ by Guenther Kelleter Modified JIRA ABE-2888 ........ r375524 |
+ rmudgett | 2012-10-30 18:26:05 -0500 (Tue, 30 Oct 2012) | 13
+ lines chan_misdn: Remove some calls to exit(). Try proper cleanup
+ when something goes wrong in misdn_lib_init(). Especially do not
+ call exit()! * Fix memory leak because stack_destroy() does not
+ free the stack struct. Patches: patch06_cleanup-init.diff
+ (license #6372) patch uploaded by Guenther Kelleter Modified JIRA
+ ABE-2888 ........ Merged revisions 375519-375524 from
+ https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
+ ........ Merged revisions 375625 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2012-11-02 17:38 +0000 [r375584-375615] Matthew Jordan <mjordan at digium.com>
+
+ * main/app.c, /: core: Fix a memory leak in app.c from an early
+ return ast_app_group_match_get_count allocates memory with the
+ regcomp function and we previously forgot to free it when bailing
+ out due to a regex compilation failure against category. (closes
+ issue AST-1018) Reported by: Guenther Kelleter Patches:
+ regcomp_memleak.diff uploaded by Guenther Kelleter (license 6372)
+ ........ Merged revisions 375299 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * channels/chan_dahdi.c, /: chan_dahdi: Fix segfault dereferencing
+ a NULL tech_pvt. The tech support customer was using the AMI
+ Redirect action shortly after a call was placed. While the
+ channel tried to do an ast_read(), the masquerade resulting from
+ the channel redirect took place. The masquerade in the middle of
+ the ast_read() resulted in the segfault. (closes issue AST-1025)
+ Reported by: Trey Blancher Patches: jira_ast_1025_v1.8_v2.patch
+ (license #5621) patch uploaded by rmudgett ........ Merged
+ revisions 375361 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * UPGRADE.txt, apps/app_queue.c, /: Multiple revisions
+ 375216,375242 ........ r375216 | jrose | 2012-10-18 15:58:07
+ -0500 (Thu, 18 Oct 2012) | 12 lines app_queue: Make ordering of
+ rrmemory/rrordered persist over add/remove members Prior to this
+ patch, adding, removing or reloading members to rrmemory would
+ cause the order to become completely jumbled. Now it behaves more
+ or less like rrordered other than the fact that it stores the
+ members on a hash table rather than a linked list. This patch
+ also prevents removal of members and member reloads from jumbling
+ rrordered queues. (issue AST-989) Reported by: Thomas Arimont
+ Review: https://reviewboard.asterisk.org/r/2164/ ........ r375242
+ | jrose | 2012-10-18 16:30:13 -0500 (Thu, 18 Oct 2012) | 8 lines
+ app_queue: add upgrade notes for 375216 Adds notes describing
+ behavioral changes to rrmemory strategy caused by 375216 (issue
+ AST-989) Reported by: Thomas Arimont ........ Merged revisions
+ 375216,375242 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * configs/sip.conf.sample, channels/sip/include/sip.h,
+ channels/sip/sdp_crypto.c, /, channels/chan_sip.c: Multiple
+ revisions 372709,373165,373532,373652,374456 ........ r372709 |
+ mjordan | 2012-09-08 20:19:21 -0500 (Sat, 08 Sep 2012) | 38 lines
+ Only re-create an SRTP session when needed; respond with correct
+ crypto policy In r356604, SRTP handling was fixed to accomodate
+ multiple crypto keys in an SDP offer and the ability to re-create
+ an SRTP session when the crypto keys changed. In certain
+ circumstances - most notably when a phone is put on hold after
+ having been bridged for a significant amount of time - the act of
+ re-creating the SRTP session causes problems for certain models
+ of phones. The patch committed in r356604 always re-created the
+ SRTP session regardless of whether or not the cryptographic keys
+ changed. Since this is technically not necessary, this patch
+ modifies the behavior to only re-create the SRTP session if
+ Asterisk detects that the remote key has changed. This allows
+ models of phones that do not handle the SRTP session changing to
+ continue to work, while also providing the behavior needed for
+ those phones that do re-negotiate cryptographic keys. In
+ addition, in Asterisk 1.8 only, it was found that phones that
+ offer AES_CM_128_HMAC_SHA1_32 will end up with no audio if the
+ phone is the initiator of the call. The phone will send an INVITE
+ request specifying that AES_CM_128_HMAC_SHA1_32 be used for the
+ cryptographic policy; Asterisk will set its policy to that value.
+ Unfortunately, when the call is Answered and a 200 OK is sent
+ back to the UA, the policy sent in the response's SDP will be the
+ hard coded value AES_CM_128_HMAC_SHA1_80. This potentially
+ results in Asterisk using the INVITE request's policy of
+ AES_CM_128_HMAC_SHA1_32, while the phone uses Asterisk's response
+ of AES_CM_128_HMAC_SHA1_80. Hilarity ensues as both endpoints
+ think the other is crazy. This patch fixes that by caching the
+ policy from the request and responding with it. Note that this is
+ not a problem in Asterisk 10 and later, as the ability to
+ configure the policy was added in that version. (issue
+ ASTERISK-20194) Reported by: Nicolo Mazzon Tested by: Nicolo
+ Mazzon Review: https://reviewboard.asterisk.org/r/2099 ........
+ r373165 | file | 2012-09-19 11:02:18 -0500 (Wed, 19 Sep 2012) |
+ 10 lines Fix a regression where direct media was not permitted
+ for calls using SIP INFO DTMF. A change was committed to fix
+ direct media ACL support. This change wrongly assumed that only a
+ single channel technology structure exists for chan_sip. This is
+ in fact false as a second exists for calls using SIP INFO DTMF.
+ The code which performs direct media ACL checking now checks for
+ both the non-INFO DTMF and INFO DTMF channel technology
+ structures. (closes issue ASTERISK-20409) Reported by: michele
+ cicciotti privatewave ........ r373532 | file | 2012-09-24
+ 19:09:46 -0500 (Mon, 24 Sep 2012) | 5 lines Add missing checks
+ that I neglected. The SIP technology and SIP info technology
+ should be considered equal. (closes issue ASTERISK-20409)
+ Reported by: michele cicciotti privatewave ........ r373652 |
+ twilson | 2012-09-25 12:21:19 -0500 (Tue, 25 Sep 2012) | 18 lines
+ Properly handle UAC/UAS roles for SIP session timers The SIP
+ session timer mechanism contains a mandatory 'refresher'
+ parameter (included in the Session-Expires header) which is used
+ in the session timer offer/answer signaling within a SIP Invite
+ dialog. It looks like asterisk is interpreting the uac resp. uas
+ role only as the initial role of client and server (caller is
+ uac, callee is uas). The standard rfc 4028 however assigns the
+ client role to the ((RE)-Invite) requester, the server role to
+ the ((RE)-Invite) responder. This patch has Asterisk track the
+ actual refresher as "us" or "them" as opposed to relying on just
+ the configured "uas" or "uac" properties. (closes issue AST-922)
+ Reported by: Thomas Airmont Review:
+ https://reviewboard.asterisk.org/r/2118/ ........ r374456 | file
+ | 2012-10-04 12:39:18 -0500 (Thu, 04 Oct 2012) | 14 lines Fix a
+ regression from direct media ACLs where the directrtpsetup option
+ no longer works. A check was added for direct media ACLs that
+ immediately forbid remote bridging if there was no bridged
+ channel. This caused directrtpsetup to no longer function as it
+ needs this information before bridging actually occurs. Logic has
+ now been adjusted so if there is no bridged channel a remote
+ bridge will still be attempted. (closes issue ASTERISK-20511)
+ Reported by: kristoff Review:
+ https://reviewboard.asterisk.org/r/2146/ ........ Merged
+ revisions 372709,373165,373532,373652,374456 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * funcs/func_math.c, main/xmldoc.c, apps/app_dial.c, /,
+ channels/chan_sip.c: Multiple revisions
+ 371357,371469,371860,372628 ........ r371357 | jrose | 2012-08-16
+ 13:57:27 -0500 (Thu, 16 Aug 2012) | 8 lines chan_sip: Use pvt
+ outgoing_call variable to set Remote-Party-ID Header Previously
+ the pvt SIP_OUTGOING flag was used instead, which will frequently
+ flip during reinvites. (closes issue AST-897) Reported by: Thomas
+ Arimont ........ r371469 | mjordan | 2012-08-17 13:51:43 -0500
+ (Fri, 17 Aug 2012) | 14 lines Fix memory leak in XML
+ documentation When formatting documentation fields, the XML
+ documentation parser calls xmldoc_get_formatted. This function
+ allocates a string buffer at the beginning of its routine.
+ Unfortunately, on certain code paths, it also calls
+ xmldoc_string_cleanup, which assumes that it will create the
+ string buffer. The previously allocated string buffer is then
+ leaked by the xmldoc_string_cleanup routine. Now: we don't do
+ that. (closes issue AST-932) Reported by: Alexander Homig
+ ........ r371860 | rmudgett | 2012-08-29 13:22:24 -0500 (Wed, 29
+ Aug 2012) | 12 lines Fix hangup cause passthrough regression. The
+ v1.8 -r369258 change to fix the F and F(x) action logic
+ introduced a regression in passing the hangup cause from the
+ called channel to the caller channel. (closes issue
+ ASTERISK-20287) Reported by: Konstantin Suvorov Patches:
+ app_dial_hangupcause.patch (license #6421) patch uploaded by
+ Konstantin Suvorov (modified) Tested by: rmudgett ........
+ r372628 | rmudgett | 2012-09-07 17:06:29 -0500 (Fri, 07 Sep 2012)
+ | 5 lines Remove annoying unconditional debug message from
+ INC/DEC functions. (closes issue AST-1001) Reported by: Guenther
+ Kelleter ........ Merged revisions 371357,371469,371860,372628
+ from http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * /, channels/chan_sip.c: chan_sip: Trigger reinvite if the SDP
+ answer is included in the SIP ACK Under certain conditions, a SIP
+ transaction involving directmedia wouldn't trigger a re-invite
+ because the SDP answer was included in an ACK instead of in a
+ message that we would have triggered the invite with. This patch
+ just queues a source change control frame if the dialog is using
+ directmedia when we find sdp for an ACK. (closes issue AST-913)
+ Reported by: Thomas Arimont ........ Merged revisions 371337 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * main/cel.c, main/channel.c, /: Multiple revisions
+ 370205,370273,370360 ........ r370205 | kpfleming | 2012-07-18
+ 14:12:03 -0500 (Wed, 18 Jul 2012) | 18 lines Resolve severe
+ memory leak in CEL logging modules. A customer reported a
+ significant memory leak using Asterisk 1.8. They have tracked it
+ down to ast_cel_fabricate_channel_from_event() in main/cel.c,
+ which is called by both in-tree CEL logging modules (cel_custom.c
+ and cel_sqlite3_custom.c) for each and every CEL event that they
+ log. The cause was an incorrect assumption about how data
+ attached to an ast_channel would be handled when the channel is
+ destroyed; the data is now stored in a datastore attached to the
+ channel, which is destroyed along with the channel at the proper
+ time. (closes issue AST-916) Reported by: Thomas Arimont Review:
+ https://reviewboard.asterisk.org/r/2053/ ........ r370273 |
+ mjordan | 2012-07-19 17:00:14 -0500 (Thu, 19 Jul 2012) | 14 lines
+ Fix compilation error when MALLOC_DEBUG is enabled To fix a
+ memory leak in CEL, a channel datastore was introduced whose
+ destruction function pointer was pointed to the ast_free macro.
+ Without MALLOC_DEBUG enabled this compiles as fine, as ast_free
+ is defined as free. With MALLOC_DEBUG enabled, however, ast_free
+ takes on a definition from a different place then utils.h, and
+ became undefined. This patch resolves this by using a reference
+ to ast_free_ptr. When MALLOC_DEBUG is enabled, this calls
+ ast_free; when MALLOC_DEBUG is not enabled, this is defined to be
+ ast_free, which is defined to be free. (issue AST-916) Reported
+ by: Thomas Arimont ........ r370360 | kpfleming | 2012-07-23
+ 09:41:03 -0500 (Mon, 23 Jul 2012) | 10 lines Free any datastores
+ attached to dummy channels. Revision 370205 added the use of a
+ datastore attached to a dummy channel to resolve a memory leak,
+ but ast_dummy_channel_destructor() in this branch did not free
+ datastores, resulting in a continued (but slightly smaller)
+ memory leak. This patch backports the change to free said
+ datastores from the Asterisk trunk. (related to issue AST-916)
+ ........ Merged revisions 370205,370273,370360 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * configs/sip.conf.sample, channels/sip/include/sip.h, /,
+ channels/chan_sip.c: Help mitigate potential reinvite glare
+ scenarios. When Asterisk servers are set up back-to-back, and
+ direct media is to be used betweeen endpoints, it is fairly
+ common for the two Asterisk servers to send direct media
+ reinvites to each other simultaneously. This results in 491s and
+ ACKs being exchanged between the servers. While the media
+ eventually gets set up properly, the problem is that there can be
+ a noticeable delay for the streams to stabilize. This patch adds
+ a new directmedia option called "outgoing". With this set, an
+ immediate direct media reinvite will only be sent if the call
+ direction is outgoing. For incoming dialogs, an immediate direct
+ media reinvite will not be sent, but further "reactionary" direct
+ media reinvites may be sent. For those who are having some deja
+ vu, that's because this patch was originally committed to trunk
+ since there is a new configuration option added. After seeing a
+ bug report about audio being slow to set up on SIP calls, it
+ became apparent that this patch would be the best solution for
+ resolving the issue. The patch is unintrusive and will have no
+ effect unless the option is explicitly enabled. (closes issue
+ AST-896) reported by Thomas Arimont (closes issue ASTERISK-19857)
+ reported by Matt Jordan ........ Merged revisions 370618 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+ * main/ssl.c, main/tcptls.c, /, channels/chan_sip.c: Resolve memory
+ leaks in TLS initialization and TLS client connections This patch
+ resolves two sources of memory leaks when using TLS in Asterisk:
+ 1) It removes improper initialization (and multiple
+ re-initializations) of portions of the SSL library. Asterisk
+ calls SSL_library_init and SSL_load_error_strings during SSL
+ initialization; collectively this obviates the need for calling
+ any of the following during initialization or client connection
+ handling: * ERR_load_crypto_strings (handled by
+ SSL_load_error_strings) * OpenSSL_add_all_algorithms (synonym for
+ SSL_library_init) * SSLeay_add_ssl_algorithms (synonym for
+ SSL_library_init) 2) Failure to completely clean up all memory
+ allocated by Asterisk and by the SSL library for TLS clients.
+ This included not freeing the SSL_CTX object in the SIP channel
+ driver, as well as not clearing the error stack when the TLS
+ client exited. Note that these memory leaks were found by Thomas
+ Arimont, and this patch was essentially written by him with some
+ minor tweaks. (closes issue AST-889) Reported by: Thomas Arimont
+ Tested by: Thomas Arimont patches: (bugAST-889.patch) by Thomas
+ Arimont (license 5525) Review:
+ https://reviewboard.asterisk.org/r/2105 ........ Merged revisions
+ 373061 from http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2012-10-11 15:46 +0000 [r374848] Matthew Jordan <mjordan at digium.com>
+
+ * main/cdr.c, /: Fix incorrect billing duration reported when batch
+ mode is enabled Similar to r369351, the billing duration can be
+ skewed when batch mode is enabled. This happened much more rarely
+ than the duration, as it only occured when the call was answered
+ (thereby indicating an actual answer time) and immediately hung
+ up on (indicating a billsec of 0). Since a billing time of '0'
+ can either mean that the call immediately ended or that the CDR
+ was improperly answered, we have to use additional information to
+ know whether or not we can trust the CDR billsec value. Prior to
+ this patch, we looked to see if we had a valid answer time. If we
+ did, and billsec was zero, we used the current time to calculate
+ what billsec value we could from the CDR being written. If batch
+ mode is enabled, this will incorrectly report a billsec value
+ being much greater than the actual duration of the call. Instead
+ of relying on the presence of an answer time to know whether or
+ not we can re-calculate the billsec for the CDR, we now also use
+ the presence of the CDR's end time to know if we need to
+ re-calculate or whether we can trust the billsec value that we
+ have. This prevents erroneous jumps in the billsec value, while
+ still making sure that in the worst case, some billing time will
+ be calculated. (closes issue AST-1016) Reported by: Thomas
+ Arimont Tested by: Thomas Arimont ........ Merged revisions
+ 374843 from http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2012-10-10 21:16 +0000 [r374807] Richard Mudgett <rmudgett at digium.com>
+
+ * apps/app_queue.c, /: app_queue: Made pass connected line updates
+ from the caller to ringing queue members. Party A calls Party B
+ Party B puts Party A on hold. Party B calls a queue. Ringing
+ queue member D sees Party B identification. Party B transfers
+ Party A to the queue. Queue member D does not get a connected
+ line update for Party A. Queue member D answers the call and
+ still sees Party B information. However, if Party A later
+ transfers the call to Party C then queue member D gets a
+ connected line update for Party C. * Made pass connected line
+ updates from the caller to queue members while the queue members
+ are ringing. (closes issue AST-1017) Reported by: Thomas Arimont
+ (closes issue ABE-2886) Reported by: Thomas Arimont Tested by:
+ rmudgett ........ Merged revisions 374801 from
+ https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
+ ........ Merged revisions 374802 from
+ http://svn.asterisk.org/svn/asterisk/branches/1.8
+
+2012-10-05 20:12 +0000 [r374569] dlee <dlee at localhost>:
+
+ * main/manager.c: Improve AMI long line error handling In AMI's
+ parser, when it receives a long line (> 1024 characters), it
+ discards that line, but continues to process the message
+ normally. Typically, this is not a problem because a) who has
+ lines that long and b) usually a discarded line results in an
+ invalid message. But if that line is specifying an optional
+ field, then the message will be processed, you get a 'Response:
+ Success', but things don't work the way you expected them to.
+ This patch changes the behavior when a line-too-long parse error
+ occurs. * Changes the log message to avoid way-too-long (and
+ truncated anyways) log messages * Adds a 'parsing' status flag to
+ Response: Success * Sets parsing = MESSAGE_LINE_TOO_LONG if,
+ well, a line is too long * Responds with an appropriate error if
+ parsing != MESSAGE_OKAY (closes issue AST-961) Reported by: John
+ Bigelow Review: https://reviewboard.asterisk.org/r/2142/
+
+2012-10-05 19:02 +0000 [r374541] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/misdn/isdn_msg_parser.c, channels/misdn/isdn_lib.c,
+ channels/misdn/isdn_lib.h, channels/chan_misdn.c, /: Multiple
+ revisions 370563,374536 ........ r370563 | rmudgett | 2012-07-30
+ 11:47:19 -0500 (Mon, 30 Jul 2012) | 2 lines Release B channel
+ allocation on error path in chan_misdn. ........ r374536 |
+ rmudgett | 2012-10-05 13:20:01 -0500 (Fri, 05 Oct 2012) | 159
+ lines Merged revisions 374515-374535 from
+ https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
+ ................ r374515 | rmudgett | 2012-10-04 17:52:36 -0500
+ (Thu, 04 Oct 2012) | 10 lines chan_misdn: Remove some deadcode *
+ Made setup_bc() static. Patches: patch1_unused-code.diff (license
+ #6372) patch uploaded by Guenther Kelleter Modified JIRA ABE-2882
+ ................ r374516 | rmudgett | 2012-10-04 18:01:01 -0500
+ (Thu, 04 Oct 2012) | 7 lines chan_misdn: Remove unused bchan
+ states Patches: patch2_unused-states.diff (license #6372) patch
+ uploaded by Guenther Kelleter JIRA ABE-2882 ................
+ r374517 | rmudgett | 2012-10-04 18:17:51 -0500 (Thu, 04 Oct 2012)
+ | 16 lines chan_misdn: Remove unnecessary null pointer checks and
+ checks for stack->nt * cleanup_bc() is always called with valid
+ bc (or it would've crashed before). * Value of stack->nt is known
+ in advance at some places. * Rename handle_event() to
+ handle_event_te(), handle_frm() to handle_frm_te(). Patches:
+ patch3_checks.diff (license #6372) patch uploaded by Guenther
+ Kelleter Modified JIRA ABE-2882 ................ r374518 |
+ rmudgett | 2012-10-04 18:21:59 -0500 (Thu, 04 Oct 2012) | 7 lines
+ chan_misdn: Fix spelling in log messages Patches:
+ patch4_spelling.diff (license #6372) patch uploaded by Guenther
+ Kelleter JIRA ABE-2882 ................ r374519 | rmudgett |
+ 2012-10-04 18:31:59 -0500 (Thu, 04 Oct 2012) | 15 lines
+ chan_misdn: Don't cleanup a bc twice. In handle_frm_te() after
+ calling misdn_lib_send_event(bc, EVENT_RELEASE_COMPLETE) bc is
+ emptied, cleaned and set not in use, although
+ misdn_lib_send_event() already did the same. This is bad. When
+ it's not in use we are not allowed to touch it. * Moved log
+ message in front of the resulting actions and fixed it to match
+ the case. Patches: patch5_bccleanup.diff (license #6372) patch
+ uploaded by Guenther Kelleter JIRA ABE-2882 ................
+ r374520 | rmudgett | 2012-10-04 18:43:56 -0500 (Thu, 04 Oct 2012)
[... 41081 lines stripped ...]
More information about the asterisk-commits
mailing list