https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271399 | jpeeler | 2010-06-18 14:28:24 -0500 (Fri, 18 Jun 2010) | 11 lines
Fix crash when parsing some heavily nested statements in AEL on reload.
Due to the recursion used when compiling AEL in gen_prios, all the stack space
was being consumed when parsing some AEL that contained nesting 13 levels deep.
Changing a few large buffers to be heap allocated fixed the crash, although I
did not test how many more levels can now be safely used.
(closes issue #16053)
Reported by: diLLec
Tested by: jpeeler
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271335 | jpeeler | 2010-06-18 13:33:17 -0500 (Fri, 18 Jun 2010) | 13 lines
Eliminate deadlock potential in dahdi_fixup().
(This is a backport of 269307, committed to trunk by rmudgett.)
Calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
(closes issue #17261)
Reported by: aragon
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271336 65c4cc65-6c06-0410-ace0-fbb531ad65f3
According to RFC 3261 section 17.2.2, which describes non-INVITE server
transaction, when a dialog enters the Completed state it must destroy
the dialog after Timer J (T1*64) fires. For a BYE transaction Asterisk
terminates the dialog immediately during sip_hangup() when it should be
waiting T1*64 ms. This results in some odd behavior. For instance if
Asterisk receives a BYE and transmits a 200ok in response, if the endpoint
never receives the 200ok it will retransmit the BYE to which Asterisk
responds with a "481 Call leg/transaction does not exist" because the
dialog is already gone.
To resolve this I made a function called sip_scheddestroy_final(). This
differs slightly from sip_schedestroy() in that it enables a flag that
will prevent the destruction from ever being rescheduled or canceled
afterwards. It also prevents the pvt's needdestroy flag from being set
which triggers the destruction of the dialog within the do_monitor thread().
By using this function we are guaranteed destruction will not occur
until the scheduled time. This allows Asterisk to respond to any possible
retransmits for a dialog after we process the initial BYE request for T1*64 ms.
Other changes: I removed two instances where sip_cancel_destroy is used
right before calling sip_scheddestroy. sip_scheddestroy always calls
sip_cancel_destroy before scheduling the new destruction so it is completely
unnecessary.
Review: https://reviewboard.asterisk.org/r/694/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Clearing the callwaitcas flag in analog_call was causing the incoming D digit
to be ignored which triggers sending the caller ID.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If there is a problem with a firmware file, Polycom phones will close the
connection. We were continuing to send the file anyway. There should be no
reason to continue sending a file if there is an error writing it.
(closes issue #16682)
Reported by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the manager http auth changes, we forgot to remove the manual
sending of the file. Also, ast_http_send adds two \r\n to the header that
is passed to it, so a trailing \r\n is removed from the Content-type
header. It might be better to change ast_http_send, but I don't like changing
the behavior of an API function.
(closes issue #17239)
Reported by: cjacobsen
Patches:
patch2.diff uploaded by cjacobsen (license 1029)
Tested by: lathama, cjacobsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270660 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "channel" option would chop the channel name at the last '-', which made
it useless for something like a channel transfer from the dialplan. The
"fullchannel" option will return the channel name as-is.
ABE-2218
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Theoretically the ./configure script is a pure bourne-shell script.
Practically it may be run by bash if /bin/sh is not good enough. But we should not count on it. See bug report for the gory details.
(closes issue #17485)
Patches:
0001-remove-bashism-from-ast_check_pwlib.m4.patch uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This way the libraries can be found even if they are in
non-standard locations.
(closes issue #16155)
Reported by: jcollie
Patches:
0008-change-configure.ac-to-look-for-pkg-config-gmime-2.0.patch uploaded by jcollie (license 412)
Tested by: jsmith, tilghman, pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines
Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r269426 | qwell | 2010-06-09 16:19:17 -0500 (Wed, 09 Jun 2010) | 6 lines
Let systems without a working fork() use res_musiconhold.
Files mode doesn't require anything special, so that can still be used just fine.
AST-357
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind pointed out that attempting to get an IE value from an event that has
no IEs produces an invalid memory read past the end of the event. Thanks to
mmichelson for pointing the problem out to me and then testing the fix.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
