This patch adds a module that emits StatsD statistics about Asterisk
endpoints. This includes:
* A GUAGE statistic for endpoint states, tracking how many endpoints are in
a particular state.
* A GUAGE statistic for each endpoint, counting the number of channels
currently associated with an endpoint.
ASTERISK-25572
Change-Id: If7e1333c5aeda8d136850b30c2101c0ee1c97305
This patch adds the ability to send StatsD statistics related to the
state of PJSIP contacts. This includes:
* A GUAGE statistic measuring the count of contacts in a particular state.
This measures how many contacts are reachable, unreachable, etc.
* The RTT time for each contact, if those contacts are qualified. This
provides StatsD engines useful time-based data about each contact.
ASTERISK-25571
Change-Id: Ib8378d73afedfc622be0643b87c542557e0b332c
This patch adds outbound registration statistics for StatsD. This includes
the following:
* A GUAGE metric for the overall count of outbound registrations.
* A GUAGE metric for each state an outbound registration can be in. As the
outbound registrations change state, the overall count of how many
outbound registrations are in the particular state is changed.
These statistics are particularly useful for systems with a large number of
SIP trunks, and where measuring the change in state of the trunks is useful
for monitoring.
ASTERISK-25571
Change-Id: Iba6ff248f5d1c1e01acbb63e9f0da1901692eb37
When Asterisk is configured to use a dynamic sorcery backend (such as
res_sorcery_astdb) with 'registration' objects, it will fail to create the
internal state objects associated with the registration objects on module
load. This is due to nothing actually querying for the specific objects
and calling their sorcery apply handler during module load.
This patch fixes that by calling get_registrations in the sorcery observer's
object_type_loaded handler. Doing this causes the sorcery backends to be
asked for the current state of all registration objects, which causes the
apply handler to be called and the internal run-time state to be created.
ASTERISK-25575 #close
Change-Id: Ie9306e797098c6d4da7bcf4a5434a15891508b23
Previously, a trancoding module did not have access to the joint but cached
format. Therefore, the module did not have access to the attributes negotiated
via SDP (line fmtp). Now, a translation module receives the joint format.
ASTERISK-25545 #close
Change-Id: Id6878a989b50573298dab115d3371ea369e1a718
When no parameter is present, Asterisk does not generate the line fmtp, as
expected. However, because a buffer was reset, even rtpmap and fmtp of previous
media codecs got removed. Now, Asterisk does not reset other codecs in case of
no parameter for H.264.
ASTERISK-25573 #close
Change-Id: I93811331f4a28c45418a9e14ee46c0debd47a286
Often, the metric names of statistics we are generating for StatsD have some
dynamic component to them. This can be the name of a particular resource, or
some internal status label in Asterisk. With the current set of functions,
callers of the statsd API must first build the metric name themselves, then
pass this to the API functions. This results in a large amount of boilerplate
code and usage of either fixed length static buffers or dynamic memory
allocation, neither of which is desireable.
This patch adds two new functions to the StatsD API that support a printf
style format specifier for constructing the metric name. A dynamic string,
allocated in threadstorage, is used to build the metric name. This eases
the burden on users of the StatsD API.
Change-Id: If533c72d1afa26d807508ea48b4d8c7b32f414ea
Receiving a 423 Interval Too Brief response after authentication for an
outbound registration attempt results in assuming that the registrar has
rejected the registration permanently. If there are no configured retries
for fatal responses then the outbound registration is stopped for that
endpoint.
For registrations, PJSIP/PJPROJECT intercepts the handling of 423
responses and does not include any authentication in the updated
registration request. When the updated request is challenged then the
Asterisk code assumes that we were challenged again because the peer
rejected the authentication we sent earlier.
* Made registration challenges keep track of the CSeq number to determine
if the received challenge response was for the request we thought we sent.
If the response's CSeq number differs from the CSeq number we last sent
with authentication then authenticate again because it is a challenge to a
different request.
Change-Id: I81b4bd36d1be095bab606e34b8b44e6302971b09
Added a new api to res_statsd.c to allow it to receive a
character pointer for the value argument. This allows for a
'+' and a '-' to easily be sent with the value.
ASTERISK-25419
Reported By: Ashley Sanders
Change-Id: Id6bb53600943d27347d2bcae26c0bd5643567611
When a request is sent using pjsip_endpt_send_request and fails, a condition
exists where the request wrapper, which is an AO2 object, may be de-ref'd
more times than it should. This occurs when the request's callback is called,
and, in the callback, the timer on the PJSIP heap is cancelled. When that
occurs, the request wrapper's lifetime is decremented. When
pjsip_endpt_send_request fails, we unilaterally decrement the lifetime of
the request wrapper again, even though we've already cancelled the reference
associated with the timer.
This patch checks the return result of pj_timer_heap_cancel_if_active before
removing the reference associated with the timer. We now only decrement it
in this case if a timer is cancelled as a result of the function call.
Change-Id: I21332343a1a019c1117076f9bf2df27be2850102
This option adds the ability to specify a timeout, in seconds, for a
participant in a ConfBridge. When the user's timeout has been reached,
the user is ejected from the conference with the CONFBRIDGE_RESULT
channel variable set to "TIMEOUT".
The rationale for this change is that there have been times where we
have seen channels get "stuck" in ConfBridge because a network issue
results in a SIP BYE not being received by Asterisk. While these
channels can be hung up manually via CLI/AMI/ARI, adding some sort of
automatic cleanup of the channels is a nice feature to have.
ASTERISK-25549 #close
Reported by Mark Michelson
Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98
The hashtab API is pretty NULL tolerant which has resulted
in remaining callers not doing much checks themselves.
Unfortunately the function to destroy an iterator does not
do a NULL check and will result in a crash if passed NULL.
This change fixes that.
ASTERISK-25552 #close
Change-Id: Ic1bf8eec3639e5a440f1c941d3ae3893ac6ed619
If an authenticated incoming caller does not respond to our 200 OK INVITE
response with an ACK then PJSIP will hangup the call. Unfortunately,
there is a chance that the session's channel will go away between one use
of the channel pointer and another when building the BYE request because
the BYE is being built by the monitor thread and not the call's serializer
thread.
* Added a check to ensure that the thread trying to add the Reason header
is the call's serializer thread. This ensures that the channel will not
go away on us.
Change-Id: I866388d2b97ea2032eaae3f3ab3f1ca6cbd2df89
In practical tests, we have seen certain taskprocessors, specifically
Stasis subscription taskprocessors, cross the recently-added high-water
mark and emit a warning. This high-water mark warning is only intended
to be emitted when things have tanked on the system and things are
heading south quickly. In the practical tests, the Stasis taskprocessors
sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in
any danger at all.
As such, this ups the high-water mark to 500 tasks instead. It also
redefines the SIP threadpool request denial number to be a multiple of
the taskprocessor high-water mark.
Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce
In Asterisk 13, cached formats are created before their corresponding format-
attribute module is registered. Cached formats are involved when a local
extension is called. Therefore, ast_format_generate_sdp_fmtp did not work
on local extensions. This change affects the Opus Codec, H.263 (Plus), H.264,
and format-attribute modules provided externally.
ASTERISK-25160 #close
Change-Id: I1ea1f0483e5261e2a050112e4ebdfc22057d1354
When the SIP threadpool is backed up with tasks, we send 503 responses
to ensure that we don't try to overload ourselves. The problem is that
we were not insuring that we were not trying to send a 503 to an
incoming SIP response.
This change makes it so that we only send the 503 on incoming requests.
Change-Id: Ie2b418d89c0e453cc6c2b5c7d543651c981e1404
We have observed situations where the SIP threadpool may become
deadlocked. However, because incoming traffic is still arriving, the SIP
threadpool's queue can continue to grow, eventually running the system
out of memory.
This change makes it so that incoming traffic gets rejected with a 503
response if the queue is backed up too much.
Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816
When appending all formats of a type all the codecs are iterated
and added. This operation was incorrectly adding the ast_format_none
format which is special in that it is supposed to be used when no
format is present. It shouldn't be appended.
ASTERISK-25535
Change-Id: I7b00f3bdf4a5f3022e483d6ece602b1e8b12827c
When ASTERISK-25449 was closed, a number of scheduler issues mentioned in
the comments were missed. These have since beed raised in ASTERISK-25476
and elsewhere.
This patch attempts to collect all of the scheduler issues discovered so
far and address them sensibly.
ASTERISK-25476 #close
Change-Id: I87a77d581e2e0d91d33b4b2fbff80f64a566d05b
This change adds handling of dead worker threads when moving them
to be active. When this happens the worker thread is removed from
both the active and idle threads container. If no threads are able
to be moved to active then the pool grows as configured.
A unit test has also been added which thrashes the idle timeout
and thread activation to exploit any race conditions between the
two.
ASTERISK-25546 #close
Change-Id: I6c455f9a40de60d9e86458d447b548fb52ba1143
Previously, format-attribute modules relied on an existing fmtp line in SDP
negotiation. However, fmtp is optional for several formats like the Opus Codec.
Now, the format-attribute module is called with an empty fmtp, which allows the
module to initialise itself to RFC defaults. Furthermore now, Asterisk is able
to differentiate between internally and externally created formats.
ASTERISK-25537 #close
Change-Id: I28f680cef7fdf51c0969ff8da71548edad72ec52
Since Asterisk 13, formats are immutable and cached. However while loading a
module like chan_sip, some formats were created instead using cached ones.
ASTERISK-25535 #close
Change-Id: I479cdc220d5617c840a98f3389b3bd91e91fbd9b
CALLERPRES() says that it's deprecated in favor of CALLERID(num-pres)
and CALLERID(name-pres). But for channel driver that don't make a
distinction between the two (e.g. SIP), it makes more sense to get/set
both at once. This change reveals the availability of CALLERID(pres),
CONNECTEDLINE(pres), REDIRECTING(orig-pres), REDIRECTING(to-pres) and
REDIRECTING(from-pres).
ASTERISK-25373 #close
Change-Id: I5614ae4ab7d3bbe9c791c1adf147e10de8698d7a
Previously, the wrapping did both lookahead and lookback, which,
together with color escape sequences, caused some lines to be wrapped
way earlier than other lines. This led to inconsistent output.
This simplifies the wrapping code and makes it more sane: if maxcolumns
is hit, we simply jump back to the last space and wrap there.
ASTERISK-25527 #close
Change-Id: I56d01c6f9a812642b1b05535c98d4db48d17c957
In SIP/SDP, Opus has two channels always (see RFC 7587 section 7). The actual
amount of channels is negotiated in-band. Therefore now, the Opus codec and its
attribute rtpmap are registered with two channels.
ASTERISK-24779 #close
Reported by: PowerPBX
Tested by: Alexander Traud
patches:
asterisk-24779.patch submitted by Sean Bright (license #5060)
Change-Id: Ic7ac13cafa1d3450b4fa4987350924b42cbb657b
If a taskprocessor's queue grows large, this can indicate that there
may be a problem with tasks not leaving the processor or else that
the number of available task processors for a given type of task is
too low. This patch makes it so that if a taskprocessor's task queue
grows above 100 queued tasks that it will emit a warning message.
Warning messages are emitted only once per task processor.
ASTERISK-25518 #close
Reported by: Jonathan Rose
Change-Id: Ib1607c35d18c1d6a0575b3f0e3ff5d932fd6600c
When a dial attempt is made that involves a requesting channel, we previously
were not:
a) Protecting access to the native format capabilities structure on the
requesting channel. That is inherently unsafe.
b) Reference bumping the lifetime of the format capabilities structure.
In both cases, something else could sneak in, blow away the format
capabilities, and we'd be holding onto an invalid format_cap structure. When
the newly created channel attempts to construct its format capabilities, things
go poorly.
This patch:
a) Ensures that we get a reference to the native format capabilities while
the requesting channel is locked
b) Holds a reference to the native format capabilities during the creation
of the new channel.
ASTERISK-25522 #close
Change-Id: I0bfb7ba8b9711f4158cbeaae96edf9626e88a54f
A previous commit reduced the AST_BUILDOPTS compiler define to
only include options that affected ABI. This included some options
that were previously displayed by cli "core show settings". This
change corrects the CLI display while still restricting buildopts.h
to ABI effecting options only.
ASTERISK-25434 #close
Reported by: Rusty Newton
Change-Id: Id07af6bedd1d7d325878023e403fbd9d3607e325
The contact_status Sorcery objects are currently not destroyed when a contact
is deleted. This causes the contact's last known RTT/status to be 'sticky'
when the contact itself may no longer exist. This patch causes the
contact_status objects associated with both dynamic and static contacts to
be destroyed if the AoR holding those contacts is also destroyed (or via
other paths where a contact may be deleted.)
Change-Id: I7feec8b9278cac3c5263a4c0483f4a0f3b62426e
When an endpoint is deleted (such as through an API), the persistent endpoint
currently continues to lurk around. While this isn't harmful from a memory
consumption perspective - as all persistent endpoints are reclaimed on
shutdown - it does cause Stasis endpoint related operations to continue
to believe that the endpoint may or may not exist.
This patch causes the persistent endpoint related to a PJSIP endpoint to be
destroyed if the PJSIP endpoint is deleted.
Change-Id: I85ac707b4d5e6aad882ac275b0c2e2154affa5bb
