Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?".  After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.

For more information about why a module goes in addons, see README-addons.txt.

chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.


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

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

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

........
  r204300 | mmichelson | 2009-06-29 17:45:34 -0500 (Mon, 29 Jun 2009) | 9 lines
  
  Add error message so that it is clear why a SIP peer was not processed when
  a DNS lookup fails on a host or outboundproxy.
  
  (closes issue #13432)
  Reported by: p_lindheimer
  Patches:
        outboundproxy.patch uploaded by p (license 558)
........


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

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

........
  r204243 | mmichelson | 2009-06-29 16:23:43 -0500 (Mon, 29 Jun 2009) | 22 lines
  
  Fix a problem where chan_sip would ignore "old" but valid responses.
  
  chan_sip has had a problem for quite a long time that would manifest when
  Asterisk would send multiple SIP responses on the same dialog before receiving
  a response. The problem occurred because chan_sip only kept track of the highest
  outgoing sequence number used on the dialog. If Asterisk sent two requests out,
  and a response arrived for the first request sent, then Asterisk would ignore
  the response. The result was that Asterisk would continue retransmitting the
  requests and ignoring the responses until the maximum number of retransmissions
  had been reached.
  
  The fix here is to rearrange the code a bit so that instead of simply comparing
  the sequence number of the response to our latest outgoing sequence number, we
  walk our list of outstanding packets and determine if there is a match. If there is,
  we continue. If not, then we ignore the response.
  
  In doing this, I found a few completely useless variables that I have now removed.
  
  (closes issue #11231)
  Reported by: flefoll

  Review: https://reviewboard.asterisk.org/r/298
........
  r204246 | mmichelson | 2009-06-29 16:37:05 -0500 (Mon, 29 Jun 2009) | 3 lines
  
  Fix build oops.
........


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

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

........
  r204170 | tilghman | 2009-06-29 14:36:01 -0500 (Mon, 29 Jun 2009) | 3 lines
  
  Revision 189537 was supposed to make 1.4 more correct.  Instead, it broke func_odbc.  Reverting.
  (closes issue #15317, issue #14614)
........


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

Also, the code in this module is horrendous and we should remove it from the
tree.  I'm not sure who is supposed to be maintaning this thing, but they
clearly are not.  I don't see the sense of leaving it in the main tree.  If it
lives *anywhere* it should be in addons.


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

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

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

This might seem like a legitimate comment that merely needed semicolon
prefixes, but in reality, the adaptive layer is designed to allow arbitrary
CDR variables, without needing the use of a userfield to store multiple items.
It's therefore not only invalid syntax but also goes against the intent of the
adaptive method.


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

........
  r204012 | mmichelson | 2009-06-29 10:04:17 -0500 (Mon, 29 Jun 2009) | 6 lines
  
  Place unlock of mutex in an else block so that it does not get unlocked twice.
  
  (closes issue #15400)
  Reported by: aragon
........


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

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

(closes issue #2264)
Reported by: pfn
Patches:
      silent-vm-1.6.2-fix2.txt uploaded by pfn (license 810)
Tested by: pfn


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

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

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

........
  r203908 | rmudgett | 2009-06-26 19:55:12 -0500 (Fri, 26 Jun 2009) | 16 lines
  
  The ISDN CPE side should not exclusively pick B channels normally.
  
  Before this patch, Asterisk unconditionally picked B channels exclusively
  on the CPE side and normally allowed alternative B channels on the network
  side.  Now Asterisk does the opposite.
  
  Reasons for the CPE side to normally not pick B channels exclusively:
  *  For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
  not have enough information to exclusively pick B channels.  (There may be
  other devices on the line.)
  *  Q.931 gives preference to the network side picking B channels.
  *  Some telcos require the CPE side to not pick B channels exclusively.
  
  (closes issue #14383)
  Reported by: mbrancaleoni
........


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

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

........
  r203848 | jpeeler | 2009-06-26 17:09:19 -0500 (Fri, 26 Jun 2009) | 5 lines
  
  Make sure to recreate the dahdi pseudo channel after dahdi restart
  
  (closes issue #14477)
  Reported by: timking
........


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

The original patch for this was written by Brett Bryant, and I split it out into
it's own module.

(closes issue #12876)
Reported by: bbryant
Patches:
      06162008_cdr_custom_syslog.diff uploaded by bbryant (license 36)
      05212009_cdr_syslog.patch uploaded by seanbright (license 71)
Tested by: seanbright

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


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

(closes issue #14594)
Reported by: JimDickenson
Patches:
      chanspy.diff uploaded by JimDickenson (license 710)


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

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

........
  r203785 | russell | 2009-06-26 16:16:39 -0500 (Fri, 26 Jun 2009) | 15 lines
  
  Don't fast forward past the end of a message.
  
  This is nice change for users of the voicemail application.  If someone gets a
  little carried away with fast forwarding through a message, they can easily
  get to the end and accidentally exit the voicemail application by hitting the
  fast forward key during the following prompt.
  
  This adds some safety by not allowing a fast forward past the end of a message.
  
  (closes issue #14554)
  Reported by: lacoursj
  Patches:
        21761.patch uploaded by lacoursj (license 707)
  Tested by: lacoursj
........


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

(closes issue #14596)
Reported by: JimDickenson
Patches:
      pong2.diff uploaded by JimDickenson (license 710)



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

(closes issue #14452)
Reported by: umberto71


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

Fix the 'nat' option to actually do RFC3581 as expected and extend the configurable values for finer control.

(closes issue #8855)
Reported by: mikma
Tested by: klaus3000, file


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

Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
as seconds.

Also, the inequality was reversed. The warning, if triggered, was "Max silence should 
be less than minmessage or you may get empty messages", which should have been logged 
if max silence was greater than minmessage, but the check was for less than.

Also, conforming if statement to coding guidelines.

closes issue #15331)
Reported by: markd

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


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

........
  r203719 | dbrooks | 2009-06-26 15:03:42 -0500 (Fri, 26 Jun 2009) | 16 lines
  
  Fixing voicemail's error in checking max silence vs min message length
  
  Max silence was represented in milliseconds, yet vmminsecs (minmessage) was represented
  as seconds.
  
  Also, the inequality was reversed. The warning, if triggered, was "Max silence should 
  be less than minmessage or you may get empty messages", which should have been logged 
  if max silence was greater than minmessage, but the check was for less than.
  
  Also, conforming if statement to coding guidelines.
  
  closes issue #15331)
  Reported by: markd
  
  Review: https://reviewboard.asterisk.org/r/293/
........


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

(closes issue #15404)
Reported by: leobrown
Patches:
      iax_codec_debug.patch uploaded by leobrown (license 541)


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

(closes issue #14413)
Reported by: pj


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

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

after a polarity reversal.

Previously on a polarity switch event chan_dahdi would set the channel
immediately as answered. This would cause problems if a polarity reversal
occurred when the line was picked up as the dial would not have yet occurred. 
Now if the polarity reversal occurs before delay has elapsed after coming off
hook or an answer, it is ignored. Also, some refactoring was done in
_handle_event.

(closes issue #13917)
Reported by: alecdavis
Patches:
      chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis


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

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

CEL is the new system for logging channel events.  This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records.  For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.

Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code.  Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.

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


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

Also change the default casing of the string contants to lowercase.  This really
just saves us from have to lowercase them later when displaying them.


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

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

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

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

This has the pleasant side effect of cleaning up the header inclusion process
in logger.c.


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

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

(issue #15269)


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

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

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

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

........
  r203380 | twilson | 2009-06-25 16:13:10 -0500 (Thu, 25 Jun 2009) | 4 lines
  
  I didn't see that Mark already fixed the underlying issue!
  
  Yay for removing useless code.
........


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