This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.
Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.
In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
outbound calls. It now does this in the appropriate location, in the
serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
Specifically, some longs and unsigned ints can't be be packed into integer
values, for obvious reasons. Since libjansson only supports integers,
floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
(a) it would emit a source IP address of 0.0.0.0 if bound to that IP
address. We now use ast_find_ourip to get a better IP address, and
properly marshal the result into an ast_strdupa'd string.
(b) Reports can be generated with no report bodies. In particular, this
occurs when a sender is transmitting information to a receiver (who
will send no RTP back to the sender). As such, the sender has no report
body for what it received. We now properly handle this case, and the
sender will emit SR reports with no body. Likewise, if we receive an
RTCP packet with no report body, we will still generate the appropriate
events.
ASTERISK-24119 #close
........
Merged revisions 419823 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for an <example /> tag in the XML documentation schema.
For CLI help, this doesn't change the formatting too much:
- Preceeding white space is removed
- Unlike with para elements, new lines are preserved
However, having an <example /> tag in the XML schema allows for the wiki
documentation generation script to surround the documentation with {code} or
{noformat} tags, generating much better content for the wiki - and allowing us
to put dialplan examples (and other code snippets, if desired) into the
documentation for an application/function/AMI command/etc.
Review: https://reviewboard.asterisk.org/r/3807/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds three new AMI commands:
* ExtensionStateList (pbx.c) - list all known extension state hints
and their current statuses. Events emitted by the list action are
equivalent to the ExtensionStatus events.
* PresenceStateList (res_manager_presencestate) - list all known
presence state values. Events emitted are generated by the stasis
message type, and hence are PresenceStateChange events.
* DeviceStateList (res_manager_devicestate) - list all known device
state values. Events emitted are generated by the stasis message
type, and hence are DeviceStateChange events.
Patch-by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3799/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ASTERISK-24124 #close
Reported by Matt Jordan
AFS-131 #close
Reported by Matt Jordan
Patches:
userevent.patch uploaded by Matt Jordan (License #6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since the PJSIP INVITE session module is invoked before any session supplements it was
possible for it to handle a redirect before the res_pjsip_diversion module interpreted
and set redirecting information on the channel. This would cause the redirecting
information to get lost.
This patch ensures that session supplements are *always* invoked before a redirect occurs
by explicitly calling them in the redirect handler.
Review: https://reviewboard.asterisk.org/r/3850/
........
Merged revisions 419764 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When creating the alphabetical sorted list each module is added to a list
temporarily. On the second iteration each module already has a pointer to
another module, causing stuff to go into a loop.
ASTERISK-24123 #close
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r419565 | mjordan | 2014-07-25 09:41:23 -0500 (Fri, 25 Jul 2014) | 21 lines
ARI: report duration values in LiveRecording objects
This patch adds three new fields to the LiveRecording model:
- total_duration: the total length of the live recording
- talking_duration: optional. The duration of talking energy that was
detected while the recording was made.
- silence_duration: optional. The duration of silence that was detected while
the recording was made.
These values are reported in the RecordingFinished ARI event.
When a DSP is enabled on the channel during the recording - which occurs when
the recording is created with max_silence_seconds (indicating that the user
actually cares about how much silence is in the file), we will report the
talking_duration and silence_duration in addition to the total_duration.
Review: https://reviewboard.asterisk.org/r/3770/
ASTERISK-24037 #close
Reported by: Samuel Galarneau
........
r419566 | mjordan | 2014-07-25 09:46:15 -0500 (Fri, 25 Jul 2014) | 1 line
Update CHANGES for r419565
........
Merged revisions 419565-419566 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk starts a module (calling its load_module function), it re-orders
the module list, sorting it alphabetically. Ostensibly, this was done so that
the output of 'module show' listed modules in alphabetic order. This had the
unfortunate side effect of making modules with complex usage patterns
unloadable. A module that has a large number of modules that depend on it is
typically abandoned during the unloading process. This results in its memory
not being reclaimed during exit.
Generally, this isn't harmful - when the process is destroyed, the operating
system will reclaim all memory allocated by the process. Prior to Asterisk 12,
we also didn't have many modules with complex dependencies. However, with
the advent of ARI and PJSIP, this can make make unloading those modules
successfully nearly impossible, and thus tracking memory leaks or ref debug
leaks a real pain.
While this patch is not a complete overhaul of the module loader - such an
effort would be beyond the scope of what could be done for Asterisk 13 -
this does make some marginal improvements to the loader such that modules
like res_pjsip or res_stasis *may* be made properly un-loadable in the future.
1. The linked list of modules has been replaced with a doubly linked list. This
allows traversal of the module list to occur backwards. The module shutdown
routine now walks the global list backwards when it attempts to unload
modules.
2. The alphabetic reorganization of the module list on startup has been
removed. Instead, a started module is placed at the end of the module list.
3. The ast_update_module_list function - which is used by the CLI to display
the modules - now does the sorting alphabetically itself. It creates its own
linked list and inserts the modules into it in alphabetic order. This allows
for the intent of the previous code to be maintained.
This patch also contains a fix for res_calendar. Without calendar.conf, the
calendar modules were improperly bumping the use count of res_calendar, then
failing to load themselves. This patch makes it so that we detect whether or
not calendaring is enabled before altering the use count.
Review: https://reviewboard.asterisk.org/r/3777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bridges created by app_bridgewait previously had the "dissolve when empty" flag set.
This caused the bridge core to destroy them when the last channel had left. This
introduced a race condition where we may have a reference to the bridge but it is
not actually joinable when we try to join it. This flag has now been removed and the
bridge is guaranteed to be joinable at all times.
ASTERISK-23987 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3836/
........
Merged revisions 419538 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "bridge destroy" CLI command is invasive to bridges and can leave them in an unexpected
state for the users of them. Since this command may be useful for developers it is now
only available when developer mode is available. To take its place "all" has been added
as a valid option to the "bridge kick" CLI command. It will kick all of the channels
in the bridge out.
ASTERISK-23987
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3840/
........
Merged revisions 419536 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call. It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.
SIP/100 -> Local;1/Local;2 -> SIP/200
Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.
Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options. Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.
Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support. The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode. The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.
With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work. Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:
SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100
If a channel already has an accountcode it can only change by the
following explicit user actions:
1) A channel originate method that can specify an accountcode to use.
2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial. e.g., Dial and
FollowMe. The exception to this propagation method is Queue. Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.
3) Dialplan using CHANNEL(accountcode).
4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.
If a channel does not have an accountcode it can get one from the
following places:
1) The channel driver's configuration at channel creation.
2) Explicit user action as already indicated.
3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.
You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications. Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.
Accountcode and peeraccount values propagate to an outgoing channel before
dialing. Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge. The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.
* Made peeraccount functional by changing accountcode propagation as
described above.
* Fixed CEL extracting the wrong ie value for the peeraccount. This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.
* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.
AFS-65 #close
Review: https://reviewboard.asterisk.org/r/3601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These change was applied to trunk in r419438
........
chan_sip: sip_subscribe_mwi_destroy should not call sip_destroy
sip_subscribe_mwi_destroy calls sip_destroy on the reference counted
mwi->call. This results in the fields of mwi->call being freed, but
mwi->call itself it leaked. If other code is still using mwi->call
it can cause problems. This change uses dialog_unref instead, to
balance the ref provided by sip_alloc().
ASTERISK-24087 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3834/
........
Merged revisions 419440 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 419441 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk, it is possible for a device to have a status of ONHOLD. This is
not typically an easy thing to determine, as a channel being on hold is not
a direct channel state. Typically, this has to be calculated outside of the
core independently in channel drivers, notably, chan_sip and chan_pjsip. Both
of these channel drivers already have to calculate device state in a fashion
more complex than the core can handle, as they aggregate all state of all
channels associated with a peer/endpoint; they also independently track
whether or not one of those channels is currently on hold and mark the device
state appropriately.
In 12+, we now have the ability to report an AST_DEVICE_ONHOLD state for all
channels that defer their device state to the core. This is due to channel hold
state actually now being tracked on the channel itself. If a channel driver
defers its device state to the core (which many, such as DAHDI, IAX2, and
others do in most situations), the device state core already goes out to get a
channel associated with the device. As such, it can now also factor the channel
hold state in its calculation.
This patch adds this logic to the device state core. It also uses an existing
mapping between device state and channel state to handle more channel states.
chan_pjsip has been updated slightly as well to make use of this (as it was,
for some reason, reporting a channel state of BUSY as a device state of INUSE,
which feels slightly wrong).
Review: https://reviewboard.asterisk.org/r/3771/
ASTERISK-24038 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
(1) It updates the unit tests to expect additional stasis messages. More
messages are now sent to the endpoint topic, due to forwarding all
channel messages and the forwarding relationship set up between
endpoints themselves.
(2) Remove the technology forwarding subscription during
ast_endpoint_shutdown. This prevents an improper double shutdown of
an endpoint from occurring.
........
Merged revisions 419318 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Say you wanted to include variables in an application map and have those
variables substituted and passed along to the application being executed;
currently this does not happen.
This patch adds this ability to pass channel variable values to an
application before being executed.
ASTERISK-22608 #close
Reported by: Michael L. Young
patches:
features_substitute_arguments_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3819/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We have a new periodic beep feature but sometimes a user needs some sort of
feedback, without the need to have a periodic beep during the recording, to let
them know that MixMonitor started recording or ended the recording. The use
case where this patch is being used is when using Dynamic Features to start and
end MixMonitor.
This patch adds an option to play a beep when MixMonitor starts and an option to
play a beep when MixMonitor ends.
ASTERISK-24051 #close
Reported by: Michael L. Young
patches:
mixmonitor-play-beep-start-stop.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3820/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When updating a row, we are currently doing an INSERT OR REPLACE INTO. The
downside to this is that the row is deleted if it exists and then a new row is
inserted. So, we are hitting the disk twice. One for the deletion and one for
the insertion.
This patch changes this statement to an INSERT INTO and if the insert fails
because a row with that key exists, we will IGNORE the failure. Then we will
attempt to perform an UPDATE on the existing row if that row wasn't just
INSERTed.
ASTERISK-24050 #close
Reported by: Michael L. Young
patches:
astdb-insert-update-io-help_trunk_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3815/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The iax2_best_codec function was changed to convert the formats
into a format compatibilities structure and grab the first
format from it. The resulting order differs from the previous
order of iax2_best_codec which causes unexpected formats to
get chosen (such as g723).
This commit brings back the old behavior of iax2_best_codec by
having a specified preference list.
Review: https://reviewboard.asterisk.org/r/3835/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents a crash in the Dial API triggered by use of the Page()
application where a format capability struct was used before checking
whether it was NULL.
ASTERISK-24074 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After merging the media formats branch, chan_iax2 was discarding
codec preferences for the purpose of choosing which codec a
channel would use once a call started. This patch restores the
Asterisk 1.8-12 codec choice behaviors.
ASTERISK-23958 #close
Review: https://reviewboard.asterisk.org/r/3800/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When configuring Asterisk to build against a version of pjproject installed
in a non-standard location, the checks for "PJSIP Transaction Group Lock
Support" and "PJSIP Media Stream Replacement Support" fail. This is
because these secondary checks are not taking the CFLAGS and LIBS returned
by the pkg-config check into account.
Review: https://reviewboard.asterisk.org/r/3830
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new operation for stored recordings, copy. It takes an
existing stored recording and makes a copy of it in the same directory
or a relative directory under the stored recording directory.
/ari/recordings/stored/{recordingName}/copy?destinationRecordingName={copy_name}
This is particularly useful for voicemail-esque applications, which may need to
copy or move recordings around a directory structure.
Review: https://reviewboard.asterisk.org/r/3768/
ASTERISK-24036 #close
Reported by: Sam Galarneau
Tested by: Sam Galarneau
........
Merged revisions 419021 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a reference count goes negative, instead of
just logging that fact, be more helpful with a
backtrace and an assert that will DO_CRASH.
This patch also removes the duplicate ao2_bt()
function and cleans up extraneous usage of the
ast_log_backtrace() call.
Review: https://reviewboard.asterisk.org/r/3765/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
........
Merged revisions 418914 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
