Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is one of the few things I could find that was just plain wrong.
Even though it probably isn't possible for it to happen, it seems weird
to have code that checks if a pointer is NULL and then immediately dereferences
that pointer if it was NULL.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that these variables were being appended to the list of vars
on the sip_pvt every time a re-registration or re-subscription came in.
Since it's just a waste of memory to put them there unless the request was an
INVITE, then the fix is to check the request type before copying the vars.
(closes issue #14037)
Reported by: marvinek
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164672 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
"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
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
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
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
is invoked, that the channel on which the callback was called
is locked. This patch corrects an instance in chan_agent where
a channel's indicate callback is called directly without first
locking the channel.
This was leading to some observed locking issues in chan_local,
but considering that all channel drivers operate under the
same expectations, the generic fix in chan_agent is the right
way to go.
AST-126
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@155861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of code to change, unless the structure is locked to ensure a consistent
state.
(closes issue #13717)
Reported by: kowalma
Patches:
20081102__bug13717.diff.txt uploaded by Corydon76 (license 14)
Tested by: kowalma
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@154365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't always define HAVE_ZAPTEL_CHANALARMS (since we check if it's defined..)
Minor cleanup to make things clear.
(closes issue #13726)
Reported by: tzafrir
Patches:
dahdi_def.diff uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
