This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When more than one call using the same codec type enters into a softmix bridge
and no audio is present for a channel the bridge optimizes the out frame by
using the same one for all channels with the same codec type. Unfortunately,
when that number (channels with same codec type) dropped to <= 1 the codec
was not dereferenced. At least not until all parties left the bridge. Thus in
the case of G.729 the license was not released. This patch ensures that the
codec is dereferenced immediately when the optimization no longer applies.
ASTERISK-24797 #close
Reported by: Luke Hulsey
Review: https://reviewboard.asterisk.org/r/4429/
........
Merged revisions 432174 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432175 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so that if a channel variable is requested and it does not exist
a 404 response will be returned instead of an allocation failed response. This makes
it easier to debug and figure out what is going on for a user.
ASTERISK-24677 #close
Reported by: Joshua Colp
........
Merged revisions 432154 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some implementations don't pay attention to the expires for individual contacts.
In this case they may consider the lack of an Expires header in the 200 OK as
unregistered. This change makes it so if an Expires header is present in the REGISTER
we will add one in the 200 OK.
ASTERISK-24785 #close
Reported by: Ross Beer
........
Merged revisions 432136 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using IMAP voicemail with FreePBX, you will often get ERROR messages
complaining about not being able to find a mailbox. This is due to how FreePBX
handles voicemail mailboxes. Unfortunately, app_voicemail has to consider this
a configuration error, as in any other system it would be indicative of
someone misconfiguring their system.
Regardless, a misconfiguration is a WARNING, and not an ERROR. This patch
demotes the message so that system administrators can hopefully reduce some
of the noise in their log files.
Note that in the original patch this was made into a NOTICE, but that's a
too forgiving.
ASTERISK-24790 #close
Reported by: Graham Barnett
patches:
app_voicemail.c.patch_noise uploaded by Graham Barnett (License 6685)
........
Merged revisions 432098 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432099 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432100 65c4cc65-6c06-0410-ace0-fbb531ad65f3
listener() opens the same code block in two places (#if and #else). This
confuses some folding editors causing it to think that an extra code block
was opened. Folding in 'geany' causes all code after listener() to be
folded as if it were part of that procedure.
ASTERISK-24813 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4435/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Hoskins reported that res_pjsip_publish_asterisk wouldn't pull config from
realtime. Turns out it was just missing a call ast_sorcery_apply_config().
res_pjsip_acl was missing it as well, so I added it. The other pjsip modules
looked OK.
ASTERISK-24811 #close
Reported-by: Matt Hoskins
Tested-by: George Joseph
Tested-by: Matt Hoskins
patches:
res_pjsip_publish_asterisk.c.patch submitted by Matt Hoskins (license 6688)
Review: https://reviewboard.asterisk.org/r/4433/
........
Merged revisions 432033 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When interfacing with Microsoft Exchange, custom headers will be returned as
all lower case. Currently, the IMAP header code will fail to parse the returned
custom headers, as it will be performing a case sensitive comparison. This can
cause playback of messages to fail, as needed information - such as origtime -
will not be present.
This patch updates app_voicemail's header parsing code to perform a case
insensitive lookup for the requested custom headers. Since the headers are
specific to Asterisk, e.g., 'x-asterisk-vm-orig-time', and headers should be
unique in an IMAP message, this should cause no issues with other systems.
ASTERISK-24787 #close
Reported by: Graham Barnett
patches:
app_voicemail.c.patch_MSExchange uploaded by Graham Barnett (License 6685)
........
Merged revisions 432012 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432013 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432014 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Processing an AOC-E event that does not or no longer has a channel
association causes a crash.
The problem with posting AOC events to the channel topic is that AOC-E
events don't always have a channel association and posting the event to
the all channels topic is just wrong. AOC-E events do however have their
own charging association method to refer to the agreement with the
charging entity.
* Changed the AOC events to post to the AMI manager topic instead of the
channel topics. If a channel is associated with the event then channel
snapshot information is supplied with the AMI event.
* Eliminated RAII_VAR() usage in aoc_to_ami() and ast_aoc_manager_event().
This patch supercedes the patch on Review: https://reviewboard.asterisk.org/r/4427/
ASTERISK-22670 #close
Reported by: klaus3000
ASTERISK-24689 #close
Reported by: Marcel Manz
ASTERISK-24740 #close
Reported by: Panos Gkikakis
Review: https://reviewboard.asterisk.org/r/4430/
........
Merged revisions 431974 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed hangup handling of the session->channel after answer if the
ast_channel_move() or ast_bridge_impart() fails. We are still the thread
controlling the session->channel so we need to call ast_hangup() to kill
the channel.
* Fixed debug messages in refer_incoming_invite_request() referencing
incorrect channnels on success. Code comments now say why the
session->channel cannot be used.
Review: https://reviewboard.asterisk.org/r/4422/
........
Merged revisions 431956 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some distributions are going to disable SSLv3 at compile time. This option can
be checked using the directive OPENSSL_NO_SSL3_METHOD. This patch updates the
TCP/TLS handling in Asterisk to look for that directive before attempting to
use the SSLv3 specific methods.
ASTERISK-24799 #close
Reported by: Alexander Traud
patches:
no-ssl3-method.patch uploaded by Alexander Traud (License 6520)
........
Merged revisions 431936 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431937 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431938 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer. The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision. Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.
* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.
* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.
* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.
ASTERISK-24700 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4417/
........
Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When RTCP debugging was enabled, an RTCP report without a report block would
cause a crash. This was due to the verbose output not checking to see if the
report_block pointer was NULl before dereferencing it.
This patch adds the necessary check to prevent printing any verbose output
if the far side hasn't provided us the information they should have.
ASTERISK-24791 #close
Reported by: JoshE
Tested by: JoshE
........
Merged revisions 431879 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "contact" object is not meant to be configured from the pjsip.conf
configuration file. It is meant to be created as a result of a registration
and stored elsewhere.
ASTERISK-24085 #close
Reported by: Rusty Newton
........
Merged revisions 431860 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431861 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_sorcery_config module currently uses a fixed bucket
size of 53. This means that depending on the number of objects
you either end up with excess buckets or a lot of collisions.
Due to the way that res_sorcery_config is implemented it's actually
possible to make the bucket size dynamic based on the number of
objects. This is due to the fact that each loading of the config file
produces a new container and does not modify the existing one.
This change uses the number of expected objects and finds a prime
number near it. In practice depending on the number of objects this
can speed up lookups anywhere from 2X to 15X. This change also removes
the lock from the container as it is not needed.
Review: https://reviewboard.asterisk.org/r/4423/
........
Merged revisions 431841 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some refactoring the way private information for timers
was stored was changed. As a result of this the action which normally
removed the timer upon closure in res_timing_pthread was also removed
causing the timer to remain after it should using up resources.
This change ensures that the timer is removed upon closure.
ASTERISK-24768 #close
Reported by: Matthias Urlichs
patches:
timer.patch submitted by Matthias Urlichs (license 5508)
........
Merged revisions 431807 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Test Event for MIXMONITOR_END - which signals that a MixMonitor has
completed - technically fired before the filestream was closed. If a test
used this to trigger a condition to verify that the file was written, it
could result in a race condition where the file size would not be what the
test expected.
Luckily, no tests were using this (although they should have been). Since the
test event needed to be moved after the point where the MixMonitor autochan has
been destroyed, the test event no longer emits the channel name. Luckily,
nothing needs it.
........
Merged revisions 431788 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431789 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A multi-asterisk box setup with direct media enabled would occasionally
crash when two re-INVITE collisions on a call leg happen in a row.
The re-INVITE logic only had one timer struct to defer the re-INVITE.
When the second collision happens the timer struct is overwritten and put
into the timer heap again. Resources for the first timer are leaked and
the heap has two positions occupied by the same timer struct. Now the
heap ordering is potentially corrupted, the timer will fire twice, and any
resources allocated for the second timer will be released twice.
* The solution is to put the collided re-INVITE into the delayed requests
queue with all the other delayed requests and cherry pick the next request
that can come off the queue when an event happens.
* Changed to put delayed BYE requests at the head of the delayed queue.
There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
has been requested.
* Made the start of a BYE request flush the delayed requests queue to
prevent a delayed request from overlapping the BYE transaction. I saw a
few cases where a delayed re-INVITE got started after the BYE transaction
started.
* Changed the delayed_request struct to use an enum instead of a string
for the request method. Cherry picking the queue is easier with an enum
than string comparisons and the compiler can warn if a switch statement
does not cover all defined enum values.
* Improved the debug output to give more information. It helps to know
which channel is involved with an endpoint. Trunks can have many channels
associated with the endpoint at the same time.
ASTERISK-24727 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4414/
........
Merged revisions 431734 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There have been a couple of times where a crash occurred in the dtls_handler
section of the code for res_pjsip. Unfortunately, in working this issue the
problem was unable to be reproduced. After looking at the backtraces and
through the code the current best guess as to why this happened might be due
to a reentrance problem and the strtok function. So, the current fix is to
convert the strtok function into the reentrant version of the function,
strtok_r.
ASTERISK-24741 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4409/
........
Merged revisions 431698 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP device that has its registration stored in RealTime unregisters,
the entry for that device is updated with blank values, i.e., "", indicating
that it is no longer registered. Unfortunately, one of those values that is
'blanked' is the device's port. If the column type for the port is not a
string datatype (the recommended type is integer), an ODBC or database error
will be thrown. MariaDB does not coerce empty strings to a valid integer value.
This patch updates the query run from chan_sip such that it replaces the port
value with a value of '0', as opposed to a blank value. This is the value that
other database backends coerce the empty string ("") to already, and the
handling of reading a RealTime registration value from a backend already
anticipates receiving a port of '0' from the backends.
ASTERISK-24772 #close
Reported by: Richard Miller
patches:
chan_sip.diff uploaded by Richard Miller (License 5685)
........
Merged revisions 431673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431674 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Looking at the Super Awesome Company sample reminded me that creating hints is
just plain gruntwork. So you can now have the pjsip conifg wizard auto-create
them for you.
Specifying 'hint_exten' in the wizard will create
'exten => <hint_exten>,hint/PJSIP/<wizard_id>'
in whatever is specified for 'hint_context'.
Specifying 'hint_application' in the wizard will create
'exten => <hint_exten>,1,<hint_application>'
in whatever is specified for 'hint_context'.
The default for 'hint_context' is the endpoint's context.
There's no default for 'hint_application'. If not specified, no app is added.
There's no default for 'hint_exten'. If not specified, neither the hint itself
nor the application will be created.
Some may think this is the slippery slope to users.conf but hints are a basic
necessity for phones unlike voicemail, manager, etc that users.conf creates.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4383/
........
Merged revisions 431643 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One of the canonical reasons for hanging up a channel is because the far end
failed to answer - or because someone else answered, and we want to get rid of
this channel. This patch adds the missing value to the 'reason' query parameter
for the DELETE /channels operation.
Review: https://reviewboard.asterisk.org/r/4400
ASTERISK-24745 #close
Reported by: Ben Merrills
patches:
add_no_answer_ari_hangup_cause.diff uploaded by Ben Merrills (License 6678)
........
Merged revisions 431622 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SDP is created for an outgoing request/response, the ICE candidates
obtained from the RTP instance are currently leaked. This causes the ao2
container that holds the candidates to never properly be reclaimed when the
RTP instance is destroyed.
This patch properly decrements the ICE candidates' container if it is
successfully obtained.
ASTERISK-24769 #close
Reported by: Matt Jordan
........
Merged revisions 431600 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The act of defining wizards for an object type in sorcery.conf will
create a minimal object type. This can cause a problem when a module
has multiple sorcery instances (which all get the wizards from sorcery.conf
applied) but the sorcery instances do not all contain full information
about the object types. Upon loading errors will occur stating that
the objects can not be created. This is confusing and is actually
perfectly fine.
This change makes it so that only object types which have been fully
defined will be loaded.
ASTERISK-24748 #close
Reported by: Joshua Colp
........
Merged revisions 431538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the app_agent_pool module initially loads there is a race condition
between the thread loading agents.conf and the device state internal
processing thread. If the device state internal processing thread handles
the agent creation state updates before the thread that loaded agents.conf
registers the device state provider callback then the cached agent state
is "Invalid". When a consumer module like app_queue asks for the agent state
it gets the cached "Invalid" state instead of the real state from the provider.
* Moved loading the agents.conf configuration to the last thing setup by
app_agent_pool in load_module(). Now the device state provider callback
is registered before the config is loaded so the agent creation state
updates are guaranteed to get the initial device state.
* Removed some now redundant config cleanup on error in load_config().
* Added lock protection when accessing the device state in
agent_pvt_devstate_get() and eliminated the RAII_VAR() usage.
ASTERISK-24737 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4390/
........
Merged revisions 431492 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk attempts to send SIP outbound publish information and no response
is ever received (no 200 okay, 412, 423) the system eventually crashes. A
response is never received because the system Asterisk is attempting to send
publish information to is not available. The underlying pjsip framework attempts
to send publish information. After several attempts it calls back into the
Asterisk outbound publish code. At this point if the "client->queue" is empty
Asterisk attempts to schedule a refresh which utilizes "rdata" and since no
response was received the given "rdata" struture is NULL. Attempting to
dereference a NULL object of course results in a crash.
The fix here removes the dependency on rdata for schedule_publish_refresh.
Instead param->expiration is now passed to it as this is set to -1 if no
response is received. Also added a notification when no response is received.
ASTERISK-24635 #close
Reported by: Marco Paland
Review: https://reviewboard.asterisk.org/r/4384/
........
Merged revisions 431490 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431491 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a new config property [servername] to the http.conf file; updated the http server to use the new property when sending responses, for showing http status through the CLI and when reporting status through the 'httpstatus' webpage. In this version, [servername] is uncommented by default.
ASTERISK-24316 #close
Reported By: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4374/
........
Merged revisions 431471 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread. This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.
To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer. Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.
ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........
Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3