then that new entry will not be processed promptly, but must wait for either a
future entry to start or a current entry's retry to occur. If no other entries
exist in the directory (other than the new entries) when a bunch expire, then
the new entries must wait until another new entry is added to be processed.
This was a rather weird race condition, really. Fixes AST-147.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"I guess that having only ip-phones in mind is not a good approach. Since it is
possible to have a sip proxy connected to asterisk we could receive a 407
(unauthorized) or 483 (too many hops) as response and dialog ending would not be
a good behavior."
So modified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
fails, and the resulting integer is garbage. Thus, we must initialize the
integer and check it afterwards for success.
(closes issue #14000)
Reported by: folke
Patches:
asterisk-sipbg-sscanf-1.4.22.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-1.6.0.1.diff uploaded by folke (license 626)
asterisk-sipbg-sscanf-trunk-r159896.diff uploaded by folke (license 626)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
both have the potential to send control frames in the middle of call setup. We
have to wait until we have received a message back from the remote end before
we try to send any more frames. Otherwise, the remote end will consider it
invalid, and we'll get stuck in an INVAL/VNAK storm.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
add channels/busy.h and channels/ringtone.h to the repository instead of generating them repeatedtly; most users do not change the settings to build them, but the Makefile rules are still there if they wish to do so
ensure that 'make clean' removes dependency files for .i files that are created in COMPILE_DOUBLE mode
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159476 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: yraber
Patches:
12694.2nd.diff uploaded by murf (license 17)
Tested by: murf, laurav
Thanks to file (Joshua Colp) for his IAX fix.
the change to cdr.c allows no-answer to percolate
up into CDR's, and feels like the right place to
locate this fix; if BUSY is done here, no-answer
should be, too.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
When compiling against Zaptel dahdi_compat will now only define all the DAHDI defines if the Zaptel define is present. Also, there is no such thing as DAHDI_PRI.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
merging the fix into 1.6.0 and realized I missed
the code in the h-exten block, and didn't catch it
because my test case had the h-exten commented out.
So, this corrects the code I missed, as a
preventative against another crash report.
Tested with the h-exten defined, all is well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because we strip spaces when copying the extension into the structure.
Therefore, use the copied item to place the item into the list.
(found by lmadsen on -dev, fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mdu113
This one is totally my fault. The code doesn't even
create a bridge if the channel CDR has POST_DISABLED.
I didn't check for that at the end of the bridge.
Fixed with a few small insertions. Tested. Looks
good. No cdr generated, no crash, no unnecc. data
objects created either.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
frame in a freed ast_filestream. This patch makes use of the
ao2 functions to make sure that we do not free an ast_filestream
structure until the embedded ast_frame has been "freed" as well.
(closes issue #13496)
Reported by: fst-onge
Patches:
filestream_frame_1_4.diff uploaded by putnopvut (license 60)
Tested by: putnopvut
Closes AST-89
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
section 15 of RFC 3261, we should terminate a dialog if we
receive a 481 or 408 in response to our BYE. Since I am aware
of at least one phone manufacturer who may sometimes send a
404 as well, I am being liberal and saying that any 4XX response
to a BYE should result in a terminated dialog.
(closes issue #12994)
Reported by: pabelanger
Patches:
12994.patch uploaded by putnopvut (license 60)
Closes AST-129
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@158053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with this build system change, if (and only if) --enable-dev-mode was used and DONT_OPTIMIZE is turned on, when a source file is compiled it will actually be preprocessed (into a .i or .ii file), then compiled once with optimization (with the result sent to /dev/null) and again without optimization (but only if the first compile succeeded, of course).
while making these changes, i did some cleanup work in Makefile.rules to move commonly-used combinations of flag variables into their own variables, to make the file easier to read and maintain
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
function. Not setting the invite state correctly on the call was
resulting in the Record application leaving empty files. I also
have updated the doxygen comment next to the declaration of the
INV_EARLY_MEDIA constant to reflect that we also use this state
when we *send* a 18X response to an INVITE.
(closes issue #13878)
Reported by: nahuelgreco
Patches:
sip-early-media-recording-1.4.22.patch uploaded by nahuelgreco (license 162)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: akkornel
This fix is the result of a bug fix in ast_app_separate_args r124395. If an argument does not exist it should always be set to a null string rather than a null pointer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@157305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) update to doxygen 1.5.x style file, as used in trunk
2) tell doxygen where are header files are, so include-file processing can be done
3) make all macros that are used to define variables/functions be expanded, so that doxygen will properly document the resulting variable/function
4) make all macros that are used to provide the contents of a variable (structure) be expanded, so that doxygen will be able to document the resulting fields
5) suppress compiler attributes (__attribute__(xxx)) from being seen by doxygen, so it will properly match up function definition and usage (for an example of th effect of this, look at the doxygen docs for ast_log() from before and afte this commit)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157104 65c4cc65-6c06-0410-ace0-fbb531ad65f3
resulted in the password not being saved, even if the input matched
what you gave when first prompted to enter a new password. This is
because the return value of ast_readstring was checked, but not checked
properly.
This bug was discovered by Jared Smith during an Asterisk training course.
Thanks for reporting it!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
N, X, and Z are off by one, as per conversation with
jsmith on #asterisk-dev; he was teaching a class
and disconcerted that this published rule was not
being followed, with patterns _NXX, _[1-8]22 and
_[2-9]22... and NXX was winning, but [1-8] should
have been.
This change, tested on these 3 patterns now
picks the proper one.
However, this change may surprise users who
set up dialplans based on previous behavior,
which has been there for what, 2 and half
years or so now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be sent, and instead, schedule a task to destroy the iax2 pvt structure
10 seconds later. This allows the IAX2 HANGUP packet to be queued,
transmitted, and ACKed before the pvt is destroyed.
(closes issue #13645)
Reported by: dzajro
Patches:
20081111__bug13645__3.diff.txt uploaded by Corydon76 (license 14)
Tested by: vazir
Reviewed: http://reviewboard.digium.com/r/51/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pep
This change adds an announce_thread responsible for playing announcements to an existing conference. This allows all announcing to be immediately stopped if necessary but more importantly allows other threads that need to play something to not block. There are multiple benefits to this, but the actual bug is for solving the scenario for a channel to be unusable after hang up for the entire duration of the parting announcement. The parting announcement can be extremely long depending on what the user recorded upon joining the conference.
Reviewed by Russell on Review Board:
http://reviewboard.digium.com/r/25/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@156178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@156167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
