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
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
This fixes an issue where a Stasis application running over ARI and
subscribed to ari/events could miss the ChannelEnteredBridge event
because it did not subscribe to the new bridge fast enough.
To accomplish this, it subscribes the application controlling the
channel to the new bridge before adding it to that bridge which
required the stasis_app_control structure to maintain a reference to
the stasis_app.
(closes issue ASTERISK-23295)
Review: https://reviewboard.asterisk.org/r/3336/
........
Merged revisions 410527 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability to have rules that are checked when adding and/or removing
channels to/from a bridge. In this case, if a channel is currently recording
and someone attempts to add it to a bridge an "is recording" rule is checked,
fails, and a 409 conflict is returned.
Also command functions now return an integer value that can be descriptive of
what kind of problems, if any, occurred before or during execution.
(closes issue ASTERISK-22624)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2947/
........
Merged revisions 403749 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code for getting channel variables from ARI assumed that you needed
to lock the channel in order to properly execute functions and read
channel variables. Apparently, this is not the case, since any dialplan
function that puts the channel into autoservice deadlocks when
attempting to remove the channel from autoservice.
........
Merged revisions 403342 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring operation sends ringing to the specified channel it is invoked on.
The dtmf operation can be used to send DTMF digits to the specified channel
of a specific length with a wait time in between. Finally hangup reasons
allow you to specify why a channel is being hung up (busy, congestion).
Early media behavior has also been tweaked slightly. When playing media to a channel
it will no longer automatically answer. If it has not been answered a progress indication
is sent instead.
(closes issue ASTERISK-22701)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2916/
........
Merged revisions 402358 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a command to the command queue to explicitly depart the channel
from the bridge when it is told it has left. If the channel has already been departed
or has entered a different bridge this command will become a no-op.
(closes issue ASTERISK-22703)
Reported by: John Bigelow
(closes issue ASTERISK-22634)
Reported by: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/2965/
........
Merged revisions 402336 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402337 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
........
Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds error checking to ARI bridge operations, when
adding/removing channels to/from bridges.
In general, the error codes fall out as follows:
* Bridge not found - 404 Not Found
* Bridge not in Stasis - 409 Conflict
* Channel not found - 400 Bad Request
* Channel not in Stasis - 422 Unprocessable Entity
* Channel not in this bridge (on remove) - 422 Unprocessable Entity
(closes issue ASTERISK-22036)
Review: https://reviewboard.asterisk.org/r/2769/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch changes ARI bridging to allow other channel operations to
happen while the channel is bridged.
ARI channel operations are designed to queue up and execute
sequentially. This meant, though, that while a channel was bridged,
any other channel operations would queue up and execute only after the
channel left the bridge.
This patch changes ARI bridging so that channel commands can execute
while the channel is bridged. For most operations, things simply work
as expected. The one thing that ended up being a bit odd is recording.
The current recording implementation will fail when one attempts to
record a channel that's in a bridge. Note that the bridge itself may
be recording; it's recording a specific channel in the bridge that
fails. While this is an annoying limitation, channel recording is
still very useful for use cases such as voice mail, and bridge
recording makes up much of the difference for other use cases.
(closes issue ASTERISK-22084)
Review: https://reviewboard.asterisk.org/r/2726/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Roles are now cleared with each entry into a bridge with addChannel.
If the roles parameter is present, the role specified will be applied
to all channels being added with the addChannel command.
(closes issue ASTERISK-21973)
Reported by: Matt Jordan
https://reviewboard.asterisk.org/r/2691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 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
Adds a new channel driver for creating channels for specific purposes
in bridges, primarily to act as either recorders or announcers. Adds
ARI commands for playing announcements to ever participant in a bridge
as well as for recording a bridge. This patch also includes some
documentation/reponse fixes to related ARI models such as playback
controls.
(closes issue ASTERISK-21592)
Reported by: Matt Jordan
(closes issue ASTERISK-21593)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2670/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds support for Stasis applications to receive bridge-related
messages when the application shows interest in a given bridge.
To supplement this work and test it, this also adds support for the
following bridge-related Stasis-HTTP functionality:
* GET stasis/bridges
* GET stasis/bridges/{bridgeId}
* POST stasis/bridges
* DELETE stasis/bridges/{bridgeId}
* POST stasis/bridges/{bridgeId}/addChannel
* POST stasis/bridges/{bridgeId}/removeChannel
Review: https://reviewboard.asterisk.org/r/2572/
(closes issue ASTERISK-21711)
(closes issue ASTERISK-21621)
(closes issue ASTERISK-21622)
(closes issue ASTERISK-21623)
(closes issue ASTERISK-21624)
(closes issue ASTERISK-21625)
(closes issue ASTERISK-21626)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk REST interface.
This adds the /playback/{playbackId}/control resource, which may be
POSTed to to pause, unpause, reverse, forward or restart the media
playback.
Attempts to control a playback that is not currently playing will
either return a 404 Not Found (because the playback object no longer
exists) or a 409 Conflict (because the playback object is still in the
queue to be played).
This patch also adds skipms and offsetms parameters to the
/channels/{channelId}/play resource.
(closes issue ASTERISK-21587)
Review: https://reviewboard.asterisk.org/r/2559
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and GET /playback/{playbackId}.
This allows an external application to initiate playback of a sound on a
channel while the channel is in the Stasis application.
/play commands are issued asynchronously, and return immediately with
the URL of the associated /playback resource. Playback commands queue up,
playing in succession. The /playback resource shows the state of a
playback operation as enqueued, playing or complete. (Although the
operation will only be in the 'complete' state for a very short time,
since it is almost immediately freed up).
(closes issue ASTERISK-21283)
(closes issue ASTERISK-21586)
Review: https://reviewboard.asterisk.org/r/2531/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When implementing playback for stasis-http, the monolithicedness of
res_stasis really started to get in my way.
This patch breaks the major components of res_stasis.c into individual
files.
* res/stasis/app.c - Stasis application tracking
* res/stasis/control.c - Channel control objects
* res/stasis/command.c - Channel command object
This refactoring also allows res_stasis applications to be loaded as
independent modules, such as the new res_stasis_answer module.
The bulk of this patch is simply moving code from one file to another,
adjusting names and adding accessors as necessary.
Review: https://reviewboard.asterisk.org/r/2530/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
