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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419823 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
features.c: Allow appliationmap to use Gosub.
Using DYNAMIC_FEATURES with a Gosub application as the mapped application
does not work. It does not work because Gosub just pushes the current
dialplan context, exten, and priority onto a stack and sets the specified
Gosub location. Gosub does not have a dialplan execution loop to run
dialplan like Macro.
* Made the DYNAMIC_FEATURES application mapping feature call
ast_app_exec_macro() and ast_app_exec_sub() for the Macro and Gosub
applications respectively.
* Backported ast_app_exec_macro() and ast_app_exec_sub() from v11 to
execute dialplan routines from the DYNAMIC_FEATURES application mapping
feature.
NOTE: This issue does not affect v12+ because it already does what this
patch implements.
AST-1391 #close
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/3844/
........
Merged revisions 419630 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419565 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419538 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419536 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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419318 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419196 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a build failure introduced by r3821. struct stasis_topic is
opaque, so topic->name is unavailable. Switch to using stasis_topic_name().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@419019 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/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most channel drivers let you specify a default accountcode to be set on
channels associated with a particular peer/endpoint/object. Prior to this
patch, chan_pjsip/res_pjsip did not support such a setting.
This patch adds a new setting to the res_pjsip endpoint object, 'accountcode'.
When a channel is created that is associated with an endpoint with this value
set, the channel will automatically have its accountcode property set to the
value configured for the endpoint.
Review: https://reviewboard.asterisk.org/r/3724/
ASTERISK-24000 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Holding a reference to the peer during mwi subscriptions
resulted in a circular reference because the final event
message would not be sent until destruction of the peer.
Instead, pass the name of the peer to the event callback
so that it can fail gracefully after the peer has gone.
ASTERISK-23959
Review: https://reviewboard.asterisk.org/r/3754/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.
* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.
* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.
* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.
AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3720/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The dtls_perform_handshake function was mistakenly placed under the guards for
USE_PJPROJECT. If PJPROJECT was not installed, the function would not be
defined, while other functions would attempt to still use it. This prevented
res_rtp_asterisk from being loaded.
ASTERISK-24001 #close
Reported by: Don Fanning
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two bugs:
1. When originating a channel into a Stasis application, we already create a
subscription for the channel that is going into our Stasis app.
Unfortunately, when you create a Local channel and pass it off to a Stasis
app, you really aren't creating just one channel: you're creating two. This
patch snags the second half of the Local channel pair (assuming it is a
Local channel pair, but luckily core_local is kind about such assumptions)
and subscribes to it as well.
2. Subscriptions are a bit sticky right now. If a subscription is made, the
'interest' count gets bumped on the Stasis subscription - but unless
something explicitly unsubscribes the channel, said subscription sticks
around. This is not much of a problem is a user is creating the subscription
- if they made it, they must want it. However, when we are creating
implicit subscriptions, we need to make sure something clears them out.
This patch takes a pessimistic approach: it watches the cache updates
coming from Stasis and, if we notice that the cache just cleared out an
object, we delete our subscription object. This keeps our ao2 container of
Stasis forwards in an application from growing out of hand; it also is a
bit more forgiving for end users who may not realize they were supposed to
unsubscribe from that channel that just hung up.
Review: https://reviewboard.asterisk.org/r/3710/
ASTERISK-23939 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.
It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.
The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.
This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.
Review: https://reviewboard.asterisk.org/r/3690/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@418071 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.
Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP. It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed. This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.
NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.
The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.
This commit is a merge of the two patches indicated below.
ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
pri-4.diff (license #6302) patch uploaded by Pavel Troller
jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett
Review: https://reviewboard.asterisk.org/r/3633/
........
Merged revisions 417956 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417957 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Removed some incorrect newlines on ast_http_error() messages in
manager.c.
* Removed an incorrect newline in res_ari_channels.c.
Addendum to ASTERISK-23552
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.
* Add http.conf session_keep_alive option to enable persistent
connections.
* Parse and discard optional chunked body extension information and
trailing request headers.
* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k. The previous
1k was kind of small.
* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function. manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()
* Add missing va_end() in ast_ari_response_error().
* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().
ASTERISK-23552 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3691/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The variables body parameter under the originate and originate with id
operations of the channel resource showed invalid JSON in its description.
The variables body parameter under the userEvent operation of the event
resource made no mention that the custom key/value pairs should be wrapped
in a variables key in order to be added to the custom user event.
ASTERISK-23975 #close
Review: https://reviewboard.asterisk.org/r/3692/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@417878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
