Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line
Minor performance bump by not allocate manager variable struct if we don't need it
........
r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines
Stasis performance improvements
This patch addresses several performance problems that were found in
the initial performance testing of Asterisk 12.
The Stasis dispatch object was allocated as an AO2 object, even though
it has a very confined lifecycle. This was replaced with a straight
ast_malloc().
The Stasis message router was spending an inordinate amount of time
searching hash tables. In this case, most of our routers had 6 or
fewer routes in them to begin with. This was replaced with an array
that's searched linearly for the route.
We more heavily rely on AO2 objects in Asterisk 12, and the memset()
in ao2_ref() actually became noticeable on the profile. This was
#ifdef'ed to only run when AO2_DEBUG was enabled.
After being misled by an erroneous comment in taskprocessor.c during
profiling, the wrong comment was removed.
Review: https://reviewboard.asterisk.org/r/2873/
........
r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines
Taskprocessor optimization; switch Stasis to use taskprocessors
This patch optimizes taskprocessor to use a semaphore for signaling,
which the OS can do a better job at managing contention and waiting
that we can with a mutex and condition.
The taskprocessor execution was also slightly optimized to reduce the
number of locks taken.
The only observable difference in the taskprocessor implementation is
that when the final reference to the taskprocessor goes away, it will
execute all tasks to completion instead of discarding the unexecuted
tasks.
For systems where unnamed semaphores are not supported, a really
simple semaphore implementation is provided. (Which gives identical
performance as the original taskprocessor implementation).
The way we ended up implementing Stasis caused the threadpool to be a
burden instead of a boost to performance. This was switched to just
use taskprocessors directly for subscriptions.
Review: https://reviewboard.asterisk.org/r/2881/
........
r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines
Optimize how Stasis forwards are dispatched
This patch optimizes how forwards are dispatched in Stasis.
Originally, forwards were dispatched as subscriptions that are invoked
on the publishing thread. This did not account for the vast number of
forwards we would end up having in the system, and the amount of work it
would take to walk though the forward subscriptions.
This patch modifies Stasis so that rather than walking the tree of
forwards on every dispatch, when forwards and subscriptions are changed,
the subscriber list for every topic in the tree is changed.
This has a couple of benefits. First, this reduces the workload of
dispatching messages. It also reduces contention when dispatching to
different topics that happen to forward to the same aggregation topic
(as happens with all of the channel, bridge and endpoint topics).
Since forwards are no longer subscriptions, the bulk of this patch is
simply changing stasis_subscription objects to stasis_forward objects
(which, admittedly, I should have done in the first place.)
Since this required me to yet again put in a growing array, I finally
abstracted that out into a set of ast_vector macros in
asterisk/vector.h.
Review: https://reviewboard.asterisk.org/r/2883/
........
r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines
Remove dispatch object allocation from Stasis publishing
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
........
Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
........
Merged revisions 399939 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399962 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399976 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
........
Merged revisions 399794 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399795 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 399796 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399797 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
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
If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397756 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397757 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 397758 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 397759 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397710 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397711 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 397712 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 397713 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397753 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds pass through support for Opus and VP8. That includes:
* Format attribute negotiation for Opus. Note that unlike some other codecs,
the draft RFC specifies having spaces delimiting the attributes in addition
to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in
chan_sip, so a small tweak was also included in this patch for that.
* A format attribute negotiation module for Opus, res_format_attr_opus
* Fast picture update for VP8. Since VP8 uses a different RTCP packet number
than FIR, this really is specific to VP8 at this time.
Note that the format attribute negotiation in res_pjsip_sdp_rtp was written
by mjordan. The rest of this patch was written completely by Lorenzo Miniero.
Review: https://reviewboard.asterisk.org/r/2723/
(closes issue ASTERISK-21981)
Reported by: Tzafrir Cohen
patches:
asterisk_opus+vp8_passthrough_20130718.patch uploaded by lminiero (License 6518)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a From header on an outbound out-of-call SIP MESSAGE were
malformed, the result could crash Asterisk.
In addition, if a From header on an incoming out-of-call SIP
MESSAGE request were malformed, the message was happily accepted
rather than being rejected up front. The incoming message path
would not result in a crash, but the behavior was bad nonetheless.
(closes issue ASTERISK-22185)
reported by Zhang Lei
........
Merged revisions 397254 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP_CODEC family of variables let you set the preferred codec to be
offered on an outbound INVITE request. However, for video calls, you need to
be able to set both the audio and video codecs to be offered. This patch lets
the SIP_CODEC variables accept a comma delineated list of codecs. The first
codec in the list is set as the preferred codec; additional codecs are still
offered however.
This lets a dialplan writer set both audio and video codecs, e.g.,
Set(SIP_CODEC=ulaw,h264)
Note that this feature was written by both Dennis Guse and Frank Haase
Review: https://reviewboard.asterisk.org/r/2728
(closes issue ASTERISK-21976)
Reported by: Denis Guse
Tested by: mjordan, sysreq
patches:
patch-channels-chan__sip.c-393919 uploaded by dennis.guse (license 6513)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
........
Merged revisions 397204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397205 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.
(closes issue ASTERISK-22212)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2753/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
........
Merged revisions 396240 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396248 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396253 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 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
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 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 makes it so that all registration attempts that fail that
also permanently modify the registration state will raise an appropriate
AMI event.
Note that this patch was forward ported to trunk and the Stasis Core
message bus by mjordan.
(closes issue ASTERISK-21368)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Demon (license 6479)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395907 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 introduces DTLS-SRTP support to chan_pjsip and the options
necessary to configure it including an option to allow choosing between
32 and 80 byte SRTP tag lengths.
During the implementation and testing of this patch, three other bugs
were found and their fixes are included with this patch. The two in
chan_sip were a segfault relating to DTLS setup and mistaken call
rejection. The third bug fix prevents chan_pjsip from attempting to
perform bridge optimization between two endpoints if either of them is
running any form of SRTP.
Review: https://reviewboard.asterisk.org/r/2683/
(closes issue ASTERISK-21419)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Temporary peers do not have an associated Stasis endpoint and quite a
bit of code in chan_sip assumes that all peers have a Stasis endpoint.
All endpoint accesses in chan_sip are now wrapped in an endpoint
NULL-check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Instead of formatting a NULL pointer into a "%s" format string (which is
usually not a good thing to do), we instead print "Unknown".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a misunderstanding about ast_bridge_impart()'s handling of the
imparted channel's reference. The channel reference is passed by the
caller unless ast_bridge_impart() returns an error.
* Fixed a memory leak in conf_announce_channel_push() if the impart
failed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support
Thanks everyone!
Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 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
Features configuration is handled in its own API in
features_config.h and features_config.c. This way, features
configuration is accessible to anything that needs it.
In addition, features configuration has been altered to
be more channel-oriented. Most callers of features API
code will be supplying a channel so that the individual
channel's settings will be acquired rather than the global
setting.
Missing from this commit is XML documentation for the
features configuration. That will be handled in a separate
commit.
Review: https://reviewboard.asterisk.org/r/2578/
(issue ASTERISK-21542)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
