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

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

........
  r177225 | murf | 2009-02-18 15:43:14 -0700 (Wed, 18 Feb 2009) | 34 lines
  
  This patch fixes a regression of sorts that was introduced in 
  rev 24425.
  
  It basically fixes AST-190/ABE-1782.
  
  What was wrong: the user has 6000 extensions in one context; and
  then 6000 contexts, one per extension. The parser could only handle
  about 4893 of the 6000 extens in the single context.
  
  This was due to the regression I mentioned. To get rid of
  shift/reduce conflicts, Luigi set up right-recursive lists
  for globals, context elements, switch lists, and statements.
  Right recursive lists got rid of the warnings, but instead, they
  use up a tremendous amount of stack space when the lists are long.
  
  I saw this a few years back, and resolved not to fix it until
  someone complained. That day has arrived!
  
  After the changes were made, I ran the regression test suite,
  and there were no problems.
  
  I took the test case the user provided, and added 100,000 
  extensions to the single context, that already had 6,000 extens
  in it. (I'll see your 6, and raise you 100!) It takes a few minutes
  to read it all in, check it and generate code for it, but no
  problems.
  
  So, I think I can say that fundamentally, there are no longer
  any limits on the number of items you can place in contexts,
  statement blocks, switches, or globals, beyond your virt mem
  constraints.
........


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

fix two very minor bugs: if anyone ever uses SLINEAR16 as a format in RTP, ensure that the samples are byte-swapped to network order if needed. also, when a smoother is operating on a format that has a sample rate other than 8000 samples per second, use the proper sample rate for computing delivery timestamps.



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

action_bridge() and bridge_exec() both search for the channels to bridge to, and then immediately drop the lock.  Instead, they should hold the lock until the masquerade is complete.  This will guarantee the channel remains and prevent any other weirdness from occurring.  In action_bridge() some more weirdness comes into play.  Both channels are needlessly locked at the same time and perform the exact same logic.  It makes sense from a coding organizational standpoint, but could cause a theoretical deadlock so I split the code up.  There is an issue associated with this, but since its a rather complicated thing to reproduce I'm not certain this alone will close it.

issue# 14296
Review: http://reviewboard.digium.com/r/167/




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

Several changes in PTLib have occurred requiring build time detection. Changes
accounted for include the library name change, config option change, install
location change, and a boolean type change which is handled by ast_ptlib.h.
Also, the sed check has been modified to properly work with autoconf >= 2.62.

(closes issue #14224)
Reported by: bergolth
Patches:
      asterisk-autoconf-sed.patch uploaded by bergolth (license 661)
      asterisk-pwlib-v3.patch uploaded by bergolth (license 661)
Tested by: jpeeler


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

........
  r177160 | jpeeler | 2009-02-18 14:06:45 -0600 (Wed, 18 Feb 2009) | 15 lines
  
  Modify h323 to build against PTLib as well as the older PWLib
  
  Several changes in PTLib have occurred requiring build time detection. Changes
  accounted for include the library name change, config option change, install
  location change, and a boolean type change which is handled by ast_ptlib.h.
  Also, the sed check has been modified to properly work with autoconf >= 2.62.
  
  (closes issue #14224)
  Reported by: bergolth
  Patches:
        asterisk-autoconf-sed.patch uploaded by bergolth (license 661)
        asterisk-pwlib-v3.patch uploaded by bergolth (license 661)
  Tested by: jpeeler
........


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

Enabling this option by default proved to be a bad idea, as the talker detection
is not very reliable.  So, make it optional again, and off by default.

(issue #13801)
Reported by: justdave


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

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

........
  r177096 | tilghman | 2009-02-18 12:30:38 -0600 (Wed, 18 Feb 2009) | 2 lines
  
  Document the return value of the update method (as requested on -dev list)
........


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

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

(closes issue #14497)
Reported by: vinsik
Patches:
      chan_update_fix-chan_sip.c.diff uploaded by vinsik (license 623)


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

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

This patch fixes merge_contexts_and_delete so it does not deadlock when hints are present.

Reason: when I re-engineered the merge_and_delete func to
reduce its lock time, I failed to notice that the 
functions it calls still also do locking as before.
This leads to deadlocks on dialplan reloads, when
there are actually living, subscribed hints registered
in the system.

While the reporter come across this problem while using
AEL, I might note that these deadlocks should also happen
if extensions.conf were used.

Here I added these routines to pbx.c:

ast_add_extension_nolock
add_pri_lockopt
ast_add_extension2_lockopt
find_context
add_hint_nolock

All of the above routines are static and restricted
to be used only within pbx.c, and more specifically
within the merge_contexts_and_delete routine.

They are pretty much the same as their counterparts
except they don't lock contexts or hints.

Most of them now do the real work of their
name-alike, with optional locking via extra arguments,
and are called by their name-alike. The goal was to
have the original functions so they would behave
exactly as before.

Both PJ and I tested these fixes, and the deadlocking
problem is no longer encountered.

(closes issue #14357)
Reported by: pj
Patches:
      14357.diff uploaded by murf (license 17)
Tested by: pj, murf



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

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

The big problem here is that the 3rd argument provided in these uses of strncpy()
did not reserve a byte for the null terminator, leaving the potential for writing
one byte past the end of the buffer.

Aside from this, there were coding guidelines violations with regards to spacing,
as well as hard coded lengths being used instead of sizeof().


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

The previous implementation of T38 faxdetect resulted in both sides of the
call jumping to a fax extension when both sides had 't38pt_udptl=yes' and
'faxdetect=yes' in sip.conf and a 'fax' extension in the current context.
This revision will jump to a 'fax' extension on incoming calls only.


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

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

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

This commit brings in the changes that were living out on the
svn/asterisk/team/sruffell/asterisk-trunk-transcoder branch.  codec_dahdi.c now
always uses signed linear as the simple codec so that a soft g729 codec will
not end up being preferred to the hardware codec.  There are also changes to
allow codec_dahdi.c to feed packets to the hardware in the native sample size of
the codec.  This solves problems with choppy audio when using G723. 



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

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

........
  r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
  
  Modify bridging to properly evaluate DTMF after first warning is played
  
  The main problem is currently if the Dial flag L is used with a warning sound,
  DTMF is not evaluated after the first warning sound. To fix this, a flag has 
  been added in ast_generic_bridge for playing the warning which ensures that if
  a scheduled warning is missed, multiple warrnings are not played back (due to a
  feature evaluation or waiting for digits). ast_channel_bridge was modified to
  store the nexteventts in the ast_bridge_config structure as that information
  was lost every time ast_channel_bridge was reentered, causing a hangup due to
  incorrect time calculations.
  
  (closes issue #14315)
  Reported by: tim_ringenbach
 
  Reviewed on reviewboard:
  http://reviewboard.digium.com/r/163/
........


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

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

This is required to create a UDPTL structure in create_addr_from_peer() to handle the
scenario where 't38pt_udptl=yes' is not defined in the [general] section of sip.conf but 
is defined the peer's context.  I tested this patch by enabling t38pt_udptl in the 
[general] section on one system and only enabling t38pt_udptl in a peer's context on
the system sending a fax.  Without the patch, the sending system will fail to initiate
T38 negotiation with the warning message, "No way to add SDP without an UDPTL structure".
When this patch is applied the sending side will successfully initiate T38 negotiation.



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

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

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

........
  r176661 | tilghman | 2009-02-17 15:21:41 -0600 (Tue, 17 Feb 2009) | 9 lines
  
  Backport change to 1.4:
    Prior to masquerade, move the group definitions to the channel performing the
    masq, so that the group count lingers past the bridge.
    (closes issue #14275)
     Reported by: kowalma
     Patches: 
           20090216__bug14275.diff.txt uploaded by Corydon76 (license 14)
     Tested by: kowalma
........


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

1) Add module use count handling so that timing modules can be unloaded.

2) Implement unload_module() functions for the timing interface modules.

3) Allow multiple timing modules to be loaded, and use the one with the
   highest priority value.

4) Report which timing module is being use in the "timing test" CLI command.

(closes issue #14489)
Reported by: russell

Review: http://reviewboard.digium.com/r/162/


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

masq, so that the group count lingers past the bridge.
(closes issue #14275)
 Reported by: kowalma
 Patches: 
       20090216__bug14275.diff.txt uploaded by Corydon76 (license 14)
 Tested by: kowalma


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

This patch changes the scheduler to use a max-heap to store pending scheduler
entries instead of a fully sorted doubly linked list.  When the number of
entries in the scheduler gets large, this will perform much better.  For much
more detailed information on this change, see the review request.

Review: http://reviewboard.digium.com/r/160/


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

Review: http://reviewboard.digium.com/r/160/


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

A heap is a convenient data structure for implementing a priority queue.

Code from svn/asterisk/team/russell/heap/.

Review: http://reviewboard.digium.com/r/160/


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

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

This patch includes a number of changes to the indications API.  The primary
motivation for this work was to improve stability.  The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.

The changes included are:

1) Remove the module res_indications.  This included the critical functionality
   that actually loaded the indications configuration.  I have seen many people
   have Asterisk problems because they accidentally did not have an
   indications.conf present and loaded.  Now, this code is in the core,
   and Asterisk will fail to start without indications configuration.

   There was one part of res_indications, the dialplan applications, which did
   belong in a module, and have been moved to a new module, app_playtones.

2) Object management has been significantly changed.  Tone zones are now
   managed using astobj2, and it is no longer possible to crash Asterisk by
   issuing a reload that destroys tone zones while they are in use.

3) The API documentation has been filled out.

4) The API has been updated to follow our naming conventions.

5) Various bits of code throughout the tree have been updated to account
   for the API update.

6) Configuration parsing has been mostly re-written.

7) "Code cleanup"

The code is from svn/asterisk/team/russell/indications/.

Review: http://reviewboard.digium.com/r/149/


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

(closes issue #14485)
 Reported by: davevg


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

The problem here is that the hint processing code was subscribed to the wrong
event type.  So, it started processing state for a hint too soon, before the
device state cache had been updated.

Also, fix a similar bug in app_queue, as it was also subscribed to the wrong
event type.

(closes issue #14461)
Reported by: alecdavis


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

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

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

nonexistent columns.


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

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

........
  r176426 | tilghman | 2009-02-16 18:49:22 -0600 (Mon, 16 Feb 2009) | 10 lines
  
  After a 'sip reload', qualifies for realtime peers weren't immediately
  restarted, instead waiting until the next registration.  We're now
  caching the qualify across a reload/restart and starting the qualify
  immediately upon loading the peer.
  (closes issue #14196)
   Reported by: pdf
   Patches: 
         20090120__bug14196_1.4.diff.txt uploaded by pdf (license 663)
   Tested by: pdf
........


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

(closes issue #14485)
 Reported by: davevg


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

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

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

........
  r176354 | dvossel | 2009-02-16 17:30:52 -0600 (Mon, 16 Feb 2009) | 8 lines
  
  Fixes issue with AST_CONTROL_SRCUPDATE not being relayed correctly during bridging
  
  This should have been committed with rev176247, but I missed it.  srcupdate frames no longer break out of the native bridge, but are not being sent to the other call leg either.  This fixs that.
  
  issue #13749
........


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

(issue #13777)
 Reported by: pj
 Patches: 
       20090203__bug13777.diff.txt uploaded by Corydon76 (license 14)
 Tested by: pj


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