git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254801 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254799 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254718 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  r254714 | qwell | 2010-03-25 14:39:23 -0500 (Thu, 25 Mar 2010) | 4 lines
  
  Fix DEBUG_THREADS issue with out-of-tree modules.
  
  Take 2, without ABI breakage this time.
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254715 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254638 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The ast_channel structure had a field used for linking a channel into a
linked list, but now that ast_channel structures are ao2 objects, this is
no longer needed, and could be harmful as ao2 objects really shouldn't
ever be placed into linked lists (since those lists don't assist with
reference count management on the objects).


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254637 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254636 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There are two unit tests contained here.

1. "Invalid ACL" This attempts to read a bunch of badly formatted ACL entries
and add them to a host access rule. The goal of this test is to be sure that
all invalid entries are rejected as they should be.

2. "ACL" This sets up four ACLs. One is a permit all, one is a deny all, and
the other two have specific rules about which subnets are allowed and which
are not. Then a set of test addresses is used to determine whether we would
allow those addresses to access us when each ACL is applied. This test, by the
way, was what resulted in AST-2010-003's creation.

Review: https://reviewboard.asterisk.org/r/532



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254557 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r254552 | mmichelson | 2010-03-25 12:33:35 -0500 (Thu, 25 Mar 2010) | 5 lines
  
  Add doxygen for acl.h
  
  Review: https://reviewboard.asterisk.org/r/528
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254553 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This adds rtpsource options analogous to the rtpdest
functions that already exist. In addition, this fixes
potential crashes which could result due to trying to
read values from nonexistent RTP streams.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254551 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines
  
  Several fixes regarding RFC2833 DTMF detection.
  
  Here is a copy and paste of the details from my request on
  reviewboard that dealt with these changes:
  
  Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:
  
  seqno 1: DTMF 1
  seqno 2: DTMF 1
  seqno 3: DTMF 1
  seqno 4: DTMF 1
  seqno 6: DTMF 1 (end)
  seqno 5: DTMF 1
  seqno 7: DTMF 1 (end)
  seqno 8: DTMF 1 (end)
  
  Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:
  
  seqno  9: DTMF 1
  seqno 10: DTMF 1 (end)
  seqno 11: DTMF 1 (end)
  seqno 13: DTMF 2
  seqno 12: DTMF 1 (end)
  seqno 14: DTMF 2
  seqno 15: DTMF 2 (end)
  seqno 16: DTMF 2 (end)
  seqno 17: DTMF 2 (end)
  
  In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.
  
  Fix 2. The second change in place is to fix an issue like the following:
  
  seqno 1: DTMF 1
  seqno 2: DTMF 1
  seqno 3: DTMF 1 (end) *packet lost*
  seqno 4: DTMF 1 (end) *packet lost*
  seqno 5: DTMF 1 (end) *packet lost*
  seqno 6: DTMF 2
  
  When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.
  
  Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254454 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r254451 | twilson | 2010-03-25 10:57:29 -0500 (Thu, 25 Mar 2010) | 2 lines
  
  Handle new SRCCHANGE control message here too
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254453 65c4cc65-6c06-0410-ace0-fbb531ad65f3

application is executing on a channel.

This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.

This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.

This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).

This patch also modifies res_fax to take advantage of the new request.

In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.

This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.

Review: https://reviewboard.asterisk.org/r/556/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Update code to reflect that handle_speechset has 4 arguments.

(closes issue #17093)
Reported by: gpatri
Patches: 
      res_agi.patch uploaded by gpatri (license 1014)
Tested by: pabelanger, mmichelson

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254446 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch removes some cases where the channel number for an ioctl was
passed as a member in a struct rather then through the file descriptor.

The gain setting functions passed around a channel which is always 0,
and thus this parameter is simply dropped.

Review: https://reviewboard.asterisk.org/r/584/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254406 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Here is a cut and paste of my review request for this change:
This past weekend, Russell ran our current suite of unit tests for Asterisk
under valgrind. The PBX pattern match test caused valgrind to spew forth two
invalid read errors. This patch contains two changes that shut valgrind up and
do not cause any new memory leaks.

Change 1: In ast_context_remove_extension_callerid2, valgrind reported an
invalid read in the for loop close to the function's end. Specifically, one of
the the strcmp calls in the loop control was reading invalid memory. This was
because the caller of ast_context_remove_extension_callerid2 (__ast_context
destroy in this case) passed as a parameter a shallow copy of an ast_exten's
exten field. This same ast_exten was what was destroyed inside the for loop,
thus any iterations of the for loop beyond the destruction of the ast_exten
would result in invalid reads. My fix for this is to make a copy of the
ast_exten's exten field and pass the copy to
ast_context_remove_extension_callerid2. In addition, I have also acted
similarly with the ast_exten's matchcid field. Since in this case a NULL is
handled quite differently than an empty string, I needed to be a bit more
careful with its handling.

Change 2: In __ast_context_destroy, we iterated over a hashtab and called
ast_context_remove_extension_callerid2 on each item. Specifically, the hashtab
over which we were iterating was an ast_exten's peer_table. Inside of
ast_context_remove_extension_callerid2, we could possibly destroy this
ast_exten, which also caused the hashtab to be freed. Attempting to call
ast_hashtab_end_traversal on the hashtab iterator caused an invalid read to
occur when trying to read the iterator->tab->do_locking field since
iterator->tab had already been freed. My handling of this problem is a bit less
straightforward. With each iteration over the hashtab's contents, we set a
variable called "end_traversal" based on the return of
ast_context_remove_extension_callerid2. If 0 is ever returned, then we know
that the extension was found and destroyed. Because of this, we cannot call
ast_hashtab_end_traversal because we will be guaranteeing a read of invalid
memory. In such a case, we forego calling ast_hashtab_end_traversal and instead
call ast_free on the hashtab iterator.

Review: https://reviewboard.asterisk.org/r/585



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254362 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Previously only configurable globally. A unit test has also been written to 
provide protection against parse failures for supported mailbox options.

(closes issue #16864)
Reported by: kobaz
Patches: 
      voicemail2.patch uploaded by kobaz (license 834)

Review: https://reviewboard.asterisk.org/r/555/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254321 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r254235 | jpeeler | 2010-03-23 19:37:23 -0500 (Tue, 23 Mar 2010) | 72 lines
  
  Ensure that monitor recordings are written to the correct location (again)
  
  This is an extension to 248860. As such the dialplan test has been extended:
  
  ; non absolute path, not combined
  exten => 5040, 1, monitor(wav,tmp/jeff/monitor_test)
  exten => 5040, n, dial(sip/5001)
  ; absolute path, not combined
  exten => 5041, 1, monitor(wav,/tmp/jeff/monitor_test2)
  exten => 5041, n, dial(sip/5001)
  ; no path, not combined
  exten => 5042, 1, monitor(wav,monitor_test3)
  exten => 5042, n, dial(sip/5001)
  ; combined: changemonitor from non absolute to no path (leaves tmp/jeff)
  exten => 5043, 1, monitor(wav,tmp/jeff/monitor_test4,m)
  exten => 5043, n, changemonitor(monitor_test5)
  exten => 5043, n, dial(sip/5001)
  ; combined: changemonitor from no path to non absolute path
  exten => 5044, 1, monitor(wav,monitor_test6,m)
  exten => 5044, n, changemonitor(tmp/jeff/monitor_test7) ; this wasn't possible before
  exten => 5044, n, dial(sip/5001)
  ; non absolute path, combined
  exten => 5045, 1, monitor(wav,tmp/jeff/monitor_test8,m)
  exten => 5045, n, dial(sip/5001)
  ; absolute path, combined 
  exten => 5046, 1, monitor(wav,/tmp/jeff/monitor_test9,m)
  exten => 5046, n, dial(sip/5001)
  ; no path, combined
  exten => 5047, 1, monitor(wav,monitor_test10,m)
  exten => 5047, n, dial(sip/5001)
  ; combined: changemonitor from non absolute to absolute (leaves tmp/jeff)
  exten => 5048, 1, monitor(wav,tmp/jeff/monitor_test11,m)
  exten => 5048, n, changemonitor(/tmp/jeff/monitor_test12)
  exten => 5048, n, dial(sip/5001)
  ; combined: changemonitor from absolute to non absolute (leaves /tmp/jeff)
  exten => 5049, 1, monitor(wav,/tmp/jeff/monitor_test13,m)
  exten => 5049, n, changemonitor(tmp/jeff/monitor_test14)
  exten => 5049, n, dial(sip/5001)
  ; combined: changemonitor from no path to absolute
  exten => 5050, 1, monitor(wav,monitor_test15,m)
  exten => 5050, n, changemonitor(/tmp/jeff/monitor_test16)
  exten => 5050, n, dial(sip/5001)
  ; combined: changemonitor from absolute to no path (leaves /tmp/jeff)
  exten => 5051, 1, monitor(wav,/tmp/jeff/monitor_test17,m)
  exten => 5051, n, changemonitor(monitor_test18)
  exten => 5051, n, dial(sip/5001)
  ; not combined: changemonitor from non absolute to no path (leaves tmp/jeff)
  exten => 5052, 1, monitor(wav,tmp/jeff/monitor_test19)
  exten => 5052, n, changemonitor(monitor_test20)
  exten => 5052, n, dial(sip/5001)
  ; not combined: changemonitor from no path to non absolute
  exten => 5053, 1, monitor(wav,monitor_test21)
  exten => 5053, n, changemonitor(tmp/jeff/monitor_test22)
  exten => 5053, n, dial(sip/5001)
  ; not combined: changemonitor from non absolute to absolute (leaves tmp/jeff)
  exten => 5054, 1, monitor(wav,tmp/jeff/monitor_test23)
  exten => 5054, n, changemonitor(/tmp/jeff/monitor_test24)
  exten => 5054, n, dial(sip/5001)
  ; not combined: changemonitor from absolute to non absolute (leaves /tmp/jeff)
  exten => 5055, 1, monitor(wav,/tmp/jeff/monitor_test24)
  exten => 5055, n, changemonitor(tmp/jeff/monitor_test25)
  exten => 5055, n, dial(sip/5001)
  ; not combined: changemonitor from no path to absolute
  exten => 5056, 1, monitor(wav,monitor_test26)
  exten => 5056, n, changemonitor(/tmp/jeff/monitor_test27)
  exten => 5056, n, dial(sip/5001)
  ; not combined: changemonitor from absolute to no path (leaves /tmp/jeff)
  exten => 5057, 1, monitor(wav,/tmp/jeff/monitor_test28)
  exten => 5057, n, changemonitor(monitor_test29)
  exten => 5057, n, dial(sip/5001)
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254277 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17086)
Reported by: tzafrir
Patches:
      asterisk_extra_settings_dirs.diff uploaded by tzafrir (license 46)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254162 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254159 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This changes native bridging to break one millisecond early so that the more
accurate timeval calculations done in the generic bridge can be performed using
the bridge config. Currently the time between exiting native bridging slightly
late can sometimes cause a large enough discrepancy for warnings to be missed.
For the record, 1.4 does not attempt to native bridge at all when warnings are
enabled.

(closes issue #15815)
Reported by: adomjan

Review: https://reviewboard.asterisk.org/r/577/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254050 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
  r254046 | qwell | 2010-03-23 16:07:54 -0500 (Tue, 23 Mar 2010) | 9 lines
  
  Allow out-of-tree modules to load, regardless of DEBUG_THREADS/DEBUG_CHANNEL_LOCKS differences.
  
  This can be guaranteed by forcing the ABI to no longer change when these compiler flags are set.
  An unfortunate side-effect to this is that there is an ABI change here.  However, there is some
  mitigation.  Existing modules *will* fail to load since they would require functions that no
  longer exist.
  
  Review: https://reviewboard.asterisk.org/r/508/
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254047 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #15494)
Reported by: makoto


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254045 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254001 65c4cc65-6c06-0410-ace0-fbb531ad65f3

fwrite returns the number of items written, not the number of bytes


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253958 65c4cc65-6c06-0410-ace0-fbb531ad65f3

users expect them to work.

'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.

This patch changes this functionality to be module-name based instead
of file-name based.

To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.

Review: https://reviewboard.asterisk.org/r/574/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253917 65c4cc65-6c06-0410-ace0-fbb531ad65f3

We can have bad results when a module, upon being loaded, attempts
to reference the channels container if the container hasn't yet
been initialized. I saw this happen by trying to preload pbx_config.so
and having a hint defined which referenced a non-existent SIP peer.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253872 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r253799 | mnicholson | 2010-03-22 14:50:00 -0500 (Mon, 22 Mar 2010) | 4 lines
  
  Unconditionally copy the caller's account code to the called party.
  
  (related to issue #16331)
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253800 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253758 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Debugging with mmichelson.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253755 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253712 65c4cc65-6c06-0410-ace0-fbb531ad65f3

ast_str_reset() was being called on a potentially uninitialized pointer.
Valgrind is my hero, once again.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253579 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253540 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253539 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253538 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253537 65c4cc65-6c06-0410-ace0-fbb531ad65f3

These changes fix build issues I had with this module on FreeBSD.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253536 65c4cc65-6c06-0410-ace0-fbb531ad65f3

internal_ao2_ref uses INTERNAL_OBJ which mzy report 'bad magic number', but
internal_ao2_ref continues on, causing segfault.

Although AO2_MAGIC number is checked by INTERNAL_OBJ before internal_ao2_ref is
called, A02_MAGIC is being destroyed (or a wrong pointer) by the time
internal_ao2_ref uses INTERNAL_OBJ.

internal_ao2_ref now returns -1 if INTERNAL_OBJ encouters a bad magic number.

(issue #17037)
Reported by: alecdavis
Patches:
      bug17037.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis




git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253490 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253378 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17049)
Reported by: russell
Tested by: russell

Review: https://reviewboard.asterisk.org/r/573/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253357 65c4cc65-6c06-0410-ace0-fbb531ad65f3