* Fixed deadlock potential calling dialog_unlink_all() in
__sip_autodestruct(). Found by helgrind.
* Fixed deadlock potential in handle_request_invite() after calling
sip_new(). Found by helgrind.
* The sip_new() function now returns with the created channel already
locked.
* Removed the dead code that starts a PBX in in sip_new(). No sip_new()
callers caused that code to be executed and it was a bad thing to do
anyway.
* Removed unused parameters and return value from dialog_unlink_all().
* Made dialog_unlink_all() and __sip_autodestruct() safely obtain the
owner and private channel locks without a deadlock avoidance loop.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the case where an INVITE is received with c=0.0.0.0 or ::.
In this case, the call should be placed on hold. Previously, we checked for
the address being null; this patch keeps that behavior but also checks for
the ANY IP addresses.
Review: https://reviewboard.asterisk.org/r/1504/
(closes issue ASTERISK-18086)
Reported by: James Bottomley
Tested by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Makes chan_sip set the tag to the channel name.
* Fixes received debug message sequence number.
* Removed tx/rx debug message type since it was hard coded to 0.
* Made udptl.c logged message header consistent if possible: "UDPTL (%s): ".
* Removed unused rx_expected_seq_no from struct ast_udptl.
(closes issue ASTERISK-18401)
Reported by: Kevin P. Fleming
Patches:
jira_asterisk_18401_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Matthew Nicholson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@339625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the change in r336294, the new AST_CONTROL_UPDATE_RTP_PEER frame
is sent when a re-invite happens. If we receive a re-invite from a device
the waitstream_core was not aware of the new control frame and would drop
the call.
(closes issue ASTERISK-18610)
Reported by: Kristijan_Vrban
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@339086 65c4cc65-6c06-0410-ace0-fbb531ad65f3
NOTE: The problem was reported against v1.6.2. It is unlikely to ever
happen on v1.8 and above since chan_dahdi.c:analog_ss_thread() is unlikely
to be used. The version in sig_analog.c has largely replaced it.
(closes issue ASTERISK-18648)
Reported by: Stephan Bosch
Patches:
jira_asterisk_18648_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Stephan Bosch
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@338800 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-17486 exposed the problem for AMI parsers.
(closes issue ASTERISK-18649)
Reported by: Jacek Konieczny
Patches:
asterisk-sipshowpeer_response_end.patch (license #6298) patch uploaded by Jacek Konieczny
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@338663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP_HEADER function only works on the the initial SIP INVITE. The documentation was updated
in trunk, but not in 1.8 or 10, so I'm making them match.
(Closes issue ASTERISK-18640)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@338492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the Caller-ID is restricted, the expected behavior is for the
Caller-ID to be blank. In chan_dahdi, the national prefix is placed onto
the Caller-ID number even if it is restricted (empty) causing the
Caller-ID to be the national prefix rather than blank.
This behavior was lost when sig_pri was extracted from chan_dahdi.
* Made not add prefix strings to empty connected line, calling, and ANI
number strings.
(closes issue ASTERISK-18577)
Reported by: Kris Shaw
Patches:
jira_asterisk_18577_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Kris Shaw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
module tries to resolve IP address to IP address and fails.
Simple fix to set family of socket this is a hangover from ipv6 changes.
(closes issue ASTERISK-18237)
(issue ASTERISK-17278)
(issue ASTERISK-17500)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
