In r411189, some behavior was changed which made sendrpid behavior
act in a more trusting manner by sending full user data for peers
set with private caller presence in P-Asserted-Identity headers.
Since this changed long time expected behaviors, we decided to pull
that patch when that was pointed out by the community. Instead, this
patch provides a trust_id_outbound setting which will expose the data
per RFC-3325 if set to 'yes' and simply not send the PAI/RPID headers
at all if set to 'no'. By default trust_id_outbound will be set to
'legacy' which will preserve the behavior prior to these patches.
Extra special thanks to Walter Doekes for providing advice and
feedback.
(closes issue AST-1301)
(closes issue ASTERISK-19465)
Reported by: Krzysztof Chmielewski
Review: https://reviewboard.asterisk.org/r/3447/
........
Merged revisions 412744 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412746 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 412747 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).
(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
........
Merged revisions 412535 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a continuation of https://reviewboard.asterisk.org/r/3349/,
committed in r412303.
It resolves a finding oej had that the phone-context be available in a
channel variable separate from SIPDOMAIN. This patch adds that variable as
SIPURIPHONECONTEXT. It also allows a local number (or global number specified
in the TEL URI) to be used to look up as a peer.
(issue ASTERISK-17179)
Review: https://reviewboard.asterisk.org/r/3349/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add an option to enable a periodic beep to be played into a call if it
is being recorded. If enabled, it uses the PERIODIC_HOOK() function
internally to play the 'beep' prompt into the call at a specified
interval. This option is provided for both Monitor() and
MixMonitor().
Review: https://reviewboard.asterisk.org/r/3424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for handling TEL URIs in inbound INVITE requests.
This includes the Request URI and the From URI. The number specified in
the Request URI will be the destination of the inbound channel in the dialplan.
The phone-context specified in the Request URI will be stored in the
TELPHONECONTEXT channel variable.
Review: https://reviewboard.asterisk.org/r/3349
ASTERISK-17179 #close
Reported by: Geert Van Pamel
Tested by: Geert Van Pamel
patches:
asterisk-12.0.0-chan_sip-RFC3966_patch.txt uploaded by Geert Van Pamel (License 6140)
asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt uploaded by Geert Van Pamel (License 6140)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412292 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a parsing error that occurred during the processing of
the AMI action. The error did not result in MixMonitor itself
misbehaving, but it could result in the AMI response not giving
correct information back.
The new header allows for one to specify a post-process command
to run when recording finishes. Previously, in order to do this,
the post-process command would have to be placed at the end of
the Options: header.
Patches: mixmonitor_command_2.patch by jhardin (License #6512)
........
Merged revisions 412048 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces a new dialplan function, PERIODIC_HOOK().
It allows you run to a dialplan hook on a channel periodically. The
original use case that inspired this was the ability to play a beep
periodically into a call being recorded. The implementation is much
more generic though and could be used for many other things.
The implementation makes heavy use of existing Asterisk components.
It uses a combination of Local channels and ChanSpy() to run some
custom dialplan and inject any audio it generates into an active call.
The other important bit of the implementation is how it figures out
when to trigger the beep playback. This implementation uses the
audiohook API, even though it's not actually touching the audio in any
way. It's a convenient way to get a callback and check if it's time
to kick off another beep. It would be nice if this was timer event
based instead of polling based, but unfortunately I don't see a way to
do it that won't interfere with other things.
Review: https://reviewboard.asterisk.org/r/3362/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the following:
(1) A new module, res_hep, which implements a generic packet capture agent for
the Homer Encapsulation Protocol (HEP) version 3. Note that this code is based
on a patch provided by Alexandr Dubovikov; I basically just wrapped it up,
added configuration via the configuration framework, and threw in a
taskprocessor.
(2) A new module, res_hep_pjsip, which forwards all SIP message traffic that
passes through the res_pjsip stack over to res_hep for encapsulation and
transmission to a HEPv3 capture server.
Much thanks to Alexandr for his Asterisk patch for this code and for a *lot*
of patience waiting for me to port it to 12/trunk. Due to some dithering on
my part, this has taken the better part of a year to port forward (I still
blame CDRs for the delay).
ASTERISK-23557 #close
Review: https://reviewboard.asterisk.org/r/3207/
........
Merged revisions 411534 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It updates the AMI version to 2.2.0 to indicate backwards compatible
changes have been made since the last release
* It updates the ARI version to 1.2.0 to indicate backwards compatible
changes have been made since the last release
* It updates the UPGRADE/CHANGES files with changes that were not
mentioned
........
Merged revisions 411529 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change turns the bridge type field into a comma separated list of attributes.
These attributes include: mixing, holding, dtmf_events, and proxy_media. By setting
the various attributes a user can control the type of bridge created with the
behavior they need for their application.
(closes issue ASTERISK-23437)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3359/
........
Merged revisions 410904 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enables DNS client support within PJSIP. System
nameservers are automatically discovered using res_init or
res_ninit. If this fails then PJSIP will resort to using
gethostbyname for resolution.
By enabling this support we gain SRV support, failover, and
weight support.
(closes issue ASTERISK-23435)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3343/
........
Merged revisions 410795 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch creates the AST_SORCERY dialplan function which allows someone to
retrieve any value from a sorcery-based config file. It's similar to
AST_CONFIG.
The creation of the function itself was fairly straightforward but it required
changes to the underlying sorcery infrastructure that rippled into individual
sorcery objects. The changes stemmed from inconsistencies in how sorcery
created ast_variable objectsets from sorcery objects and the inconsistency
in how individual objects used that feature especially when it came to
parameters that can be specified multiple times like contact in aor and match
in identify. You can read more here...
http://lists.digium.com/pipermail/asterisk-dev/2014-February/065202.html
So, what this patch does, besides actually creating the AST_SORCERY function,
is the following...
* Creates ast_variable_list_append which is a helper to append one ast_variable
list to another.
* Modifies the ast_sorcery_object_field_register functions to accept the
already-defined sorcery_fields_handler callback.
* Modifies ast_sorcery_objectset_create to accept a parameter indicating return
type preference...a single ast_variable with all values concatenated or an
ast_variable list with multiple entries. Also fixed a few bugs.
* Modifies individual sorcery object implementations to use the new function
definition of the ast_sorcery_object_field_register functions.
* Modifies location.c and res_pjsip_endpoint_identifier_ip.c to implement
sorcery_fields_handler handlers so they return multiple occurrences as an
ast_variable_list.
* Added a whole bunch of tests to test_sorcery.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3254/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The changes log was written with language that was a little too internal
Asterisk specific, so it's been changed to be more in the frame of reference
of an ARI user. Also, previously the AMI event changes were omitted from the
change log as well as the ability to include a bridge name in the ARI post
bridges command.
........
Merged revisions 407461 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a note in the changes file about the new 'StatusText' field that was
added to the 'ExtensionStatus' event.
(issue ASTERISK-23154)
Reported by: Jonathan Rose
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is in preparation for external MWI support.
Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context. The
only exception is the legacy hasvoicemail users.conf option. The legacy
option will only work for app_voicemail mailboxes. The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.
chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier. chan_sip just stored and
compared the two components. chan_dahdi actually used the box
information.
The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number. As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.
Review: https://reviewboard.asterisk.org/r/3072/
........
Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When doing the rework of the CDR engine that pushed all of the logic into cdr.c
and made it respond to changes in channel state over Stasis, we knew that
accessing the CDR engine from the dialplan would be "slightly"
non-deterministic. Dialplan threads would be accessing CDRs while Stasis
threads would be updating the state of said CDRs - whereas in the past,
everything happened on the dialplan threads. Tests have shown that "slightly"
is in reality "very".
This patch synchronizes things by making the dialplan applications/functions
that manipulate CDRs do so over Stasis. ForkCDR, NoCDR, ResetCDR, CDR, and
CDR_PROP now all use Stasis to send their requests over to the CDR engine,
and synchronize on the channel Stasis topic via a subscription so that they
return their values/control to the dialplan at the appropriate time.
While going through this, the following changes were also made:
* DISA, which can reset the CDR when a user successfully authenticates, now
just uses the ResetCDR app to do this. This prevents having to duplicate
the same Stasis synchronization logic in that application.
* Answer no longer disables CDRs. It actually didn't work anyway - calling
DISABLE on the channel's CDR doesn't stop the CDR from getting the Answer
time - it just kills all CDRs on that channel, which isn't what the caller
would intend.
(closes issue ASTERISK-22884)
(closes issue ASTERISK-22886)
Review: https://reviewboard.asterisk.org/r/3057/
........
Merged revisions 404294 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the time, this is only useful for retrieving the filename.
The purpose of this function is to better facilitate multiple
mixmonitors per channel. Setting a MIXMONITOR_FILENAME channel
variable is not conducive to such behavior, so allowing finer
grained access to individual mixmonitor properties improves
the situation. The MIXMONITOR_FILENAME channel variable is still
set, though, so there is no worry about backwards compatibility.
Review: https://reviewboard.asterisk.org/r/3023
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made PickupChan() search by channel uniqueids if the search could not
find a channel by name.
* Ensured PickupChan() never considers the picking channel for pickup.
* Made PickupChan() option p use a common search by name routine. The
original search was erroneously case sensitive.
(issue AFS-42)
Review: https://reviewboard.asterisk.org/r/3017/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
By the time the directory application exits, a channel variable
DIRECTORY_RESULT will be set for the channel that invoked it which
can be used to determine the reason for exit. The changes log and
the app_directory documentation contain specific details about
each of the possible values for DIRECTORY_RESULT.
Review: https://reviewboard.asterisk.org/r/3016/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to how background works, if a say application is called with
this variable set to 'true', 'yes', 'on', etc. then using DTMF while
the say action is in progress will result in the channel jumping to
that extension in the dialplan.
Review: https://reviewboard.asterisk.org/r/3011/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also adds the ability to clear all profile items and makes behavior more
consistent with documentation as when choosing whether to use CONFBRIDGE
datastore profiles or the application arguments to the confbridge application.
(closes issue ASTERISK-22760)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2971/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ConfBridge now has the ability to set the language of announcements to the
conference. The language can be set on a bridge profile in
confbridge.conf or by the dialplan function
CONFBRIDGE(bridge,language)=en.
(closes issue ASTERISK-19983)
Reported by: Jonathan White
Patches:
M19983_rev2.diff (license #5138) patch uploaded by junky (modified)
Tested by: rmudgett
........
Merged revisions 400741 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400742 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
........
Merged revisions 397989 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch from ASTERISK-21965 was committed perhaps a bit too hastily. Walter
and Tzafrir have pointed out numerous issues with the approach and have
propsed an alternative in r/2757. Since it's not a time critical issue and
is not worth holding up the release of 12 for it, I've gone ahead and reverted
r394939 from 12/trunk and re-opened ASTERISK-21965.
........
Merged revisions 397938 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch replaces contrib/realtime/ with a new setup for managing the
database schema required for database integration with Asterisk. In
addition to initializing a database with the proper schema, alembic can do a
database migration to assist with upgrading Asterisk in the future.
Hopefully this helps make setting up and operating Asterisk with a database
easier.
With this the schema only needs to be maintained in one place instead of
once per database. The schemas I have added here have a bit of improvement
over the examples that were there before (some added consistency and added
some missing indexes). Managing the schema in one place here also applies
to all databases supported by SQLAlchemy.
See contrib/ast-db-manage/README.md for more details.
Review: https://reviewboard.asterisk.org/r/2731
patch by Russell Bryant (license 6300)
........
Merged revisions 397874 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397875 65c4cc65-6c06-0410-ace0-fbb531ad65f3