Updated the doxygen \arg line after looking at the file for some other Asterisk documentation
and noticing they weren't up to date. Thanks to seanbright for looking at the code for me :)

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

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

There were many changes in revision 176627 which would avoid the error that a
missing config would have caused.  Other than this, there are no other config
files (including asterisk.conf, surprisingly) that are required.


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

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

........
  r257856 | jpeeler | 2010-04-19 14:09:46 -0500 (Mon, 19 Apr 2010) | 1 line
  
  make app_voicemail compile with IMAP_STORAGE
........


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

This allows for multiple SRV queries to be done
from the dialplan for the same service on a single call while
still allowing one to bypass the call to SRVQUERY if they so
please.

Taking action since no comments had been left for a while.
This can easily be reverted if needed. External tests
still pass.



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

Because res/res_features.c was removed and main/cdr.c added, these changes
didn't make it to trunk and the 1.6.x branches


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

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

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

........
  r257686 | dhubbard | 2010-04-16 16:15:43 -0500 (Fri, 16 Apr 2010) | 21 lines
  
  Make the mixmonitor thread process audio frames faster
  
  Mantis issue 17078 reports MixMonitor recordings have shorter durations than 
  the call duration.  This was because the mixmonitor thread was not processing 
  frames from the audiohook fast enough.  The mixmonitor thread would slowly fall 
  behind the most recent audio frame and when the channel hangs up, the mixmonitor 
  thread would exit without processing the same number of frames as the channel; 
  leaving the mixmonitor recording shorter than actual call duration.
  
  This revision fixes this issue by moving the ast_audiohook_trigger_wait() and 
  the subsequent audiohook.status check into the block where the 
  ast_audiohook_read_frame() function returns NULL.
  
  (closes issue #17078)
  Reported by: geoff2010
  Patches:
        dw-M17078.patch uploaded by dhubbard (license 733)
  Tested by: dhubbard, geoff2010
  
  Review: https://reviewboard.asterisk.org/r/611/
........


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

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

Revision 1072 of libpri added SERVICE message support for the 'national' 
switchtype. The attached patch enables the use of 'pri service' CLI commands 
on dahdi channels that are configured for the 'national' switchtype.

(closes issue #17142)
Reported by: dhubbard
Patches:
      dw-ni2.patch uploaded by dhubbard (license 733)
Tested by: elguero, dhubbard

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


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

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

........
  r257544 | tilghman | 2010-04-15 16:23:24 -0500 (Thu, 15 Apr 2010) | 6 lines
  
  Allow application options with arguments to contain parentheses, through a variety of escaping techniques.
  
  Fixes SWP-1194 (ABE-2143).
  
  Review: https://reviewboard.asterisk.org/r/604/
........


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

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

........
  r257467 | tilghman | 2010-04-15 15:24:50 -0500 (Thu, 15 Apr 2010) | 13 lines
  
  Don't recreate peer, when responding to a repeated deregistration attempt.
  
  When a reply to a deregistration is lost in transmit, the client retries the
  deregistration.  Previously, this would cause a realtime/autocreate peer to be
  loaded back into memory, after it had already been correctly purged.  Instead,
  we just want to resend the reply without loading the peer.
  
  (closes issue #16908)
   Reported by: kkm
   Patches: 
         20100412__issue16908.diff.txt uploaded by tilghman (license 14)
   Tested by: kkm
........


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

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

........
  r257426 | lmadsen | 2010-04-15 14:40:33 -0500 (Thu, 15 Apr 2010) | 13 lines
  
  Update backtrace.txt documentation.
  
  Update the backtrace.txt documentation so it conforms to the same layout as
  other documents we've been working on recently. Additionally, add a bunch of
  new information about gathering backtraces for crashes and deadlocks, along
  with ways of verifying your file before uploading it. Create a couple of one
  line commands for people to generate the files we need.
  
  (closes issue #17190)
  Reported by: lmadsen
  Patches: 
        backtrace.txt.patch-2 uploaded by lmadsen (license 10)
  Tested by: lmadsen, pabelanger
........


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

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

........
  r257342 | lmadsen | 2010-04-15 08:41:45 -0500 (Thu, 15 Apr 2010) | 1 line
  
  Update address of the bug tracker.
........


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

........
  r257266 | tilghman | 2010-04-14 18:08:11 -0500 (Wed, 14 Apr 2010) | 10 lines
  
  When forwarding a message, ensure that prepending works correctly.
  
  This is a regression in 1.4, only.
  
  (closes issue #17103)
   Reported by: mglazer
   Patches: 
         20100408__issue17103.diff.txt uploaded by tilghman (license 14)
   Tested by: tilghman
........


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

Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file.  This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.

(closes issue #16646)
 Reported by: pinga-fogo
 Patches: 
       20100414__issue16646.diff.txt uploaded by tilghman (license 14)
 Tested by: tilghman
 
Review: https://reviewboard.asterisk.org/r/547/


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

(closes issue #16774)
 Reported by: kowalma
 Patches: 
       20100315__issue16774.diff.txt uploaded by tilghman (license 14)
 Tested by: falves11, jamicque

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


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

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

........
  r257070 | mnicholson | 2010-04-13 11:46:30 -0500 (Tue, 13 Apr 2010) | 9 lines
  
  Add an option to restore past broken behavor of the Events manager action
  
  Before r238915, certain values for the EventMask parameter of the Events action would result in no response being returned.  This patch adds an option to restore that broken behavior.  Also while fixing this bug I discovered that passing an empty EventMasks parameter would also result in no response being returned, this has been fixed as well while being preserved when the broken behavior is requested.
  
  (closes issue #17023)
  Reported by: nblasgen
  
  Review: https://reviewboard.asterisk.org/r/602/
........


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

(closes issue #17001)
 Reported by: snuffy
 Patches: 
       20100412__issue17001.diff.txt uploaded by tilghman (license 14)
 Tested by: snuffy


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

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

 
* Change copyright date
* Place channel in autoservice when doing SRV lookup
* Get rid of trailing whitespace
* Change logic in load_module function



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

Specifically, the situation would happen when multiple
callers would request CC for a single generically-monitored
device. If the monitored device became available but the
caller did not answer the recall, then there was nothing
that would poke the CC core to let it know that it should
attempt to recall someone else instead.

After careful consideration, I came to the conclusion that
the only area of Asterisk that needed to be touched was the
generic CC monitor. All other types of CC would require something
outside of Asterisk to invoke a recall for a separate device.

This was accomplished by changing the generic monitor destructor
to poke other generic monitor instances if the device is currently
available and the specific instance was currently not suspended.

In order to not accidentally trigger recalls at bad times, the
fit_for_recall flag was also added to the generic_monitor_instance_list
struct. This gets set as soon as a monitored device becomes available.
It gets cleared if a CCNR request triggers the creation of a new
generic monitor instance. By doing this, we don't accidentally try
to recall a device when the monitored device was being monitored
for CCNR and never actually became available for recall in the first
place.

This error was discovered by Steve Pitts during in-house testing
at Digium.



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

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

........
  r256900 | lmadsen | 2010-04-12 12:29:26 -0500 (Mon, 12 Apr 2010) | 15 lines
  
  Add How-To document on collecting debugging info for issues.asterisk.org
  
  Paul Belanger has been helping a lot with bug tracking recently and created
  this document that we can now point to when additional debugging information
  is required. This document will help those filing issues to know how to get
  the information required when filing their issues. This will make things
  easier on the developers.
  
  Initial text and changes by pabelanger. Tweaks and editing by myself.
  
  (closes issue #17159)
  Reported by: pabelanger
  Patches: 
        HOWTO_collect_debug_information.txt.patch uploaded by lmadsen (license 10)
  Tested by: tzafrir, pabelanger, lmadsen
........


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

(issue #17159)

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

To guarantee the channel is valid when calling setvar on the MASTER_CHANNEL
dialplan function, a channel reference must be taken before unlocking. Thanks
to russell for pointing out the error.



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

A simple patch to enable auto tab complete.

(closes issue #17152)
Reported by: pabelanger
Patches: 
      0017152.patch uploaded by pabelanger (license 224)

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

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

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

In troff '-' is used for a hyphen. A minus is denoted by '\-' . This is
normally also used for a dash.

This patch converts all '-'-s that are minuses or dashes to '\-'.


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

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

Call completion code tries to grab the call completion parameters
from the requesting channel during local_request. When originating
a call to a local channel, however, this channel is NULL. This
was causing an issue for me when trying to run a test script.



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

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

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

From the original issue report opened by Nick Lewis:
Many sip headers in many sip methods contain the ABNF structure
 name-andor-addr = name-addr / addr-spec
 Examples include the to-header, from-header, contact-header, replyto-header

 At the moment chan_sip.c makes various different attempts to parse this name-andor-addr structure for each header type and for each sip method with sometimes limited degrees of success.

 I recommend that this name-andor-addr structure be parsed by a dedicated function and that it be used irrespective of the specific method or header that contains the name-andor-addr structure

Nick has also included unit tests for verifying these routines as well, so...heck yeah.

(closes issue #16708)
Reported by: Nick_Lewis
Patches:
      reqresp_parser-nameandoraddr2.patch uploaded by Nick Lewis (license 657

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



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

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

From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:

1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
   multiple calls to the same device. This proved to not be such a good idea
   when implementing protocol-specific monitors, and so we ended up using one
   monitor per-device per-call.
3. There are some configuration options which were conceived after the document
   was written. These are documented in the ccss.conf.sample that is on this
   review request.
		      
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.

This implements CCBS and CCNR in several flavors.

First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.

Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:

* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
  what is defined in the referenced draft.

* Implementation of the draft required support for SIP PUBLISH. I attempted to write
  this in a generic-enough fashion such that if someone were to want to write PUBLISH
  support for other event packages, such as dialog-state or presence, most of the effort
  would be in writing callbacks specific to the event package.

* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
  parser. The PIDF support added is a bit minimal. I first wrote a validation
  routine to ensure that the PIDF document is formatted properly. The rest of the
  PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
  code. In other words, while there is PIDF support here, it is not in any state
  where it could easily be applied to other event packages as is.

Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.

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


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

From Review Board:
There are two interrelated changes here.

First, there is the introduction of func_srv. This adds two new read-only
dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the
ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV
records instead. In order to facilitate this work, I added a couple of new API
calls to srv.h. ast_srv_get_record_count tells the number of records returned
by an SRV lookup. This number is calculated at the time of the SRV lookup.
ast_srv_get_nth_record allows one to get a numbered SRV record.

Second, there is the modification to chan_sip that allows one to specify a
hostname or IP address (along with a port) to send an outgoing INVITE to when
dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV
records and then use the host and port from the results to dial via a specific
host instead of what is configured in sip.conf.

Review: https://reviewboard.asterisk.org/r/608
SWP-1200



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

  
Using wildcard matching in the Makefile is not adequate to determine whether
an export file should exist for a module or not, so instead we'll just
create one if the module needs one, or copy the default one if it does not.


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

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