Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543

ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.

The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.

This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.

This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.

ASTERISK-25925

Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb

Invisible bridges function the same as normal bridges, but they have the
following restrictions:

* They never show up in CLI, AMI, or ARI queries.
* They do not have Stasis messages published about them.

Invisible bridges' main use is for when use of the bridging system is
desired, but the bridge should not be known to users of the Asterisk
system.

ASTERISK-25925

Change-Id: I804a209d3181d7c54e3d61a60eb462e7ce0e3670

The res_pjsip_authenticator_digest, res_pjsip_endpoint_identifier_*
and res_pjsip_registrar modules should load ASAP
to avoid "No matching endpoint found" for legitimate endpoint.

ASTERISK-25994

Change-Id: Iac95d95ad031e0be104189d29e923a2ad7c24a1b

ASTERISK-25903 added a new headers to AMI Event ContactStatusDetail.
ASTERISK-25904 added a new Status to AMI Event ContactStatusDetail.
These additions should be also in stasis_endpoints
to include in command "manager show event ContactStatus"

Change-Id: I7610ad02a998e1f26c20caa27aa50279d0164f6a

It is possible for the nativeformats of a channel to change
throughout its lifetime. As a result a user of it needs to either
ensure the channel is locked when accessing the formats or keep
a reference to the nativeformats themselves.

This change fixes the file playback support so it keeps a
reference to the nativeformats when accessing things.

ASTERISK-25998 #close

Change-Id: Ie45b65475e1481ddf05b874ee48f63e39fff8915

ASTERISK-25931

Change-Id: Icc4321a88f5c93ff809da3f372eebbf69c6a8549

ASTERISK-25956 #close

Change-Id: If6961ec54be276d5ab4f012ee7e7b420cb45de38

The app_fax set FAXMODE variable, but res_fax missing this feature.
This patch add FAXMODE variable which is set to either "audio" or "T38".

ASTERISK-25980

Change-Id: Ie3dcbfb72cc681e9e267a60202f7fb8723a51b6b

When option 'o' was not set, ChanSpy created its audiohook with the flag
AST_AUDIOHOOK_MUTE_WRITE, which caused ChanSpy to listen audio from one
direction only.

ASTERISK-25866 #close

Change-Id: I5c745855eea29a3fbc4e4aed0b0c0f53580535e0

With the old SIP module AMI sends PeerStatus event on every
successfully REGISTER requests, ie, on start registration,
update registration and stop registration.

With PJSIP AMI sends ContactStatus only when status is changed.
Regarding registration:
on start registration - Created
on stop registration - Removed
but on update registration nothing

This patch added contact.updated event.

ASTERISK-25904

Change-Id: I8fad8aae9305481469c38d2146e1ba3a56d3108f

For all OSes:
* Disabled third-party codecs in pjproject and added
  '--disable-speex-codec --disable-speex-aec --disable-gsm-codec' to the
  configure options since we don't use the pjsip codec capability.

FreeBSD:
* Added FreeBSD support to install_prereq.
* Changed pjproject/configure.m4 to use $GNU_MAKE instead of hardcoding "make".
* Added __progname and environ to asterisk.exports.in.
* Reverted the use of ldconfig to create shared library symlinks to ln.
* Only enable epoll in pjproject if `uname -s` is Linux.
* Added a patch to pjproject to take the name of the 'make' command from
  an environment variable if supplied.  This is needed for the python bindings.
  (merged by Teluu into pjproject trunk 5/3/2016)
FreeBSD support isn't complete.  Still some general issues regarding
make/gmake having nothing to do with pjproject.  With some handholding it DOES
build successfully.

CentOS:
Added 'patch' and 'bzip2' to install_prereq PACKAGES_RH.
CentOS 6/7 32/64 build and run the pjsip testsuite successfully.

Ubuntu:
No changes required.
Ubuntu 15/16 32/64 build and run the pjsip testsuite successfully.

Debian:
No changes required.
Debian 6/7/8 32/64 build and run the pjsip testsuite successfully.

There will utimately be a follow-up patch to create an install_prereq for
the testsuite as I've discovered a few missing requirements.

ASTERISK-25968 #close

Change-Id: I5756a07facfc63798115a5e73a8709382fe9259c

Voicemail email addresses can be corrupt or voicemail
emails can end up being sent to the wrong email address if asterisk is
reading voicemail.conf during a reload and processing an email at the
same time. This patch always copies the struct that would otherwise only
be copied once.

ASTERISK-24463 #close
Reported by: John Campbell
Tested by: Etienne Lessard
Tested by: Andrew Nagy
Change-Id: I3a0643813116da84e2617291903d0d489b7425fb

If the Asterisk system name is set in asterisk.conf, it will be stored
into the "reg_server" field in the ps_contacts table to facilitate
multi-server setups.

ASTERISK-25931

Change-Id: Ia8f6bd2267809c78753b52bcf21835b9b59f4cb8

Note: When packagers use these files (as an example) the paths are never
really used when they are split using '='.

Note: Thirdparty applications will also have trouble parsing the file when
expecting '=>'.

Change-Id: I0ada647f588e81f023fb1333ca15a1a333fd6004

Create PUBLISH messages to update a third party when an extension state
changes because of either a device or presence state change.

A configuration example:

[exten-state-publisher]
type=outbound-publish
server_uri=sip:instance1@172.16.10.2
event=presence
; Optional regex for context filtering, if specified only extension state
; for contexts matching the regex will cause a PUBLISH to be sent.
@context=^users
; Optional regex for extension filtering, if specified only extension
; state for extensions matching the regex will cause a PUBLISH to be sent.
@exten=^[0-9]*
; Required body type for the PUBLISH message.
;
; Supported values are:
; application/pidf+xml
; application/xpidf+xml
; application/cpim-pidf+xml
; application/dialog-info+xml (Planned support but not yet)
@body=application/pidf+xml

The '@' extended variables are used because the implementation can't
extend the outbound publish type as it is provided by the outbound publish
module.  That means you either have to use extended variables, or
implement some sort of custom extended variable thing in the outbound
publish module.  Another option would be to refactor that stuff to have an
option which specifies the use of an alternate implementation's
configuration and then have that passed to the implementation.  JColp
opted for the extended variables method originally.

ASTERISK-25972 #close

Change-Id: Ic0dab4022f5cf59302129483ed38398764ee3cca

When starting the extension state publishers, check if the requested
message body generator is available.  If not available give error message
and skip starting that publisher.

* res_pjsip_pubsub.c: Create new API if type/subtype generator
registered.

* res_pjsip_exten_state.c: Use new body generator API for validation.

ASTERISK-25922

Change-Id: I4ad69200666e3cc909d4619e3c81042d7f9db25c

Change-Id: I8f0b57841feaab56c8a4e821b5ccb4e05e5fbadb

Change-Id: Ia0b2e15773894c599e5c5748bbc70e99f434192a

Change-Id: Id8752073ef06472a2fd96080f4009fac42843e67