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
Dummy channels created by ast_dummy_channel_alloc() should be destoyed by
ast_channel_unref(). Using ast_channel_release() needlessly grabs the
channel container lock and can cause a deadlock as a result.
* Analyzed use of ast_dummy_channel_alloc() and made use
ast_channel_unref() when done with the dummy channel. (Primary reason for
the reported deadlock.)
* Made app_dial.c:dial_exec_full() not call ast_call() holding any channel
locks. Chan_local could not perform deadlock avoidance correctly.
(Potential deadlock exposed by this issue. Secondary reason for the
reported deadlock since the held lock was part of the deadlock chain.)
* Fixed some uses of ast_dummy_channel_alloc() not checking the returned
channel pointer for failure.
* Fixed some potential chan=NULL pointer usage in func_odbc.c. Protected
by testing the bogus_chan value.
* Fixed needlessly clearing a 1024 char auto array when setting the first
char to zero is enough in manager.c:action_getvar().
(closes issue ASTERISK-18613)
Reported by: Thomas Arimont
Patches:
jira_asterisk_18613_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: Thomas Arimont
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With these options enabled, they can cause Asterisk to freak out by
SYN flooding a network and eating the CPU. Obviously it would be good to
fix the code so that this can't happen, but we can at least change the default
configuration so it doesn't happen.
This was reported downstream to the Fedora issue tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=658431
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337774 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
The first 9 frames are not reported as some devices dont use srtp
from first frame these are suppresed.
the warning is then output only once every 100 frames.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337541 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
in the case of DAHDI the channel is hungup.
This patch tries to "fix" the problem and make the channel compatiable and warn the user of
this problem.
Please note there is a underlying problem with codec negotion this does not fix the problem
it does try to rectify it and prevent loss of service.
Review: https://reviewboard.asterisk.org/r/1442/
(closes issue ASTERISK-17541)
(closes issue ASTERISK-18063)
(issue ASTERISK-14384)
(issue ASTERISK-17502)
(issue ASTERISK-18325)
(issue ASTERISK-18422)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an issue where the voicemail duration was being reported
with a duration significantly less than the actual sound file duration.
Voicemails that contained mostly silence were reporting the duration of
only the sound in the file, as opposed to the duration of the file with
the silence. This patch fixes this by having two durations reported in
the __ast_play_and_record family of functions - the sound_duration and the
actual duration of the file. The sound_duration, which is optional, now
reports the duration of the sound in the file, while the actual full duration
of the file is reported in the duration parameter. This allows the voicemail
applications to use the sound_duration for minimum duration checking, while
reporting the full duration to external parties if the voicemail is kept.
(issue ASTERISK-2234)
(closes issue ASTERISK-16981)
Reported by: Mary Ciuciu, Byron Clark, Brad House, Karsten Wemheuer, KevinH
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1443
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The current RedHat init script was not LSB compatible. This change will make it LSB compatible so that
it can work correctly with Heartbeat.
(Closes issue ASTERISK-18253)
Reported by: c0rnoTa
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When checking an extension for E_CANMATCH using the new extension matching
algorithm, an exact match was not returned as a possible match resulting in the
queue failing to allow a caller to exit on DTMF. This removes the requirement
that an extension be longer than acquired digits for an E_CANMATCH operation
to succeed.
(closes issue ASTERISK-18044)
Review: https://reviewboard.asterisk.org/r/1367/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@337061 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
This patch addresses crashes related to RTCP handling. The backtraces just
show a crash in ast_rtcp_write() where it appears that the RTP instance is no
longer valid. There is a race condition with scheduled RTCP transmissions and
the destruction of the RTP instance. This patch utilizes the fact that
ast_rtp_instance is a reference counted object and ensures that it will not get
destroyed while a reference is still around due to scheduled RTCP
transmissions.
RTCP transmissions are scheduled and executed from the chan_sip scheduler
context. This scheduler context is processed in the SIP monitor thread. The
destruction of an RTP instance occurs when the associated sip_pvt gets
destroyed (which happens when the sip_pvt reference count reaches 0). However,
the SIP monitor thread is not the only thread that can cause a sip_pvt to get
destroyed. The sip_hangup function, executed from a channel thread, also
decrements the reference count on a sip_pvt and could cause it to get
destroyed.
While this is being changed anyway, the patch also removes calling
ast_sched_del() from within the RTCP scheduler callback. It's not helpful.
Simply returning 0 prevents the callback from being rescheduled.
(closes issue ASTERISK-18570)
Related issues that look like they are the same problem:
(issue ASTERISK-17560)
(issue ASTERISK-15406)
(issue ASTERISK-15257)
(issue ASTERISK-13334)
(issue ASTERISK-9977)
(issue ASTERISK-9716)
Review: https://reviewboard.asterisk.org/r/1444/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Makefile workaround for 10.6 extended to work on 10.7 and later.
* Now uses the 'weak' symbol for Lion systems, which no longer support
'weak_import'
Closes ASTERISK-17612.
Closes ASTERISK-18213.
Tested by: tilghman, oej.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial d and H options break DTMF attended transfer atxferdropcall
option.
1) Party A calls party B.
2) Party B does a DTMF attended transfer to Party C.
If the dialplan uses the Dial d or H options to call Party C then the Dial
application answers the call immediately before initiating the call leg to
Party C. The premature answer causes the transfer code to not invoke the
atxferdropcall=no behavior for a blonde transfer since Party C has
"answered". The transfer code thinks that Party B has "consulted" with
Party C when Party B hangs up and completes the transfer to Party A.
Party A now hears ringback until Party C actually answers.
ASTERISK-13294 Dial d option.
ASTERISK-11067 Dial H option to disconnect before answer.
The referenced issues made Dial answer with the d and H options because
many SIP and ISDN phones cannot send DTMF before the call is connected.
* Made require the dialplan to control when or if the call needs to be
answered to use the Dial application d and H options. (The call is no
longer surprise answered when using the Dial d or H options.)
Review: https://reviewboard.asterisk.org/r/1381/
JIRA AST-623
JIRA AST-666
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@336658 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
