This patch adds a new module, res_pjsip_history, that provides a slightly
better way of debugging SIP message traffic on a busy Asterisk system. The
existing mechanisms all rely on passively dumping a SIP message to the CLI.
While this is perfectly fine for logging purposes and well controlled
environments, on many installations, the amount of SIP messages Asterisk
receives will quickly swamp the CLI. This makes it difficult to view/capture
those messages that you want to diagnose in real time.

This patch provides another way of handling this. When enabled, the module
will store SIP message traffic in memory. This traffic can then be queried
at leisure.

In order to make the querying useful, a CLI command has been implemented,
'pjsip show history', that supports a basic expression syntax similar to
SQL or other query languages. A small number of useful fields have been
added in this initial patch; additional fields can easily be added in
later improvements. Those fields are:
 - number: The entry index in the history
 - timestamp: The time the message was recieved
 - addr: The source/destination address of the message
 - sip.msg.request.method: The request method
 - sip.msg.call-id: The Call-ID header

Note - this is a resurrection of the module initially proposed on Review Board
here: https://reviewboard.asterisk.org/r/4053/

Change-Id: I39bd74ce998e99ad5ebc0aab3e84df3a150f8e36

Change-Id: I9d88fac0394d5bbaff0900a2ee911c4e4478846b

In 450579e9, a change was made that removed the deletion of the
'contact_status' object when a 'contact' object is deleted in sorcery.
This unfortunately means that the 'contact_status' object persists, even when
something has explicitly removed a contact. The result is that the state of
the contact will not be regenerated if that contact is re-created, and the
stale state will be reported/used for that contact. It also results in
no ContactStatusChanged events being generated for either ARI or AMI.

This patch restores the deletion logic that was removed. Doing so now
results in the expected events being generated again.

Change-Id: I28789a112e845072308b5b34522690e3faf58f07

Change-Id: I19b49112e1b630bd04e859f14ccf96f8ebd6b151

Resolves an edge case dtls negotiation delay for certain networks which
somehow manage to drop the rtcp side's packet when these are both sent
ast_rtp_remote_address_set, causing it to have to time-out and restart
the handshake.

Move dtls pending bio flush in to it's own function, and call it from
ast_rtp_on_ice_complete, when we're rtp->ice, rather than when
ast_rtp_remote_address_set.

Keep the existing flush from the recent change to res_rtp_remote_address_set
if ice is not being used.

ASTERISK-25614 #close
Reported-by: XenCALL
Tested by: XenCALL

Change-Id: Ie2caedbdee1783159f375589b6fd3845c8577ba5

This change introduces the configuration option 'full_backend_cache'
which changes the cache to be a full mirror of the backend instead
of a per-object cache. This allows all sorcery retrieval operations
to be carried out against it and is useful for object types which
are used in a "retrieve all" or "retrieve some" pattern.

ASTERISK-25625 #close

Change-Id: Ie2993487e9c19de563413ad5561c7403b48caab5

The JSON library Asterisk uses, jansson, is not thread
safe for us in a few ways. To help with this wrappers for JSON
object reference count increasing and decreasing were added
which use a global lock to ensure they don't clobber over
each other. This does not extend to reference count manipulation
within the jansson library itself. This means you can't safely
use the object borrowing specifier (O) in ast_json_pack and
you can't share JSON instances between objects.

This change removes uses of the O specifier and replaces them
with the o specifier and an explicit ast_json_ref. Some cases
of instance sharing have also been removed.

ASTERISK-25601 #close

Change-Id: I06550d8b0cc1bfeb56cab580a4e608ae4f1ec7d1

- Trigger pending DTLS packets to send out, once the RTP instance's remote
  address is set.
- Avoids locking the DTLS structure unnecessarily by only doing this if
  DTLS is passive.
- Add DTLS locks around the structurally sensitive calls in the SSL
  portion of __rtp_recvfrom, since dtls_srtp_check_pending does not lock
  inside of itself, and we're dealing with the SSL BIO in at least two
  threads.

WebRTC channels may receive a DTLS handshake before
ast_rtp_remote_address_set is called, which causes there to be a pending
response to send out.   Previous to 1ad827, this was handled by calling
dtls_srtp_check_pending on receipt of any RTP packet - a STUN or RTP
packet could trigger the pending handshake response.  Since that was
rightfully removed, whenever the DTLS handshake is received before the
remote address is set, we would have to wait until another SSL packet
arrives.

As of Chrome M47's optimizations to their handshake process, WebRTC
conversations between Chrome M47+ and Asterisk, where Asterisk is passive,
experience a 1 second delay without this patch, because the SSL handshake
is received before ICE negotation stores the remote_address, and the next
SSL packet isn't received until after a 1 second timeout in Chrome, which
causes a new handshake request.

ASTERISK-25614 #close

Change-Id: I547f1be7e302dbf71f6553dd8cbc0657b1d0b908

pjproject < 2.5.0 will segfault on a tls transport if async_operations
is greater than 1.  A runtime version check has been added to throw
an error if the version is < 2.5.0 and async_operations > 1.

To assist in the check, a new api "ast_compare_versions" was added
to utils which compares 2 major.minor.patch.extra version strings.

ASTERISK-25615 #close

Change-Id: I8e88bb49cbcfbca88d9de705496d6f6a8c938a98
Reported-by: George Joseph
Tested-by: George Joseph

Fixed a bug that originally would show a negative number of
active calls occuring in Asterisk. A gauge is persistent so
incrementing and decrementing it results in a more consistent
performance. Also changed to the call to StatsD to use
ast_statsd_log_string() so that a "+" could be sent to StatsD.

ASTERISK-25619 #close

Change-Id: Iaaeff5c4c6a46535366b4d16ea0ed0ee75ab2ee7

Both transport and endpoint now check for the existence and readability
of tls certificate and key files before passing them on to pjproject.
This will cause the object to not load rather than waiting for pjproject
to discover that there's a problem when a session is attempted.

NOTE: chan_sip also uses ast_rtp_dtls_cfg_parse but it's located
in build_peer which is gigantic and I didn't want to disturb it.
Error messages will emit but it won't interrupt chan_sip loading.

ASTERISK-25618 #close

Change-Id: Ie43f2c1d653ac1fda6a6f6faecb7c2ebadaf47c9
Reported-by: George Joseph
Tested-by: George Joseph

See ASTERISK-25615.
If the transport protocol is tls and async_operations > 1, pjproject
will segfault if more than one operation is attempted on the same socket.
Until this is fixed upstream, a check has been added to throw an error
if a tls transport config has async_operations set to > 1.

ASTERISK-25615

Change-Id: I76b9a5b2a5a0054fe71ca5851e635f2dca7685a6
Reported-by: George Joseph
Tested-by: George Joseph

It will never be perfect or even pretty, mostly because of the differences
between static and dynamic contacts.

Created:

Can't use the contact or contact_status alloc functions
because the objects come and go regardless of the actual state.

Can't use the contact_apply_handler, ast_sip_location_add_contact or
a sorcery created handler because they only get called for dynamic
contacts.  Similarly, permanent_uri_handler only gets called for
static contacts.

So, Matt had it right. :)  ast_res_pjsip_find_or_create_contact_status is
the only place it can go and not have duplicated code.  Both
permanent_uri_handler and contact_apply_handler call find_or_create.

Removed:

Can't use the destructors for the same reason as above.  The only
place to put this is in persistent_endpoint_contact_deleted_observer
which I believe is the "correct" place but even that will handle only
dynamic contacts.  This doesn't called on shutdown however.  There is
no hook to use for static contacts that may be removed because of a
config change while asterisk is in operation.

I moved the cleanup of contact_status from ast_sip_location_delete_contact
to the handler as well.

Status Change and RTT:

Although they worked fine where they were (in update_contact_status) I
moved them to persistent_endpoint_contact_status_observer to make it
more consistent with removed.  There was logic there already to detect
a state change.

Finally, fixed a nit in permanent_uri_handler rmudgett reported
eralier.

ASTERISK-25608 #close

Change-Id: I4b56e7dfc3be3baaaf6f1eac5b2068a0b79e357d
Reported-by: George Joseph
Tested-by: George Joseph

ASTERISK-25584 #close

Change-Id: Iae00071b4ff1ae76f24995aeac4d00284fd14f91

Beside that, the format-attribute module sends only non-default values in the
line fmtp, now. This avoids unnecessary overhead in SDP messages. Furthermore,
previously the parameter stereo was not parsed when being the first parameter.

ASTERISK-25583 #close

Change-Id: Iae85ba3e5960bfd5d51cf65bcffad00dd4875a73

When 90d9a707 was merged, it mostly tested dynamic contacts created as
a result of registering a PJSIP endpoint. Contacts generated in this
fashion typically have a long alphanumeric string as their object identifier,
which maps reasonably well for StatsD. Unfortunately, this doesn't work in the
general case. StatsD treats both '.' and ':' characters as special characters.
In particular, having a ':' appear in the middle of a StatsD metric will
result in the metric being rejected.

This causes some obvious issues with SIP URIs.

The StatsD API should not be responsible for escaping the metric name passed
to it. The metric is treated as a single long string, and it would be
challenging to know what to escape in the string passed to the function.
Likewise, we don't want to escape the metric in PJSIP, as that involves
overhead that is wasted when either res_statsd isn't loaded or enabled.

This patch takes an alternative approach. The Contact ID has been changed
to be "aor@@uri_hash" instead of "aor@@uri". This (a) won't contain any of the
aforementioned special characters, (b) can be done on Contact creation,
which has minimal impact on run-time performance, and (c) also conforms to an
earlier commit that changed the ID for dynamic contacts.

The downside of this is that StatsD users will have to map SHA1 hashes back to
the Contacts that are emitting the statistics. To that end, the CLI commands
have been updated to include the first 10 characters of the MD5 hash, which
should be enough to match what is shown in Graphite (or some other StatsD
backend).

ASTERISK-25595 #close

Change-Id: Ic674a3307280365b4a45864a3571c295b48a01e2
Reported-by: Matt Jordan
Tested-by: George Joseph

An earlier commit changed the id of dynamic contacts to contain
a hash instead of the uri.  This patch updates status change
logging to show the aor/uri instead of the id.  This required
adding the aor id to contact and contact_status and adding
uri to contact_status.  The aor id gets added to contact and
contact_status in their allocators and the uri gets added to
contact_status in pjsip_options when the contact_status is
created or updated.

ASTERISK-25598 #close

Reported-by: George Joseph
Tested-by: George Joseph

Change-Id: I56cbec1d2ddbe8461367dd8b6da8a6f47f6fe511

Change-Id: If83d63cf11cbc6df9b15251848b01feb570ade49

The fastagi record-file testsuite test sometimes fails reporting an empty
recorded file. This was happening because Asterisk was sending the agi result
notification prior to actually closing the file and the data, being buffered,
had not been written to the file yet when the test attempts to check the file
size.

This patch makes it so the record file stream is closed prior to sending the
agi result notification.

ASTERISK-25593 #close

Change-Id: I6b2b3be3ae37f7c7b18e672c419a89b3b8513cde

Fixes some minor typos in the CHANGES file, plus an embarrasing typo in
the StatsD API.

Change-Id: I9ca4858c64a4a07d2643b81baa64baebb27a4eb7

The usage info for 'pjsip send notify' previously referenced the
chan_sip configuration sip_notify.conf.  Fix this to reference
the correct configuration pjsip_notify.conf.

ASTERISK-25590 #close

Change-Id: I3898271a8e8a8b1db201741e790ebe2c6bf5cdea

This patch adds a module that emits StatsD statistics about Asterisk
endpoints. This includes:
 * A GAUGE statistic for endpoint states, tracking how many endpoints are in
   a particular state.
 * A GAUGE statistic for each endpoint, counting the number of channels
   currently associated with an endpoint.

ASTERISK-25572

Change-Id: If7e1333c5aeda8d136850b30c2101c0ee1c97305

If the sorcery object type is not found a NULL is returned.
Unfortunately, sorcery_realtime_filter_objectset() will crash after
complaining about not finding the object type and saying to expect errors.

* Use ao2_cleanup() instead of ao2_ref() to prevent the crash.

ASTERISK-25165
Reported by Corey Farrell

Change-Id: Ic3b64453ea3058cb68d5c26d97d4fe7b8eea2e97

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

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

When a channel is in a direct media bridge, a re-INVITE may arrive that forces
Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge
must change its technology to a simple bridge, and re-INVITE the media back
to Asterisk.

Generally, this logic mostly already exists in Asterisk. However, prior to this
patch, there were a few bugs:
(1) The T.38 framehook currently prevents a channel capable of T.38 faxes from
    ever entering into a direct media bridge. This applies even when the only
    media being passed over the channel is audio. This patch fixes this bug
    by having the framehook specify that it defers caring about any frame type.
    This allows the channels to enter into a direct media bridge, which will
    be broken when a re-INVITE is received.
(2) When a re-INVITE is received, nothing instructed the bridging layer to
    re-inspect the allowed bridging technology. This now occurs when either
    a re-INVITE is received from a peer, or when a response is received from
    the far end (that is, when the T.38 state changes to either
    T38_PEER_REINVITE or T38_LOCAL_REINVITE).
(3) chan_pjsip needs to do a small amount of work to prevent a direct media
    bridge from being chosen when a T.38 session is in progress. When a T.38
    session supplement has a t38 datastore - which is added when we detect
    we should start thinking about T.38 on a channel - we now refuse a native
    RTP bridge.
(4) When a BYE request is received, we don't terminate the T.38 session. If
    the other side of a T.38 fax survives the hangup (due to the 'g' flag
    in Dial, for example), we don't currently re-INVITE the media on the
    other channel back to audio. This patch now has res_pjsip_t38 intercept
    BYE requests and inform the far side that the T.38 session is terminated.
    This naturally causes the correct re-INVITEs to be sent.

ASTERISK-25582

Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb

This patch adds some debug statements to res_pjsip_t38. These statements help
to determine which SDP negotiation callbacks are being executed, and, when
a particular callback exits, why a callback may not have applied its logic
to the local or remote SDP.

Change-Id: I61b3fb9183b7ebbb5da8e9f48b59a5d9d7042d77

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

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

Change-Id: Ie16f5053ebde0dc6507845393709b4d6a3ea526d

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

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

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

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 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

ASTERISK-25533 #close

Change-Id: Ie1a9d1a6511b3f1a56b93d04475fbf8a4e40010a

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