David Vossel [Tue, 14 Apr 2009 15:02:04 +0000 (15:02 +0000)]
audio_audiohook_write_list() does not correctly update sample size after ast_translate.
audio_audiohook_write_list() does not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz. While no 16kz codecs are supported in 1.4 at the moment, this will save headaches in the future if they ever are. the sample size is now updated after translating to reflect this possibility. Thanks to jcolp and mmichelson for helping me work this out.
Mark Michelson [Thu, 9 Apr 2009 18:51:20 +0000 (18:51 +0000)]
Handle a SIP race condition (reinvite before an ACK) properly.
RFC 5047 explains the proper course of action to take if a
reINVITE is received before the ACK from a previous invite
transaction. What we are to do is to treat the reINVITE as
if it were both an ACK and a reINVITE and process it normally.
Later, when we receive the ACK we had been expecting, we will
ignore it since its CSeq is less than the current iseqno of
the sip_pvt representing this dialog.
Race condition between ast_cli_command() and 'module unload' could cause a deadlock.
Add lock timeouts to avoid this potential deadlock.
(closes issue #14705)
Reported by: jamessan
Patches:
20090320__bug14705.diff.txt uploaded by tilghman (license 14)
Tested by: jamessan
Backport resolution for file descriptor leak in 1.6.0 to 1.4.
This fixes short reads in http manager sessions, such as those done by the
ast-gui branch. (Fixes AST-198)
Mark Michelson [Wed, 8 Apr 2009 16:52:03 +0000 (16:52 +0000)]
Fix a small logical error when loading moh classes.
We were unconditionally incrementing the number of mohclasses
registered. However, we should actually only increment if the
call to moh_register was successful.
While this probably has never caused problems, I noticed it
and decided to fix it anyway.
Mark Michelson [Wed, 8 Apr 2009 15:26:46 +0000 (15:26 +0000)]
Make a couple of changes with regards to a new message printed in ast_read().
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
Fix a bug where DAHDI/Zaptel channels would not properly switch formats when requested
Don't offer AST_FORMAT_SLINEAR on DAHDI/Zaptel channels... while it could provide a slight performance benefit, the translation core in Asterisk has some flaws when a channel driver offers multiple raw formats. this fix is much simpler than fixing the translation core to solve that issue (although that will be done later).
Distinguish in a sent email between simple sends and forwards.
(closes issue #11678)
Reported by: jamessan
Patches:
20090330__bug11678.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman, lmadsen
Russell Bryant [Fri, 3 Apr 2009 01:57:44 +0000 (01:57 +0000)]
Fix a memory leak in cdr_radius.
I came across this while doing some testing of my ast_channel_ao2 branch.
After running a test overnight that generated over 5 million calls, Asterisk
had taken up about 1 GB of my system memory. So, I re-ran the test with
MALLOC_DEBUG turned on. However, it showed no leaks in Asterisk during the
test, even though Asterisk was still consuming it somehow.
Instead, I turned to valgrind, which when run with --leak-check=full, told
me exactly where the leak came from, which was from allocations inside the
radiusclient-ng library. This explains why MALLOC_DEBUG did not report it.
After a bit of analysis, I found that we were leaking a little bit of memory
every time a CDR record was passed to cdr_radius.
I don't actually have a radius server set up to receive CDR records. However,
I always have my development systems compile and install all modules. In
addition to making sure there are not build errors across modules, always
loading modules helps find bugs like this, too, so it is strongly recommend for
all developers.
the DAHDI_GETCONF, DAHDI_SETCONF and DAHDI_GET_PARAMS ioctls were recently corrected to show that they do, in fact, read data from userspace as part of their work. due to this fix, valgrind now reports a number of cases where chan_dahdi passed an uninitialized (or partially) buffer to these ioctls, which could lead to unexpected behavior.
this patch corrects chan_dahdi to ensure that buffers passed to these ioctls are always fully initialized.
David Vossel [Wed, 1 Apr 2009 19:02:00 +0000 (19:02 +0000)]
Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
Russell Bryant [Wed, 1 Apr 2009 13:47:30 +0000 (13:47 +0000)]
Fix a case where DTMF could bypass audiohooks.
This change fixes a situation where an audiohook that wants DTMF would not
actually get it. This is in the code path where we end DTMF digit length
emulation while handling a NULL frame.
David Brooks [Tue, 31 Mar 2009 16:37:12 +0000 (16:37 +0000)]
Fix incorrect parsing in chan_gtalk when xmpp contains extra whitespaces
To drill into the xmpp to find the capabilities between channels, chan_gtalk
calls iks_child() and iks_next(). iks_child() and iks_next() are functions in
the iksemel xml parsing library that traverse xml nodes. The bug here is that
both iks_child() and iks_next() will return the next iks_struct node
*regardless* of type. chan_gtalk expects the next node to be of type IKS_TAG,
which in most cases, it is, but in this case (a call being made from the
Empathy IM client), there exists iks_struct nodes which are not IKS_TAG data
(they are extraneous whitespaces), and chan_gtalk doesn't handle that case,
so capabilities don't match, and a call cannot be made.
iks_first_tag() and iks_next_tag(), on the other hand, will not return the
very next iks_struct, but will check to see if the next iks_struct is of
type IKS_TAG. If it isn't, it will be skipped, and the next struct of type
IKS_TAG it finds will be returned. This assures that chan_gtalk will find
the iks_struct it is looking for.
This fix simply changes all calls to iks_child() and iks_next() to become
calls to iks_first_tag() and iks_next_tag(), which resolves the capability
matching.
The following is a payload listing from Empathy, which, due to the extraneous
whitespace, will not be parsed correctly by iksemel:
Mark Michelson [Tue, 31 Mar 2009 15:34:05 +0000 (15:34 +0000)]
Fix some state_interface stuff that was in trunk but not in the backport to 1.4.
Issue #14359 was fixed between the time that I posted the review of the backport
of the state interface change for 1.4. This merges the changes from that issue
back into 1.4.
Richard Mudgett [Mon, 30 Mar 2009 20:38:11 +0000 (20:38 +0000)]
Make chan_misdn BRI TE side normally defer channel selection to the NT side.
Channel allocation collisions are not handled by chan_misdn very well.
This patch simply avoids the problem for BRI only.
For PRI, allocation collisions are still possible but less likely since
there are simply more channels available and each end could use a different
allocation strategy.
misdn.conf options available:
te_choose_channel - Use to force the TE side to allocate channels.
method - Specify the channel allocation strategy.
Mark Michelson [Mon, 30 Mar 2009 16:17:35 +0000 (16:17 +0000)]
Fix queue weight behavior so that calls in low-weight queues are not inappropriately blocked.
(This is copied and pasted from the review request I made for this patch)
Asterisk has some odd behavior when queue weights are used. The current logic used when
potentially calling a queue member is:
If the member we are going to call is part of another queue and _that other queue has any
callers in it_ and has a higher weight than the queue we are calling from, then don't try
to contact that member. The issue here is what I have marked with underscores. If the
higher-weighted queue has any callers in it at all, then the queue member will be unreachable
from the lower-weighted queue. This has the potential to be really really bad if using a
queue strategy, such as leastrecent or fewestcalls, with the potential to call the same
member repeatedly.
The fix proposed by garychen on issue 13220 is very simple and, as far as I can see, works
well for this situation. With this set of changes, the logic used becomes:
If the member we are going to call is part of another queue, the other queue has a higher
weight than the queue we are calling from, and the higher weight queue has at least as many
callers as available members, then do not try to contact the queue member. If the higher
weighted queue has fewer callers than available members, then there is no reason to deny
the call to this member since the other queue can afford to spare a member.
Since the fix involved writing a generic function for determining the number of available
members in the queue, I also modified the is_our_turn function to make use of the new
num_available_members function to determine if it is our turn to try calling a member. There
is one small behavior change. Before writing this patch, if you had autofill disabled, then
if you were the head caller in a queue, you would automatically be told that it was your
turn to try calling a member. This did not take into account whether there were actually any
queue members available to take the call. Now we actually make sure there is at least one
member available to take the call if autofill is disabled.
Mark Michelson [Mon, 30 Mar 2009 15:23:59 +0000 (15:23 +0000)]
Backport state interface changes to app_queue from trunk.
After several issues raised on the Asterisk bugtracker against
the 1.4 branch were determined to be fixable with the state interface
change available in the 1.6.X series, it finally came time to just
suck it up and backport the change.
For a detailed explanation of what this change entails, the original
trunk commit for this feature may be found here:
In addition, the details for the use of this change to fix the problems
stated in issue #12970 may be found in the review request I made for
this change. It is linked below.
Joshua Colp [Mon, 30 Mar 2009 14:35:47 +0000 (14:35 +0000)]
Improve our handling of T38 in the initial INVITE from a device.
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
Joshua Colp [Fri, 27 Mar 2009 13:06:45 +0000 (13:06 +0000)]
Fix an issue where nat=yes would not always take effect for the RTP session on outgoing calls.
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
David Vossel [Thu, 26 Mar 2009 21:07:32 +0000 (21:07 +0000)]
pri loop TestClient/TestServer fails: server SEND DTMF 8
app_test was failing when sending the last DTMF digit, 8, because of the 100ms pause issued after DTMF is sent. During this pause the other side would hang up causing the test to look like it failed. Now the other side waits a second before hanging up.
Avoid destroying the CLI line when moving the cursor backward and trying to autocomplete.
When moving the cursor backward and pressing TAB to autocomplete, a NULL is put
in the line and we are loosing what we have already wrote after the actual
cursor position.
Mark Michelson [Mon, 23 Mar 2009 17:59:28 +0000 (17:59 +0000)]
Fix a memory leak in res_monitor.c
The only way that this leak would occur is if Monitor were started
using the Manager interface and no File: header were given. Discovered
while reviewing the ast_channel_ao2 review request.
David Vossel [Thu, 19 Mar 2009 19:40:07 +0000 (19:40 +0000)]
Cleaning up a few things in detect disconnect patch
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
David Vossel [Thu, 19 Mar 2009 16:15:16 +0000 (16:15 +0000)]
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
Mark Michelson [Thu, 19 Mar 2009 16:04:02 +0000 (16:04 +0000)]
Fix an issue where cancelled outgoing SIP calls would erroneously report the device as "in use."
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
Jeff Peeler [Wed, 18 Mar 2009 19:57:05 +0000 (19:57 +0000)]
Allow H.323 Plus library to be used in addition to the OpenH323 library
Chan_h323 can now be compiled against both the previously supported versions of
OpenH323 as well as the current H.323 Plus (version 1.20.2). The configure
script has been modified to look in the default install location of h323 to
hopefully help avoid using the environment variables OPENH323DIR and PWLIBDIR.
Also, the CLI command "h323 show version" has been added which indicates which
version of h323 is in use.
Russell Bryant [Wed, 18 Mar 2009 02:09:13 +0000 (02:09 +0000)]
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
Kevin P. Fleming [Wed, 18 Mar 2009 01:55:22 +0000 (01:55 +0000)]
Improve the build system to *properly* remove unnecessary symbols from the runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
Kevin P. Fleming [Wed, 18 Mar 2009 01:28:42 +0000 (01:28 +0000)]
Improve the build system to *properly* remove unnecessary symbols from the runtime global namespace. Along the way, change the prefixes on some internal-only API calls to use a common prefix.
With these changes, for a module to export symbols into the global namespace, it must have *both* the AST_MODFLAG_GLOBAL_SYMBOLS flag and a linker script that allows the linker to leave the symbols exposed in the module's .so file (see res_odbc.exports for an example).
Tilghman Lesher [Tue, 17 Mar 2009 05:50:52 +0000 (05:50 +0000)]
Fix race in astdb
The underlying db1 implementation does not fully isolate the pages retrieved
from astdb, so the lock protecting accesses needs to be extended until the
copy from the shared memory structure is done.
(closes issue #14682)
Reported by: makoto
David Vossel [Mon, 16 Mar 2009 17:47:42 +0000 (17:47 +0000)]
Randomize IAX2 encryption padding
The 16-32 byte random padding at the beginning of an encrypted IAX2 frame turns out to not be all that random at all. This patch calls ast_random to fill the padding buffer with random data. The padding is randomized at the beginning of every encrypted call and for every encrypted retransmit frame.
Tilghman Lesher [Mon, 16 Mar 2009 15:39:15 +0000 (15:39 +0000)]
Fixup glare detection, to fix a memory leak of a local pvt structure.
(closes issue #14656)
Reported by: caspy
Patches:
20090313__bug14656__2.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
Mark Michelson [Fri, 13 Mar 2009 17:12:32 +0000 (17:12 +0000)]
Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF.
Dynamic features defined in the applicationmap section of features.conf allow
one to specify whether the caller, callee, or both have the ability to use the
feature. The documentation in the features.conf.sample file could be interpreted
to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the
calling channel in order to allow for the callee to be able to use the features
which he should have permission to use. However, the DYNAMIC_FEATURES variable
would only be read from the channel of the participant that pressed the DTMF
sequence to activate the feature. The result of this was that the callee was
unable to use dynamic features unless the dialplan writer had taken measures
to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel.
This commit changes the behavior of ast_feature_interpret to concatenate the
values of DYNAMIC_FEATURES from both parties involved in the bridge. The features
themselves determine who has permission to use them, so there is no reason to believe
that one side of the bridge could gain the ability to perform an action that they
should not have the ability to perform.
Kevin Fleming pointed out on the asterisk-users list that the typical way that this
was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel
so that the value would be inherited by the called channel. While this works, the
documentation alone is not enough to figure out why this is necessary for the callee
to be able to use dynamic features. In this particular case, changing the code to match
the documentation is safe, easy, and will generally make things easier for people for
future installations.
This bug was originally reported on the asterisk-users list by David Ruggles.
Mark Michelson [Thu, 12 Mar 2009 18:29:48 +0000 (18:29 +0000)]
Properly send a 487 on an INVITE we have not responded to if we receive a BYE.
If we receive an INVITE from an endpoint and then later receive a BYE from that
same endpoint before we have sent a final response for the INVITE, then we need
to respond to the INVITE with a 487.
There was logic in the code prior to this commit which seemed to exist solely to
handle this situation, but there was one condition in an if statement which
was incorrect. The only way we would send a 487 was if the sip_pvt had no owner
channel. This made no sense since we created the owner channel when we received
the INVITE, meaning that the majority of the time we would never send the 487.
The 487 being sent should not rely on whether we have created a channel. Its
delivery should be dependent on the current state of the initial INVITE transaction.
With this commit, that logic is now correctly in place.
Joshua Colp [Thu, 12 Mar 2009 16:29:19 +0000 (16:29 +0000)]
Fix issue with streaming MOH failing if nobody is listening.
When a music class is setup to actually provide music on hold
from a stream we need to constantly read audio from it since it
will constantly be providing audio. This is now done despite there
being no channels listening to it.
Russell Bryant [Wed, 11 Mar 2009 21:42:58 +0000 (21:42 +0000)]
Make code that updates BRIDGEPEER variable thread-safe.
It is not safe to read the name field of an ast_channel without the channel
locked. This patch fixes some places in channel.c where this was being done,
and lead to crashes related to masquerades.
David Vossel [Wed, 11 Mar 2009 17:25:31 +0000 (17:25 +0000)]
encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames
If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted. This causes the entire frame to be corrupted. When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense. When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop. To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted. Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct.
Joshua Colp [Wed, 11 Mar 2009 17:22:52 +0000 (17:22 +0000)]
Fix issue where an attended transfer could not be completed under a rare scenario.
When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.
Joshua Colp [Wed, 11 Mar 2009 16:36:50 +0000 (16:36 +0000)]
Fix a problem with inband DTMF detection on outgoing SIP calls when dtmfmode=auto.
When dtmfmode was set to auto the inband DTMF detector was not setup
on outgoing SIP calls. This caused inband DTMF detection to fail.
The inband DTMF detector is now setup for both dtmfmode inband and auto.
Jeff Peeler [Wed, 11 Mar 2009 03:25:04 +0000 (03:25 +0000)]
Fix malloc debug macros to work properly with h323.
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue. Because using the ast prefix calls are
a better choice, ast_free_ptr is the new wrapper for free to pass to functions.
Also, a little bit of clean up was done to avoid the debug macros intentionally
being redefined.
David Vossel [Fri, 6 Mar 2009 17:19:55 +0000 (17:19 +0000)]
Fix handling of backreferences for ENUM lookups
enum.c did not handle regex backtraces correctly. The '\1' in the regex is a backreference that requires a pattern match to be inserted. The way the code used to work is that it would find the backreference and insert the entire input string minus the '+'. This is incorrect. The regexec() function takes in a variable called pmatch which is an array of structs containing the start and end indexes for each backreference substring. The original code actually passed the pmatch array pointer into regexec but never did anything with it. Now when a backtrace is found, the backtrace number is looked up in the pmatch array and the correct substring is inserted.
Mark Michelson [Thu, 5 Mar 2009 23:26:11 +0000 (23:26 +0000)]
[IMAP] Fix message retrieval issues when identical mailbox names were defined in separate contexts.
There was a fix put in a while back so that an X-Asterisk-VM-Context message header was
added to stored IMAP voicemails. This would allow for us to differentiate if the same
mailbox name was used in multiple contexts. The problem still left was that not all places
where messages were retrieved actually attempted to use this header for information when
retrieving messages. This commit fixes that so that MWI and message retrieval from VoiceMailMain
work as expected.
Mark Michelson [Thu, 5 Mar 2009 18:58:48 +0000 (18:58 +0000)]
Fix broken mailbox parsing when searchcontexts option is enabled.
When using the searchcontexts option in voicemail.conf, the code
made the assumption that all mailbox names defined were unique across
all contexts. However, the code did nothing to actually enforce this
assumption, nor did it do anything to alert a user that he may have
created an ambiguity in his voicemail.conf file by defining the same
mailbox name in multiple contexts.
With this change, we now will issue a nice long warning if searchcontexts
is on and we encounter the same mailbox name in multiple contexts and ignore
any duplicates after the first box. Whether searchcontexts is enabled or not,
if we come across a duplicate mailbox in the same context, then we will issue
a warning and ignore the duplicated mailbox. I have also added a small note
to voicemail.conf.sample in the explanation for searchcontexts explaining
that you cannot define the same mailbox in multiple contexts if you have
enabled the option.
Fix problems when RTP packet frame size is changed
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Mark Michelson [Tue, 3 Mar 2009 22:48:18 +0000 (22:48 +0000)]
Clarify some documentation of queues.conf.sample
It had always been possible to explicitly specify a "blank"
value for a sound file in queues.conf and have no sound played
back. The problem with this is that it would result in some ugly
CLI warnings from file.c.
This commit introduces a check when playing a file in app_queue
to see if the name of the file is zero-length and return early if
that is the case. Also, the ability to specify the blank sound
files in queues.conf is now mentioned more clearly in queues.conf.sample
projects / thirdparty / asterisk.git / log
