........
r375993 | mmichelson | 2012-11-07 11:01:13 -0600 (Wed, 07 Nov 2012) | 30 lines
Fix misuses of timeouts throughout the code.
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
........
r375994 | mmichelson | 2012-11-07 11:08:44 -0600 (Wed, 07 Nov 2012) | 3 lines
Remove some debugging that accidentally made it in the last commit.
........
Merged revisions 375993-375994 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375995 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376014 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376015 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The following dialplan applications now recognize 'W' to pause sending
DTMF for one second in addition to the previously existing 'w' that paused
sending DTMF for half a second. Dial, ExternalIVR, and SendDTMF.
* The chan_dahdi analog port dialing and deferred DTMF dialing for PRI now
distinguishes between 'w' and 'W'. The 'w' pauses dialing for half a
second. The 'W' pauses dialing for one second.
* Created dahdi_dial_str() in chan_dahdi that eliminated a lot of
duplicated dialing code and diagnostic messages for the channel driver.
(closes issue ASTERISK-20039)
Reported by: Jeremiah Gowdy
Patches:
jgowdy-wait-6-22-2012.diff (license #5621) patch uploaded by Jeremiah Gowdy
Expanded patch to add support in chan_dahdi.
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds HANGUPCAUSE information to called channels so that hangup
handlers can, in conjunction with predial dialplan execution, access
the hangupcause information when the dialed channel hangs up on a
one-to-one basis instead of a many-to-one basis as with HANGUPCAUSE
usage on the caller channel.
Review: https://reviewboard.asterisk.org/r/2069/
(closes issue ASTERISK-20198)
........
Merged revisions 371258 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HANGUPCAUSE hash (trunk only) meant to replace SIP_CAUSE has now
been replaced with the HANGUPCAUSE and HANGUPCAUSE_KEYS dialplan
functions to better facilitate access to the AST_CAUSE translations
for technology-specific cause codes. The HangupCauseClear application
has also been added to remove this data from the channel.
(closes issue SWP-4738)
Review: https://reviewboard.asterisk.org/r/2025/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The awk script parses out the first instance of the DOCUMENTATION tag that it
finds within a file. If a file did not previously have a DOCUMENTATION tag
but received one due to it having an AMI event, then the XML fragment
associated with the AMI event was erroneously placed in the resulting XML
file. Without the python scripts, these XML fragments will not validate.
This patch adds DOCUMENTATION tags at the top of those files that did
not previously have them to prevent the awk script from pulling AMI event
documentation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369910 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds some basic documentation for a number of modules. This
includes core source files in Asterisk (those in main), as well as
chan_agent, chan_dahdi, chan_local, sig_analog, and sig_pri. The DTD
has also been updated to allow referencing of AMI commands.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is not necessary to generate information cause code frames on every
protocol event that occurs. This removes all the instances where the
frame was not conveying a cause code and was instead just conveying a
protocol-specific message. This also corrects the generation of the
message associated with disconnects for MFC/R2 to use the MFC/R2
specific text for the disconnect cause.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds call ID logging changes to specific channel drivers that weren't handled
handled in phase II of Call ID Logging. Also covers logging for threads for
threads created by systems that may be involved with many different calls.
Extra special thanks to Richard for rigorous review of chan_dahdi and its
various signalling modules.
review: https://reviewboard.asterisk.org/r/1927/
review: https://reviewboard.asterisk.org/r/1950/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is part of the DAHDI support for the Asterisk 11 "Who Hung Up?"
project and covers the implementation for the technologies implemented
in sig_analog.c and sig_pri.c. Tested on a local machine to verify
protocol and cause information is available.
Review: https://reviewboard.asterisk.org/r/1953/
(issue SWP-4222)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369185 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r369001 | kpfleming | 2012-06-15 10:56:08 -0500 (Fri, 15 Jun 2012) | 11 lines
Add support-level indications to many more source files.
Since we now have tools that scan through the source tree looking for files
with specific support levels, we need to ensure that every file that is
a component of a 'core' or 'extended' module (or the main Asterisk binary)
is explicitly marked with its support level. This patch adds support-level
indications to many more source files in tree, but avoids adding them to
third-party libraries that are included in the tree and to source files
that don't end up involved in Asterisk itself.
........
r369002 | kpfleming | 2012-06-15 10:57:14 -0500 (Fri, 15 Jun 2012) | 3 lines
Add a script to enable finding source files without support-levels defined.
........
Merged revisions 369001-369002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369005 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A deadlock can occur when a POTS phone tries to flash hook to originate a
second call for 3-way or transfer. If another process is scanning the
channels container when the POTS line flash hooks then a deadlock will
occur.
* Release the channel and private locks when creating a new channel as a
result of a flash hook.
(closes issue ASTERISK-19842)
Reported by: rmudgett
Tested by: rmudgett
........
Merged revisions 368644 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368645 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Extracting sig_analog from chan_dahdi lost call progress detection
functionality.
* Fix analog ports from considering a call answered immediately after
dialing has completed if the callprogress option is enabled.
(closes issue ASTERISK-18841)
Reported by: Richard Miller
Patches:
chan_dahdi.diff (license #5685) patch uploaded by Richard Miller (Modified by me)
sig_analog.c.diff (license #5685) patch uploaded by Richard Miller (Modified by me)
sig_analog.h.diff (license #5685) patch uploaded by Richard Miller
........
Merged revisions 347006 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 347007 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix potential deadlocks in SIP and IAX blind transfer to parking.
* Fix SIP, IAX, DAHDI analog, and MGCP channel drivers to respect the
parkext_exclusive option with transfers (Park(,,,,,exclusive_lot)
parameter). Created ast_park_call_exten() and ast_masq_park_call_exten()
to maintian API compatibility.
* Made masq_park_call() handle a failed ast_channel_masquerade() setup.
* Reduced excessive struct parkeduser.peername[] size.
........
Merged revisions 341254 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 341255 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@341256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r330706 | kmoore | 2011-08-03 08:39:06 -0500 (Wed, 03 Aug 2011) | 17 lines
Merged revisions 330705 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r330705 | kmoore | 2011-08-03 08:38:17 -0500 (Wed, 03 Aug 2011) | 10 lines
Call pickup broken for DAHDI channels when beginning with #
The call pickup feature did not work on DAHDI devices for anything other than
feature codes beginning with * since all feature codes in chan_dahdi were
originally hard-coded to begin with *. This patch is also applied to
chan_dahdi.c to fix this bug with radio modes.
(closes issue AST-621)
Review: https://reviewboard.asterisk.org/r/1336/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@330707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r316224 | rmudgett | 2011-05-03 14:18:30 -0500 (Tue, 03 May 2011) | 16 lines
The dahdi_hangup() call does not clean up the channel fully.
After dahdi_hangup() has supposedly hungup an ISDN channel there is still
traffic on the S0-bus because the channel was not cleaned up fully.
Shuffled the hangup code to include some missing cleanup. Also fixed some
code formatting in the area. I think the primary missing clean up code
was the call to tone_zone_play_tone() to turn off any active tones on the
channel.
(closes issue #19188)
Reported by: jg1234
Patches:
issue19188_v1.8.patch uploaded by rmudgett (license 664)
Tested by: jg1234
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r313190 | rmudgett | 2011-04-11 10:40:30 -0500 (Mon, 11 Apr 2011) | 39 lines
Merged revisions 313189 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r313189 | rmudgett | 2011-04-11 10:32:53 -0500 (Mon, 11 Apr 2011) | 32 lines
Merged revisions 313188 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r313188 | rmudgett | 2011-04-11 10:27:52 -0500 (Mon, 11 Apr 2011) | 25 lines
Stuck channel using FEATD_MF if caller hangs up at the right time.
The cause was actually a caller hanging up just at the end of the Feature
Group D DTMF tones that setup the call. The reason for this is a "guard
timer" that's implemented using ast_safe_sleep(100). If the caller
happens to hang up AFTER the final tone of the DTMF string but BEFORE the
end of that ast_safe_sleep(), then ast_safe_sleep() will return non-zero.
This causes the code to bounce to the end of ss_thread(), but it does NOT
tear down the call properly.
This should be a rare occurrence because the caller has to hang up at
EXACTLY the right time. Nonetheless, it was happening quite regularly on
the reporter's system. It's not easily reproducible, unless you purposely
increase the guard-time to 2000 or more. Once you do that, you can
reproduce it every time by watching the DTMF debug and hanging up just as
it ends.
Simply add an ast_hangup() before goto quit.
(closes issue #15671)
Reported by: jcromes
Patches:
issue15671.patch uploaded by pabelanger (license 224)
Tested by: jcromes
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
................
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
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