chan_sip sets the hangup cause code to AST_CAUSE_REQUESTED_CHAN_UNAVAIL
(44) when a channel is hung up due to an RTP timeout. So do the same
when it happens with PJSIP for parity.

Change-Id: I3546ebbde6460c22a27c9da1bf321711b5961ab8

Updated the AMI version for the following reason (see CHANGES for more details):

The 'PJSIPShowEndpoint' command's response event of 'IdentifyDetail' now
contains a new optional parameter, 'MatchHeader'.

Change-Id: Ie206913ef1dcfa6a2ebe3282da2387e52d6f05b9

After configuring Asterisk with '--with-pjproject-bundled' the configure/build
process attempts to download pjproject from its download site. Currently, a
timeout of 10 seconds is used that will stop the download process if pjproject
has not been fully downloaded in that time. For some systems this was not enough
time and the process was timing out too early.

This patch raises the download timeout value to '60'. Also, this patch fixes
another bug where the DOWNLOAD_TIMEOUT variable was not being properly exported
due to a naming error. DOWNLOAD_MAX_TIMEOUT is now properly renamed to
DOWNLOAD_TIMEOUT.

ASTERISK-26814 #close

Change-Id: Ia56e4e8a3d39db76bc8a1852b2cf07ec10b39842

The documentation for JABBER_STATUS (and the deprecated JabberStatus
app) indicate that a return value of 7 indicates that the specified
buddy was not in the roster. It also indicates that you can specify a
"bare" JID (one without a resource). Unfortunately the actual behavior
does not match the documented behavior.

Assuming that our roster includes the buddy online and available
"valid@example.org/Valid" and does *not* include the buddy
"invalid@example.org", the JABBER_STATUS() function returns the
following before this patch:

+------------------------------+------------+--------------------------+
| Buddy                        | Status     | Result                   |
+------------------------------+------------+--------------------------+
| valid@example.org            |  Online    |  7 (Not in roster)       |
| valid@example.org/Valid      |  Online    |  1 (Online)              |
| valid@example.org/Invalid    |  N/A       |  7 (Not in roster)       |
| invalid@example.org          |  N/A       |  Error logged, no return |
| invalid@example.org/Valid    |  N/A       |  Error logged, no return |
+------------------------------+------------+--------------------------+

And after this patch:

+------------------------------+------------+--------------------------+
| Buddy                        | Status     | Result                   |
+------------------------------+------------+--------------------------+
| valid@example.org            |  Online    |  1 (Online)              |
| valid@example.org/Valid      |  Online    |  1 (Online)              |
| valid@example.org/Invalid    |  N/A       |  6 (Offline)             |
| invalid@example.org          |  N/A       |  7 (Not in roster)       |
| invalid@example.org/Valid    |  N/A       |  7 (Not in roster)       |
+------------------------------+------------+--------------------------+

This brings the behavior in line with the documentation.

ASTERISK-23510 #close
Reported by: Anthony Critelli

Change-Id: I9c3241035363ef4a6bdc21fabfd8ffcd9ec657bf

If any errors occur during the TLS connection setup, we currently dump a
fairly generic error message. So instead we try to pull in something
useful from OpenSSL to report instead.

ASTERISK-24712
Reported by: Matthias Urlichs

Change-Id: I288500991a9681f447d92913b11fedaf426087f4

SSL_connect returns non-zero for both success and some error conditions
so simply negating is inadequate.

Change-Id: Ifbf882896e598703b6c615407fa456d3199f95b1

If we never establish a connection to our Jabber server, iksemel never sets up
its internal transport pointer, so attempting to send a message dereferences a
NULL pointer and causes a crash.

ASTERISK-21855 #close
Reported by: Jeremy Kister

Change-Id: I204a568894e4a53ab929783ecc594a000f04d79c

ASTERISK-25622 #close
Reported by: Sean Darcy

Change-Id: I8472cb7bfb58d411a3cfbd482da98cae2d94d1e9

Dynamic payload types were statically defined in Asterisk. This unfortunately
limited the number of dynamic payloads that could be registered. With this patch
dynamic payload type numbers are now assigned dynamically and per RTP instance.
However, in order to limit any issues where some clients expect the old
statically defined value this patch makes it so the value Asterisk used to pre-
designate is used for the dynamic assignment if available.

An option, "rtp_use_dynamic", has also been added (can be set in asterisk.conf)
that turns the new dynamic behavior on or off. When off it reverts back to using
statically defined payload values. This option defaults to "yes" in Asterisk 15.

ASTERISK-26515 #close
patches:
  ASTERISK-26515.diff submitted by jcolp (license 5000

Change-Id: I7653465c5ebeaf968f1a1cc8f3f4f5c4321da7fc

The CDR code previously did not allow the user field to be set
from the 'h' extension in the dialplan. This change removes that
limitation and allows it to be set.

ASTERISK-26818

Change-Id: I0fed8a79b5e408bac4e30542b8f33a61c5ed9aa6

Support for RFC3578 overlap dialling (i.e. 484 Response to partially matched
destinations) as currently provided by chan_sip is missing from res_pjsip.
This patch adds a new endpoint attribute (allow_overlap) [defaults to yes]
which when set to yes enables 484 responses to partial destination
matches rather than the current 404.

ASTERISK-26864

Change-Id: Iea444da3ee7c7d4f1fde1d01d138a3d7b0fe40f6

Rather than hard-coding UDP, allow consumers of the HEP API to specify
which protocol is in use. Update the PJSIP provider to pass in the
current protocol type.

ASTERISK-26850 #close

Change-Id: I54bbb0a001cfe4c6a87ad4b6f2014af233349978

This reverts commit 163e9e53.

Change-Id: Ief28479c77a298879dfe2c56be7ee92dc465da4b

We aren't validating that the URI we just parsed is a SIP/SIPS one before
trying to access the user, host, and port members of a possibly uninitialized
structure.

Also update the MessageSend documentation to indicate what 'from' formats are
accepted.

ASTERISK-26484 #close
Reported by: Vinod Dharashive

Change-Id: I476b5cc5f18a7713d0ee945374f2a1c164857d30

ASTERISK-26776 #close

Change-Id: I884b6f4e8233a355d0be687ec78d41bc0e4d3fd2

Some codecs - codec_speex specifically - take voice frames and return
other types of frames, like CNG. If we subsequently treat those as
voice frames, we'll run into trouble when destroying the frame because
of the requirement that each voice frame have an associated format.

ASTERISK-26880 #close
Reported by: Kirsty Tyerman

Change-Id: I43f8450c48fb276ad8b99db8512be82949c1ca7c

Fixed a bug in function "ast_audiohook_write_frame" that checked the
variable other_factory_samples and only flushed the factories, so they
would be in sync, when other_factory_samples > 0. When there is not any
rtp incoming the variable other_factory_samples will be 0, and although
the result of "our_factory_ms - other_factory_ms" may be very large,
this led to the record file not syncing.

ASTERISK-26875 #close
Reported-by: Aaron An
Tested-by: Aaron An

Change-Id: Ia4d890fb8fc1636a7188502bab35f555685aea22

POSIX does not require getprotobyname() to be thread safe and some
implementations use static memory which causes issues when multiple
threads are used.

Further, our usage of it today is just to ultimately get IPPROTO_TCP
for calls to setsockopt(). So instead we just use IPPROTO_TCP directly.

Change-Id: I2e14e58674808f7ce99b2f5e900d0f90d0d8da48

We are currently passing in the capacity of the read buffer instead of the
number of bytes that we actually read off the wire.

Change-Id: I60465049727d955c7f9a5e529e6f2aaff04cda36