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

Because the context, extension, and application are stored in stringfields,
checking for them being NULL doesn't work so well. This patch uses the
appropriate string library call, ast_strlen_zero, to see if there is a value
in the context/exten/app values.

Change-Id: Ie09623bfdf35f5a8d3b23dd596647fe3c97b9a23

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

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

To be able to barge into a call by dialling a prefix+extension that maps
to the extensions device.

Senario is that DECT headset users may be away from their desks and need
to transfer the call, the goal is that from any phone they dial a prefix
then their extension and are added to the bridge that they are in, from
there they can drop the headset call, as it's also on the handset,
and transfer the caller.

The dialplan would look like, where prefix=73, extension = 8512;
exten => _738512,1,BridgeAdd(SIP/cisco0001)

ASTERISK-25551 #close
Reported By: Alec Davis

Change-Id: I8eb5096a02168dcc8d7aeea416ef36ba4ed10540

Implemented support for the StatsD sample rate parameter,
which is a parameter for determining when to send computed
statistics to a client.

Valid sample rate values are:
Less than or equal to 0.0 will never be sent.
Between 0.0 and 1.0 will randomly be sent.
Greater than or equal to 1.0 will always be sent.

ASTERISK-25419
Reported By: Ashley Sanders

Change-Id: I11d315d0a5034fffeae1178e650aa8264485ed52

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

commit aae45acb (Mark Michelson 2015-04-15 10:38:02 -0500 6525)
refer ASTERISK-24958

above commit removed ast_channel_lock(qe->chan);
but failed to remove corresponding ast_channel_unlock(qe->chan);

ASTERISK-25561 #close
Reported Alec Davis

Change-Id: Ie05f4e2d08912606178bf1fded57cc022c7a2e1a

When dns_parse_answer_ex was iterating over the answers it
wasn't incrementing the answer pointer correctly after the first
answer.  The result was that no answers after the first
were being returned.  For results where multiple records should
have been sorted by priority, weight, etc., there was nothing
to sort so the only the first record was returned even if it
wouldn't have been the correct record based on the sort.

ASTERISK-25565 #close
Reported-by: Daniel Tryba
Tested-by George Joseph

Change-Id: I8622604fefdcd3c11e2c5609a6382e53b1467b0b

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

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

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