Age | Commit message (Collapse) | Author | Files | Lines |
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
Handle failures building translation paths more effectively.
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@296001 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292411 | pabelanger | 2010-10-20 20:00:51 -0400 (Wed, 20 Oct 2010) | 10 lines
Record priv-recordintro as sln, not gsm
This removes the gsm->sln step when transcoding
priv-recordintro.
(closes issue #18176)
Reported by: pabelanger
Patches:
chan_sip.diff uploaded by pabelanger (license 224)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@292412 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
pattern ranges and pattern special characters was inconsistent.
(closes issue #16903)
Reported by: Nick_Lewis
Patches:
pbx.c-specificity.patch uploaded by Nick Lewis (license 657)
Tested by: Nick_Lewis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@285710 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279206 | rmudgett | 2010-07-23 16:56:44 -0500 (Fri, 23 Jul 2010) | 7 lines
SIP promiscuous redirect could fail to dial the redirect.
The ast_channel was created with one variable to ast_request() but the
call to ast_call() that initiates the outgoing call was using a different
variable. The two variables are not equivalent if the call_forward string
included a channel technology specifier. e.g., SIP/200
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@279207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r275028 | mnicholson | 2010-07-09 11:05:58 -0500 (Fri, 09 Jul 2010) | 15 lines
Merged revisions 275027 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r275027 | mnicholson | 2010-07-09 11:04:21 -0500 (Fri, 09 Jul 2010) | 8 lines
Clear the AST_CDR_FLAG_DIALED flag for channels going into the pbx via the G option in app_dial
(closes issue #17592)
Reported by: jamicque
Patches:
G-flag-cdr-fix1.diff uploaded by mnicholson (license 96)
Tested by: jamicque, mnicholson
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@275029 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r255504 | lmadsen | 2010-03-31 12:48:09 -0500 (Wed, 31 Mar 2010) | 5 lines
Add documentation clarifying when 't' and 'T' can be used.
(closes issue #17021)
Reported by: kovzol
Tested by: lmadsen, kovzol, davidw, ebroad
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@255505 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r253538 | russell | 2010-03-20 06:43:08 -0500 (Sat, 20 Mar 2010) | 2 lines
Resolve compiler warnings on FreeBSD.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@253612 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r244393 | tilghman | 2010-02-02 14:32:29 -0600 (Tue, 02 Feb 2010) | 18 lines
Properly respect GOSUB_RESULT as to what to do with the master channel.
Previously, we would parse GOSUB_RESULT, but not actually do anything with it.
(closes issue #16686)
Reported by: bklang
Patches:
app_dial-respect-gosub_result.patch uploaded by bklang (license 919)
(with modifications)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@244395 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r227829 | mnicholson | 2009-11-04 15:03:33 -0600 (Wed, 04 Nov 2009) | 17 lines
Merged revisions 227827 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r227827 | mnicholson | 2009-11-04 14:52:27 -0600 (Wed, 04 Nov 2009) | 10 lines
This patch modifies the Dial application to monitor the calling channel for hangups while playing back announcements.
(closes issue #16005)
Reported by: falves11
Patches:
dial-announce-hangup-fix1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, falves11
Review: https://reviewboard.asterisk.org/r/407/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@227831 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r226890 | file | 2009-11-02 14:08:54 -0400 (Mon, 02 Nov 2009) | 18 lines
Merged revisions 226889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226889 | file | 2009-11-02 14:08:11 -0400 (Mon, 02 Nov 2009) | 11 lines
Fix a bug where the recorded privacy introduction file would not get removed if the caller hung up
while the called party had not yet answered.
This was fixed by introducing an argument to the 'n' option which, when enabled, removes the introduction
file under all scenarios. This was done to preserve the behavior that has existed for quite some time.
(closes issue #14674)
Reported by: ulogic
Patches:
bug14674.patch uploaded by jpeeler (license 325)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@226893 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r224567 | file | 2009-10-19 16:49:09 -0300 (Mon, 19 Oct 2009) | 12 lines
Merged revisions 224565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r224565 | file | 2009-10-19 16:47:50 -0300 (Mon, 19 Oct 2009) | 5 lines
Do not attempt early media bridging (ie: direct RTP setup) if options are enabled that should prevent it.
(closes issue #14763)
Reported by: cupotka
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@224571 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r223832 | jpeeler | 2009-10-12 18:48:09 -0500 (Mon, 12 Oct 2009) | 15 lines
Merged revisions 223804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r223804 | jpeeler | 2009-10-12 18:12:50 -0500 (Mon, 12 Oct 2009) | 8 lines
Ensure ringing continues for branched calls after progress is received
While waiting for an answer, don't send progress for branched calls
for which ringing was sent.
(closes issue #15028)
Reported by: fnordian
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@223835 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r223215 | mmichelson | 2009-10-09 13:17:34 -0500 (Fri, 09 Oct 2009) | 9 lines
Recorded merge of revisions 223213 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r223213 | mmichelson | 2009-10-09 13:17:12 -0500 (Fri, 09 Oct 2009) | 3 lines
Fix potential memory leak in app_dial.c
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@223257 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r208593 | russell | 2009-07-24 13:42:32 -0500 (Fri, 24 Jul 2009) | 14 lines
Merged revisions 208592 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r208592 | russell | 2009-07-24 13:38:24 -0500 (Fri, 24 Jul 2009) | 7 lines
Do not log an ERROR if autoservice_stop() returns -1.
This does not indicate an error. A return of -1 just means that the channel
has been hung up.
(reported in #asterisk-dev)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@208596 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r198285 | seanbright | 2009-05-29 23:26:06 -0400 (Fri, 29 May 2009) | 15 lines
Merged revisions 198251 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r198251 | seanbright | 2009-05-29 22:46:41 -0400 (Fri, 29 May 2009) | 8 lines
Treat an empty FORWARD_CONTEXT the same way we treat a missing one.
(closes issue #15056)
Reported by: p_lindheimer
Patches:
05292009_bug15056.diff uploaded by seanbright (license 71)
Tested by: p_lindheimer
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@198297 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r195162 | eliel | 2009-05-18 10:45:23 -0400 (Mon, 18 May 2009) | 9 lines
Warn about the use of the application WaitExten() within a Macro().
Update applications documentation to warn the user about the use of the
WaitExten() application within a Macro(). Recommend the use of Read()
instead.
(closes issue #14444)
Reported by: ewieling
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@195164 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r189495 | twilson | 2009-04-20 16:24:34 -0500 (Mon, 20 Apr 2009) | 9 lines
Merged revisions 189463 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189463 | twilson | 2009-04-20 16:00:52 -0500 (Mon, 20 Apr 2009) | 2 lines
Don't treat a NOANSWER like a CHANUNAVAIL
........
................
r189516 | twilson | 2009-04-20 16:29:29 -0500 (Mon, 20 Apr 2009) | 9 lines
Merged revisions 189465 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189465 | twilson | 2009-04-20 16:10:27 -0500 (Mon, 20 Apr 2009) | 2 lines
Update CDR appropriately when AST_CAUSE_NO_ANSWER is set
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.2@189536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
application.
(closes issue #14647)
Reported by: sherpya
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@181612 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14601)
Reported by: alecdavis
Patches:
app_dial.optionk.diff.txt uploaded by alecdavis (license 585)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@180120 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@174945 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
reviewboard this before committing again...
reopened 11583 until all Russell's issues are
resolved.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@172929 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to be used within the dial app, before a call is bridged.
Many thanks to sobomax for submitting this patch.
Quoting from bug 11582:
"So the goal of the patch was to use the user configured feature code during the
call setup phase. The original ast_feature_interpret() function is not well suited
for this purpose as it uses much call bridge specific data and doesn't separate a
detection of feature from a feature handler call. So a new function ast_feature_detect()
has been extracted off the ast_feature_interpret() function but keeping the original
logic intact except some insignificant changes to locking.
"Having created the ast_feature_detect() function the possibility to use feature detection
in almost any place of the asterisk code. So a call to this function has been added to
wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler
however and uses old call leg disconnect logic to make the changes as small and simple as
possible to prevent unexpected problems. A disconnect feature currently is the only one
supported during call setup as other features as call parking and call transfer don't make much
sense during call setup. However if need in some of the features would arise it is much easier to
implement as the infrastructure changes are already in place with this patch."
I have cleaned up the patch somewhat, and verified that the existing functionality is not
harmed, and that the new functionality works. Terry has committed his stuff, and there were
no conflicts (see 14274).
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
patch-include__asterisk__features.h uploaded by sobomax (license 359)
patch-res__res_features.c uploaded by sobomax (license 359)
enable-features-during-call-setup.diff uploaded by sobomax (license 359)
11583.newdiff uploaded by murf (license 17)
enable-features-during-call-setup-1.diff uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
Tested by: sobomax, murf
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@172890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@172580 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Also, implement a private cause code (as suggested by Tilghman). This works with
chan_sip, but doesn't propagate through chan_local.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@172318 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170568 | file | 2009-01-23 15:06:54 -0400 (Fri, 23 Jan 2009) | 4 lines
When a call is forwarded stop any active indications. The new channel will provide an indication, if need be, itself.
(closes issue #14310)
Reported by: RadicAlish
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@170569 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@167935 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
When placing a call to a queue which ran a gosub on the member's
channel, Asterisk would crash every time, stemming from the fact
that the member's channel was being hung up unexpectedly when the
Gosub completed. The necessary change was pretty much copied and
pasted from app_dial's similar changes made last week.
I also took the opportunity to change a LOG_DEBUG message in
app_dial to use ast_debug. I am guessing this was due to a direct
merge from 1.4 that was not corrected to use trunk's preferred
syntax.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@166861 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@166665 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is part of an effort to completely remove AST_PBX_KEEPALIVE and other
similar return codes from the source. While this usage was perfectly safe,
there are others that are problematic. Since we know ahead of time that
we do not want to PBX to destroy the channel, the PBX API has been changed
so that information can be provided as an argument, instead, thus removing
the need for the KEEPALIVE return value.
Further changes to get rid of KEEPALIVE and related code is being done by
murf. There is a patch up for that on review 29.
Review: http://reviewboard.digium.com/r/98/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@165723 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
for app_dial and app_queue to run a gosub when the call is answered.
* Check for the existence of the gosub target in gosub_exec. If it is nonexistent,
then this will cause errors when we attempt to actually run the gosub, including
a definite memory leak and potential crashes. Return an error in this situation
* Check the return value of pbx_exec in app_dial and app_queue before attempting
to actually run the gosub routine. If there was an error, we should not attempt
to run the gosub.
* Change a '|' to a ',' in app_queue.
* Add some extra curly braces where they had been missing previously.
(closes issue #13548)
Reported by: fiddur
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@160626 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a call fails
1) Hang up the original destination if the local channel cannot
be requested.
2) Hang up the local channel (in addition to the original destination)
if ast_call fails when calling the newly created local channel.
This prevents channels from sticking around forever in the
case of a botched call forward (e.g. to an extension which does not
exist).
(closes issue #13764)
Reported by: davidw
Patches:
13764_v2.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, davidw
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@159554 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158053 | mmichelson | 2008-11-20 11:33:06 -0600 (Thu, 20 Nov 2008) | 12 lines
Make sure to set the hangup cause on the calling channel in the case
that ast_call() fails. For incoming SIP channels, this was causing
us to send a 603 instead of a 486 when the call-limit was reached on
the destination channel.
(closes issue #13867)
Reported by: still_nsk
Patches:
13867.diff uploaded by putnopvut (license 60)
Tested by: blitzrage
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@158066 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines
Fix a crash in the end_bridge_callback of app_dial and
app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@157306 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a function: in these cases, we have to use the heap, or garbage will result.
(closes issue #13898)
Reported by: alecdavis
Patches:
20081114__bug13898__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@157253 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156386 | tilghman | 2008-11-12 15:18:57 -0600 (Wed, 12 Nov 2008) | 5 lines
When using call limits under 1 second, infinite call lengths are allowed,
instead.
(closes issue #13851)
Reported by: ruddy
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@156388 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156167 | mmichelson | 2008-11-12 11:38:33 -0600 (Wed, 12 Nov 2008) | 7 lines
When doing some tests, I was having a crash at the end of every call
if an attended transfer occurred during the call. I traced the cause to
the CDR on one of the channels being NULL. murf suggested a check in
the end bridge callback to be sure the CDR is non-NULL before proceeding,
so that's what I'm adding.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@156169 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r155553 | seanbright | 2008-11-08 20:08:07 -0500 (Sat, 08 Nov 2008) | 6 lines
Use static functions here instead of nested ones. This requires a small
change to the ast_bridge_config struct as well. To understand the reason
for this change, see the following post:
http://gcc.gnu.org/ml/gcc-help/2008-11/msg00049.html
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@155554 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
branch, and add the ones needed for all the new code here too
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@153616 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@153468 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This commit introduces the first phase of an effort to manage documentation of the
interfaces in Asterisk in an XML format. Currently, a new format is available for
applications and dialplan functions. A good number of conversions to the new format
are also included.
For more information, see the following message to asterisk-dev:
http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@153365 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@153181 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152538 | murf | 2008-10-28 23:19:04 -0600 (Tue, 28 Oct 2008) | 14 lines
A little documentation cross-ref between features and
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@152605 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@152536 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152368 | tilghman | 2008-10-28 12:04:56 -0500 (Tue, 28 Oct 2008) | 8 lines
Reset all DIAL variables back to blank, in case Dial is called multiple times
per call (which could otherwise lead to inconsistent status reports).
(closes issue #13216)
Reported by: ruddy
Patches:
20081014__bug13216.diff.txt uploaded by Corydon76 (license 14)
Tested by: ruddy
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@152369 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to mean that no timeout is desired.
(closes issue #13625)
Reported by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@149279 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so we don't have to hardcode anything.
(closes issue #13636)
Reported by: seanbright
Patches:
13636.diff uploaded by seanbright (license 71)
Reviewed by: russellb, putnopvut
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@147388 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
our DAHDI operator mode stuff. Technically, it would work fine, as 'DAH'
is currently unique amongst our channel technologies, but as Jared points
out:
<@jsmith> Sure... as long as the technology starts whith DAH.... but
it could be DAHDOO!
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@147050 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #13354)
Reported by: adomjan
Patches:
20080828__bug13354.diff.txt uploaded by Corydon76 (license 14)
20080829__bug13354__1.6.0.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, adomjan
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@143031 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@142676 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@139627 f38db490-d61c-443f-a65b-d21fe96a405b
|