Fixes the crash in ASTERISK-17955 gdb-11918.txt backtrace.
* Added some missing libss7 access lock protection.
* Prevent cancelling the ss7_linkset() thread at inoportune times just
like the pri_dchannel() thread.
(issue ASTERISK-17955)
Reported by: Ian M Sherman
Patches:
jira_asterisk_17955_v1.8.patch (license #5621) patch uploaded by rmudgett
(attached to related ASTERISK-17966)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sig_ss7_hangup() failed to release the SS7 linkset lock if the call had
the alreadyhungup flag set.
* Made unlock the SS7 linkset lock in sig_ss7_hangup() if the
alreadyhungup flag is set.
* Made ss7_start_call() not hold any locks while creating the channel for
an incoming call to prevent deadlock.
* Made ss7_grab() a void function, since it could never fail, to simplify
calling code.
* Made obtain the channel lock to do softhangup in some places.
Patches:
jira_ast_668_v1.8.patch (license #5621) patch uploaded by rmudgett
JIRA AST-668
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_h323 was not updated causeing all to flee to chan_ooh323.
the brave Jedi [asterisk developers] pondered this miscarrige of justice
and restored order to the force for the sake of closing out 2 old issues.
(closes issue ASTERISK-17278)
(closes issue ASTERISK-17500)
Reported by: dread, sybasesql
Tested by: irroot
Reviewed by: IRC (russellb, kpfleming)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336499 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue ASTERISK-18573)
Patches:
sip_mwi_lock.patch (license #5041) by Gregory Hinton Nietsky
Thanks to irrot for the reminder, to Gregory for the patch!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In a situation involving devices on separate Asterisk trunks, the remote RTP bridge would
break when starting a call with directmedia. This patch queues a new type of control frame
so that our RTP bridge loop can properly detect when these situations occur and check to see
if peers need to be updated in order to send their media to the proper location.
(Closes issue ASTERISK-18340)
Reported by: Thomas Arimont
(Closes issue ASTERISK-17725)
Reported by: kwk
Tested by: twilson, jrose
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
it rotates between ports but never checks the channels in the ports.
i have extensivly tested it and verified it works on 1 upto 4 ports.
before the patch only 1 out of each port was used now all are used as
expected.
(closes issue ASTERISK-18413)
Reported by: irroot
Tested by: irroot
Reviewed by: irroot
Review: https://reviewboard.asterisk.org/r/1410/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI agents list called on shutdown causes a segfault, introducing proper locking
will prevent this.
(closes issue ASTERISK-18092)
Reported by: agustina
Patches: chan_agent.patch (License #5041) patch uploaded by irroot
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes the missing DAHDI channels when using the newer chan_dahdi.conf
sections for channel configuration.
(closes issue ASTERISK-18496)
Reported by: Sean Darcy
Patches:
jira_asterisk_18496_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Sean Darcy, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
IAX2 does not support IPv6 and getting such addresses from DNS can cause error
messages on the remote end involving bad IPv4 address casts in the presence of
IPv6/IPv4 tunnels. This patch ensures that IAX2 will not encounter IPv6
addresses via DNS queries.
(closes issue ASTERISK-18090)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the launch of 1.6 event-based MWI we have two threads handling the peer->mwipvt,
which cause issues with SIP history additions in combination with the max limit for
number of history entries.
Review: https://reviewboard.asterisk.org/r/1373/
(closes issue ASTERISK-18288)
Thanks to irrot for peer review. Work with this bug funded by IPvision AS
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP phone uses the dial application and receives a 484 Address
Incomplete response, if overlapped dialing is enabled for SIP, then
the 484 Address Incomplete is forwarded back to the SIP phone and the
HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete
application dialplan logic was automatically triggered; now, explicit
dialplan usage of the application is required.
Additionally, this patch adds a new AST_CONTOL_FRAME type called
AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame,
it is an indication that the dialplan expects more digits back from the
device. If the device supports overlap dialing it should attempt to
notify the device that the dialplan is waiting for more digits; otherwise,
it can handle the frame in a manner appropriate to the channel driver.
(closes issue ASTERISK-17288)
Reported by: Mikael Carlsson
Tested by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/1416/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The following error will consistently occur when trying to dial into a
MeetMe conference when the server does not have DAHDI hardware installed:
app_meetme.c: No DAHDI channel available for conference, user introduction
disabled (is chan_dahdi loaded?)
While chan_dahdi is loaded correctly during compilation and install of
Asterisk/Dahdi, including associated modules, etc., a chan_dahdi.conf
configuration file in /etc/asterisk is not created by FreePBX if hardware
does not exist, causing MeetMe to be unable to open a DAHDI pseudo
channel.
* Allow chan_dahdi to create a pseudo channel when there is no
chan_dahdi.conf file to load.
(closes issue ASTERISK-17398)
Reported by: Preston Edwards
Patches:
jira_asterisk_17398_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Multiple users attempting to pickup a call that has been forked to
multiple extensions either crashes or fails a masquerade with a "bad
things may happen" message.
This is the scenario that is causing all the grief:
1) Pickup target is selected
2) target is marked as being picked up in ast_do_pickup()
3) target is unlocked by ast_do_pickup()
4) app dial or queue gets a chance to hang up losing calls and calls
ast_hangup() on target
5) SINCE A MASQUERADE HAS NOT BEEN SETUP YET BY ast_do_pickup() with
ast_channel_masquerade(), ast_hangup() completes successfully and the
channel is no longer in the channels container.
6) ast_do_pickup() then calls ast_channel_masquerade() to schedule the
masquerade on the dead channel.
7) ast_do_pickup() then calls ast_do_masquerade() on the dead channel
8) bad things happen while doing the masquerade and in the process
ast_do_masquerade() puts the dead channel back into the channels container
9) The "orphaned" channel is visible in the channels list if a crash does
not happen.
This patch does the following:
* Made ast_hangup() set AST_FLAG_ZOMBIE on a successfully hung-up channel
and not release the channel lock until that has happened.
* Made __ast_channel_masquerade() not setup a masquerade if either channel
has AST_FLAG_ZOMBIE set.
* Fix chan_agent misuse of AST_FLAG_ZOMBIE since it would no longer work.
(closes issue ASTERISK-18222)
Reported by: Alec Davis
Tested by: rmudgett, Alec Davis, irroot, Karsten Wemheuer
(closes issue ASTERISK-18273)
Reported by: Karsten Wemheuer
Tested by: rmudgett, Alec Davis, irroot, Karsten Wemheuer
Review: https://reviewboard.asterisk.org/r/1400/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334009 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The response of SIPshowpeer ends with "\r\n\r\n". Since other commands are
ended by using \r\n this confuses any interfacing script.
(closes issue ASTERISK-17486)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If Asterisk starts and no DNS is available, outbound registrations will fail
indefinitely. This patch copies the address from the sip_registry struct, which
will be updated, to the peer->addr when necessary.
If dnsmgr is enabled, the registration fails without the patch because even
though the address on the registry is updated via dnsmgr, the address is just
copied on the first try. Since we use ast_sockaddr_copy, dnsmgr can't update
the address that is copied to the sip_pvt or peers.
Closes issue ASTERISK-18000
Review: https://reviewboard.asterisk.org/r/1335/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@333836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change CRC4 to CRC in the output of "dahdi show status" so that it can apply in
more situations without confusing users, especially since T1 lines use CRC6
instead of CRC4.
(closes issue AST-471)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
France Telecom brings layer 2 and layer 1 down on BRI lines when the line
is idle. When layer 1 goes down Asterisk cannot make outgoing calls and
the HA8 and HB8 cards also get IRQ misses.
The inability to make outgoing calls is because the line is in red alarm
and Asterisk will not make calls over a line it considers unavailable.
The IRQ misses for the HA8 and HB8 card are because the hardware is
switching clock sources from the line which just brought layer 1 down to
internal timing.
There is a DAHDI option for the B410P card to not tell Asterisk that layer
1 went down so Asterisk will allow outgoing calls: "modprobe wcb4xxp
teignored=1". There is a similar DAHDI option for the HA8 and HB8 cards:
"modprobe wctdm24xxp bri_teignored=1". Unfortunately that will not clear
up the IRQ misses when the telco brings layer 1 down.
* Add layer 2 persistence option to customize the layer 2 behavior on BRI
PTMP lines. The new option has three settings: 1) Use libpri default
layer 2 setting. 2) Keep layer 2 up. Bring layer 2 back up when the peer
brings it down. 3) Leave layer 2 down when the peer brings it down.
Layer 2 will be brought up as needed for outgoing calls.
JIRA AST-598
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332264 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Before, having multiple subscriptions to mailboxes on a sip peer set via the mailbox
setting in sip.conf would only result in updates being sent on whichever mailbox
triggered the mwi event. Now all of them get counted regardless. Also fixes a bug
involving parsing of the mailbox option in sip.conf so that trailing and leading
spaces before/after commas are trimmed.
(closes issue ASTERISK-18067)
Reported by: aragon
(closes issue ASTERISK-15479)
Reported by: Ben Winslow
Patches: chan_sip.c-mwi_multi_mailbox_fix-1.6.2.13.diff (License #5288) patch uploaded by Ben Winslow
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
setting of HASH(SIP_CAUSE,<chan name>) on the channel.
Having chan_sip set HASH(SIP_CAUSE,<chan name>) on the channel carries a
significant performance penalty because of the usage of the MASTER_CHANNEL()
dialplan function.
AST-580
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Address chan_dahdi.conf dahdichan option todo item about needing line
number.
* Make ignore_failed_channels option also apply to dahdichan option.
* Don't attempt to create a default pseudo channel if the chan_dahdi.conf
channel/channels option is not allowed.
* Add a similar check for dahdichan in normal chan_dahdi.conf sections as
is done in users.conf.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The fake event should only be processed by the channel that currently
owns the private and not the associated call waiting or 3-way channel.
JIRA AST-620
JIRA SWP-3616
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI actions DAHDIHangup and DAHDITransfer have no effect on a DAHDI
channel. These two AMI actions are highly specialized to analog channels
and appear to make the channel behave like a jack port for headsets.
* Made the faked DAHDI event get processed before a normal media stream
read in dahdi_read() instead of trying to trigger an exception read by
setting the AST_FLAG_EXCEPTION flag. Apparently a change was made long
ago that changed how AST_FLAG_EXCEPTION is processed in the core.
Unfortunately, the faked DAHDI events no longer worked when that happened.
* Updated the DAHDI AMI action documentation for the following actions:
DAHDITransfer, DAHDIHangup, DAHDIDialOffhook, DAHDIDNDon, DAHDIDNDoff,
DAHDIShowChannels, and DAHDIRestart.
* Made use sscanf() instead of atoi() for better error checking of the
DAHDIChannel header string.
JIRA AST-620
JIRA SWP-3616
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Any SIP notify sent via AMI or CLI leaks a SIP PVT with ref count +2. Removing
the additional ref just before the invite and adding an unref following it
corrects the issue as seen via REF_DEBUG. The unref existed in a distant
revision and it appears as though the wrong ref operation was removed.
(closes issue ASTERISK-18091)
Review: https://reviewboard.asterisk.org/r/1332/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add some reentrancy protection in pbx.c when creating the contexts_table
hash table.
* Fix inverted test in chan_sip.c conditional code.
* Fix uninitialized variable and use of the wrong variable in chan_iax2.c.
* Fix test of return value in app_parkandannounce.c. Explicitly testing
for -1 is bad if the function does not actually return that value when it
fails.
* Fixup some comments and add some curly braces in features.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@330705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes crash in chan_iax2 resulting from an edge case in the
way control frames are queued during calltoken negotiation is complete.
(closes issue ASTERISK-17610)
Reported by: mgrobecker
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@330581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r330033 | rmudgett | 2011-07-28 11:26:38 -0500 (Thu, 28 Jul 2011) | 15 lines
Datacalls with B410P fail.
Incoming and outgoing call legs of a data call are using different
formats: a-law, u-law. When the call is bridged, the media stream is run
through translation to convert the media formats. The translation is bad
for data calls.
* Make incoming call that does not explicitly specify u-law or a-law use
the DAHDI channel's default law. The outgoing call always uses the
default law from the DAHDI channel.
(closes issue ABE-2800)
Patches:
jira_abe_2800_companding.patch (license #5621) patch uploaded by rmudgett
..........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@330050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "pri show channels" command is useful for debuging to see if there are
any stuck B channels.
..........
r307964 | rmudgett | 2011-02-15 15:42:55 -0600 (Tue, 15 Feb 2011) | 9 lines
Add CLI "pri show channels" command.
List the current mapping of DAHDI B channels to Asterisk channel names and
which calls are on hold or call-waiting. Calls on hold or call-waiting
are not associated with any B channel.
JIRA LIBPRI-27
JIRA SWP-2547
..........
r308205 | rmudgett | 2011-02-17 14:21:56 -0600 (Thu, 17 Feb 2011) | 1 line
Add more verbage to CLI command 'pri show channels' usage.
..........
r312579 | rmudgett | 2011-04-04 11:17:58 -0500 (Mon, 04 Apr 2011) | 59 lines
Change also updates 'pri show channels' command with the "chan idle"
column to report if a channel is available for use.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@329012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The functionality of inband DTMF in chan_sip relied upon
ast_rtp_instance_dtmf_mode_get/set not working properly to avoid calling
ast_rtp_instance_dtmf_begin/end on RTP streams with inband DTMF. According to
documentation, ast_rtp_instance_dtmf_begin/end is meant only for RFC2833 DTMF,
never inband. This fixes the regression introduced in revision 328823.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@328935 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When deciding whether Asterisk was allowed to bridge the call away from the
core, chan_sip did not take into account the usage of features on dialed
channels that require monitoring of DTMF on channels utilizing inband DTMF.
This would cause Asterisk to allow the call to be locally or remotely bridged,
preventing access to the data required to detect activations of such features.
(closes 17237)
Review: https://reviewboard.asterisk.org/r/1302/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@328823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ideally, sip_setoption shouldn't be called if there is a lack of a sip private structure. But this will fix a crash.
(closes issue ASTERISK-17909)
Reported by: Mark Murawski
Tested by: Mark Murawski
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@328608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
