This patch introduces a new identifier for channels: tenantid. It's
a stringfield on the channel that can be used for general purposes. It
will be inherited by other channels the same way that linkedid is.
You can set tenantid in a few ways. The first is to set it in the
dialplan with the Set and CHANNEL functions:
exten => example,1,Set(CHANNEL(tenantid)=My tenant ID)
It can also be accessed via CHANNEL:
exten => example,2,NoOp(CHANNEL(tenantid))
Another method is to use the new tenantid option for pjsip endpoints in
pjsip.conf:
[my_endpoint]
type=endpoint
tenantid=My tenant ID
This is considered the best approach since you will be able to see the
tenant ID as early as the Newchannel event.
It can also be set using set_var in pjsip.conf on the endpoint like
setting other channel variable:
set_var=CHANNEL(tenantid)=My tenant ID
Note that set_var will not show tenant ID on the Newchannel event,
however.
Tenant ID has also been added to CDR. It's read-only and can be accessed
via CDR(tenantid). You can also get the tenant ID of the last channel
communicated with via CDR(peertenantid).
Tenant ID will also show up in CEL records if it has been set, and the
version number has been bumped accordingly.
Fixes: #740
UserNote: tenantid has been added to channels. It can be read in
dialplan via CHANNEL(tenantid), and it can be set using
Set(CHANNEL(tenantid)=My tenant ID). In pjsip.conf, it is recommended to
use the new tenantid option for pjsip endpoints (e.g., tenantid=My
tenant ID) so that it will show up in Newchannel events. You can set it
like any other channel variable using set_var in pjsip.conf as well, but
note that this will NOT show up in Newchannel events. Tenant ID is also
available in CDR and can be accessed with CDR(tenantid). The peer tenant
ID can also be accessed with CDR(peertenantid). CEL includes tenant ID
as well if it has been set.
UpgradeNote: A new versioned struct (ast_channel_initializers) has been
added that gets passed to __ast_channel_alloc_ap. The new function
ast_channel_alloc_with_initializers should be used when creating
channels that require the use of this struct. Currently the only value
in the struct is for tenantid, but now more fields can be added to the
struct as necessary rather than the __ast_channel_alloc_ap function. A
new option (tenantid) has been added to endpoints in pjsip.conf as well.
CEL has had its version bumped to include tenant ID.
(cherry picked from commit 3841fa814e)
Certain channel options are not set anywhere or
exposed in any way to users, making them unusable.
This exposes some of these options which make sense
for users to manipulate at runtime.
Resolves: #442
(cherry picked from commit 9211fb5e97)
Adds version information for applications, functions,
and manager events/actions.
This is not completely exhaustive by any means but
covers most new things added that have release
versioning information in the issue tracker.
ASTERISK-29940 #close
Change-Id: I506401e93c799715dbbe97c0a8ba18af2bf5e131
Adds the lastcontext and lastexten channel fields to allow users
to access previous dialplan execution locations.
ASTERISK-29840 #close
Change-Id: Ib455fe300cc8e9a127686896ee2d0bd11e900307
Documentation for built-in special system and channel
vars is currently outdated, and updating is a manual
process since there is no XML documentation for these
anywhere.
This adds documentation for system vars to func_env
and for channel vars to func_channel so that they
appear along with the corresponding fields that would
be accessed using a function.
ASTERISK-29848 #close
Change-Id: I6997f925c4a45fffe71321861f5898a8b7182fa9
Adds a function to check for the existence of a channel by
name or by UNIQUEID.
ASTERISK-29656 #close
Change-Id: Ib464e9eb6e13dc683a846286798fecff4fd943cb
The following fields return an error when read from dialplan:
- exten
- context
- userfield
- channame
ASTERISK-28796 #close
Change-Id: Ieacaac629490f8710fdacc9de80ed5916c5f6ee2
The functions behind the flag and the flag itself were removed
from Asterisk 12 as incompatible with the new architecture.
Change-Id: I058493ef7a53ee290fd225bbcbb07bf46b623ccf
Be more explicit in what is meant by the master channel to eliminate
misunderstanding.
ASTERISK-23133
Change-Id: I453bcaf4b99404a5a3e345dbf093ac6c1afcfc72
Setting channel variables with the AMI Originate action caused a deadlock
when you set CDR(amaflags) or CDR(accountcode). This path has the channel
locked when the CDR function is called. The CDR function then
synchronously passes the job to a stasis thread. The stasis handling
function then attempts to lock the channel. Deadlock results.
* Avoid deadlock by making the CDR function handle setting amaflags and
accountcode directly on the channel rather than passing it off to the CDR
processing code under a stasis thread to do it.
* Made the CHANNEL function and the CDR function process amaflags the same
way.
* Fixed referencing the wrong message type in cdr_prop_write().
ASTERISK-27460
Change-Id: I5eacb47586bc0b8f8ff76a19bd92d1dc38b75e8f
* Added CHANNEL(callid) to retrieve the call identifier log tag associated
with the channel. Dialplan now has access to the call log search key
associated with the channel so it can be saved in case there is a problem
with the call.
ASTERISK-26878
Change-Id: I2c97ebd928b6f3c5bc80c5729e4d3c07f453049f
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
This updates func_channel.c and main/message.c to use a generic xpointer
include instead of including info from each channel driver. Now the
name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in
documentation for func_channel. Setting the name attribute of info to
MessageToInfo or MessageFromInfo causes it to be included in the
MessageSend application and AMI action.
Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea
* Following the example of the PJSIP channel driver, the channel
technology specific documentation has been moved to the respective
channel drivers that provide that functionality. This has the benefit
of locating the documentation of items with those modules that provide
it.
* Examples of using the CHANNEL function for both standard items as well
as for PJSIP have been added.
* The 'max_forwards' standard item has been documented.
Change-Id: Ifaa79a232c8ac99cf8da6ef6cc7815d398b1b79b
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
ASTERISK-24958 #close
Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
........
Merged revisions 430817 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It would be useful to get the current hold status of a channel.
Added CHANNEL(onhold) item that returns 1 (onhold) and 0 (not-onhold) for
the hold status of a channel.
ASTERISK-24038
Reported by: Matt Jordan
AFS-113 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3983/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The CHANNEL() audionativeformat, videonativeformat, audioreadformat, and
audiowriteformat now need locking since the media format rework when
accessing the channel's format pointers.
* Increased the buffer size for CHANNEL() audionativeformat and
videonativeformat output strings since the allow=all can be a lengthy
list.
* Tweaked the CHANNEL() XML documentation for secure_bridge_signaling,
secure_bridge_media, and state.
* Ensured the output buffer is initialized for secure_bridge_signaling and
secure_bridge_media.
* Made use the locked_copy_string() macro instead of inlining it for trace
and checkhangup.
........
Merged revisions 422700 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
* RTP information, including source/destination media addresses, whether or
not the media is secure, held, and other properties.
* RTCP information. This includes sets of parseable information, as well as
individual statistic attriutes.
* PJSIP information. This includes URIs, local/remote signalling addresses,
whether or not the signalling is secure, and other properties.
* The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
function to obtain more detailed endpoint information.
Review: https://reviewboard.asterisk.org/r/3038/
........
Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.
(closes issue ASTERISK-22039)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2717
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* ASTERISK-20383
Missing named call pickup group features:
CHANNEL(callgroup) - Need CHANNEL(namedcallgroup)
CHANNEL(pickupgroup) - Need CHANNEL(namedpickupgroup)
Pickup() - Needs to also select from named pickup groups.
* ASTERISK-20384
Using the pickupexten, the pickup channel selection could fail even though
there was a call it could have picked up. In a call pickup race when
there are multiple calls to pickup and two extensions try to pickup a
call, it is conceivable that the loser will not pick up any call even
though it could have picked up the next oldest matching call.
Regression because of the named call pickup group feature.
* See ASTERISK-20386 for the implementation improvements. These are the
changes in channel.c and channel.h.
* Fixed some locking issues in CHANNEL().
(closes issue ASTERISK-20383)
Reported by: rmudgett
(closes issue ASTERISK-20384)
Reported by: rmudgett
(closes issue ASTERISK-20386)
Reported by: rmudgett
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2112/
........
Merged revisions 373220 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373221 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Hangup handlers are an alternative to the h extension. They can be used
in addition to the h extension. The idea is to attach a Gosub routine to
a channel that will execute when the call hangs up. Whereas which h
extension gets executed depends on the location of dialplan execution when
the call hangs up, hangup handlers are attached to the call channel. You
can attach multiple handlers that will execute in the order of most
recently added first.
(closes issue ASTERISK-19549)
Reported by: Mark Murawski
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2002/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
