Assertions were caused by attempting to play music on hold to a channel with
no formats. Parking unit test channels were given formats and a technology so
that they would be able to pretend to read/write frames.
ASTERISK-24413 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4075/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With MALLOC_DEBUG the /main/config config_basic_ops test was causing a
SEGV while doing an ast_category_delete in an ast_category_browse loop.
Apparently this never worked but was also never tested. I removed the
test, added 2 notes to config.h indicating that it's not supported and
added a few lines of code to ast_category_delete to prevent the SEGV
should someone attempt it in the future.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4078/
........
Merged revisions 425525 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tasks that were marked for pending deletion in the scheduler would be moved to
the cache for later reuse, but after being recycled the deleted mark wouldn't
be removed resulting in fresh tasks being deleted without reason... and
immediately moved back into the cache where they could be reused again. This
could cause horrendous things to happen in just about anything that used a
scheduler.
ASTERISK-24321 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4071/
........
Merged revisions 425503 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Masquerades into and out of channels that are involved in a dial operation
don't create the expected dial end event. The missing dial end event goes
against the model for things like CDRs and generating Dial end manager
actions and such.
There are four cases:
1) A channel masquerades into the caller channel. The case happens when
performing a blonde transfer using the channel driver's protocol.
2) A channel masquerades into a callee channel. The case happens when
performing a directed call pickup.
3) The caller channel masquerades out of dial. The case happens when
using the Bridge application on the caller channel.
4) A callee channel masquerades out of dial. The case happens when using
the Bridge application on a peer channel.
As it turned out, all four cases need to be handled instead of just the
first one.
ASTERISK-24237
Reported by: Richard Mudgett
ASTERISK-24394 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4066/
........
Merged revisions 425430 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If res_phoneprov failed to fully load (due to not being configured), the
providers container will be NULL. If a module attempts to register a phone
provisioning provider, it should check for the presence of the container.
If there is no providers container, it should return an error.
This patch makes the ast_phoneprov_provider_register function do that...
otherwise this would be a silly commit message.
........
Merged revisions 425220 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425221 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the 'force_rport' option is enabled the behavior should be the same
as if the remote side placed rport into the message themselves. Therefore
any responses we send should include the source port of the request in the
rport of the Via header.
#SIPit31
ASTERISK-24387 #close
Reported by: Matt Jordan
........
Merged revisions 425131 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
endpoint->inbound_auths was changed to a vector in 13 and I
committed the 12 patch instead of the 13 patch.
Tested-by: George Joseph
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When starting ice if there is not at least one remote ice candidate with an RTP
component asterisk will crash. This is due to an assertion in pjnath as it
expects at least one candidate with an RTP component. Added a check to make
sure at least one candidate contains an RTP component and at least one candidate
has an RTCP component.
ASTERISK-24383 #close
Review: https://reviewboard.asterisk.org/r/4039/
........
Merged revisions 425030 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes res_phoneprov more modular so other modules (like pjsip)
can provide configuration information instead of res_phoneprov relying solely
on users.conf and sip.conf. To accomplish this a new ast_phoneprov public API
is now exposed which allows config providers to register themselves, set
defaults (server profile, etc) and add user extensions.
* ast_phoneprov_provider_register registers the provider and provides callbacks
for loading default settings and loading users.
* ast_phoneprov_provider_unregister clears the defaults and users.
* ast_phoneprov_add_extension should be called once for each user/extension
by the provider's load_users callback to add them.
* ast_phoneprov_delete_extension deletes one extension.
* ast_phoneprov_delete_extensions deletes all extensions for the provider.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/3970/
........
Merged revisions 424963 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The underlying library, pjnath, that res_rtp_asterisk uses for ICE
support does not have support for ICE-TCP. As candidates are
passed through directly to it this can cause error messages to occur
when it receives something unexpected (such as a TCP candidate).
This change merely ignores all non-UDP candidates so they never
reach pjnath.
ASTERISK-24326 #close
Reported by: Joshua Colp
........
Merged revisions 424852 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 424853 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 13+, any given message type is not guaranteed to exist even
if Asterisk comes up correctly since creation of the message type could
be declined. The indexer should not prevent Asterisk from starting
under these conditions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When message type creation is declined via stasis.conf, certain
operations log errors assuming that the declined type is being used
before initialization or after destruction. These error messages get
quite spammy for oft used message types and should not be logged in the
first place since the message type is validly NULL.
Reported by: Matt DiMeo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Formats within a capabilities structure are addressed starting at 0, not 1.
Assuming 1 causes it to exceed an array.
ASTERISK-24389 #close
Reported by: Kevin Harwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424752 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the auth_reject_permanent parameter was not initialized on
the registration client state, leading to the parameter being disabled
regardless of the value specified in pjsip.conf.
This patch initialized the setting on the registration client state to the
provided configuration value.
ASTERISK-24398 #close
........
Merged revisions 424730 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If SendMessage encounters an error (such as incorrect input provided to the
action), it will currently return -1. Actions should only return -1 if the
connection to the AMI client should be closed. In this case, SendMessage
causing the client to disconnect is inappropriate.
This patch causes the action to return 0, which simply causes the action to
fail.
Review: https://reviewboard.asterisk.org/r/4024
ASTERISK-24354 #close
Reported by: Peter Katzmann
patches:
sendMessage.patch uploaded by Peter Katzmann (License 5968)
........
Merged revisions 424690 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 424691 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the Bridge application to bridge a channel that is executing an
applicaiton such as Wait results in a lingering Surrogate channel in the
CLI "core show channels" output even though it has already hungup.
* Fix bridge_exec() to not hold onto the current_dest_chan ref once it has
been put into the bridge.
* Eliminated bridge_exec()'s use of RAII_VAR().
ASTERISK-24224 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4041/
........
Merged revisions 424668 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An OPTIONS request that is sent to Asterisk but not to a specific endpoint is
currently sent a 404 in response. This is because, not surprisingly, an empty
extension is never going to be found in the dialplan.
This patch makes it so that we only attempt to look up the endpoint in the
dialplan if it is specified in the OPTIONS request URI.
#SIPit31
ASTERISK-24370 #close
Reported by: Matt Jordan
........
Merged revisions 424624 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling PJSIP_MEDIA_OFFER on a non-PJSIP channel is hazardous to your health.
It will treat the channels as a PJSIP channel, eventually hitting an ao2 error,
FRACKing on assertion error, and quite likely crashing.
This patch adds checks to the read/write callbacks that ensure that the channel
technology is of type 'PJSIP' before attempting to operate on the channel.
#SIPit31
ASTERISK-24382 #close
Reported by: Matt Jordan
........
Merged revisions 424621 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a message that exceeds the PJ_MAX_PKT_SIZE is sent over a reliable
transport, it is possible (although it shouldn't occur) for pjproject to pass
up an rdata object with a NULL msg in the msg_info. Needless to say, things
that attempt to dereference this are in for a rough ride.
In particular, this caused crashes in three different locations, all of which
are 'low level' enough to intercept an rdata object early in processing:
(1) res_pjsip_logger
(2) res_hep_pjsip
(3) res_pjsip/distributor
Anything that can intercept an rdata object before res_pjsip/distributor should
be defensive when looking at the received packet.
#SIPit31
ASTERISK-24369 #close
Reported by: Matt Jordan
........
Merged revisions 424618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A subscription that has been persisted can - for various reasons - fail to be
re-created on startup. This patch resolves a number of crashes that occurred
when a subscription cannot be re-created on several off-nominal paths.
#SIPit31
ASTERISK-24368 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
