- 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

ASTERISK-25615
Reported by: George Joseph

Change-Id: Ieff35307254ca193f3d473cff2e396ca57c7ce0b

An ERROR or WARNING message should generally indicate that something has gone
wrong in Asterisk. In the case of writing to a file descriptor, Asterisk is not
in control of when the far end closes its reading on a file descriptor. If the
far end does close the file descriptor in an unclean fashion, this isn't a bug
or error in Asterisk, particularly when the situation can be gracefully
handled in Asterisk.

Currently, when this happens, a user would see the following somewhat cryptic
ERROR message:

  "utils.c: write() returned error: Broken pipe"

There's a few problems with this:
(1) It doesn't provide any context, other than 'something broke a pipe'
(2) As noted, it isn't actually an error in Asterisk
(3) It can get rather spammy if the thing breaking the pipe occurs often, such
    as a FastAGI server
(4) Spammy ERROR messages make Asterisk appear to be having issues, or can even
    mask legitimate issues

This patch changes ast_carefulwrite to only log an ERROR if we actually had one
that was reasonably under our control. For debugging purposes, we still emit
a debug message if we detect that the far side has stopped reading.

Change-Id: Ia503bb1efcec685fa6f3017bedf98061f8e1b566

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

Adds the TCP Keep Alive option to TCP and TLS server sockets. Previously
this option was only being set on session sockets.
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
According to the link above, the SO_KEEPALIVE option is useful for knowing
when a TCP connected endpoint has severed communication without indicating
it or has become unreachable for some reason. Without this patch, keep
alive is not set on the socket listening for incoming TCP sessions and
in Komatsu's report this resulted in the thread listening for TCP becoming
stuck in a waiting state.

ASTERISK-25364 #close
Reported by: Hiroaki Komatsu

Change-Id: I7ed7bcfa982b367dc64b4b73fbd962da49b9af36

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

The default value was never set for audio_buffers, causing bad
audio quality.  This ensures the default is always set.

ASTERISK-25569 #close

Change-Id: I2d2ee3e644120b0f9f6ea6ab9286d7d590942a44

Asterisk may crash when calling ast_channel_get_t38_state(c)
on a locked channel which is being hung up.

ASTERISK-25609 #close

Change-Id: Ifaa707c04b865a290ffab719bd2e5c48ff667c7b

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

The current logic for ICE negotiation starts it
when receiving an SDP with ICE candidates. This is
incorrect as ICE negotiation can only start when each 
call party have at least one pair of local and remote 
candidate. Starting ICE negotiation early would result 
in negotiation failure and ultimately no audio.

This change makes it so ICE negotiation is only started
when a response with SDP is received or when a response
with SDP is sent.

ASTERISK-24146

Change-Id: I55a632bde9e9827871b09141d82747e08379a8ca

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

ASTERISK-25599 #close

Change-Id: Idbd187f711b2ec63dda949ca0f79aa0c1a0a0b6e

ASTERISK-25616 #close

Change-Id: Ibe729aaf2e6e25506cff247cec5149ec1e589319

A crash happens sometimes when performing a CLI "sip reload".  The bogus
peer gets refreshed while it is in use by a new call which can cause the
crash.

* Protected the global bogus peer object with an ao2 global object
container.

ASTERISK-25610 #close

Change-Id: I5b528c742195681abcf713c6e1011ea65354eeed

This reverts commit 6614babe.

Unfortunately, using a bridge to manage T.38 state will cause severe deadlocks
in core_unreal/chan_local. Local channels attempt to reach across both their
peer and the peer's bridge to inspect T.38 state. Given the propensity of
Local channel chains, managing the locking situation in such a scenario is
practically infeasible.

Change-Id: Ic687397ffea08dfb899345a443bd990ec3d0416a

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

This patch fixes a crash which would occur when an audiohook was
applied to a channel using an audio codec that could not be translated
to signed linear (such as when using pass-through codecs like OPUS or
when the codec translator module for the format in use is not loaded).

ASTERISK-25498 #close
Reported by: Ben Langfeld

Change-Id: Ib6ea7373fcc22e537cad373996136636201f4384

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

* changes:
  Audit improper usage of scheduler exposed by 5c713fdf. (v13 additions)
  Audit improper usage of scheduler exposed by 5c713fdf.

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

Currently if a channel is transferred out of a bridge, the BRIDGEPEER
variable (also BRIDGEPVTCALLID) remain set even once the channel is
out of the bridge. This patch removes these variables when leaving
the bridge.

ASTERISK-25600 #close
Reported by: Mark Michelson

Change-Id: I753ead2fffbfc65427ed4e9244c7066610e546da

Change-Id: If83d63cf11cbc6df9b15251848b01feb570ade49

According to the API doxygen a sched ID of 0 is valid.  Unfortunately, 0
was never returned historically and several users incorrectly coded usage
of the returned sched ID assuming that 0 was invalid.

ASTERISK-25476

Change-Id: Ib19c7ebb44ec9fd393ef6646dea806d4f34e3a20

chan_sip.c:
* Initialize mwi subscription scheduler ids earlier because of ASTOBJ to
ao2 conversion.

* Initialize register scheduler ids earlier because of ASTOBJ to ao2
conversion.

chan_skinny.c:
* Fix more scheduler usage for the valid 0 id value.

ASTERISK-25476

Change-Id: If9f0e5d99638b2f9d102d1ebc9c5a14b2d706e95