https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176216 | kpfleming | 2009-02-16 15:10:38 -0600 (Mon, 16 Feb 2009) | 3 lines
fix a flaw in the ast_string_field_build() family of API calls; these functions made no attempt to reuse the space already allocated to a field, so every time the field was written it would allocate new space, leading to what appeared to be a memory leak.
........
r176254 | kpfleming | 2009-02-16 15:41:46 -0600 (Mon, 16 Feb 2009) | 3 lines
correct a logic error in the last stringfields commit... don't mark additional space as allocated if the string was built using already-allocated space
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I was finding that on my dev box, occasionally attempting to "stop now" in
trunk would cause Asterisk to hang. I traced this to the fact that the logger
thread was waiting on a condition which had already been signalled. The logger
thread also need to be sure to check the value of the close_logger_thread variable.
The close_logger_thread variable is only checked when the list of logmessages is empty.
This allows for the logger thread to print and free any pending messages before exiting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) It had numerous coding guidelines violations with regards to formatting.
2) It allocated memory using ast_calloc() that was never freed.
3) It didn't check for failure from the allocation.
4) It used sprintf() and strcat() to build the result, doing zero checking to
prevent writing past the end of the provided buffer.
The function also lacks API documentation, but that has not been addressed in
this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported.
Along the way, some related work was done:
1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way.
2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec.
3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result).
Review: http://reviewboard.digium.com/r/158/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175311 | tilghman | 2009-02-12 15:19:40 -0600 (Thu, 12 Feb 2009) | 9 lines
Fix crashes when receiving certain T.38 packets. Also, increase the maximum
size of T.38 packets and warn users when they try to set the limits above those
maximums.
(closes issue #13050)
Reported by: schern
Patches:
20090212__bug13050.diff.txt uploaded by Corydon76 (license 14)
Tested by: schern
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175294 | jpeeler | 2009-02-12 14:34:36 -0600 (Thu, 12 Feb 2009) | 9 lines
Fix ParkedCall event information for From field in the case of a blind transfer
If the parker information can not be obtained from the peer, try and see if
the BLINDTRANSFER channel variable has been set. Previously, a blind transfer
to the ParkAndAnnounce app would return nothing for the From.
Closes AST-189
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175187 | jpeeler | 2009-02-12 11:57:10 -0600 (Thu, 12 Feb 2009) | 6 lines
Fix crash in event of failed attempt to transfer to parking
The peer may not necessarily exist, such as in the case of a transfer to
ParkAndAnnounce. In this case don't try to play a sound to it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175188 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines
Don't send DTMF for infinite time if we do not receive an END event.
I thought that this was going to end up being a pretty gnarly fix, but it turns
out that there was actually already a configuration option in rtp.conf,
dtmftimeout, that was intended to handle this situation. However, in between
Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost.
So, this commit brings it back to life.
The default timeout is 3 seconds. However, it is worth noting that having
this be configurable at all is not really the recommended behavior in RFC 2833.
From Section 3.5 of RFC 2833:
Limiting the time period of extending the tone is necessary
to avoid that a tone "gets stuck". Regardless of the
algorithm used, the tone SHOULD NOT be extended by more than
three packet interarrival times. A slight extension of tone
durations and shortening of pauses is generally harmless.
Three seconds will pretty much _always_ be far more than three packet
interarrival times. However, that behavior is not required, so I'm going to
leave it with our legacy behavior for now.
Code from svn/asterisk/team/russell/issue_14460
(closes issue #14460)
Reported by: moliveras
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Core show locks information involving an ao2_trylock did not
show the function that called ao2_trylock, but would instead
show ao2_trylock as the source of the lock. This is not useful
when trying to debug locking issues.
One bizarre note is that this logic is already in 1.4 but somehow
did not get merged to trunk or the 1.6.X branches.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'd' option would not work for channel types which use RTP to transport
DTMF digits. The only way to allow for this to work was to answer the channel
if we saw that this option was enabled.
I realized that this may cause issues with CDRs, specifically with giving false
dispositions and answer times. I therefore modified ast_answer to take another
parameter which would tell if the CDR should be marked answered.
I also extended this to the Answer application so that the channel may be answered
but not CDRified if desired.
I also modified app_dictate and app_waitforsilence to only answer the channel if it
is not already up, to help not allow for faulty CDR answer times.
All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all
the changes except for the change to the Answer application will go in since we do
not introduce new features into stable branches
(closes issue #14164)
Reported by: DennisD
Patches:
14164.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/145
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We need to do this because while we know that the freeing of the channel may cause something to become
not in use we do not know this for sure. There may be another channel that is still up which would cause
it to be in use.
(closes issue #13238)
Reported by: kowalma
Patches:
20090121__bug13238.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The explanation behind this fix is a bit complicated, and I've already
typed it up in the code as a huge comment inside of manager.c, so I'll
give the abridged version here.
We needed a way to separate action-specific data from session-specific data.
Unfortunately, the only way to maintain API compatibility and to not have to
change every single manager action was to rename the current mansession structure
and wrap it inside a new mansession structure which actually contains action-
specific data.
(closes issue #14364)
Reported by: awk
Patches:
14364_better.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/148/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r174583 | mnicholson | 2009-02-10 11:52:42 -0600 (Tue, 10 Feb 2009) | 18 lines
Improve behavior of jitterbuffer when maxjitterbuffer is set.
This change improves the way the jitterbuffer handles maxjitterbuffer and
dramatically reduces the number of frames dropped when maxjitterbuffer is
exceeded. In the previous jitterbuffer, when maxjitterbuffer was exceeded, all
new frames were dropped until the jitterbuffer is empty. This change modifies
the code to only drop frames until maxjitterbuffer is no longer exceeded.
Also, previously when maxjitterbuffer was exceeded, dropped frames were not
tracked causing stats for dropped frames to be incorrect, this change also
addresses that problem.
(closes issue #14044)
Patches:
bug14044-1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson
Review: http://reviewboard.digium.com/r/144/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit expands the Asterisk scheduler API to include a common implementation
of a scheduler context being processed by a dedicated thread. chan_iax2 has been
updated to use this new code. Also, as a result, this resolves some race
conditions related to the previous chan_iax2 scheduler handling.
Related to rev 171452 which resolved the same issues in 1.4.
Code from team/russell/sched_thread2
Review: http://reviewboard.digium.com/r/129/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines
Parking attempts made to one end of a bridge no longer will hang up due to a
parking failure.
Parking attempts made using either one-touch, or doing either a blind or
assisted transfer to the parking extension now keep up the bridge instead of
hanging up the attempted parked party. Normal causes for the parking attempt
to fail includes the specific specified extension (via PARKINGEXTEN) not being
available or if all the parking spaces are currently in use. To avoid having
to reverse a masquerade park_space_reserve was made to provide foresight if
a parking attempt will succeed and if so reserve the parking space.
(closes issue #13494)
Reported by: mdu113
Reviewed by Russell: http://reviewboard.digium.com/r/133/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
an fseek() on the stream, which is an invalid operation for a socket. Turning
off buffering explicitly lets the stdio functions know they cannot do this,
thus avoiding a potential error.
(closes issue #14400)
Reported by: fnordian
Patches:
tcptls.patch uploaded by fnordian (license 110)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem came from the fact that a frame read from a format interpreter
was not freed. Adding a call to ast_frfree fixed this. The explanation for
why this caused the problem is a bit complex, but here goes:
There was a problem in all versions of Asterisk where the embedded frame
of a filestream structure was referenced after the filestream was freed. This
was fixed by adding reference counting to the filestream structure. The refcount
would increase every time that a filestream's frame pointer was pointing to an
actual frame of data. When the frame was freed, the refcount would decrease. Once
the refcount reached 0, the filestream was freed, and as part of the operation,
the open files were closed as well.
Thus it becomes more clear why a missing ast_frfree would cause a reference leak
and cause the files to not be closed. You may ask then if there was a frame leak
before this patch. The answer to that is actually no! The filestream code was
"smart" enough to know that since the frame we received came from a format interpreter,
the frame had no malloced data and thus didn't need to be freed. Now, however, there
is cleanup that needs to be done when we finish with the frame, so we do need to
call ast_frfree on the frame to be sure that the refcount for the filestream is
decremented appropriately.
(closes issue #14384)
Reported by: fiddur
Patches:
14384.patch uploaded by putnopvut (license 60)
Tested by: fiddur, putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
interfere with correct parsing of the extension. Also, if an unterminated
character class DOES make its way into the pbx core (through some other
method), ensure that it does not crash Asterisk.
(closes issue #14362)
Reported by: Nick_Lewis
Patches:
20090129__bug14362.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2. Use curl to download sound files, as curl is installed natively on OS X,
whereas wget and fetch are not.
(closes issue #14332)
Reported by: oej
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be used within the dial app, before a call is bridged.
Many thanks to sobomax for submitting this patch.
Quoting from bug 11582:
"So the goal of the patch was to use the user configured feature code during the
call setup phase. The original ast_feature_interpret() function is not well suited
for this purpose as it uses much call bridge specific data and doesn't separate a
detection of feature from a feature handler call. So a new function ast_feature_detect()
has been extracted off the ast_feature_interpret() function but keeping the original
logic intact except some insignificant changes to locking.
"Having created the ast_feature_detect() function the possibility to use feature detection
in almost any place of the asterisk code. So a call to this function has been added to
wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler
however and uses old call leg disconnect logic to make the changes as small and simple as
possible to prevent unexpected problems. A disconnect feature currently is the only one
supported during call setup as other features as call parking and call transfer don't make much
sense during call setup. However if need in some of the features would arise it is much easier to
implement as the infrastructure changes are already in place with this patch."
I have cleaned up the patch somewhat, and verified that the existing functionality is not
harmed, and that the new functionality works. Terry has committed his stuff, and there were
no conflicts (see 14274).
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
patch-include__asterisk__features.h uploaded by sobomax (license 359)
patch-res__res_features.c uploaded by sobomax (license 359)
enable-features-during-call-setup.diff uploaded by sobomax (license 359)
11583.newdiff uploaded by murf (license 17)
enable-features-during-call-setup-1.diff uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
Tested by: sobomax, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172438 | tilghman | 2009-01-29 16:54:29 -0600 (Thu, 29 Jan 2009) | 9 lines
Lose the CAP_NET_ADMIN at every fork, instead of at startup. Otherwise, if
Asterisk runs as a non-root user and the administrator does a 'restart now',
Asterisk loses the ability to set QOS on packets.
(closes issue #14004)
Reported by: nemo
Patches:
20090105__bug14004.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172441 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Also, change a function in app.c to return a userful value instead of always returning 0.
Patch by fnordian, changed by Corydon76 and myself.
This does not close the bug report, as fnordian had an additional change we're still discussing.
(related to issue #14059)
Reported by: fnordian
Patches:
chan_sip_hfield.patch uploaded by fnordian (license 110)
20090116__bug14059.diff.txt uploaded by Corydon76 (license 14)
Tested by: fnordian, Corydon76, oej
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r171621 | mmichelson | 2009-01-27 14:06:01 -0600 (Tue, 27 Jan 2009) | 18 lines
Prevent a crash from occurring when a jitter buffer interpolated frame is
removed from a slinfactory
slinfactory used the "samples" field of an ast_frame in order to determine
the amount of data contained within the frame. In certain cases, such as
jitter buffer interpolated frames, the frame would have a non-zero value for
"samples" but have NULL "data"
This caused a problem when a memcpy call in ast_slinfactory_read would attempt
to access invalid memory. The solution in use here is to never feed frames into
the slinfactory if they have NULL "data"
(closes issue #13116)
Reported by: aragon
Patches:
13116.diff uploaded by putnopvut (license 60)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@171622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines
When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them.
(closes issue #14249)
Reported by: RadicAlish
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines
Fix broken call pickup
There was a subtle change in ast_do_masquerade which
resulted in failed attempts to pickup calls. The problem
was that the value of the AST_FLAG_OUTGOING flag was
copied from the clone to the original channel. In the case
of call pickup, this meant that the AST_FLAG_OUTGOING flag
ended up being cleared on the channel that was attempting
to execute the pickup.
Because this flag was not set, when ast_read came across
an answer frame, it ignored it. The result of this was that
the calling channel was never properly answered.
This fix changes the behavior in ast_do_masquerade to set
the flags on the original channel to the union of the flags
on the clone channel. This way, if the AST_FLAG_OUTGOING
flag is set on either of the two channels involved in the
masquerade, the resulting channel will have the flag set
as well.
(closes issue #14206)
Reported by: francesco_r
Patches:
14206.patch uploaded by putnopvut (license 60)
Tested by: francesco_r, aragon, putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170393 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170050 | file | 2009-01-22 11:13:56 -0400 (Thu, 22 Jan 2009) | 6 lines
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)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit fixes a crash that was occurring when attempting to
say a number between 10000 and 100000 due to dividing by 0.
This also removes some places where a "zero" is spoken when it
should not be.
(closes issue #14291)
Reported by: dant
Patches:
say.c-14291.diff uploaded by dant (license 670)
Tested by: dant
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r169722 | tilghman | 2009-01-21 15:02:32 -0600 (Wed, 21 Jan 2009) | 8 lines
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
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a problem that caused chan_sip to think that every open TCP session
was to a remote address of 0.0.0.0:0.
(closes issue #14287)
Reported by: jamesgolovich
Patches:
bug-14287.diff.txt uploaded by jamesgolovich (license 176)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HW_PHYSMEM64 is only available in latest OpenBSD and/or amd64 versions of OpenBSD.
Use HW_PHYSMEM when HW_PHYSMEM64 is not available.
(closes issue #14129)
Reported by: ys
Patches:
2009011600_physmem64.diff.txt uploaded by mvanbaak (license 7)
Tested by: mvanbaak, jtodd
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169327 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168716 | twilson | 2009-01-15 12:22:49 -0600 (Thu, 15 Jan 2009) | 12 lines
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
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the user says count=ENUMLOOKUP(${EXTEN},ALL,c,,enum.mydomain.tld);
then it won't complain about the empty arg (c,,...) and fabled's patch
won't let it swap the commas for pipes.
Ran it thru my dialplan and no complaints.
(closes issue #14169)
Reported by: fabled
Patches:
function-argument-separator-fix.diff uploaded by fabled (license 448)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This started as work to fix the 'core show sysinfo'
CLI command but while working on it oej
pointed out that read_credentials did not compile neither.
So while being there, fix that as well.
Thanks for all the testing oej!
(closes issue #14129)
Reported by: ys
Tested by: oej, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168603 | tilghman | 2009-01-14 13:02:55 -0600 (Wed, 14 Jan 2009) | 7 lines
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
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168604 65c4cc65-6c06-0410-ace0-fbb531ad65f3
at this level prior to a large patch merge which converted ast_verbose
calls to ast_verb
(closes issue #14221)
Reported by: jcovert
Patches:
srv.c.patch uploaded by jcovert (license 551)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
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.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r166568 | mmichelson | 2008-12-23 09:16:26 -0600 (Tue, 23 Dec 2008) | 12 lines
Fix a crash resulting from a datastore with inheritance but no duplicate callback
The fix for this is to simply set the newly created datastore's data pointer
to NULL if it is inherited but has no duplicate callback.
(closes issue #14113)
Reported by: francesco_r
Patches:
14113.patch uploaded by putnopvut (license 60)
Tested by: francesco_r
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
(closes issue #14118)
Reported by: blitzrage
Patches:
14118v2.patch uploaded by putnopvut (license 60)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function is being added as a method to allow for
an audiohook to move to a new channel during a channel
masquerade. The most obvious use for such a facility is
for MixMonitor when a transfer is performed. Prior to
the addition of this functionality, if a channel
running MixMonitor was transferred by another party, then
the recording would stop once the transfer had completed.
By using AUDIOHOOK_INHERIT, you can make MixMonitor
continue recording the call even after the transfer
has completed.
It has also been determined that since this is seen
by most as a bug fix and is not an invasive change,
this functionality will also be backported to 1.4 and
merged into the 1.6.0 branches, even though they are
feature-frozen.
(closes issue #13538)
Reported by: mbit
Patches:
13538.patch uploaded by putnopvut (license 60)
Tested by: putnopvut
Review: http://reviewboard.digium.com/r/102/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r165796 | russell | 2008-12-18 15:39:25 -0600 (Thu, 18 Dec 2008) | 11 lines
Make ast_carefulwrite() be more careful.
This patch handles some additional cases that could result in partial writes
to the file description. This was done to address complaints about partial
writes on AMI.
(issue #13546) (more changes needed to address potential problems in 1.6)
Reported by: srt
Tested by: russell
Review: http://reviewboard.digium.com/r/99/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is part of an effort to completely remove AST_PBX_KEEPALIVE and other
similar return codes from the source. While this usage was perfectly safe,
there are others that are problematic. Since we know ahead of time that
we do not want to PBX to destroy the channel, the PBX API has been changed
so that information can be provided as an argument, instead, thus removing
the need for the KEEPALIVE return value.
Further changes to get rid of KEEPALIVE and related code is being done by
murf. There is a patch up for that on review 29.
Review: http://reviewboard.digium.com/r/98/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165723 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r165591 | file | 2008-12-18 13:11:42 -0400 (Thu, 18 Dec 2008) | 4 lines
Only care about a compatible codec for early bridging if we are actually bridging to another channel. If we are not we actually want to bring the audio back to us.
(closes issue #13545)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
access 'struct ast_str' members, but this must only be used inside the API implementation.
(closes issue #14098)
Reported by: eliel
Patches:
ast_str.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165502 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164881 | russell | 2008-12-16 15:38:29 -0600 (Tue, 16 Dec 2008) | 9 lines
Fix an issue where DEBUG_THREADS may erroneously report that a thread
is exiting while holding a lock.
If the last lock attempt was a trylock, and it failed, it will still be in the
list of locks so that it can be reported.
(closes issue #13219)
Reported by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164806 | russell | 2008-12-16 14:35:25 -0600 (Tue, 16 Dec 2008) | 9 lines
Add "restart gracefully" to the AMI blacklist of CLI commands.
"module unload" was already identified as a command that can not be used
from the AMI. "restart gracefully" effectively unloads all modules, and will
run in to the same problems.
(closes issue #13894)
Reported by: kernelsensei
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: toc
Tested by: murf
OK, Well this issue has had its share of flip-flopping.
I found the following:
1. the code in question, in ext_cmp1 in pbx.c, would not
allow two extensions that vary only by any dashes contained
within them, to be defined in the same context.
2. for input dialstrings, dashes are NOT ignored.
So, skipping them when sorting patterns seemed a bit silly.
Thus, you might declare ext 891 in a context, but
if you try dialing 8-9-1, it will NOT match 891.
So, I proposed to remove the code from ext_cmp1 to
skip the spaces and dashes. Just kept us from
declaring 891 and 8-9-1 in the same context,
forcing users to generate otherwise uselessly
obfuscated dialplan code to get the same effect.
Then, I tried out 1.4, and found that:
1. you can declare 891 and 8-9-1 in the
same context!
2. You can't define 891, and have 8-9-1 match
it! Nor can you define 8-9-1, and have 891
match it!
So, it appears that my proposal simply restores
the pbx to behaving as it did in 1.4.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164736 | russell | 2008-12-16 11:06:29 -0600 (Tue, 16 Dec 2008) | 14 lines
Fix memory leak and invalid reporting issues with DEBUG_THREADLOCALS.
One issue was that the ast_mutex_* API was being used within the context of the
thread local data destructors. We would go off and allocate more thread local data
while the pthread lib was in the middle of destroying it all. This led to a memory
leak.
Another issue was an invalid argument being provided to the the object_add
API call.
(closes issue #13678)
Reported by: ys
Tested by: Russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164201 | russell | 2008-12-15 08:31:37 -0600 (Mon, 15 Dec 2008) | 31 lines
Handle a case where a call can be bridged to a channel that is still ringing.
The issue that was reported was about a case where a RINGING channel got
redirected to an extension to pick up a call from parking. Once the parked
call got taken out of parking, it heard silence until the other side answered.
Ideally, the caller that was parked would get a ringing indication. This patch
fixes this case so that the caller receives ringback once it comes out of
parking until the other side answers.
The fixes are:
- Make sure we remember that a channel was an outgoing channel when doing
a masquerade. This prevents an erroneous ast_answer() call on the channel,
which causes a bogus 200 OK to be sent in the case of SIP.
- Add some additional comments to explain related parts of code.
- Update the handling of the ast_channel visible_indication field. Storing
values that are not stateful is pointless. Control frames that are events
or commands should be ignored.
- When a bridge first starts, check to see if the peer channel needs to be
given ringing indication because the calling side is still ringing.
- Rework ast_indicate_data() a bit for the sake of readability.
(closes issue #13747)
Reported by: davidw
Tested by: russell
Review: http://reviewboard.digium.com/r/90/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@164203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163761 | tilghman | 2008-12-12 16:03:10 -0600 (Fri, 12 Dec 2008) | 7 lines
Simple fix for Ctrl-C not immediately exiting Asterisk, but also add a
pointer inside editline to look back to asterisk.c, so others don't spend
as much time as I did looking (in the wrong place) for the appropriate
function.
Reported by: ZX81, via the #asterisk-users channel
Fixed by: me (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The name "ser" was used in a lot of places. However, it is a relic from when
the struct was a server_instance, not a session_instance. It was renamed since
it represents both a server or client connection.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163448 | russell | 2008-12-12 07:44:08 -0600 (Fri, 12 Dec 2008) | 26 lines
Resolve issues that could cause DTMF to be processed out of order.
These changes come from team/russell/issue_12658
1) Change autoservice to put digits on the head of the channel's frame readq
instead of the tail. If there were frames on the readq that autoservice
had not yet read, the previous code would have resulted in out of order
processing. This required a new API call to queue a frame to the head
of the queue instead of the tail.
2) Change up the processing of DTMF in ast_read(). Some of the problems
were the result of having two sources of pending DTMF frames. There
was the dtmfq and the more generic readq. Both were used for pending
DTMF in various scenarios. Simplifying things to only use the frame
readq avoids some of the problems.
3) Fix a bug where a DTMF END frame could get passed through when it
shouldn't have. If code set END_DTMF_ONLY in the middle of digit emulation,
and a digit arrived before emulation was complete, digits would get
processed out of order.
(closes issue #12658)
Reported by: dimas
Tested by: russell, file
Review: http://reviewboard.digium.com/r/85/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163383 | tilghman | 2008-12-11 17:35:55 -0600 (Thu, 11 Dec 2008) | 9 lines
When a Ctrl-C or Ctrl-D ends a remote console, on certain shells, the terminal
is messed up. By intercepting those events with a signal handler in the remote
console, we can avoid those issues.
(closes issue #13464)
Reported by: tzafrir
Patches:
20081110__bug13464.diff.txt uploaded by Corydon76 (license 14)
Tested by: blitzrage
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The conversion to use ast_check_hangup() everywhere instead of checking the softhangup
flag directly introduced this problem. The issue is that ast_check_hangup() checked
for tech_pvt to be NULL. Unfortunately, this will be NULL is some valid circumstances,
such as with a dummy channel.
The fix is simple. Don't check tech_pvt. It's pointless, because the code path that
sets this to NULL is when the channel hangup callback gets called. This happens inside
of ast_hangup(), which is the same function responsible for freeing the channel. Any
code calling ast_check_hangup() better not be calling it after that point, and if so,
we have a bigger problem at hand.
(closes issue #14035)
Reported by: erogoza
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163092 | russell | 2008-12-11 10:54:51 -0600 (Thu, 11 Dec 2008) | 11 lines
Fix an issue that made it so you could only have a single caller executing
a custom feature at a time. This was especially problematic when custom
features ran for any appreciable amount of time.
The fix turned out to be quite simple. The dynamic features are now stored
in a read/write list instead of a list using a mutex.
(closes issue #13478)
Reported by: neutrino88
Fix suggested by file
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@163094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel variables, and in any case, was redundant;
pbx_substitute_variables_helper ALREADY does substitution for global
variables.
(closes issue #13327)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162653 | file | 2008-12-10 12:05:29 -0400 (Wed, 10 Dec 2008) | 6 lines
Increment the sequence number on the end packets for RFC2833. After reading the RFC some more and doing some testing I agree with this change.
(closes issue #12983)
Reported by: vt
Patches:
dtmf_inc_seqnum_on_end_pkts.diff uploaded by vt (license 520)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the nightly update of the documentation on asterisk.org, I'll post
an update to asterisk-dev with a pointer to the changes. This covers some
release branch and commit policy information. None of this should be a
surprise, since it's just documenting what we have already been doing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162413 | russell | 2008-12-09 16:17:39 -0600 (Tue, 09 Dec 2008) | 8 lines
Remove the test_for_thread_safety() function completely.
The test is not valid. Besides, if we actually suspected that recursive
mutexes were not working, we would get a ton of LOG_ERROR messages when
DEBUG_THREADS is turned on.
(inspired by a discussion on the asterisk-dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162265 | mmichelson | 2008-12-09 14:28:44 -0600 (Tue, 09 Dec 2008) | 6 lines
If we fail to start a thread for the pbx to run in, we need to
be sure to decrease the number of active calls on the system.
This fix may relate to ABE-1713, but it is not certain yet.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162204 | file | 2008-12-09 15:47:07 -0400 (Tue, 09 Dec 2008) | 7 lines
Make sure that the timestamp for DTMF is not the same as the previous voice frame and do not send audio when transmitting DTMF as this confuses some equipment.
(closes issue #13209)
Reported by: ip-rob
Patches:
13209.diff uploaded by file (license 11)
Tested by: ip-rob, bujones
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r161948 | russell | 2008-12-09 08:52:25 -0600 (Tue, 09 Dec 2008) | 15 lines
Fix a problem with GROUP() settings on a masquerade.
The previous code carried over group settings from the old channel to the new
one. However, it did nothing with the group settings that were already on the
new channel. This patch removes all group settings that already existed on the
new channel.
I have a more complicated version of this patch which addresses only the most
blatant problem with this, which is that a channel can end up with multiple
group settings in the same category. However, I could not think of a use case
for keeping any of the group settings from the old channel, so I went this route
for now.
(closes AST-152)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Avoid printing the name of an argument in the [Arguments] tag if there is no description
for that argument.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when a save occurs to a different filename, everything goes to the alternate
filename, instead of appending to the original. This is important for the
AMI command UpdateConfig.
(closes issue #13301)
Reported by: trevo
Patches:
20081113__bug13301.diff.txt uploaded by Corydon76 (license 14)
20081113__bug13301__1.6.0.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161181 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r161013 | jpeeler | 2008-12-04 12:30:41 -0600 (Thu, 04 Dec 2008) | 9 lines
(closes issue #13835)
Reported by: matt_b
Tested by: jpeeler
This mirrors a check that was present in ast_rtp_read to also be in ast_rtp_raw_write to not schedule sending the receiver report if the remote RTCP endpoint address isn't present in the RTCP structure.
Closes AST-142.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161014 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r160943 | mmichelson | 2008-12-04 10:44:18 -0600 (Thu, 04 Dec 2008) | 15 lines
Fix a callerid parsing issue. If someone formatted callerid like the
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/trunk@160945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on cli_permissions.conf configuration file, we are able to permit or deny
cli commands based on some patterns and the local user and group running rasterisk.
(Sorry if I missed some of the testers).
Reviewboard: http://reviewboard.digium.com/r/11/
(closes issue #11123)
Reported by: eliel
Tested by: eliel, IgorG, Laureano, otherwiseguy, mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
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
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159818 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because SPRINTF() use non-literal format strings (which cannot be checked), move it into its own module so the rest of func_strings can benefit from format string checking
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r159316 | murf | 2008-11-25 15:41:10 -0700 (Tue, 25 Nov 2008) | 15 lines
(closes issue #12694)
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/trunk@159360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(or ~500 chars max on LOW_MEMORY) to 80 chars max). This will allow more
channels to be used in a single hint.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159162 65c4cc65-6c06-0410-ace0-fbb531ad65f3
it would be best to maintain API compatibility. Instead, this commit introduces
ao2_callback_data() which is functionally identical to ao2_callback() except
that it allows you to pass arbitrary data to the callback.
Reviewed by Mark Michelson via ReviewBoard:
http://reviewboard.digium.com/r/64
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158603 | murf | 2008-11-21 16:14:50 -0700 (Fri, 21 Nov 2008) | 11 lines
In reference to the fix made for 13871, I was
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/trunk@158606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158600 | tilghman | 2008-11-21 17:07:46 -0600 (Fri, 21 Nov 2008) | 5 lines
The passed extension may not be the same in the list as the current entry,
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/trunk@158602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158483 | murf | 2008-11-21 14:19:47 -0700 (Fri, 21 Nov 2008) | 11 lines
(closes issue #13871)
Reported by: mdu113
This one is totally my fault. The code doesn't even
create a bridge CDR 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/trunk@158484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: snyfer
This handles the case for a zero length file to attempt to be streamed. Instead of failing from not playing any data, go ahead and return success as ast_streamfile should consider playing nothing a success when there is nothing to play.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157859 | kpfleming | 2008-11-19 15:34:47 -0600 (Wed, 19 Nov 2008) | 7 lines
the gcc optimizer frequently finds broken code (use of uninitalized variables, unreachable code, etc.), which is good. however, developers usually compile with the optimizer turned off, because if they need to debug the resulting code, optimized code makes that process very difficult. this means that we get code changes committed that weren't adequately checked over for these sorts of problems.
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/trunk@157974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in 1.6.1 (as compared to 1.6.0 and versions of 1.4), this change also
deprecates the use of Asterisk with FreeBSD 4, given the central use of va_copy
in core functions. va_copy() is C99, anyway, and we already require C99 for
other purposes, so this isn't really a big change anyway. This change also
simplifies some of the core ast_str_* functions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines
Fix a crash in the end_bridge_callback of app_dial and
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/trunk@157306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: alex70
Patches:
13420.13539.patch uploaded by murf (license 17)
Tested by: murf, awk
This fixes two problems: a spurious linefeed insertion
probably left over from pre-precomment times. Only
generated when category had no previous comments.
The other problem: Insertions could get the line-numbering
out of whack and generate negative line numbers, causing
chunks of line numbers to be emitted, on the scale of the
number of lines up to that point in the file. In such cases,
abort the looping, and all is well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: smurfix
This reverts a change I made in 116297. At the time it seemed the change was required to solve an issue with attempting a transfer but then letting it timeout without dialing any digits. However, I didn't realize that having an empty extension was possible. I'm removing the immediate return that was added in pbx_find_extension if the extension is null.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- MeetMe()
- MeetMeCount()
- MeetMeChannelAdmin()
- MeetMeAdmin()
- SLAStation()
- SLATrunk()
- Add an attribute to optionlist 'hasparams' with the same functionality as the one
we have in <parameter> and <argument> (the DTD was updated)
- Fix a leak when getting an attribute while parsing an <optionlist>.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156297 | murf | 2008-11-12 12:36:16 -0700 (Wed, 12 Nov 2008) | 18 lines
It turns out that the 0x0XX00 codes being returned for
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/trunk@156299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156164 | russell | 2008-11-12 11:29:52 -0600 (Wed, 12 Nov 2008) | 7 lines
Move the sanity check that makes sure "always fork" is not set along with the
console option to be after the code that reads options from asterisk.conf.
This resolves a situation where Asterisk can start taking up 100% when
misconfigured.
(Thanks to Bryce Porter (x86 on IRC) for letting me log in to his system to
figure out what was causing the 100% CPU problem.)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Add CLI aliases module to asterisk.
- Remove all deprecated CLI commands from the code
Initial work done by file.
Junk-Y and lmadsen did a lot of work and testing to
get the list of deprecated commands into the configuration file.
Deprecated CLI commands are now handled by this new module,
see cli_aliases.conf for more info about that.
ok russellb@ via reviewboard
(closes issue #13735)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A new <agi> element is used to describe the XML documentation.
We have the usual synopsis,syntax,description and seealso for AGI commands.
The CLI 'agi show commands' command was changed to show all the documentation se
ctions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_channel_search_locked need to be made. Specifically, the caller needs to be able to
pass arbitrary data which in turn is passed to the callback. This patch addresses all
of the nested functions currently in asterisk trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ao2_callback and ao2_find). Currently, passing OBJ_POINTER to either
of these mandates that the passed 'arg' is a hashable object, making
searching for an ao2 object based on outside criteria difficult.
Reviewed by Russell and Mark M. via ReviewBoard:
http://reviewboard.digium.com/r/36/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
container. The OBJ_MULTIPLE flag must be provided here. Otherwise, this would
only remove a single object.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@155241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Functions are printed without parenthesis like: FUNTION
Applications are printed with parenthesis like: AppName()
Cli commands are printed like: 'core show application'
The other type of references are printed as they are inside the <ref> tag.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel list calling a caller-defined callback. The callback returns non-zero
if a match is found. This should speed up some of the code that I committed
earlier today in chan_sip (which is also updated by this commit).
Reviewed by russellb and kpfleming via ReviewBoard:
http://reviewboard.digium.com/r/28/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces the first phase of an effort to manage documentation of the
interfaces in Asterisk in an XML format. Currently, a new format is available for
applications and dialplan functions. A good number of conversions to the new format
are also included.
For more information, see the following message to asterisk-dev:
http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
had no effect
* Updated dialing API documentation to indicate that timeouts
are specified in milliseconds
* Added a new timeout argument to the Page application. If time
expires, any endpoints which have not answered will be hung up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the low default value of featuredigittimeout, I decided it
was high time to change it. I have changed the default to
2000 ms based on a suggestion from Leif Madsen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151905 | russell | 2008-10-25 05:59:02 -0500 (Sat, 25 Oct 2008) | 8 lines
Move AMI initialization to occur after loading modules. This prevents a
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@151101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We'll create a bogus channel for the function call and destroy it when we're done. If we have trouble allocating the bogus channel then we're not going to try executing the function call at all and run the risk of crashing.
(closes issue #13715)
reported by: makoto
patch by: bweschke
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prodded on IRC by Russell and fixed by eliel
(closes issue #13730)
Reported by: eliel
Patches:
main_cli.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150664 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150304 | mmichelson | 2008-10-16 18:40:54 -0500 (Thu, 16 Oct 2008) | 6 lines
Reverting changes from commits 150298 and 150301 since
I was mistakenly under the assumption that dialplan functions
*always* required that a channel be present. I need to go
home earlier, I think :)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150298 | mmichelson | 2008-10-16 18:34:37 -0500 (Thu, 16 Oct 2008) | 10 lines
Don't try to call a dialplan function's read callback from
the manager's GetVar handler if an invalid channel has
been specified. Several dialplan functions, including
CHANNEL and SIP_HEADER, do not check for NULL-ness of
the channel being passed in.
(closes issue #13715)
Reported by: makoto
........
r150301 | mmichelson | 2008-10-16 18:35:07 -0500 (Thu, 16 Oct 2008) | 3 lines
And don't forget to return on the error condition
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@150302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines
Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.
Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
'update2', which permits updates which match across multiple columns, instead
of requiring all tables to have a single unique identifier. All of the other
API calls with the exception of 'update' already had the ability to match on
multiple fields, so it was a missing and very desireable feature that an API
call implementing an update should have this, too.
This does not change any outward performance of Asterisk, but it should make
life easier for application developers who use the RealTime framework.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the trie info when they do 'dialplan show ...'
(even with debug set to non-zero); so I set up a
'dialplan debug [context]' cli command instead,
to explicitly show just the trie info. I even
added an extension_exists() call to make sure the
trie info is built. I moved the explanatory header
to above the extension loop to ensure it only prints
once. And it will do this now, whether debug is set
or not.
I removed the trie printing from the 'dialplan show'
command entirely.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_voicemail. Instead, include it where it is needed. This turned out to be a
relatively minor issue because other headers include logger.h as well.
Need to test -addons before merging this back to 1.6.0.
(closes issue #13605)
Reported by: tomo1657
Patches:
13605_seanbright.diff uploaded by seanbright (license 71)
Tested by: mmichelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
been removed. Furthermore, now we actually use the Context argument
passed to set the transfer context and don't error out if no
context is specified.
This addresses the actual problems outlined in issue 12158. Regarding
the other points brought up, regarding the inability to not transfer
to extensions which cannot be represented by DTMF, it is not enough of
a constraint that it is worth attempting to rework the feature.
(closes issue #12158)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146026 | murf | 2008-10-03 12:12:54 -0500 (Fri, 03 Oct 2008) | 18 lines
(closes issue #13579)
Reported by: dwagner
(closes issue #13584)
Reported by: dwagner
Tested by: murf, putnopvut
The thought occurred to me that the res= from the extension spawn
was ending up being returned from the bridge.
"Thou shalt not poison the return value". Made the change
and it appears to allow blind xfers to work as normal.
If I'm wrong, reopen the bugs. But it looks good to me!
Many thanks to putnopvut for helping me reproduce this!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@148112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: krisk84
Tested by: krisk84
This change prevents a call that is placed in the parkinglot to be picked up before the PBX is finished. If another extension dials the parking extension before the PBX thread has completed at minimum warnings will occur about the PBX not properly being terminated. At worst, a crash could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: nickpeirson
Patches:
pbx.c.patch uploaded by nickpeirson (license 579)
replace_bzero+bcopy.patch uploaded by nickpeirson (license 579)
Tested by: nickpeirson, murf
1. replaced all refs to bzero and bcopy to memset and memmove instead.
2. added a note to the CODING-GUIDELINES
3. add two macros to asterisk.h to prevent bzero, bcopy from creeping
back into the source
4. removed bzero from configure, configure.ac, autoconfig.h.in
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) r143204:
The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel.
2) r143270:
Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced.
3) r143475: (the one liner)
compare peer and chan instead of looking at the parked user (pu), which could have possibly already have been freed by the parking thread
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is no garbage attempted to be used. Also, do not set args to unknown value again if there are
no options passed in.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
read from the .asterisk_history file (and subsequently being duplicated
when written). We weren't checking the result of fgets() which meant
that we read the same line twice before feof() actually returned non-
zero.
Also, stop writing out an extra blank line between each item in the
history file, fix a minor off-by-one error, and use symbolic constants
rather than a hardcoded integer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the first item in the CLI entry list. This was preventing '!' from
showing up in either 'help' or in tab completion.
(closes issue #13578)
Reported by: mvanbaak
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@146198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
problem within strptime(3), which we are correcting here with ast_strptime().
(closes issue #11040)
Reported by: DEA
Patches:
20080910__bug11040.diff.txt uploaded by Corydon76 (license 14)
Tested by: DEA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to fix blind transfers with my last commit here, I also
caused an unwanted side-effect. That is, only the first
priority of the 'h' extension would be executed when
a blind transfer occurred instead of all priorities.
Essentially, my last commit corrected the return value
of ast_bridge_call. However, the implementation still
was not 100% correct. Now it is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
within ast_bridge_call was reversed.
This problem was observed when a blind transfer placed from
the callee channel of a test call failed.
While the problem I am solving here is exactly the same
as what was reported in issue #13584, the difference is
that this fix I am applying is trunk-only. Issue #13584
was reported against the 1.4 branch, and my tests
of 1.4's blind transfers appear to work fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This work is done by lmadsen, junky and mvanbaak
during AstriDevCon.
This is the second audit the CLI got, and
this time lmadsen made sure he had _ALL_ modules
loaded that have CLI commands in them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@145121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144924 | kpfleming | 2008-09-27 10:00:48 -0500 (Sat, 27 Sep 2008) | 6 lines
improve header inclusion process in a few small ways:
- it is no longer necessary to forcibly include asterisk/autoconfig.h; every module already includes asterisk.h as its first header (even before system headers), which serves the same purpose
- astmm.h is now included by asterisk.h when needed, instead of being forced by the Makefile; this means external modules will build properly against installed headers with MALLOC_DEBUG enabled
- simplify the usage of some of these headers in the AEL-related stuff in the utils directory
........
r144925 | kpfleming | 2008-09-27 10:13:30 -0500 (Sat, 27 Sep 2008) | 2 lines
fix some minor issues with rev 144924
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144677 | murf | 2008-09-26 11:47:13 -0600 (Fri, 26 Sep 2008) | 12 lines
(closes issue #13563)
Reported by: mnicholson
Patches:
found1.diff uploaded by mnicholson (license 96)
This patch was mainly meant to apply to trunk and 1.6.x,
but I'm applying it to 1.4 also, which should be a perfectly
harmless fix to the vast majority of users who are not using
external switches, but the few who might be affected
will not have to go to the pain of filing a bug report.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: nickpeirson
The user attached a patch, but the license is not yet
recorded. I took the liberty of finding and replacing
ALL index() calls with strchr() calls, and that
involves more than just main/pbx.c;
chan_oss, app_playback, func_cut also had calls
to index(), and I changed them out. 1.4 had no
references to index() at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144066 | murf | 2008-09-23 10:41:49 -0600 (Tue, 23 Sep 2008) | 29 lines
(closes issue #13489)
Reported by: DougUDI
Tested by: murf
(closes issue #13490)
Reported by: seanbright
Tested by: murf
(closes issue #13467)
Reported by: edantie
Tested by: murf, edantie, DougUDI
This crash happens because we are unsafely handling old pointers.
The channel whose cdr is being handled, has been hung up and
destroyed already. I reorganized the code a bit, and tried not
to lose the fork-cdr-chain concepts of the previous code.
I now verify that the 'previous' channel (the channel we
had when the bridge was started), still exists, by looking it up
by name in the channel list. I also do not try to reset the
CDR's of channels involved in bridges.
Testing shows it solves the crash problem, and should not
negatively impact previous fixes involving CDR's generated
during/after blind transfers. (The reason we need to reset
the CDR's on the "beginning" channels in the first place).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@144067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is set, don't bother searching for a region to free, just
immediately exit.
This has the dual benefit of suppressing a warning message
about freeing memory at (nil) and of optimizing the free()
replacement by not having to do any futile searching for
the proper region to free.
(closes issue #13498)
Reported by: pj
Patches:
13498.patch uploaded by putnopvut (license 60)
Tested by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r143337 | mmichelson | 2008-09-17 13:24:15 -0500 (Wed, 17 Sep 2008) | 6 lines
Allow for "G.729" if offered in an SDP even though
it is not RFC 3551 compliant. Some Cisco switches
will send this in an SDP, and it doesn't hurt to
be able to accept this.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142992 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142474 | murf | 2008-09-10 15:58:17 -0600 (Wed, 10 Sep 2008) | 30 lines
(closes issue #12318)
Reported by: krtorio
I made a small change to the code that handles local channel situations.
In that code, I copy the answer time from the peer cdr, to the bridge_cdr,
but I wasn't also copying the disposition from the peer cdr.
So, Now I copy the disposition, and I've tested against
these cases:
1. phone 1 never answers the phone; no cdr is generated at all.
this should show up as a manager command failure or something.
2. phone 2 never answers. CDR is generated, says NO ANSWER
3. phone 2 is busy. CDR is generated, says BUSY
4. phone 2 answers: CDR is generated, times are correct; disposition
is ANSWERED, which is correct. The start time is the time that
the manager dialed the first phone. The answer time is the time
the second phone picks up.
I purposely left the cid and src fields blank; since this call really
originates from the manager, there is no 'easy' data to put in these
fields. If you feel strongly that these fields should be filled in,
re-open this bug and I'll dig further.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142354 | russell | 2008-09-10 11:39:53 -0500 (Wed, 10 Sep 2008) | 7 lines
It is a normal situation that a task gets put in the scheduler that should run
as soon as possible. Accept "0" as an acceptable time to run, and also treat
negative as "run now", and don't print a debug message about it.
(inspired by a message asking about the "request to schedule in the past"
debug message on the -dev list)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
or when calling ast_waitfor(). These are inappropriate times to hold the channel
lock. This is what has caused "could not get the channel lock" messages from
chan_sip and has likely caused a negative impact on performance results of SIP
in Asterisk 1.6. Thanks to file for pointing out this section of code.
(closes issue #13287)
(closes issue #13115)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141806 | russell | 2008-09-08 16:02:36 -0500 (Mon, 08 Sep 2008) | 7 lines
When doing an async goto, detect if the channel is already in the middle of a
masquerade. This can happen when chan_local is trying to optimize itself out.
If this happens, fail the async goto instead of bursting into flames.
(closes issue #13435)
Reported by: geoff2010
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes applied by this patch:
- Fix autocompletion in 'sip prune realtime', sip peers where never auto completed. Now we complete this command with:
'sip prune realtime peer' -> all | like | sip peers
Also I have modified the syntax in the usage, was wrong...
- Pass ast_cli_args->argv and ast_cli_args->argc while running autocompletion on CLI commands (CLI_GENERATE).
With this we avoid comparisons on ast_cli_args->line like this:
strcasestr(a->line, " description")
strcasestr(a->line, "descriptions ")
strcasestr(a->line, "realtime peer"), and so on..
Making the code more confusing (check the spaces in description!).
The only thing we must be sure is to first check a->pos or a->argc.
- Fix 'iax2 prune realtime' autocompletion, now we autocomplete this command with 'all' & 'iax2 peers', check a look that iax2 peers where all the peers, now only the ones in the cache..
(closes issue #13133)
Reported by: eliel
Patches:
clichanges.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141028 | jpeeler | 2008-09-04 12:00:29 -0500 (Thu, 04 Sep 2008) | 7 lines
(closes issue #11979)
Fixes multiple parking problems:
Crash when executing a park on an extension dialed by AGI due to not returning the proper return code.
Crash when using a builtin feature that was a subset of a enabled dynamic feature.
Crash due to always hanging up the peer despite the fact that the peer was supposed to be parked.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@141039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of changes to the Set and MSet apps, so people aren't
so shocked and surprised when they upgrade from
1.4 to 1.6.
Also, for the sake of those upgrading from 1.4 to
1.6 with AEL, I provide automatic support for the
"old" way of using Set(), that still does the
exact same old thing with quotes and backslashes
and so on as 1.4 did, by having AEL compile in the
use of MSet() instead of Set(), everywhere it inserts
this code.
But, if the app_set var is set to 1.6 or higher,
it uses the "new", non-evaluative Set().
This only usually happens if the user manually
inserts this into the asterisk.conf file, or runs
the "make samples" command.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140747 | murf | 2008-09-02 17:36:56 -0600 (Tue, 02 Sep 2008) | 1 line
I am turning the warnings generated in ast_cdr_free and post_cdr into verbose level 2 messages. Really, they matter little to end users. You either get the CDR's you wanted, or you don't, and it is a bug.
For trunk, I am going one step further. These messages were pretty worthless even for debug, so I'm completely removing them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140690 | murf | 2008-09-02 16:40:13 -0600 (Tue, 02 Sep 2008) | 1 line
After reconsidering, with respect to 13409, ast_cdr_detach should be OK, better in fact, than ast_cdr_free, which generates lots of useless warnings that will undoubtably generate complaints.
Hmmm. It doesn't hush the useless warnings, but it does allow control of posting via the detach and post routines, for those possible situations,
where you'd want to post single-channel cdrs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140670 | murf | 2008-09-02 16:15:57 -0600 (Tue, 02 Sep 2008) | 14 lines
(closes issue #13409)
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140488 | mmichelson | 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) | 22 lines
After working on the ao2_containers branch, I noticed
something a bit strange. In all cases where we provide
a callback function to ao2_container_alloc, the callback
function would only return 0 or CMP_MATCH. After inspecting
the ao2_callback() code carefully, I found that if you're
only looking for one specific item, then you should return
CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue
traversing the current bucket until the end searching for
more matches.
In cases like chan_iax2 where in 1.4, all the peers are
shoved into a single bucket, this makes for potentially
terrible performance since the entire bucket will be
traversed even if the peer is one of the first ones come
across in the bucket.
All the changes I have made were for cases where the
callback function defined was passed to ao2_container_alloc
so that calls to ao2_find could find a unique instance
of whatever object was being stored in the container.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: erousseau
This was a reasonable enhancement request, which was
easy to implement. Since it's an enhancement, it
could only be applied to trunk.
Basically, for accounting where "initiated" seconds
are billed for, if the microseconds field on the end
time is greater than the microseconds field for the
answer time, add one second to the billsec field.
The implementation was requested by erousseau, and
I've implemented it as requested. I've updated the
CHANGES, the cdr.conf.sample, and the .h files
accordingly, to accept and set a flag for the
corresponding new option. cdr.c adds in the extra
second based on the usec fields if the option is
set. Tested, seems to be working fine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@140057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139764 | murf | 2008-08-25 09:33:14 -0600 (Mon, 25 Aug 2008) | 9 lines
This patch reverts the changes made via 139347, and 139635, as users
are seeing adverse difference.
I will un-close 13251.
Back to the drawing board/ concept/ beginning/ whatever!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139635 | murf | 2008-08-22 16:24:02 -0600 (Fri, 22 Aug 2008) | 6 lines
I found some problems with the code I committed earlier, when
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139074 | murf | 2008-08-20 11:14:55 -0600 (Wed, 20 Aug 2008) | 12 lines
(closes issue #13263)
Reported by: brainy
Tested by: murf
The specialized reset routine is tromping on the
flags field of the CDR. I made a change to not
reset the DISABLED bit. This should get rid of this
problem.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@139083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to the Set app in trunk/1.6.x, as they come from the 1.4 world. They are only bitten if
they write their AEL dialplan in the 1.4 world, and then carry it over to a trunk/1.6.x
installation where a "make samples" was executed, or where they hand-edited the
asterisk.conf file and added the [compat] category with app_set = 1.6 (or higher).
(this commit does not totally solve 13249, at least not yet)
The change involves issueing a single warning while the AEL file is loading, if:
1. app_set is present in the config file, and set to 1.6 or higher.
2. there are double quotes in an assignment statement (eg x = "hi there";)
3. the warning was not already issued.
The standalone app, aelparse, does not (yet) issue this warning. I'd have to
have it read in the asterisk.conf file, and that's a bit of hassle. I'll add
it if users request it, tho.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138815 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of the name/value pairs, pointed out by snuffy-home on #asterisk-commits.
For those of you who rely on the position of name/value pairs in manager
events... stop... that is why associative arrays were invented.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138482 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138027 | russell | 2008-08-15 10:07:16 -0500 (Fri, 15 Aug 2008) | 9 lines
Ensure that when a hangup occurs in autoservice, that a hangup frame gets
properly deferred to be read from the channel owner when it gets taken out
of autoservice.
(closes issue #12874)
Reported by: dimas
Patches:
v1-12874.patch uploaded by dimas (license 88)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would reset to 500 ms every time a non-voice frame
was received. The total time we poll should be 500 ms, so
now we save the amount of time left after the poll returned
and use that as our argument for the next call to poll
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Instead, poll the channel until receiving a voice frame. The
cap on this poll is 500 ms.
The optional delay is still allowable in the Answer() application,
but the delay has been moved back to its original position, after
the call to the channel's answer callback. The poll for the voice
frame will not happen if a delay is specified when calling Answer().
(closes issue #12708)
Reported by: kactus
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines
Since adding the AST_CONTROL_SRCUPDATE frame type,
there are places where ast_rtp_new_source may be called
where the tech_pvt of a channel may not yet have an
rtp structure allocated. This caused a crash in chan_skinny,
which was fixed earlier, but now the same crash has been
reported against chan_h323 as well. It seems that the best
solution is to modify ast_rtp_new_source to not attempt to
set the marker bit if the rtp structure passed in is NULL.
This change to ast_rtp_new_source also allows the removal
of what is now a redundant pointer check from chan_skinny.
(closes issue #13247)
Reported by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135841 | mmichelson | 2008-08-05 19:25:10 -0500 (Tue, 05 Aug 2008) | 27 lines
Merging the issue11259 branch.
The purpose of this branch was to take into account
"burps" which could cause jitterbuffers to misbehave.
One such example is if the L option to Dial() were used
to inject audio into a bridged conversation at regular
intervals. Since the audio here was not passed through
the jitterbuffer, it would cause a gap in the jitterbuffer's
timestamps which would cause a frames to be dropped for a
brief period.
Now ast_generic_bridge will empty and reset the jitterbuffer
each time it is called. This causes injected audio to be handled
properly.
ast_generic_bridge also will empty and reset the jitterbuffer
if it receives an AST_CONTROL_SRCUPDATE frame since the change
in audio source could negatively affect the jitterbuffer.
All of this was made possible by adding a new public API call
to the abstract_jb called ast_jb_empty_and_reset.
(closes issue #11259)
Reported by: plack
Tested by: putnopvut
........
r135847 | mmichelson | 2008-08-05 19:27:54 -0500 (Tue, 05 Aug 2008) | 4 lines
Revert inadvertent changes to app_skel that occurred when
I was testing for a memory leak
........
r135850 | mmichelson | 2008-08-05 19:29:54 -0500 (Tue, 05 Aug 2008) | 3 lines
Remove properties that should not be here
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135851 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: falves11
Tested by: murf
falves11 ==
The changes I introduce here seem to clear up the problem
for me. However, if they do not for you, please reopen this
bug, and we'll keep digging.
The root of this problem seems to be a subtle memory corruption
introduced when creating an extension with an empty extension
name. While valgrind cannot detect it outside of DEBUG_MALLOC
mode, when compiled with DEBUG_MALLOC, this is certain death.
The code in main/features.c is a puzzle to me. On the initial
module load, the code is attempting to add the parking extension
before the features.conf file has even been opened!
I just wrapped the offending call with an if() that will not
try to add the extension if the extension name is empty. THis
seems to solve the corruption, and let the "memory show allocations"
work as one would expect.
But, really, adding an extension with an empty name is a seriously
bad thing to allow, as it will mess up all the pattern matching
algorithms, etc. So, I added a statement to the add_extension2 code to return
a -1 if this is attempted.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r134883 | murf | 2008-07-31 13:23:42 -0600 (Thu, 31 Jul 2008) | 51 lines
(closes issue #11849)
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
........
and as to 1.4 to trunk; have I expressed my
feelings about code shifting from one file
to another? Good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
driver into a common place for multiple channel drivers.
(closes issue #13152)
Reported by: caio1982
Patches:
atxfer_complete_sound3.diff uploaded by caio1982 (license 22)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
respectively. Also, take the opportunity to clean up the CLI prompt
generation code.
(closes issue #13175)
Reported by: eliel
Patches:
cliprompt.patch uploaded by eliel (license 64)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
implementations. Asterisk has, for a long time,
had its own implementation of poll(2) which
just used the input arguments to call select(2).
In 1.4, this internal implementation was used
for Darwin systems. This was removed in Asterisk
trunk at some point, but it seems as though this
was not the right move to make.
On Mac OS X, it appears as though the poll used
to gather CLI input does not respond properly
when connecting via a remote Asterisk console.
Reverting to the use of Asterisk's poll fixed
the issue.
Also, there is now an option for the configure
script, --enable-internal-poll, which will allow
for anyone to use Asterisk's internal poll
implementation in case they suspect that their
system's poll implementation is buggy.
closes issue #11928)
Reported by: adriavidal
Patches:
1.6.0-configurev2.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@134125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
called from elsewhere in Asterisk to find the current state of a device. In
that case, we want to use the cached value if it exists. The other way is when
processing a device state change. In that case, we do not want to check the
cache because returning the last known state is counter productive.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133945 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we do NOT need to uri_decode in manager.
(if I sent core%20show%20channels from a telnet
session, it should be interpreted literally, however,
if I send that from an http session, it should be
decoded, which is the behaivor now)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133649 | tilghman | 2008-07-25 12:19:39 -0500 (Fri, 25 Jul 2008) | 8 lines
Fix some errant device states by making the devicestate API more strict in
terms of the device argument (only without the unique identifier appended).
(closes issue #12771)
Reported by: davidw
Patches:
20080717__bug12771.diff.txt uploaded by Corydon76 (license 14)
Tested by: davidw, jvandal, murf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ago (does not affect 1.4), where you would pass
a pointer to the end of a character array, and
ast_uri_decode would do no good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to Asterisk licensing information. The licensing page includes the Asterisk license,
as well as a (not yet complete) list of 3rd party libraries that may be used, as well
as what license we receive them under.
Help filling out this list in the format that I have started in doxyref.h would be
much appreciated. :)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the code checks to see if there is a cached state available, use the aggregate
cached state across all servers, and not just the local state.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
this commit, only the logger thread's PID would
be printed.
(closes issue #13150)
Reported by: atis
Patches:
log_pid.diff uploaded by putnopvut (license 60)
Tested by: eliel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: murf
Tested by: murf
For: J. Geis
The 'data' field in the ast_exten struct was being
'moved' from the current dialplan to the replacement
dialplan. This was not good, as the current dialplan
could have problems in the time between the change
and when the new dialplan is swapped in.
So, I modified the merge_and_delete code to strdup
the 'data' field (the args to the app call), and
then it's freed as normal.
I improved a few messages; I added code to limit
the number of calls to the context_merge_incls_swits_igps_other_registrars()
to one per context. I don't think having it called
multiple times per context was doing anything bad,
but it was inefficient.
I hope this fixes the problems Mr. Geiss was noting in
asterisk-users, see
http://lists.digium.com/pipermail/asterisk-users/2008-July/215634.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r133169 | mmichelson | 2008-07-23 14:39:47 -0500 (Wed, 23 Jul 2008) | 12 lines
As suggested by seanbright, the PSEUDO_CHAN_LEN in
app_chanspy should be set at load time, not at compile
time, since dahdi_chan_name is determined at load time.
Also changed the next_unique_id_to_use to have the
static qualifier.
Also added the dahdi_chan_name_len variable so that
strlen(dahdi_chan_name) isn't necessary. Thanks to
seanbright for the suggestion.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r132872 | kpfleming | 2008-07-23 06:52:18 -0500 (Wed, 23 Jul 2008) | 2 lines
minor optimization for stringfields: when a field is being set to a larger value than it currently contains and it happens to be the most recent field allocated from the currentl pool, it is possible to 'grow' it without having to waste the space it is currently using (or potentially even allocate a new pool)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@132964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Kevin P. Fleming
Mark Michelson
Russell Bryant
Jeff Peeler
Joshua Colp
Matthew Nicholson
Terry Wilson
Steve Murphy
Richard Mudgett
Olle Johansson
Michiel van Baak
Sean Bright
Dwayne M. Hubbard
Eliel C. Sardanons
Brandon Kruse
Jason Parker
Ryan Brindley
Pari Nannapaneni
BJ Weschke
Brett Bryant