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

................
  r296167 | rmudgett | 2010-11-24 16:49:48 -0600 (Wed, 24 Nov 2010) | 57 lines
  
  Merged revisions 296166 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r296166 | rmudgett | 2010-11-24 16:42:45 -0600 (Wed, 24 Nov 2010) | 50 lines
    
    Merged revisions 296165 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24 Nov 2010) | 43 lines
      
      Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
      
      The FXS connected phone has to have CW/CID support to fail, as it will
      send back a DTMF 'A' or 'D' when it's ready to receive CallerID.  A normal
      phone with no CID never fails.  Also the SIP phone does not hear MOH when
      the CW call is answered.
      
      The DTMF end frame is suppressed when the phone acknowledges the CW signal
      for CID.  The problem is the DTMF begin frame needs to be suppressed as
      well.  The DTMF begin frame is causing SIP to start sending the DTMF RTP
      frames.  Since the DTMF end frame is suppressed, SIP will not stop sending
      those DTMF RTP packets.
      
      * Suppress the DTMF begin and end frames when the channel driver is
      looking for DTMF digits.
      
      * Fixed a couple issues caused by not cleaning up the CID spill if you
      answer the CW call while it is sending the CID spill.
      
      * Fixed not sending CW/CID spill to the phone when the call is natively
      bridged.  (Fixed by not using native bridge if CW/CID is possible.)
      
      * Suppress received audio when sending CW/CID spills.  The other parties
      involved do not need to hear the CW/CID spills and may be confused if the
      CW call is for them.
      
      (closes issue #18129)
      Reported by: alecdavis
      Patches:
            issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664)
      Tested by: alecdavis, rmudgett
      
      
      NOTE:
      
      * v1.4 does not have the main problem fixed by suppressing the DTMF start
      frames.  The other three items fixed are relevant.
      
      * If you really must restore native bridging between analog ports, you
      need to disable CW/CID either by configuring chan_dahdi.conf
      callwaitingcallerid=no or dialing *70 before dialing the number to
      temporarily disable CW.
    ........
  ................
................


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

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

........
  r295747 | rmudgett | 2010-11-19 21:11:15 -0600 (Fri, 19 Nov 2010) | 13 lines
  
  One way audio before answering call waiting call on analog port.
  
  * Analog call waiting Caller ID spills could get stuck resulting in one
  way audio until the waiting call is answered.  This only happens on the
  second (and later) call waiting call if the active call is not the first
  call.
  
  * The CLI/AMI "dahdi show channel" command could report the wrong channel
  information.
  
  Must keep the struct analog_pvt.owner and struct dahdi_pvt.owner pointer
  in sync.
........


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

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

........
  r295516 | rmudgett | 2010-11-19 10:47:11 -0600 (Fri, 19 Nov 2010) | 13 lines
  
  Bring sig_analog extraction more into alignment with orig-trunk/v1.6.2 chan_dahdi.
  
  * Restore SMDI support.
  * Fixed initial value of struct analog_pvt.use_callerid.  It may get
  forced on depending upon other config options.
  * Call analog_dnd() instead of manual inlined code.
  * Removed unused struct analog_pvt.usedistinctiveringdetection.
  * Removed the struct analog_pvt.unknown_alarm flag.  It was really the
  struct analog_pvt.inalarm flag.
  * Use ast_debug() instead of ast_log(LOG_DEBUG).
  * Rename several function's index variable to idx.
  * Some formatting tweaks.
........


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

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

........
  r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
  
  Analog lines do not transfer CONNECTED LINE or execute the interception macros.
  
  Add connected line update for sig_analog transfers and simplify the
  corresponding sig_pri and chan_misdn transfer code.
  
  Note that if you create a three-way call in sig_analog before transferring
  the call, the distinction of the caller/callee interception macros make
  little sense.  The interception macro writer needs to be prepared for
  either caller/callee macro to be executed.  The current implementation
  swaps which caller/callee interception macro is executed after a three-way
  call is created.
  
  Review:	https://reviewboard.asterisk.org/r/996/
  
  JIRA ABE-2589
  JIRA SWP-2372
........


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

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

................
  r293807 | rmudgett | 2010-11-03 13:35:19 -0500 (Wed, 03 Nov 2010) | 34 lines
  
  Merged revisions 293806 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r293806 | rmudgett | 2010-11-03 13:31:57 -0500 (Wed, 03 Nov 2010) | 27 lines
    
    Merged revisions 293805 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r293805 | rmudgett | 2010-11-03 13:23:04 -0500 (Wed, 03 Nov 2010) | 20 lines
      
      Party A in an analog 3-way call would continue to hear ringback after party C answers.
      
      All parties are analog FXS ports.
      1) A calls B.
      2) A flash hooks to call C.
      3) A flash hooks to bring C into 3-way call before C answers.  (A and B hear ringback)
      4) C answers
      5) A continues to hear ringback during the 3-way call. (All parties can hear each other.)
      
      * Fixed use of wrong variable in dahdi_bridge() that stopped ringback on
      the wrong subchannel.
      
      * Made several debug messages have more information.
      
      A similar issue happens if B and C are SIP channels.  B continues to hear
      ringback.  For some reason this only affects v1.8 and trunk.
      
      * Don't start ringback on the real and 3-way subchannels when creating the
      3-way conference.  Removing this code is benign on v1.6.2 and earlier.
    ........
  ................
................


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

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

................
  r293648 | rmudgett | 2010-11-02 16:29:25 -0500 (Tue, 02 Nov 2010) | 20 lines
  
  Merged revisions 293647 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r293647 | rmudgett | 2010-11-02 16:26:30 -0500 (Tue, 02 Nov 2010) | 13 lines
    
    Merged revisions 293639 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r293639 | rmudgett | 2010-11-02 16:24:13 -0500 (Tue, 02 Nov 2010) | 6 lines
      
      Make warning message have more useful information in it.
      
      Change "Unable to get index, and nullok is not asserted" to "Unable to get
      index for '<channel-name>' on channel <number> (<function>(), line
      <number>)".
    ........
  ................
................


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

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

........
  r293530 | rmudgett | 2010-11-01 12:29:30 -0500 (Mon, 01 Nov 2010) | 10 lines
  
  Analog 3-way call would not connect all parties if one was using sig_pri.
  
  Also the "dahdi show channel" would not show the correct 3-way call
  status.
  
  * Synchronized the inthreeway flag between chan_dahdi and sig_analog.
  
  * Fixed a my_set_linear_mode() sign error and made take an analog sub
  channel enum.
........


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

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

................
  r293418 | rmudgett | 2010-10-29 20:53:29 -0500 (Fri, 29 Oct 2010) | 16 lines
  
  Merged revisions 293417 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r293417 | rmudgett | 2010-10-29 20:49:15 -0500 (Fri, 29 Oct 2010) | 9 lines
    
    Merged revisions 293416 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r293416 | rmudgett | 2010-10-29 20:45:49 -0500 (Fri, 29 Oct 2010) | 1 line
      
      Remove some more code that serves no purpose.
    ........
  ................
................


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

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

................
  r293341 | rmudgett | 2010-10-29 19:46:41 -0500 (Fri, 29 Oct 2010) | 16 lines
  
  Merged revisions 293340 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r293340 | rmudgett | 2010-10-29 19:40:10 -0500 (Fri, 29 Oct 2010) | 9 lines
    
    Merged revisions 293339 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r293339 | rmudgett | 2010-10-29 19:34:12 -0500 (Fri, 29 Oct 2010) | 1 line
      
      Remove some code that serves no purpose.
    ........
  ................
................


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

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

................
  r291656 | rmudgett | 2010-10-13 18:45:11 -0500 (Wed, 13 Oct 2010) | 34 lines
  
  Merged revisions 291655 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r291655 | rmudgett | 2010-10-13 18:36:50 -0500 (Wed, 13 Oct 2010) | 27 lines
    
    Merged revisions 291643 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r291643 | rmudgett | 2010-10-13 18:29:58 -0500 (Wed, 13 Oct 2010) | 20 lines
      
      Deadlock between dahdi_exception() and dahdi_indicate().
      
      There is a deadlock between dahdi_exception() and dahdi_indicate() for
      analog ports.  The call-waiting and three-way-calling feature can
      experience deadlock if these features are trying to do something and an
      event from the bridged channel happens at the same time.
      
      Deadlock avoidance code added to obtain necessary channel locks before
      attemting an operation with call-waiting and three-way-calling.
      
      (closes issue #16847)
      Reported by: shin-shoryuken
      Patches:
            issue_16847_v1.4.patch uploaded by rmudgett (license 664)
            issue_16847_v1.6.2.patch uploaded by rmudgett (license 664)
            issue_16847_v1.8_v2.patch uploaded by rmudgett (license 664)
      Tested by: alecdavis, rmudgett
      
      Review: https://reviewboard.asterisk.org/r/971/
    ........
  ................
................


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

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

........
  r286931 | jpeeler | 2010-09-15 14:22:15 -0500 (Wed, 15 Sep 2010) | 16 lines
  
  Add parking extension for non-default parking lots.
  
  This is a new feature that allows for parking to custom parking lots to be
  accessed directly, rather than with channel variables or by changing the
  default parking lot. The extension is set with the parkext option just as the
  default parking lot is done. Also, the manager action has been updated to
  optionally allow a specified parking lot.
  
  (closes issue #14882)
  Reported by: vmikhnevych
  Patches: 
        patch_14882.txt uploaded by mnick (license 874)
        modified by me
  
  Review: https://reviewboard.asterisk.org/r/884/
........


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

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

........
  r286904 | rmudgett | 2010-09-15 13:28:05 -0500 (Wed, 15 Sep 2010) | 12 lines
  
  Unable to originate calls using E&M over T1.
  
  When originating a call from Unit Under Test to Reference Unit using E&M
  RBS signaling mode, I get the following warning message: "Ring/Off-hook in
  strange state 3 on channel 1".
  
  Fixed the sig_analog outgoing flag.  It was never set when sig_analog was
  extracted from chan_dahdi.
  
  JIRA SWP-2191
  JIRA AST-408
........
  r286905 | rmudgett | 2010-09-15 13:29:21 -0500 (Wed, 15 Sep 2010) | 1 line
  
  Simplify some code in sig_analog.
........


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

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

........
  r281870 | rmudgett | 2010-08-11 15:30:29 -0500 (Wed, 11 Aug 2010) | 4 lines
  
  Fix a call to analog_set_pulsedial() not setting 0 or 1 only.
  
  * Also a couple minor tweaks.
........


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

(issue #17318)



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

FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.

Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.

(closes issue #17318)
Reported by: armeniki
Patches: 
      fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

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



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

This fixes some cases of no outgoing calls on FXO before an incoming call.

Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.

If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .

(closes issue #14577)
Reported by: jkroon
Patches:
      asterisk_chan_dahdi_hookstate_fix_trunk_new.diff uploaded by frawd (license 610)
Tested by: frawd

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


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

The issue here is that passing an array to a function prohibits the ARRAY_LEN
macro from returning the real size. To avoid this the size is now defined and
use of ARRAY_LEN is avoided.

(closes issue #15718)
Reported by: alecdavis
Patches: 
      bug15718.patch uploaded by jpeeler (license 325)



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

Expand the ani field in ast_party_caller and ast_party_connected_line to
an ast_party_id.

This is an extension to the ast_callerid restructuring patch in review:
https://reviewboard.asterisk.org/r/702/

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


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

The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.

Eliminate struct ast_callerid and replace it with the following struct
organization:

struct ast_party_name {
	char *str;
	int char_set;
	int presentation;
	unsigned char valid;
};
struct ast_party_number {
	char *str;
	int plan;
	int presentation;
	unsigned char valid;
};
struct ast_party_subaddress {
	char *str;
	int type;
	unsigned char odd_even_indicator;
	unsigned char valid;
};
struct ast_party_id {
	struct ast_party_name name;
	struct ast_party_number number;
	struct ast_party_subaddress subaddress;
	char *tag;
};
struct ast_party_dialed {
	struct {
		char *str;
		int plan;
	} number;
	struct ast_party_subaddress subaddress;
	int transit_network_select;
};
struct ast_party_caller {
	struct ast_party_id id;
	char *ani;
	int ani2;
};

The new organization adds some new information as well.

* The party name and number now have their own presentation value that can
be manipulated independently.  ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.

* The party name and number now have a valid flag.  Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.

* The party name now has a character set value.  SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.

* The dialed party now has a numbering plan value that could be useful to
have available.

The various channel drivers will need to be updated to support the new
core features as needed.  They have simply been converted to supply
current functionality at this time.


The following items of note were either corrected or enhanced:

* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.

* CALLERPRES() is now deprecated because the name and number have their
own presentation values.

* Fixed app_alarmreceiver.c write_metadata().  The workstring[] could
contain garbage.  It also can only contain the caller id number so using
ast_callerid_parse() on it is silly.  There was also a typo in the
CALLERNAME if test.

* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string.  ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string.  Then using
ast_shrink_phone_number() could alter it even more.

* Fixed caller ID name and number memory leak in chan_usbradio.c.

* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.

* Protected access to a caller channel with lock in chan_sip.c.

* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk().  Also made save all caller ID data instead of just the name
and number strings.

* Simplified cdr.c set_one_cid().  It hand coded the ast_callerid_merge()
function.

* Corrected some weirdness with app_privacy.c's use of caller
presentation.

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


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

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

Clearing the callwaitcas flag in analog_call was causing the incoming D digit
to be ignored which triggers sending the caller ID.


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

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

The CLI "dahdi show channel" command was not correctly reporting the
InAlarm status.

The inalarm flag is now consistently passed between chan_dahdi and
submodules.


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

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

........
  r260434 | jpeeler | 2010-04-30 17:22:46 -0500 (Fri, 30 Apr 2010) | 11 lines
  
  Ensure channel state is not incorrectly set in the case of a very early answer.
  
  The needringing bit was being read in dahdi_read after answering thereby
  setting the state to ringing from up. This clears needringing upon answering
  so that is no longer possible.
  
  (closes issue #17067)
  Reported by: tzafrir
  Patches: 
        needringing.diff uploaded by tzafrir (license 46)
........


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

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

........
  r260195 | rmudgett | 2010-04-29 17:11:47 -0500 (Thu, 29 Apr 2010) | 26 lines
  
  DTMF CallerID detection problems.
  
  The code handling DTMF CallerID drops digits on long CallerID numbers and
  may timeout waiting for the first ring with shorter numbers.
  
  The DTMF emulation mode was not turned off when processing DTMF CallerID.
  When the emulation code gets behind in processing the DTMF digits it can
  skip a digit.
  
  For shorter numbers, the timeout may have been too short.  I increased it
  from 2 seconds to 4 seconds.  Four seconds is a typical time between rings
  for many countries.
  
  (closes issue #16460)
  Reported by: sum
  Patches:
        issue16460.patch uploaded by rmudgett (license 664)
        issue16460_v1.6.2.patch uploaded by rmudgett (license 664)
  Tested by: sum, rmudgett
  
  Review: https://reviewboard.asterisk.org/r/634/
  
  JIRA SWP-562
  JIRA AST-334
  JIRA SWP-901
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260231 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

Also avoid potential crash because cause could be NULL.


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

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

........
  r250480 | jpeeler | 2010-03-03 13:04:11 -0600 (Wed, 03 Mar 2010) | 15 lines
  
  Make sure to clear red alarm after polarity reversal.
  
  From the issue:
  The automatic overnight line tests (or manual ones) used on UK (BT) lines causes
  a red alarm on a dahdi / TDM400P connected channel. This is because the line
  uses voltage tests (battery loss) and polarity reversal. The polarity reversal
  causes chan_dahdi to initiate v23 CallerID processing but during this the event
  DAHDI_EVENT_NOALARM is ignored so that the alarm is never cleared.
  
  (closes issue #14163)
  Reported by: jedi98
  Patches: 
        chan_dahdi-1.4-inalarm.diff uploaded by jedi98 (license 653)
  Tested by: mattbrown, Chainsaw, mikeeccleston
........


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

If the limit was set past MAX_INT upon answering, the call was immediately
hung up due to overflow from the return of ast_tvdiff_ms (in ast_check_hangup).
The time calculation functions ast_tvdiff_sec and ast_tvdiff_ms have been
changed to return an int64_t to prevent overflow. Also the reporter suggested
adding a message indicating the reason for the call hanging up. Given that the
new limit is so much higher, the message (which would only really be useful in
the overflow scenario) has been made a debug message only.

(closes issue #16006)
Reported by: viraptor


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

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

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

(closes issue #16440)
Reported by: mmichelson


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

Reviewboard: https://reviewboard.asterisk.org/r/416/


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

The reported bug was actually only for pulsedigit, dtmfup, and dtmfdown
handling. Also added recognition for fax events (just some verbose output) and
fixed handling for the ec_disabled_event. In order to make comparing the analog
version of events to the DAHDI events easier, the ordering has been changed to
follow that of the DAHDI events.

(closes issue #15924)
Reported by: tzafrir



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

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

........
  r218401 | jpeeler | 2009-09-14 16:47:11 -0500 (Mon, 14 Sep 2009) | 11 lines
  
  Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor.
  
  After talking to rmudgett about some of his recent iflist locking changes, it
  was determined that the only place that would destroy a channel without being
  explicitly to do so was in handle_init_event. The loop to walk the interface
  list has been modified to wait to destroy the channel until the dahdi_pvt of
  the channel to be destroyed is no longer needed.
  
  (closes issue #15378)
  Reported by: samy
........


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

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

This fixes the problem that would occur if an analog phone was picked up while
the caller id was being sent. The caller id before sent the whole spill even
after pickup and is now corrected.



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

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

Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.  

(closes issue #9096)
Reported by: fleed
Patches:
      9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs


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

made analog_set_linear_mode return back the mode that was being overwritten 
so it could be restored later. 


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