This patch adds the functionality to app_queue of calculating
the average amount of time that channels are bridged for a
queue. The algorithm used to calculate the average is the same
exponential average currently used to calculate the average holdtime.
See the CHANGES file to see the methods you may use to view this
information.
(closes issue #13960)
Reported by: coolmig
Patches:
app_queue.c.diff.trunk-r158840 uploaded by coolmig (license 621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167792 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r167620 | kpfleming | 2009-01-07 17:32:21 -0600 (Wed, 07 Jan 2009) | 5 lines
When a SIP request or response arrives for a dialog with an associated Asterisk channel, and the lock on that channel cannot be obtained because it is held by another thread, instead of dropping the request/response, queue it for later processing when the channel lock becomes available.
http://reviewboard.digium.com/r/123/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the queues.conf.sample documentation to mention that you need to preload chan_local.so as well if you plan on using Local channels for queue members, and you're preloading pbx_config.so.
(closes issue #14179)
Reported by: CrashHD
Tested by: CrashHD
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r167179 | mmichelson | 2009-01-05 10:51:59 -0600 (Mon, 05 Jan 2009) | 41 lines
A couple of changes to T.38 SDP attribute handling
There are some boolean attributes for T.38 such
as T38FaxFillBitRemoval, T38FaxTranscodingMMR, and
T38FaxTranscodingJBIG. By simply being present, we
should treat these as a "true" value. The current
code, however, was requiring a 1 or 0 as the value
of the attribute in order to parse it. This is due
to the fact that there are some T.38 endpoints and
gateways that also transmit this information
incorrectly. This patch follows the "be liberal in
what you accept and strict in what you send"
philosophy by accepting both the correctly- and
incorrectly-formatted attributes, but only sending
information as it is supposed to be sent.
It was also discovered that a particular type of
T.38 gateway sends some non-standard T.38 SDP
attributes. Instead of using T38FaxMaxDatagram
and T38MaxBitRate, it used T38MaxDatagram and
T38FaxMaxRate respectively. We now will properly
accept these attributes as well.
Note that there are a lot of patches cited in
the below commit message template. This is
because the person who submitted these patches is
an awesome person and wrote 1.4, 1.6.0, and 1.6.1
variants.
(closes issue #13976)
Reported by: linulin
Patches:
chan_sip.c.1.4-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.4-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.0-relaxedT38_update1.diff uploaded by arcivanov (license 648)
chan_sip.c.1.6.1-relaxedT38_update1.diff uploaded by arcivanov (license 648)
Tested by: arcivanov
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@166861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Note that in the SIPS URI scheme, transport is independent of TLS,
and thus "sips:alice@atlanta.com;transport=tcp" and
"sips:alice@atlanta.com;transport=sctp" are both valid (although
note that UDP is not a valid transport for SIPS). The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r166592 | tilghman | 2008-12-23 09:35:38 -0600 (Tue, 23 Dec 2008) | 3 lines
Compile, even if both DAHDI and Zaptel are not installed.
(Closes issue #14120)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166568 | mmichelson | 2008-12-23 09:16:26 -0600 (Tue, 23 Dec 2008) | 12 lines
Fix a crash resulting from a datastore with inheritance but no duplicate callback
The fix for this is to simply set the newly created datastore's data pointer
to NULL if it is inherited but has no duplicate callback.
(closes issue #14113)
Reported by: francesco_r
Patches:
14113.patch uploaded by putnopvut (license 60)
Tested by: francesco_r
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the value of AGISIGUP was not always
honored when set on a channel.
(closes issue #13711)
Reported by: fmueller
Patches:
13711.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166380 | mmichelson | 2008-12-22 14:56:29 -0600 (Mon, 22 Dec 2008) | 36 lines
Fix a deadlock relating to channel locks and autoservice
It has been discovered that if a channel is locked prior
to a call to ast_autoservice_stop, then it is likely that
a deadlock will occur. The reason is that the call to
ast_autoservice_stop has a check built into it to be sure
that the thread running autoservice is not currently trying
to manipulate the channel we are about to pull out of
autoservice.
The autoservice thread, however, cannot advance beyond where
it currently is, though, because it is trying to acquire
the lock of the channel for which autoservice is attempting
to be stopped.
The gist of all this is that a channel MUST NOT be locked
when attempting to stop autoservice on the channel.
In this particular case, the channel was locked by a call
to ast_read. A call to ast_exists_extension led to autoservice
being started and stopped due to the existence of dialplan
switches.
It may be that there are future commits which handle the same
symptoms but in a different location, but based on my looks through
the code, it is very rare to see a construct such as this one.
(closes issue #14057)
Reported by: rtrauntvein
Patches:
14057v3.patch uploaded by putnopvut (license 60)
Tested by: rtrauntvein
Review: http://reviewboard.digium.com/r/107/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch introduces a function to do careful writes on a file stream which
will handle timeouts and partial writes. It is currently used in AMI to
address the issue that has been reported. However, there are probably a few
other places where this could be used.
(closes issue #13546)
Reported by: srt
Tested by: russell
http://reviewboard.digium.com/r/104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A crash was brought up on the bugtracker. The first run through valgrind
was full of legitimate complaints of uninitialized values in func_timeout when
setting a response timeout. These were fixed but the crash persisted.
A second run through showed the real problem. The reference counting used
for filestreams was incorrect because there were some missing increments
when a frame was read from a format module.
(closes issue #14118)
Reported by: blitzrage
Patches:
14118v2.patch uploaded by putnopvut (license 60)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
