Age | Commit message (Collapse) | Author |
|
Add new global, instance and wizard observers.
instance_created
wizard_registered
wizard_unregistered
instance_destroying
instance_loading
instance_loaded
wizard_mapped
object_type_registered
object_type_loading
object_type_loaded
wizard_loading
wizard_loaded
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4215/
........
Merged revisions 428999 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429000 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Add
const char *ast_variable_find_in_list(const struct ast_variable *list,
const char *variable);
ast_variable_find() requires a config category to search whereas
ast_variable_find_in_list() just needs the root list element which is
useful if you don't have a category.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4217/
........
Merged revisions 428733 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428734 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ast_string_fields_copy relies on the fact that
__ast_string_field_release_active never previously
zeroed pool->used, so keeping the existing pointer
was "ok". Now that existing pools can be reset to
'empty', it is important to set each field to
__ast_string_field_empty after releasing the memory.
ASTERISK-24535 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4186/
........
Merged revisions 428272 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428273 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Optimistic SRTP is the ability to enable SRTP but not have it be
a fatal requirement. If SRTP can be used it will be, if not it won't be.
This gives you a better chance of using it without having your sessions
fail when it can't be.
Encrypt all the things!
Review: https://reviewboard.asterisk.org/r/3992/
........
Merged revisions 428222 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows for a configurable number of attempts for a transferer
to dial an extension to transfer the call to. For Asterisk 13, the
default values are such that upgrading between versions will not
cause a behaivour change. For trunk, though, the defaults will be
changed to be more user-friendly.
Review: https://reviewboard.asterisk.org/r/4167
........
Merged revisions 428145 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is the Asterisk 13 version of the patch. The main difference is in the pubsub
code since it was completely refactored between Asterisk 12 and 13.
Review: https://reviewboard.asterisk.org/r/4175
........
Merged revisions 427841 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change corrects message ordering in cases where a channel-related
message can be received after a Stasis/ARI application has received the
StasisEnd message. The StasisEnd message was being passed to
applications directly without waiting for the channel topic to empty.
As a result of this fix, other bugs were also identified and fixed:
* StasisStart messages were also being sent directly to apps and are
now routed through the stasis message bus properly
* Masquerade monitor datastores were being removed at the incorrect
time in some cases and were causing StasisEnd messages to not be sent
* General refactoring where necessary for the above
* Unsubscription on StasisEnd timing changes to prevent additional
messages from following the StasisEnd when they shouldn't
A channel sanitization function pointer was added to reduce processing
and AO2 lookups.
Review: https://reviewboard.asterisk.org/r/4163/
ASTERISK-24501 #close
Reported by: Matt Jordan
........
Merged revisions 427788 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427789 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
matching digits.
* Made collecting DTMF digits for the DTMF feature hooks pass frames from
the bridge.
* Made collecting DTMF digits possible by other bridge hooks if there is a
need.
ASTERISK-24447 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4123/
........
Merged revisions 427493 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427494 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427495 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Fix missing / unreachable calls to __ast_string_field_release_active.
* Reset pool->used to zero when the current pool->active reaches zero.
ASTERISK-24307 #close
Reported by: Etienne Lessard
Tested by: ibercom, Etienne Lessard
Review: https://reviewboard.asterisk.org/r/4114/
........
Merged revisions 427380 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 427381 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427382 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change adds an option, moh_passthrough, that when enabled will pass
hold and unhold requests through using a SIP re-invite. When placing on
hold a re-invite with sendonly will be sent and when taking off hold a
re-invite with sendrecv will be sent. This allows remote servers to handle
the musiconhold instead of the local Asterisk instance being responsible.
Review: https://reviewboard.asterisk.org/r/4103/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Because opus transcoding support cannot be included in the standard Asterisk
distribution, a few codec_opus implementations have popped up. To make it
easier for people to drop in opus support in their own installations, this
patch adds configure checks for libopus.
Review: https://reviewboard.asterisk.org/r/4106/
........
Merged revisions 426234 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@426235 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
gcc on the ARM platform defaults 'char' to 'unsigned char' whereas Intel and
SPARC default to 'signed char'. This is only an issue in the rare cases where
negative values are assigned to a 'char' but this this patch insures
compatibility by detecting platforms that default to 'unsigned' and adding an
'-fsigned-char' flag to _ASTCFLAGS.
If compiling for ARM (native or cross-compile) be sure to run ./bootstrap.sh
and ./configure to regenerate the build files. You shouldn't have to do this
for Intel or SPARC.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4091/
........
Merged revisions 425964 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425965 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
connection-oriented transports.
This change adds a module which is configurable using the keep_alive_interval setting in the
global section that will send a CRLF keep alive to all active connection-oriented transports at
the provided interval. This is useful because it can help keep connections open through NATs.
This functionality also exists within PJSIP but can not be controlled at runtime and requires
recompiling it.
Review: https://reviewboard.asterisk.org/r/4084/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
applicable.
This change adds a configuration option which adds a 'user=phone' parameter if the user
portion of the request URI or the From URI is determined to be a number.
Review: https://reviewboard.asterisk.org/r/4073/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Fix infinite loop when calling ast_variable_retrieve inside an
ast_category_browse loop when there is more than 1 category with
the same name.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4089/
........
Merged revisions 425713 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425714 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub
have loaded properly before attempting to load any modules that depend
on them since the module loader system is not currently capable of
resolving module dependencies on its own.
ASTERISK-24312 #close
Reported by: Dafi Ni
Review: https://reviewboard.asterisk.org/r/4062/
........
Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425691 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425700 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
........
Merged revisions 425526 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Based on feedback from Richard, I created an accessor for
res_phoneprov/ast_phoneprov_std_variable_lookup and added
load priority to AST_MODULE_INFO.
Tested-by: George Joseph
Tested-by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4076/
........
Merged revisions 425480 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425481 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425482 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
........
Merged revisions 425384 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425385 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
........
Merged revisions 424964 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424965 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423478 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Empty here means that there are no formats in the format_cap structure
or the only format in it is the "none" format.
I've added calls to check the emptiness of a format_cap in a few places
in order to short-circuit operations that would otherwise be pointless
as well as to prevent some assertions from being triggered in cases
where channels with no formats are used.
........
Merged revisions 423414 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
res_pjsip_pubsub has two separate checks that it makes when a SUBSCRIBE
arrives.
* It checks that there is a subscription handler for the Event
* It checks that there are body generators for the types in the Accept header
The problem is, there's nothing that ensures that these two things will
actually mesh with each other. For instance, Asterisk will accept a subscription
to MWI that accepts pidf+xml bodies. That doesn't make sense.
With this commit, we add some type information to the mix. Subscription
handlers state they generate data of type X, and body generators state
that they consume data of type X. This way, Asterisk doesn't end up in
some hilariously mismatched situation like the one in the previous paragraph.
ASTERISK-24136 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/3877
Review: https://reviewboard.asterisk.org/r/3878
........
Merged revisions 423344 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423348 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When no transport is associated to an endpoint, the AMI output for
PJSIPShowEndpoint indicates an error instead of silently ignoring the
missing transport.
This patch causes the error to appear only if a transport was specified
on the endpoint and the transport doesn't exist. It also fixes an issue
with counting the objects that were actually found.
ASTERISK-24161 #close
ASTERISK-24331 #close
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3998/
........
Merged revisions 423282 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423284 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423285 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If you call ast_category_insert with a match category that doesn't exist, the
list traverse runs out of 'next' categories and you get a SEGV. This patch
adds check for the end-of-list condition and changes the signature to return
an int for success/failure indication instead of a void.
The only consumer of this function is manager and it was also changed to use
the return value.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3993/
........
Merged revisions 423276 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 423277 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423278 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423279 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423280 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Changes made during format improvements resulted in the
recording to voicemail option 'm' of the MixMonitor app
writing a zero length duration in the msgXXXX.txt file.
This change introduces a new function ast_ratestream(),
which provides the sample rate of the format associated
with the stream, and updates the app_voicemail function
for ast_app_copy_recording_to_vm to calculate the right
duration.
Review: https://reviewboard.asterisk.org/r/3996/
ASTERISK-24328 #close
........
Merged revisions 423192 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
1. The number of file descriptors an ioqueue instance can handle is fixed, so we
now spawn the required number to handle the load.
2. Our transport identifiers were exceeding the range supported by pjnath.
3. The TURN client did not set up client binding causing needless bandwidth usage.
4. The code no longer updates address information on each packet.
5. STUN traffic was getting looped back to Asterisk instead of going through the
TURN server.
6. Synchronization now ensures things are completely setup or destroyed.
7. Logging now reflects the target the TURN server is sending to/receiving from
on our behalf.
ASTERISK-23577 #close
Reported by: Jay Jideliov
ASTERISK-23634 #close
Reported by: Roman Skvirsky
Review: https://reviewboard.asterisk.org/r/3982/
........
Merged revisions 423150 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423151 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423152 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:
context exten channel dest_channel app data
default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20
However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:
context exten channel dest_channel app data
macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20
The same is true of a GoSub:
context exten channel dest_channel app data
subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20
This generally makes the context/exten fields less than useful.
It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.
This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.
Review: https://reviewboard.asterisk.org/r/3962/
ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Adds an option to the dial API that marks an outgoing dial as replacing the dialing channel for the purpose of propagating accountcode. When it is used, AST_CHANNEL_REQUESTOR_REPLACEMENT is used instead of AST_CHANNEL_REQUESTOR_BRIDGE_PEER when setting accountcodes on the involved channels with ast_channel_req_accountcodes.
Review: https://reviewboard.asterisk.org/r/3968/
........
Merged revisions 422684 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
media has been negotiated.
Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.
As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.
In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.
ASTERISK-24212 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3930
........
Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 422200 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows the callerid parsing function to handle malformed input
strings and strings containing escaped and unescaped double quotes.
This also adds a unittest to cover many of the cases where the parsing
algorithm previously failed.
Review: https://reviewboard.asterisk.org/r/3923/
Review: https://reviewboard.asterisk.org/r/3933/
........
Merged revisions 422112 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422114 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422154 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ASTERISK-24147 #close
Reported by: Edvin Vidmar
Review: https://reviewboard.asterisk.org/r/3908/
........
Merged revisions 421879 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421880 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch fixes gcc warnings that occur due to the type qualifier 'const'
being ignored on a return type of int.
ASTERISK-24246 #close
Reported by: Shaun Ruffell
patches:
0001-main-uri-Quiet-warning-about-ignored-attribute-on-re.patch uploaded by Shaun Ruffell (License 5417)
........
Merged revisions 421675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses a few issues:
1) The order of Dial events have been changed when performing a call forward.
The order has now been altered to
1) Dial begins dialing channel A.
2) When A forwards the call to B, we issue the dial end event to channel
A, indicating the dial is being canceled due to a forward to B.
3) When the call to channel B occurs, we then issue a new dial begin to
channel B.
2) Call forwards are now reported on the calling channel, not the peer channel.
3) AMI DialEnd events have been altered to display the extension the call is
being forwarded to when relevant.
4) You can now get the values of channel variables for channels that are not
currently in the Stasis application. This brings the retrieval of channel
variables more in line with the rest of channel read operations since they
may be performed on channels not in Stasis.
ASTERISK-24134 #close
Reported by Matt Jordan
ASTERISK-24138 #close
Reported by Matt Jordan
Patches:
forward-shenanigans.diff uploaded by Matt Jordan (License #6283)
Review: https://reviewboard.asterisk.org/r/3899
........
Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If a manager or CLI user attached a mixmonitor to a call running a dynamic
bridge feature while in a bridge, the feature would be interrupted and the
channel would be forcibly kicked out of the bridge (usually ending the call
during a simple 1 to 1 call). This would also occur during any similar action
that could set the unbridge soft hangup flag, so the fix for this was to
remove unbridge from the soft hangup flags and make it a separate thing all
together.
ASTERISK-24027 #close
Reported by: mjordan
Review: https://reviewboard.asterisk.org/r/3900/
........
Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is to support the backwards compatible changes made in the next version
of Asterisk.
........
Merged revisions 420805 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420808 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The patch to catch channels being shoehorned into Stasis() via external
mechanisms also happens to catch Announcer and Recorder channels
because they aren't known to be stasis-controlled channels in the usual
sense. This marks those channels as Stasis()-internal channels and
allows them directly into bridges.
Review: https://reviewboard.asterisk.org/r/3903/
........
Merged revisions 420795 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420796 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This commit adds the ability for a user to configure
a resource list in pjsip.conf. Subscribing to this
list simultaneously subscribes the subscriber to all
resources listed. This has the potential to reduce
the amount of SIP traffic when loads of subscribers
on a system attempt to subscribe to each others' states.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Fixed the iax.conf bandwidth option. This is the root cause of
ASTERISK-24150.
* Added checks in iax2_request() to ensure that there are actual formats
requested for the new channel to prevent any more fracks from issues like
ASTERISK-24150. This is a consequence of the iax.conf bandwidth option
not working.
* Fixed struct iax2_codec_pref.order member size mismatch issue when
converting to and from the codec preference order list passed over the
wire. In addition the values sent over the wire are now compatible with
previous Asterisk versions.
* Fixed several issues dealing with the struct iax2_codec_pref members.
Off-by-one, array limit errors, and the order/framing members always need
to be updated together.
* Made iax2_request() setup the channel's native format preference order
according to the user's wishes. The new media format strategy needs the
order specified earler.
* Fixed usage of ast_format_compatibility_bitfield2format(). The function
can return NULL if the bitfield was not associated with a function.
* Deleted dead code iax2_codec_pref_getsize() and
iax2_codec_pref_setsize().
* Made iax2_parse_allow_disallow() and iax2_codec_pref_string() call
iax2_codec_pref_to_cap() instead of inlining it.
* Made IAX_CAPABILITY_MEDBANDWIDTH, IAX_CAPABILITY_LOWBANDWIDTH, and
IAX_CAPABILITY_LOWFREE constants again as they were in Asterisk v1.8.
* Renamed prefs to prefs_global so it won't get confused with the local
pref versions.
* Fixed too small buffer in handle_cli_iax2_show_peer().
* Fixed ast_cli() calls in handle_cli_iax2_show_peer() to output complete
lines.
* Changed struct create_addr_info.prefs to be struct iax2_codec_pref as an
optimization so iax2_request() and iax2_call() do less work.
* Fixed a potential deadlock in ast_iax2_new() on an off-nominal path when
the pbx could not get started.
* Made set_config() setup a local prefs list along side the local
capability format bitfield. Once the config is loaded, then the local
copies are put into the global versions.
* Fix unininialized codec_buf in function_iaxpeer().
ASTERISK-24150 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3890/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This fixes a class of issues where Stasis applications were not made
aware that their channels were being manipulated or replaced by
external entitiessuch as transfers, AMI commands, or dialplan
applications such as Bridge(). Inconsistent information such as
StasisEnd events with unknown channels as a result of masquerades has
also been corrected. To accomplish these fixes, several new fields
were added to blind and attended transfer messages as well as
StasisStart and BridgeAttendedTransfer Stasis events.
ASTERISK-23941 #close
Review: https://reviewboard.asterisk.org/r/3865/
Review: https://reviewboard.asterisk.org/r/3857/
Review: https://reviewboard.asterisk.org/r/3852/
Review: https://reviewboard.asterisk.org/r/3816/
Review: https://reviewboard.asterisk.org/r/3731/
Review: https://reviewboard.asterisk.org/r/3729/
Review: https://reviewboard.asterisk.org/r/3728/
........
Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
state using SIP.
This module uses the inbound and outbound PUBLISH support to exchange device and mailbox
state between Asterisk instances. Each instance is configured to publish to the other and
requires no intermediary server. The functionality provided is similar to the XMPP and
Corosync support.
Review: https://reviewboard.asterisk.org/r/3780/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This module implements the core parts required for doing outbound PUBLISH.
It takes care of configuration, lifetime management, and authentication.
Additional modules implement the specific events that are published.
Review: https://reviewboard.asterisk.org/r/3780/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|