Allow for a position to be specified when entering a queue.
This would allow for one to add a caller to a specific place in the
queue instead of just placing the caller in the back every time. To help
facilitate some interesting manipulations, a new channel variable called
QUEUEPOSITION has been added. When a caller is removed from a queue, his
position in that queue is stored in the QUEUEPOSITION variable. One such
strategy an administrator can employ is to allow for the removal of a caller
from one queue followed by the insertion of the same caller into a separate
queue in the same position.
Labels are sometimes (most of the time?) NULL for extensions.
(closes issue #14895)
Reported by: chris-mac
Patches:
20090423__bug14895__2.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
........
If both sides of a Local channel were hung up at around the same time it was
possible for one thread to destroy the local private structure and have the other thread
immediately try to remove the already freed structure from the local channel list.
........
................
There seems to be a bug with old versions of g++ that doesn't allow a structure
member to use the name list. Rename list member to group_list in ast_group_info
and change the few places it is used.
Previously, packetization settings were ignored and now they are not. A new
config option 'autoframing' has been added to mirror the way chan_sip handles
it. Turning on the autoframing option (available both as a global option or per
peer) overrides the local settings with the remote packetization settings.
Testing was performed with varying packetization levels with the following
codecs: ulaw, alaw, gsm, and g729.
(closes issue #12415)
Reported by: pj
Patches:
2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7),
modified by me
........
Do not continue to receive DTMF, when the channel is hungup and about to be destroyed.
(closes issue #14858)
Reported by: barryf
Patches:
20090421__bug14858.diff.txt uploaded by tilghman (license 14)
Tested by: barryf
........
Fixes segfault when switching UDP to TCP in sip.conf after reload.
If transport in sip.conf is switched from UDP to TCP, Asterisk segfaults right after issuing a sip reload. The problem is the socket type is changed to TCP but the fd may still be present for UDP. Later, when the TCP session should be created or set using an existing one, it isn't because the old file descriptor is still present. Now every time transport is changed during a sip.conf reload, the file descriptor is set to -1, signifying it must be created or found.
Add check in configure script to check for GLOB_NOMAGIC and GLOB_BRACE in glob.h
This allows config.c to compile when linked against uclibc that does not support these parameters
........
................
AEL was not handling the case of a device hint containing an @ symbol, which
caused parking hints (e.g. hint(park:exten@context)) to error out the parser.
This patch makes AEL treat the @ the same way it treats colon and ampersand
now, meaning the characters are included in verbatim.
Clean up problem with manager implementation of mmap where it was not testing against MAP_FAILED response.
Got rid of shadowed variable used in processign the mmap results.
Change test of mmap results to compare against MAP_FAILED
........
................
Fix a bug with non-UDP connections that caused dialogs to not get freed.
This issue crept up because of a reference count issue on non-UDP based dialogs.
The dialog reference count was increased when transmitting a packet reliably but never
decreased. This caused the dialog structure to hang around despite being unlinked from
the dialogs container.
Fixed autologoff in agents.conf not working when agent logs in via AgentLogin app
An agent logs in by calling an extension that calls the AgentLogin app. In agents.conf ackcall=always is set, so when they get a call they have the choice to either acknowledge it or ignore it. autologoff=10 is set as well, so if the agent ignores the call over 10sec one may assume that the agent should be logged out (and in this case hungup on as well), but this was not happening.
Prevent a crash when SIP blonde transferring an unbridged call.
If one attempts to use the attended transfer button on a SIP phone
to transfer an unbridged call (such as a call to an IVR) but hangs
up while the target of the transfer is still ringing, we need to not
crash.
The problem was that ast_hangup was called from outside the channel
thread.
Fix a bug where a value used to create the channel name was bogus.
This commit fixes the scenario where an incoming call is authenticated
using a peer entry. Previously the channel name was created using either
the username setting from the sip.conf entry or the IP address that the
call came from. Now the channel name will be created using the peer name
itself. This commit will not change the way the channel name is generated
for users or friends.
(closes issue #14256)
Reported by: Nick_Lewis
Patches:
chan_sip.c-chname.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, file
........
................
1. Differentiate between literal characters in an extension
and characters that should be treated as a pattern match. Prior to
these fixes, an extension such as NNN would be treated as a pattern,
rather than a literal string of N's.
2. Fixed the logic used when matching an extension with a bracketed
expression, such as 2[5-7]6.
3. Removed all areas of code that were executed when NOT_NOW was
#defined. The code in these areas had the potential to crash, for
one thing, and the actual intent of these blocks seemed counterproductive.
4. Fixed many many coding guidelines problems I encountered while looking
through the corresponding code.
5. Added failure cases and warning messages for when duplicate extensions
are encountered.
6. Miscellaneous fixes to incorrect or redundant statements.
National prefix inserted even when caller ID not available
When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank.
Make the cancellation of the dial timeout on a call forward optional.
This introduces the 'z' option to app_dial. With it set, a call forward
will cancel any timeout originally set for this instance of the Dial
application.
This is the companion commit to libpri r732. Service messages are now supported
for switch types 4ess/5ess. A new option service_message_support has been added
to chan_dahdi.conf and is noted in the sample config file. The service message
support is turned off by default. The current implementation relies on AstDB
to keep track of channel state, which allows the statuses to be preserved
across Asterisk restarts. Below is a description of the storage format.
The state and reason for the service state are in the form <state>:<reason>,
where:
<state> ::= { 'O' } // 'O' – Out Of Service
<reason> ::= { '0' | '1' | '2' | '3' }, where:
'0' – No reason (backwards compatibility)
'1' – NEAR END
'2' – FAR END
'3' – both NEAR and FAR END
The new CLI commands to handle channel service state are:
pri service disable channel <chan>
pri service enable channel <chan>
Many people contributed to the development of this functionality. Because I
entered at the very end I do not know the exact history. Special thanks to
all who moved the bug forward one way or another:
cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
and did a large portion of the work)
Fix a bug with the change I made yesterday to outbound proxy support.
Per discussion with oej on IRC we need the actual IP address, not the
outbound proxy IP address, in the sa field. Upon further inspection
this should make the behaviour of all other uses of the outbound proxy
in the code.
........
Fix a bug where using an outbound proxy would cause the local address to be 127.0.0.1.
Copy the outbound proxy IP address into the SIP dialog structure as the IP address we will
be sending to. This has to be done because the logic that determines what local IP address to use
in the SIP messages is not aware of an outbound proxy being in place. It only knows what IP address
we are sending to.
This allows for you to change the From header for outgoing MWI
NOTIFY requests. Prior to this, the best you could do was to
set a callerid in the general section of sip.conf. The problem
was that this was used for all outbound requests, not just
MWI NOTIFY requests.
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.
Add ability for dialplan execution to continue when caller hangs up.
The F option to app_dial has been modified to accept no parameters and perform
the above functionality. I don't see anywhere else that is doing function
overloading, but this really is the best place for this operation because:
- It makes it close to the 'g' option in the argument list which provides
similar functionality.
- The existing code to support the current F option provides a very
convienient location to add this new feature.
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
........
................
Fix a crash in res_musiconhold when using cached realtime moh.
The moh_register function links an mohclass and then immediately
unrefs the class since the container now has a reference. The problem
with using realtime music on hold is that the class is allocated,
registered, and started in one fell swoop. The refcounting logic
resulted in the count being off by one. The same problem did not
happen when using a static config because the allocation and registration
of an mohclass is a separate operation from starting moh. This also did
not affect non-cached realtime moh because the classes are not registered
at all.
I also have modified res_musiconhold to use the _t_ variants of the ao2_
functions so that more info can be gleaned when attempting to trace the
refcounts. I found this to be incredibly helpful for debugging this issue
and there's no good reason to remove it.
Permit zero-length text messages in SIP.
(Related to an issue posted to the -users list, subject "AEL2, BASE64_DECODE and hexadecimal")
........
................
add a dedicated log channel for modules to be able report security-related events, so that they can be fed into external processes for analysis and possible mitigation efforts
(inspired by this evening's Toronto Asterisk Users Group meeting and previous dicussions amongst various community members)
........
Add timer for features so that backup bridge config can go away
The biggest change done here was elimination of the backup_config for use with
features. Previously, the bridging code upon detecting a feature would set the
start time of the bridge to the start time of the feature. Then after the
feature had either expired or timed out the start time would be reset to the
true bridge start time from the backup_config. Now, the time differences are
calculated with respect to the newly added feature_start_time timeval instead.
There should be no behavior changes from the previous functionality aside from
the bridge timing being unaffected by either valid or partial feature matches.
Previously the timing would be increased by the length of time configured for
featuredigittimeout, which was probably never noticed.
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.
........
................
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.
........
................
This commit introduces COLP/CONP and Redirecting party information into Asterisk.
The channel drivers which have been most heavily tested with these enhancements are
chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be
introduced in a later commit. chan_skinny has code added to it here, but according
to user pj, the support on chan_skinny is not working as of now. This will be fixed in
a later commit.
A special thanks goes out to bugtracker user gareth for getting the ball rolling and
providing the initial support for this work. Without his initial work on this, this would
not have been nearly as painless as it was.
This functionality has been tested by Digium's product quality department, as well as a
customer site running thousands of calls every day. In addition, many many many many bugtracker
users have tested this, too.
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).
........
................
audio_audiohook_write_list() did not correctly update sample size after ast_translate.
audio_audiohook_write_list() did not take into account that the sample size may change after translation depending on if the original frame is is 8khz or 16khz. the sample size is now updated after translating to reflect this possibility. This caused the audio on the receiving end to sound terrible. Thanks to jcolp and mmichelson for helping me work this out.
Fix the ability to retrieve voicemail messages from IMAP.
A recent change made interactive vm_states no longer get
added to the list of vm_states and instead get stored in
thread-local storage.
In trunk and all the 1.6.X branches, the problem is that
when we search for messages in a voicemail box, we would
attempt to update the appropriate vm_state struct by directly
searching in the list of vm_states instead of using the
get_vm_state_by_imap_user function. This meant we could not
find the interactive vm_state that we wanted.
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.
........
................
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.
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.
This patch provides a number of optimizations to the stringfields API, focused around saving (not wasting) memory whenever possible. Thanks to Mark Michelson for inspiring this work and coming up with the first two optimizations that are represented here:
Changes:
- Cleanup of some code, fix incorrect doxygen comments
- When a field is emptied or replaced with a new allocation, decrease the amount of 'active' space in the pool it was held in; if that pool reaches zero active space, and is not the current pool, then free it as it is no longer in use
- When allocating a pool, try to allocate a size that will fit in a 'standard' malloc() allocation without wasting space
- When allocating space for a field, store the amount of space in the two bytes immediately preceding the field; this eliminates the need to call strlen() on the field when overwriting it, and more importantly it 'remembers' the amount of space the field has available, even if a shorter string has been stored in it since it was allocated
- Don't automatically double the size of each successive pool allocated; it's wasteful
projects / thirdparty / asterisk.git / log
