It looks like we're not properly calculating jitter values on received
video streams. This patch enables the code that does jitter calculations
for those streams.
Change-Id: Iaac985808829c8f034db8c57318789c4c8c11392
If Realtime @ variable value is NULL or empty or contains only whitespaces
then when we try to retrieve it using PJSIP_ENDPOINT we get WARNING
pjsip_endpoint_function_read: Unknown property @my_var for PJSIP endpoint.
And the variable is missing in the result of CLI pjsip show endpoint.
This patch keeps empty sorcery extended field.
ASTERISK-28341 #close
Change-Id: I221fccc04cbfa2be17ce971f64ae0e74e465eea0
Because StasisEnd's timestamp created it's own timestamp, it makes
wrong timestamp, compare to other channel event(ChannelDestroyed).
Fixed to getting a timestamp from the Channel's timestamp.
ASTERISK-28333
Change-Id: I5eb8380fc472f1100535a6bc4983c64767026116
As part of an earlier voicemail refactor, ast_delete_mwi_state_full
was modified to remove the pool topic for a mailbox when the state
was deleted. This was an attempt to prevent stale topics from
accumulating when app_voicemail was reloaded and a mailbox went
away. Unfortunately because of the fact that when app_voicemail
reloads, ALL mailboxes are deleted then only current ones recreated,
topics were being removed from the pool that still had subscribers
on them, then recreated as new topics of the same name. So now
modules like res_pjsip_mwi are listening on a topic that will
never receive any messages because app_voicemail is publishing on
a different topic that happens to have the same name. The solutiuon
to this is not easy and given that accumulating topics for
deleted mailboxes is less evil that not sending NOTIFYs...
* Removed the call to stasis_topic_pool_delete_topic in
ast_delete_mwi_state_full.
Also:
* Fixed a topic reference leak in res_pjsip_mwi
mwi_stasis_subscription_alloc.
* Added some debugging to mwi_stasis_subscription_alloc,
stasis_topic_create, and topic_dtor.
* Fixed a topic reference leak in an error path in
internal_stasis_subscribe.
ASTERISK-28306
Reported-by: Jared Hull
Change-Id: Id7da0990b3ac4be4b58491536b35f41291247b27
Changed to requirement to having timestamp for all of ARI events.
The below ARI events were changed to having timestamp.
PlaybackStarted, PlaybackContinuing, PlaybackFinished,
RecordingStarted, RecordingFinished, RecordingFailed,
ApplicationReplaced, ApplicationMoveFailed
ASTERISK-28326
Change-Id: I382c2fef58f5fe107e1074869a6d05310accb41f
Topic names now follow: <subsystem>:<functionality>[/<object>]
This ensures that they are all unique, and also provides better
insight in to what each topic is for.
Subscriber ids now also use the main topic name they are
subscribed to and an incrementing integer as their identifier to
make it easier to understand what the subscription is primarily
responsible for.
Both the CLI commands for listing topic and subscription statistics
now sort to make it a bit easier to see what is going on.
Subscriptions will now show all topics that they are receiving messages
from, not just the main topic they were subscribed to.
ASTERISK-28335
Change-Id: I484e971a38c3640f2bd156282e532eed84bf220d
Currently, when the Asterisk calculates rtp statistics, it uses
sample_count as a unsigned integer parameter. This would be fine
for most of cases, but in case of large enough number of sample_count,
this might be causing the divide by zero error.
ASTERISK-28321
Change-Id: If7e0629abaceddd2166eb012456c53033ea26249
chan_sip will always ignore 183 responses that do not contain SDP
however, chan_pjsip will currently always translate it into a
183 with SDP. This new flag allows chan_pjsip to have the same
behavior as chan_sip.
ASTERISK-28322 #close
Change-Id: If81cfaa17c11b6ac703e3d71696f259d86c6be4a
strtok() uses a static buffer, making it not thread safe.
Also add a #define to cause a compile failure if strtok is used.
Change-Id: Icce265153e1e65adafa8849334438ab6d190e541
Added the ability to move between Stasis applications within Stasis.
This can be done by calling 'move' in an application, providing (at
minimum) the channel's id and the application to switch to. If the
application is not registered or active, nothing will happen and the
channel will remain in the current application, and an event will be
triggered to let the application know that the move failed. The event
name is "ApplicationMoveFailed", and provides the "destination" that the
channel was attempting to move to, as well as the usual channel
information. Optionally, a list of arguments can be passed to the
function call for the receiving application. A full example of a 'move'
call would look like this:
client.channels.move(channelId, app, appArgs)
The control object used to control the channel in Stasis can now switch
which application it belongs to, rather than belonging to one Stasis
application for its lifetime. This allows us to use the same control
object instead of having to tear down the current one and create
another.
ASTERISK-28267 #close
Change-Id: I43d12b10045a98a8d42541889b85695be26f288a
This small feature will help to checking the bridge's status to
figure out which bridge is in old/zombie or not. Also added
detail items for the 'bridge show *' cli to provide more detail
info. And added creation item to the ARI as well.
ASTERISK-28279
Change-Id: I460238c488eca4d216b9176576211cb03286e040
PJSIP assumes that these header names are not allocated, and does not
clone the name strings when reusing headers.
Block unload of res_pjsip_diversion until shutdown to ensure static
memory stays valid.
ASTERISK-28312 #close
Change-Id: Ibd6ea55ec4a604bbd43ac07f8d0b54da2c39b8b9
Rather than calling ast_odbc_find_table() in the prepare callback, call
it beforehand and pass it in to the callback to avoid the need for a
second connection.
ASTERISK-28166 #close
Change-Id: I6f8a0b9990d636fd6bc1a92ed70f7050d2436202
apply_negotiated_sdp_stream was returning a "1" when no joint
capabilities were found on an outgoing call instead of a "-1".
This indicated to res_pjsip_session that the handler DID handle
the sdp when in fact it didn't. Without the appropriate setup,
a subsequent media frame coming in would have an invalid stream_num
and cause a seg fault when the stream was attempted to be retrieved.
apply_negotiated_sdp_stream now returns the correct "-1" and any
media is now discarded before it reaches the core stream processing.
ASTERISK-28260
Reported by: Sotiris Ganouris
Change-Id: Ia095cb16b4862f2f6ad6d2d2a77453fa2542371f
This reverts commit d524ad523d.
Reason for revert: This causes Contact and Via headers to have the wrong
transport address.
ASTERISK-28309 #close
Change-Id: Ibba4d6176f68e39279fcd9a545f81d56e747bed8
If both send_registrations and send_auth are both set to yes,
outbound_auth/username must be set or we crash.
ASTERISK-27992 #close
Change-Id: I6418d56de1ae53f80393b314c2584048fbf7f11d
When a contact was removed by the registrar it did not always check to see if
the circumstances involved a monitored reliable transport. For instance, if the
'remove_existing' option was set to 'true' then when existing contacts were
removed due to 'max_contacts' being reached, those existing contacts being
removed did not unregister the transport monitor.
Also, it was possible to add more than one monitor on a reliable transport for
a given aor and contact.
This patch makes it so all contact removals done by the registrar also remove
any associated transport monitors if necessary. It also makes it so duplicate
monitors cannot be added for a given transport.
ASTERISK-28213
Change-Id: I94b06f9026ed177d6adfd538317c784a42c1b17a
This module allows presence subscriptions to voicemail boxes. This
allows common BLF keys to act as voicemail waiting indicators.
ASTERISK-28301
Change-Id: I62a246c24f3d7d432e33e22d7a4a57c15c292fdd
Delivery timeval in the smoother object will fall behind while a DTMF is
being generated. This can eventually lead to invalid rtp timestamps.
To prevent this from happening the smoother needs to be reset after every
DTMF to keep the timing up to date.
ASTERISK-28303 #close
Change-Id: Iaba3f7b428ebd72a4caa90e13b829ab4f088310f
When listing the applications the apps lock was incorrectly
locked twice instead of being locked and then unlocked.
ASTERISK-28302
Change-Id: If7d064592a9e88c0f1049214c50e02be6dabf79e
When processing SSRC attributes we were iterating through
all of them, even though we only need to know the remote
SSRC once. This was problematic because some browsers group
SSRCs together on a stream, and due to our negotiation only
end up using the first one. Since we set the second one as
the remote SSRC we would drop the received media from them
instead of allowing it through.
In the future this may be extended to allow SSRC groups
and to use information from the attributes.
Change-Id: I4dc87087dbe56a83aa65f0f897bbd4ca75ec1270
To prevent one subsystem's taskprocessors from causing others
to stall, new capabilities have been added to taskprocessors.
* Any taskprocessor name that has a '/' will have the part
before the '/' saved as its "subsystem".
Examples:
"sorcery/acl-0000006a" and "sorcery/aor-00000019"
will be grouped to subsystem "sorcery".
"pjsip/distributor-00000025" and "pjsip/distributor-00000026"
will bn grouped to subsystem "pjsip".
Taskprocessors with no '/' have an empty subsystem.
* When a taskprocessor enters high-water alert status and it
has a non-empty subsystem, the subsystem alert count will
be incremented.
* When a taskprocessor leaves high-water alert status and it
has a non-empty subsystem, the subsystem alert count will be
decremented.
* A new api ast_taskprocessor_get_subsystem_alert() has been
added that returns the number of taskprocessors in alert for
the subsystem.
* A new CLI command "core show taskprocessor alerted subsystems"
has been added.
* A new unit test was addded.
REMINDER: The taskprocessor code itself doesn't take any action
based on high-water alerts or overloading. It's up to taskprocessor
users to check and take action themselves. Currently only the pjsip
distributor does this.
* A new pjsip/global option "taskprocessor_overload_trigger"
has been added that allows the user to select the trigger
mechanism the distributor uses to pause accepting new requests.
"none": Don't pause on any overload condition.
"global": Pause on ANY taskprocessor overload (the default and
current behavior)
"pjsip_only": Pause only on pjsip taskprocessor overloads.
* The core pjsip pool was renamed from "SIP" to "pjsip" so it can
be properly grouped into the "pjsip" subsystem.
* stasis taskprocessor names were changed to "stasis" as the
subsystem.
* Sorcery core taskprocessor names were changed to "sorcery" to
match the object taskprocessors.
Change-Id: I8c19068bb2fc26610a9f0b8624bdf577a04fcd56
Event type filtering is now enabled, and configurable per application. An app is
now able to specify which events are sent to the application by configuring an
allowed and/or disallowed list(s). This can be done by issuing the following:
PUT /applications/{applicationName}/eventFilter
And then enumerating the allowed/disallowed event types as a body parameter.
ASTERISK-28106
Change-Id: I9671ba1fcdb3b6c830b553d4c5365aed5d588d5b
p2p_write updates txformat but doesn't require a smoother. If a smoother
was created by another bridge type the smoother could fall out of date causing
one way audio issues. To prevent this the smoother is now destroyed on the
start of native bridge.
ASTERISK-28284 #close
Change-Id: I84e67f144963787fff9b4d79ac500514fb40cdc6
Currently, the Asterisk's pjsip_session module does not keeping the
rtcp's stats info after it was removed. But by adding the results
vector and keeping it until session is destroying, it can give more
useful information for other modules.
ASTERISK-28253
Change-Id: Ib25c2d3fc4da084aecfde2a82c1b1d733bd64fa5
A previous patch attempt to mitigate blocked threads on transport shutdown for
a given contact. It was thought that a second lock could be avoided by checking
the 'removing' flag on the transport monitor twice (once before and once after
the normal named aor locking). However as with usual threading issues if the
timing was right the original problem still occured.
This patch adds locking around the first 'removing' flag check and set, thus
nullifying the secondary check, so it was removed.
ASTERISK-28213
Change-Id: Iaa8e36e5311789549b76d8de42dfcea96013b2ed
When Asterisk is connected and used with a database the response
time of the database can cause problems in Asterisk if it is long.
Normally the only way to see this problem would be to retrieve a
backtrace from Asterisk and examine where things are blocked, or
examine the database to see if there is any indication of a
problem.
This change adds some basic query logging to make it easier to
investigate such a problem. When logging is enabled res_odbc will
now keep track of the number of queries executed, as well as the
query that has taken the longest time to execute. There is also
an option which will cause a WARNING message to be output if a
query takes longer than a configurable amount of time to execute.
This makes it easier and clearer for users that their database may
be experiencing a problem that could impact Asterisk.
ASTERISK-28277
Change-Id: I173cf4928b10754478a6a8c27dfa96ede0f058a6
Matthew Fredrickson
George Joseph
Friendly Automation
Alexei Gradinari
sungtae kim
Joshua C. Colp
Sean Bright
Torrey Searle
Ben Ford
Kevin Harwell