If we are unable to request a DAHDI pseudo channel and we are using the user introduction without review option make sure it gets unset so other code does not blindly assume a DAHDI pseudo channel exists.
(closes issue #14282)
Reported by: cheesegrits
........
................
Do a string comparison instead of pointer comparison since some people specify the context they are actually in as an argument to get around some funkiness.
(closes issue #14011)
Reported by: dveiga
Patches:
pbx.c.patch uploaded by dveiga (license 665)
........
................
Clear the autoloop flag when parsing and setting the context/extension/priority to go back to. When the channel executes a PBX again we want it to start out at the point we explicitly say and at that point it will not yet be doing autoloop.
(closes issue #14304)
Reported by: jcovert
........
AST_RWLOCK_INIT_VALUE is always defined. What we really wanted to ask is
whether autoconf detected a static initializer value. This fixes rwlocks
on all such platforms (mainly, Mac OS X).
(closes issue #13767)
Reported by: jcovert
Patches:
20090121__bug13767.diff.txt uploaded by Corydon76 (license 14)
Tested by: jcovert, Corydon76
........
................
Read lock the contexts to maintain the locking order when we are notified that the state of a device has changed.
(closes issue #13839)
Reported by: mcallist
........
................
Extra NULLs in the output cause some terminal types to abort in the middle of
a color code, causing terminal weirdness.
(closes issue #14130)
Reported by: coolmig
Patches:
20090121__bug14130.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, coolmig
........
................
Fix device state parsing issues for channel names with multiple slashes
The fix being applied is a bit different for trunk and the 1.6.X branches.
For trunk, we only wish to strip off the characters beyond the second slash
if the channel is a Local channel (i.e. we are removing the /n from the device
name). Other channel technologies with multiple slashes (e.g. DAHDI) need the
information after the second slash in order to get the proper device state
information.
In addition to this fix, the 1.6.X branches are receiving a much more important
fix as well. The problem in 1.6.X is that the member's device name was being directly
changed instead of having a copy changed. This meant that we would strip off the
second slash and trailing characters and then leave the member's device name like
that permanently thereafter.
Terry Wilson [Tue, 20 Jan 2009 20:13:18 +0000 (20:13 +0000)]
We don't support ~expiry in 1.6.0 register statements
This must have inadvertantly got merged in sometime as the code doesn't handle
this option, and configs/sip.conf.sample doesn't mention it as available. So
just remove it from the WARNING message
Make a proper builtin attended transfer to parking work
This is an ugly hack from 1.4 that allows the timeout callback from a parked
call to use the right channel name for the callback when the park is done with
a builtin attended transfer (that isn't completed early). This hasn't ever
worked in trunk and no one has complained yet, so eh.
........
Prevent a crash in chan_local due to a potential NULL pointer dereference
Move the check for if both channels on a local_pvt have generators to below
where p->chan is checked for NULLity (NULLness?). This prevents a crash from
occurring if p->chan is NULL.
Convert call to park_call_full to masq_park_call_announce
Since we removed the AST_PBX_KEEPALIVE return value, we need to use masqueraded
parking, otherwise we will try to call ast_hangup() in __pbx_run() and in
do_parking_thread() and then promptly crash.
(closes issue #14215)
Reported by: waverly360
Tested by: otherwiseguy
(closes issue #14228)
Reported by: kobaz
Tested by: otherwiseguy
........
................
Account for possible NULL pointer when we receive a 408 in response to a REGISTER
It may be that by the time we receive a reply to a REGISTER request, the attempt has
timed out and thus the registry structure pointed to by the corresponding sip_pvt has
gone away. This situation was handled properly for a 200 OK response, but the 408
case assumed that the sip_registry struct was non-NULL, thus potentially causing a crash
This commit fixes this assumption and prints out a message to the console if we should
receive a late 408 response to a REGISTER
Fix the conjugation of Russian and Ukrainian languages.
(related to issue #12475)
Reported by: chappell
Patches:
vm_multilang.patch uploaded by chappell (license 8)
........
................
This patch fixes a problem where a goto (or jump, in this case)
fails a consistency check because it can't find a matching
extension. The problem was a missing instruction to end
the range notation in the code where it converts the pattern
into a regex and uses the regex code to determine the match.
I tested using the AEL code the user supplied, and now,
the consistency check passes.
remove the PBX_ODBC logic from the configure script, and add GENERIC_ODCB logic that includes copying the relevant LIB and INCLUDE data from either UnixODBC or iODBC, based on which was found; if both were found, prefer UnixODBC
this stops modules from being linked against both sets of libraries on systems that have both installed
........
Make sure that we have the same terminology in sip.conf.sample and the source code warning.
Thanks Nick Lewis for pointing this out in the bug tracker.
Add a missing unlock and properly handle the 'maxusers' setting on MeetMe
conferences. We were using the 'user number' field to compare against the
maximum allowed users, which works assuming users with lower user numbers
didn't leave the conference.
Fix some crashes from bad datastore handling in app_queue.c
* The queue_transfer_fixup function was searching for and removing
the datastore from the incorrect channel, so this was fixed.
* Most datastore operations regarding the queue_transfer datastore
were being done without the channel locked, so proper channel locking
was added, too.
* Fixed create_process() allocation of process ID values.
The allocated process IDs could overflow their respective
NT and TE fields. Affects outgoing calls.
........
................
Don't read into a buffer without first checking if a value is beyond the end.
(closes issue #13600)
Reported by: atis
Patches:
20090106__bug13600.diff.txt uploaded by Corydon76 (license 14)
Tested by: atis
........
................
Don't overflow when paging more than 128 extensions
The number of available slots for calls in app_page was hardcoded to 128.
Proper bounds checking was not in place to enforce this limit, so if more than
128 extensions were passed to the Page() app, Asterisk would crash. This patch
instead dynamically allocates memory for the ast_dial structures and removes
the (non-functional) arbitrary limit.
This issue would have special importance to anyone who is dynamically creating
the argument passed to the Page application and allowing more than 128
extensions to be added by an outside user via some external interface.
The patch posted by a_villacis was slightly modified for some coding guidelines
and other cleanups. Thanks, a_villacis!
(closes issue #14217)
Reported by: a_villacis
Patches: 20080912-asterisk-app_page-fix-buffer-overflow.patch uploaded by a (license 660)
Tested by: otherwiseguy
........
................
If either conditional is NULL, don't try copying it.
(closes issue #14226)
Reported by: caspy
Patches:
20090113__bug14226.diff.txt uploaded by Corydon76 (license 14)
........
................
Repeat attempts to write when we receive -EAGAIN from the driver, as detailed
in the ALSA sample code (see http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2pcm_8c-example.html#a32)
Reported by: Jerry Geis (via the -users list)
Fixed by: me (license 14)
........
................
This gits rid of the notion of an owning_app allowing the request and hangup to be initiated by different threads. Originating from an active agent channel requires this. The implementation primarily changes __login_exec to wait on a condition variable rather than a lock.
I am reverting the fix made in revision 168128 (and its upward merges)
after being contacted by Olle Johansson and being shown how this fix is
incorrect. Thanks to Olle for clearing this up for me.
INFO, NOTIFY, OPTIONS, REFER, and MESSAGE requests
were not checking the topmost Via to determine where
to send the response. Adding check_via calls to those
request handlers solves this.
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.
Answer the channel if it has not already been answered and we've already found a valid profile for followme.
(closes issue #14140)
Reported by: dimas
Patches:
14140.patch uploaded by dimas
........
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.
Leif Madsen [Wed, 7 Jan 2009 14:33:38 +0000 (14:33 +0000)]
Merged revisions 167373 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
r167373 | lmadsen | 2009-01-07 09:26:19 -0500 (Wed, 07 Jan 2009) | 1 line
Update the sip-friends.sql file to use the non-deprecated 'defaultname' instead of 'username' and remove an extra comma that would cause the script to fail as-is
........
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
More clearly explain that quote marks are no longer necessary.
(closes issue #13718)
Reported by: davidw
Patches:
20081020__bug13718.diff.txt uploaded by Corydon76 (license 14)
Tested by: blitzrage
........
When parsing environment variable ASTERISK_PROMPT, make sure to proceed to the next character when a non format specifier is used (no %). Otherwise, the while loop looking for the null byte will never exit.
Update app_queue to deal with the removal of AST_PBX_KEEPALIVE
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.
There is no section 22.2.2 in rfc 3261. I believe 26.2.2 is what was meant:
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.
........
Steve Murphy [Wed, 24 Dec 2008 00:52:12 +0000 (00:52 +0000)]
Merged revisions 166665 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Due to non-symmetrical updating, I had some fairly
interesting conflicts to straighten out in this
release. The changes were such that I was compelled
to run thru all the same tests as trunk, which turned
up some problems, which I fixed.
Merged revisions 166093 via svnmerge from
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.
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.
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.
Russell Bryant [Mon, 22 Dec 2008 17:14:18 +0000 (17:14 +0000)]
Merged revisions 166282 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
r166282 | russell | 2008-12-22 11:09:36 -0600 (Mon, 22 Dec 2008) | 12 lines
Introduce ast_careful_fwrite() and use in AMI to prevent partial writes.
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/
Mark Michelson [Mon, 22 Dec 2008 16:30:25 +0000 (16:30 +0000)]
When merging the fix for issue #14118, I found that
the issue didn't affect 1.6.0, but in this case that's
not an especially good thing, because it means that
the fix for issue #13496 was not merged into 1.6.0 in
the first place. This commit kills two birds with one
stone by putting both fixes in the 1.6.0 branch
Mark Michelson [Mon, 22 Dec 2008 16:12:34 +0000 (16:12 +0000)]
Back these changes out for now. The initial refcounting
for filestreams didn't get merged into 1.6.0. I'll have
to get that in first and then put this change in
Fix a file playback crash and explicitly initialize values in func_timeout.c
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.
projects / thirdparty / asterisk.git / log
