* Return correct status: SUCCESS/FAILED/HANGUP. Previously, abnormal
exits from the command loop such as hangup would return SUCCESS.
* The "asyncagi break" command now returns SUCCESS and is now the only way
to break the command loop with that status. Previously, it returned
FAILED.
* The AMI event AsyncAGI End is no longer sent if the AsyncAGI Start event
is not sent. Previously, this happened because of an error setting up the
AGI pipes.
* All executed AGI commands now get an AsyncAGI Exec result event.
Previously, if the command returned failure (because of hangup), the
command loop just exited with FAILURE and did not send the AsyncAGI Exec
result event.
* Makes sure that the channel frame queue is empty on hangup.
Review: https://reviewboard.asterisk.org/r/1183/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@314069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Deadlock avoidance between the sip pvt and the pvt->owner is
very difficult. Now that channel's are ao2 objects, this complication
is no longer necessary. It turns out the pvt's msg queue only
exists because of deadlock avoidance (when deadlock avoidance fails
msgs were added to a queue to be processed later), so this goes away as well.
The technique used in the new sip_lock_pvt_full() function should
be used as a template for replacing all locations where deadlock
avoidance occurs between a channel tech_pvt and the pvt's owner.
My hope is that this will begin a reversal of the invalid channel
driver locking architecture we have been using for so long.
This patch also resolves an issue where the pvt->owner gets
unlocked during processing the msg queue.
(closes issue #18690)
Reported by: dvossel
Review: https://reviewboard.asterisk.org/r/1182/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@314067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes how chan_sip handles dynamic rtp payload types
it does not understand. At the moment if a dynamic payload's mime
type does not match one we understand, the payload does not get
removed from our payload table. As a result of this, the payload
is set to whatever dynamic codec we use internally for that payload
number on outgoing INVITES. This is incorrect.
This patch fixes this by properly checking the rtpmap set function's
return code to make sure it was found. The function can return both
-1 and -2 depending on the source of the mismatch. We were just
checking -1 explicitly.
Review: https://reviewboard.asterisk.org/r/1169/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@314017 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Executing Dial(DAHDI/1/18475551212,300,) with the echotraining config
option enabled outputs the following debug messages unconditionally:
Dialing T1847555121 on 1
Dialing www2w on 1
* Made debug messages in my_dial_digits() normal debug messages that do
not get output unless enabled.
* Reworded some debug messages in my_dial_digits() to be clearer.
* Replace strncpy() with ast_copy_string() in my_dial_digits() which does
the same job better.
(closes issue #18847)
Reported by: vmikhelson
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It looks like it was intentional to leave any commands or in-flight
commands in the queue in case Async AGI is run again on the call.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
Merged revisions 313545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
Asterisk does not hangup a channel after endpoint hangs up.
If the call that the dialplan started an AGI script for is hungup while
the AGI script is in the middle of a command then the AGI script is not
notified of the hangup. There are many AGI Exec commands that this can
happen with. The reported applications have been: Background, Wait, Read,
and Dial. Also the AGI Get Data command.
* Don't wait on the Asterisk channel after it has hung up. The channel is
likely to never need servicing again.
* Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
in run_agi(). It previously only could return AGI_RESULT_SUCCESS or
AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
(closes issue #17954)
Reported by: mn3250
Patches:
issue17954_v1.8.patch uploaded by rmudgett (license 664)
issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
issue17954_v1.4.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA SWP-2171
(closes issue #18492)
Reported by: devmod
Tested by: rmudgett
JIRA SWP-2761
(closes issue #18935)
Reported by: nvitaly
Tested by: astmiv, rmudgett
JIRA SWP-3216
(closes issue #17393)
Reported by: siby
Tested by: rmudgett
JIRA SWP-2727
Review: https://reviewboard.asterisk.org/r/1165/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313588 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added fields that are in "core show channel" to dumpchan output.
* Fixed reuse of formatbuf before the previous string stored there was
used by snprintf. All output strings now have their own buffer.
* Adjusted the buffer sizes to not be so abusive of the stack now that
there are more buffers.
Change requested by oej.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Merged revisions 313435 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r313432 | jrose | 2011-04-12 13:12:29 -0500 (Tue, 12 Apr 2011) | 14 lines
reload Chan_dahdi memory leak caused by variables
chan_dahdi reloading with variables set via setvar in chan_dahdi.conf would
stay in the dahdi_pvt structs for individual channels (causing them to just
continue adding the new ones to the list) and also there was a memory leak
causes by the conf objects. This patch resolves both of these by using
ast_variables_destroy during the loading process.
(closes issue #17450)
Reported by: nahuelgreco
Patches:
patch.diff uploaded by jrose (license 1225)
Tested by: tilghman, jrose
Review: https://reviewboard.asterisk.org/r/1170/
........
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r313432 | jrose | 2011-04-12 13:12:29 -0500 (Tue, 12 Apr 2011) | 14 lines
reload Chan_dahdi memory leak caused by variables
chan_dahdi reloading with variables set via setvar in chan_dahdi.conf would
stay in the dahdi_pvt structs for individual channels (causing them to just
continue adding the new ones to the list) and also there was a memory leak
causes by the conf objects. This patch resolves both of these by using
ast_variables_destroy during the loading process.
(closes issue #17450)
Reported by: nahuelgreco
Patches:
patch.diff uploaded by jrose (license 1225)
Tested by: tilghman, jrose
Review: https://reviewboard.asterisk.org/r/1170/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In app_dial.c:wait_for_answer() frames from the inbound channel should be
sent to all outbound channels instead of only if there is just one
outbound channel.
Control frames like AST_CONTROL_CONNECTED_LINE need to be passed to all of
the the outbound channels. This can happen if a blond transfer is done by
a remote switch on the inbound channel.
JIRA AST-443
JIRA SWP-2730
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@313190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calculation of the Odd/Even flag was wrong.
Implement correct algo, and set odd/even=0 if data would be truncated.
Only allow automatic calculation of the O/E flag, don't let dialplan influence.
(closes issue #19062)
Reported by: festr
Patches:
bug19062.diff2.txt uploaded by alecdavis (license 585)
Tested by: festr, alecdavis, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@313001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Regression from -r312575 B channel shifting during negotiation.
* Also combine updating the alarm flag with clearing the resetting flag.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The get_destination() function was not using the "s" extension when the
request URI did not specify an extension. This is a regression caused
when the URI parsing code was extracted into parse_uri().
Made get_destination() substitute the "s" extension when the parsed URI
results in an empty string.
(closes issue #18348)
Reported by: shmaize
Patches:
issue18348_v1.8.patch uploaded by rmudgett (license 664)
Tested by: shmaize
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines
Merged revisions 312573 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
Issues with ISDN calls changing B channels during call negotiations.
The handling of the PROCEEDING message was not using the correct call
structure if the B channel was changed. (The same for PROGRESS.) The call
was also not hungup if the new B channel is not provisioned or is busy.
* Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
using the correct structure and B channel. If there is any problem with
the operations then the call is now hungup with an appropriate cause code.
* Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
correct structure by looking for the call and not using the channel ID.
NOTIFY is an exception with versions of libpri before v1.4.11 because a
call pointer is not available for Asterisk to use.
* Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
the correct structure by looking for the call and not using the channel
ID.
(closes issue #18313)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2620
(closes issue #18231)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2924
(closes issue #18488)
Reported by: jpokorny
JIRA SWP-2929
JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
JIRA DAHDI-406
JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a call is sent to an ISDN phone that rejects the call with
RELEASE_COMPLETE(cause: call reject(21), or busy(17)) Asterisk crashes.
I could not get my setup to crash. However, I could see the possibility
from a race condition between queuing an AST_CONTROL_BUSY to the core and
then queueing an AST_CONTROL_HANGUP. If the AST_CONTROL_BUSY is processed
before the AST_CONTROL_HANGUP is queued, the ast_channel could be
destroyed out from under chan_misdn.
Avoid this particular crash scenario by not queueing the
AST_CONTROL_HANGUP if the AST_CONTROL_BUSY was queued.
(closes issue #18408)
Reported by: wimpy
Patches:
issue18408_v1.8.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, wimpy
JIRA SWP-2679
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CallCompletionRequest()/CallCompletionCancel() dialplan applications
exit nonzero on normal failure conditions. The nonzero exit causes the
dialplan to hangup immediately. The dialplan author has no opportunity to
report success/failure to the user.
* Made always return zero so the dialplan can continue.
* Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and
CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively. Also
documented the values set.
* Reduced the warning about no core instance in CallCompletionCancel() to
a debug message. It is a normal event and should not be output at the
WARNING level.
(closes issue #18763)
Reported by: p_lindheimer
Patches:
ccss.patch uploaded by p lindheimer (license 558) Modified
Tested by: p_lindheimer, rmudgett
JIRA SWP-3042
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312461 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312210 | alecdavis | 2011-04-01 21:47:29 +1300 (Fri, 01 Apr 2011) | 29 lines
Merged revisions 312174 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312174 | alecdavis | 2011-04-01 21:29:49 +1300 (Fri, 01 Apr 2011) | 23 lines
voicemail: get real last_message_index and count_messages, ODBC resequence
change last_message_index to read the max msgnum stored in the database
change count_messages to actually count the number of messages.
last_message_index change:
This fixed overwriting of the last message if msgnum=0 was missing.
Previously every incoming message would overwrite msgnum=1.
count_messages change:
allows us to detect when requencing is required in opneA_mailbox.
resequence enabled for ODBC storage:
Assists with fixing up corrupt databases with gaps, but only when
a user actively opens there mailboxes.
(closes issue #18692,#18582,#19032)
Reported by: elguero
Patches:
based on odbc_resequence_mailbox2.1.diff uploaded by elguero (license 37)
Tested by: elguero, nivek, alecdavis
Review: https://reviewboard.asterisk.org/r/1153/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312103 | alecdavis | 2011-04-01 20:25:54 +1300 (Fri, 01 Apr 2011) | 22 lines
Merged revisions 312070 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312070 | alecdavis | 2011-04-01 19:46:56 +1300 (Fri, 01 Apr 2011) | 16 lines
app_voicemail: close_mailbox needs to respect additional messages while mailbox is open.
close_mailbox leave gaps in message sequence if messages are deleted and new messages
arrive during this time, this is because the shuffle down to slot 0, only shuffles
the number of pre-existing messages when mailbox is opened, ignoring new arrivals.
Fix: in close_mailbox re-evaluate number of messages before the shuffle, this then includes new arrivals.
Happens on filebased or ODBC storage.
(issues #19032,#18582,#18692,#18998)
Reported by: alecdavis,tootai,afosorio
Review: https://reviewboard.asterisk.org/r/1153/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The segfault happens because jb->mutexjb is uninitialized from the
ast_malloc(). The internals of ast_mutex_init() were assuming a nonzero
value meant mutex tracking initialization had already happened. Recent
changes to mutex tracking code to reduce excessive memory consumption
exposed this uninitialized value.
Converted misdn_jb_init() to use ast_calloc() instead of ast_malloc().
Also eliminated redundant zero initialization code in the routine.
(closes issue #18975)
Reported by: irroot
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@312022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function isn't used anywhere yet, but we definitely don't want
to keep the same value for buf between calls to the function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@311558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is supposed to improve Solaris compatibility since Solaris goes berserk when trying to output NULL strings.
(closes issue #18759)
Reported by: bklang
Patches:
null-strings.patch uploaded by bklang (license 919)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@311352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The queued AST_CONTROL_BUSY could sometimes be processed before the
call_forward dial string is recognized.
* Moved setting the call_forwarding dial string after sending a response
to the initiator and just queue an empty frame to wake up the media thread
instead of an AST_CONTROL_BUSY.
* Added check for empty rerouting/deflection number and respond with an
error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@311297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r310986 | rmudgett | 2011-03-16 13:56:28 -0500 (Wed, 16 Mar 2011) | 28 lines
Dial() o option broke when connected line feature added.
The patch restores the o option behavior and adds the ability to specify
the CallerID. The Dial o and f options are complementary to each other.
The o option stores the CallerID on the outgoing channel as the channel's
CallerID. The f option forces the CallerID sent by the outgoing channel.
o(x) - The argument 'x' is optional. If not present, then specify that
the CallerID that was present on the *calling* channel be stored as the
CallerID on the *called* channel. This was the behavior of Asterisk 1.0
and earlier. If present, then specify the CallerID stored on the *called*
channel. Note that o(${CALLERID(all)}) is similar to option o without
parameters.
f(x) - The argument 'x' is optional and its presence changes the behavior
of this option. If not present, then force the outgoing CallerID on a
call-forward or deflection to the dialplan extension for this Dial() using
a dialplan 'hint'. For example, some PSTNs do not allow CallerID to be
set to anything other than the numbers assigned to you. If present, then
force the outgoing CallerID to 'x'.
Patches:
jira_abe_2752_dial_fo_options.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
JIRA ABE-2752
JIRA SWP-3096
..........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@311295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
