following: "name <number>" (including the quotation marks), then the parts
would be parsed as
name: "name
number: number
This is because the closing quotation mark was not discovered since the number
and everything after was parsed out of the string earlier. Now, there is a check
to see if the closing quote occurs after the number, so that we can know if we
should strip off the opening quote on the name.
Closes AST-158
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: john8675309
Patches:
patch.13597 uploaded by murf (license 17)
Tested by: murf, john8675309
This patch causes the setcid func to update the CDR
clid after setting the channel field.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was initiated but not yet completed. If the bridge is immediately retried,
then we may send a storm of TXREQ packets, even though the first set is sent
reliably (retransmitted). Fixes AST-137.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
