We should not be processing any incoming messages until we are fully
booted.  We may not have dialplan or other needed configuration loaded
yet.

ASTERISK-26089 #close
Reported by: Scott Griepentrog

ASTERISK-26088
Reported by:  Richard Mudgett

Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264

Testing has shown that our usage of UnixODBC is problematic
due to bugs within UnixODBC itself as well as the heavy weight
cost of connecting and disconnecting database connections, even
when pooling is enabled.

For users of UnixODBC 2.3.1 and earlier crashes would occur due
to insufficient protection of the disconnect operation. This was
fixed in UnixODBC 2.3.2 and above.

For users of UnixODBC 2.3.3 and higher a slow-down would occur
under heavy database use due to repeated connection establishment.
A regression is present where on each connection the database
configuration is cached again, with the cache growing out of
control.

The connection pool implementation present in this change helps
to mitigate these issues by reducing how much we connect and
disconnect database connections. We also solve the issue of
crashes under UnixODBC 2.3.1 by defaulting the maximum number of
connections to 1, returning us to the previous working behavior.
For users who may have a fixed version the maximum concurrent
connection limit can be increased helping with performance.

The connection pool works by keeping a list of active connections.
If the connection limit has not been reached a new connection is
established. If the connection limit has been reached then the
request waits until a connection becomes available before
continuing.

ASTERISK-26074 #close
ASTERISK-26054 #close

Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff

Icelandic has some weird grammar rules when dealing with dates and
numbers. There are different genders used depending on which number
you're dealing with, and only a handful of numbers do change depending
on the gender. There is also an implied gender in several cases.

This patch was originally written for asterisk 1.6, and has been in use
for several years without crashes. I cleaned it up a bit and rewrote
what was necessary for Asterisk 13.

The functions were copied from other similar languages and modified
where appropriate. If i recall correctly, the German and Danish
functions were used as a base.

ASTERISK-26087
Reported by: Örn Arnarson
Tested by: Örn Arnarson

Change-Id: Ib7d8bd7b0fede5767921ed821315b5b508c0e665

Change the awkward and not as flexible UnicastRTP options format
From:
Dial(UnicastRTP/127.0.0.1[/[<engine>][/[<codec>]]])
To:
Dial(UnicastRTP/127.0.0.1[/[<options>]])

Where <options> can be standard Asterisk flag options:
c(<codec>) - Specify which codec/format to use such as 'ulaw'.
e(<engine>) - Specify which RTP engine to use such as 'asterisk'.

More option flags can be easily added later such as the codec's RTP
payload type to use when the codec does not have a static payload type
defined.

Change-Id: I0c297aaf09e2ee515536cb7437bb8042ff8ff3c9

Added a new channel variable FORWARDERNAME which indicates which
channel was responsible for a forwarding requests received on dial attempt.

Fixed a bug in the app_queue: FORWARD_CONTEXT is not used.

ASTERISK-26059 #close

Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2

If you create a local channel and don't specify an originator channel
to take capabilities from, we automatically add all audio formats to
the new channel's capabilities. When we try to make the channel
compatible with another, the "best format" functions pick the best
format available, which in this case will be slin192.  While this is
great for preserving quality, it's the worst for performance and
overkill for the vast majority of applications.

In the absense of any other information, adding all formats is the
correct thing to do and it's not always possible to supply an
originator so a new parameter 'formats' has been added to the channel
create/originate functions. It's just a comma separated list of formats
to make availalble for the channel. Example: "ulaw,slin,slin16".
'formats' and 'originator' are mutually exclusive.

To facilitate determination of format names, the format name has been
added to "core show codecs".

ASTERISK-26070 #close

Change-Id: I091b23ecd41c1b4128d85028209772ee139f604b

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

As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.

Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.

ASTERISK-26011

Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576

Add the option 'enable_callee_prompt' to followme.conf. Enabled by
default. If disabled, a callee is not prompted to accept or reject
the forwarded call.

ASTERISK-26064 #close

Change-Id: I0a8b19d4cf95c86a07c992813babb9e4a4acfff5
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

func_odbc was changed in Asterisk 13.9.0
to make func_odbc use a single database connection per DSN
because of reported bug ASTERISK-25938
with MySQL/MariaDB LAST_INSERT_ID().

This is drawback in performance when func_odbc is used
very often in dialplan.

Single database connection should be optional.

ASTERISK-26010

Change-Id: I7091783a7150252de8eeb455115bd00514dfe843

This patch adds a new feature to ARI that allows a client to download
the media associated with a stored recording. The new route is
/recordings/stored/{name}/file, and transmits the underlying binary file
using Asterisk's HTTP server's underlying file transfer facilities.

Because this REST route returns non-JSON, a few small enhancements had
to be made to the Python Swagger generation code, as well as the
mustache templates that generate the ARI bindings.

ASTERISK-26042 #close

Change-Id: I49ec5c4afdec30bb665d9c977ab423b5387e0181

Some SBCs require responses to empty SIP INFO packets
after establishing call via INVITE, if not responded to
they may drop your call after unspecified timeout of X minutes.

They are identified by having no Content-Type, check for this
and respond with 200 - OK message.

ASTERISK-24986 #close
Reported-by: Ilya Trikoz, Federico Santulli

Change-Id: Ib27e4f07151e5aef28fa587e4ead36c5b87c43e0

Added a new multi_user option that when specified allows a particular
configuration to be used for multiple users. It does this by replacing
the user portion of the server uri with a dynamically created one.

Two new API calls have been added in order to make use of the new
functionality:

ast_sip_publish_user_send - Sends an outgoing publish message based on the
given user. If state for the user already exists it uses that, otherwise
it dynamically creates new outbound publishing state for the user at that
time.

ast_sip_publish_user_remove - Removes all outbound publish state objects
associated with the user. This essentially stops outbound publishing for
the user.

ASTERISK-25965 #close

Change-Id: Ib88dde024cc83c916424645d4f5bb84a0fa936cc

* Provide consistent indenting of lines in bulleted paragraphs
* Respect the 80 character column width
* Group all like items together, e.g., all dialplan applications under
  "Applications", etc.
* Use a single blank line to break up functionality changes within a
  larger section
* Use two blanks lines to delineate larger sections

Change-Id: I0488554f5cb7c51da70003d69288a21c9aab9647

Many ARI applications will want to play multiple media files in a row to
a resource. The most common use case is when building long-ish IVR prompts
made up of multiple, smaller sound files. Today, that requires building a
small state machine, listening for each PlaybackFinished event, and triggering
the next sound file to play. While not especially challenging, it is tedious
work. Since requiring developers to write tedious code to do normal activities
stinks, this patch adds the ability to play back a list of media files to a
resource.

Each of the 'play' operations on supported resources (channels and bridges)
now accepts a comma delineated list of media URIs to play. A single Playback
resource is created as a handle to the entire list. The operation of playing
a list is identical to playing a single media URI, save that a new event,
PlaybackContinuing, is raised instead of a PlaybackFinished for each non-final
media URI. When the entire list is finished being played, a PlaybackFinished
event is raised.

In order to help inform applications where they are in the list playback, the
Playback resource now includes a new, optional attribute, 'next_media_uri',
that contains the next URI in the list to be played.

It's important to note the following:
 - If an offset is provided to the 'play' operations, it only applies to the
   first media URI, as it would be weird to skip n seconds forward in every
   media resource.
 - Operations that control the position of the media only affect the current
   media being played. For example, once a media resource in the list
   completes, a 'reverse' operation on a subsequent media resource will not
   start a previously completed media resource at the appropiate offset.
 - This patch does not add any new operations to control the list. Hopefully,
   user feedback and/or future patches would add that if people want it.

ASTERISK-26022 #close

Change-Id: Ie1ea5356573447b8f51f2e7964915ea01792f16f

At one point in time, it seemed like a good idea to use the Asterisk
channel name as the HEP correlation UUID. In particular, it felt like
this would be a useful identifier to tie PJSIP messages and RTCP
messages together, along with whatever other data we may eventually send
to Homer. This also had the benefit of keeping the correlation UUID
channel technology agnostic.

In practice, it isn't as useful as hoped, for two reasons:
1) The first INVITE request received doesn't have a channel. As a
   result, there is always an 'odd message out', leading it to be
   potentially uncorrelated in Homer.
2) Other systems sending capture packets (Kamailio) use the SIP Call-ID.
   This causes RTCP information to be uncorrelated to the SIP message
   traffic seen by those capture nodes.

In order to support both (in case someone is trying to use res_hep_rtcp
with a non-PJSIP channel), this patch adds a new option, uuid_type, with
two valid values - 'call-id' and 'channel'. The uuid_type option is used
by a module to determine the preferred UUID type. When available, that
source of a correlation UUID is used; when not, the more readily available
source is used.

For res_hep_pjsip:
 - uuid_type = call-id: the module uses the SIP Call-ID header value
 - uuid_type = channel: the module uses the channel name if available,
                        falling back to SIP Call-ID if not
For res_hep_rtcp:
 - uuid_type = call-id: the module uses the SIP Call-ID header if the
                        channel type is PJSIP and we have a channel,
                        falling back to the Stasis event provided
                        channel name if not
 - uuid_type = channel: the module uses the channel name

ASTERISK-25352 #close

Change-Id: Ide67e59a52d9c806e3cc0a797ea1a4b88a00122c

With the old SIP module we can use IP access controls per peer.
PJSIP module missing this feature.

This patch added next configuration Endpoint options:
    "acl" - list of IP ACL section names in acl.conf
    "deny" - List of IP addresses to deny access from
    "permit" - List of IP addresses to permit access from
    "contact_acl" - List of Contact ACL section names in acl.conf
    "contact_deny" - List of Contact header addresses to deny
    "contact_permit" - List of Contact header addresses to permit

This patch also better logging failed request:
    add custom message instead of "No matching endpoint found"
    add SIP method to logging

ASTERISK-25900

Change-Id: I456dea3909d929d413864fb347d28578415ebf02

This patch allows for having app_confbridge register the name of the
conference as an extension into a specific context, similar to
regcontext for chan_sip.  This variant is not quite as involved as the
one in chan_sip and doesn't allow for multiple contexts or custom
extensions, you can only specify the context and the conference name
will always be used as the extension to register.

ASTERISK-25989 #close

Change-Id: Icacf94d9f2b5dfd31ef36f6cb702392619a7902f

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

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

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

A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username.  This is most often used when customers
have a PBX that needs to register rather than identify by IP address.  From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.

In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id.  With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.

The fixes:

A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor.  This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.

Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved.  So to keep the order, a vector was added
to the end of ast_sip_endpoint.  This is only used by res_pjsip_registrar
to find the aor.  The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.

Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.

The order is:

username@domain
username@domain_alias
username

Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert.  It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed.  As a result
though, that first security alert is actually a false alarm.

To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time.  Those configuration options have been added to
the global config object.  This feature is only used when auth_username
is enabled.

Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.

The testsuite tests all pass but new tests are forthcoming for this new
feature.

ASTERISK-25835 #close
Reported-by: Ross Beer

Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d

This patch added new global pjsip option 'disable_multi_domain'.
Disabling Multi Domain can improve Realtime performance by reducing
number of database requests.

ASTERISK-25930 #close

Change-Id: I2e7160f3aae68475d52742107949a799aa2c7dc7

ChanSpy was creating its audiohook with the flags AST_AUDIOHOOK_TRIGGER_SYNC
and AST_AUDIOHOOK_SMALL_QUEUE, which caused audio frames to be lost when
queues grow too large or when read and write queues go out of sync.
Now these flags are set conditionally:
- AST_AUDIOHOOK_TRIGGER_SYNC is not set if the option "o" is set
- a new option "l" is created: if set, AST_AUDIOHOOK_SMALL_QUEUE will not
be set on the audiohook

ASTERISK-25866

Change-Id: I9c7652f41d9fa72c8691e4e70ec4fd16b047a4dd

The first available transport of the appropriate type is used now.
This patch adds new config option 'transport' for outbound-publish.
If transport is set then outbound PUBLISH requests will use this transport.

ASTERISK-25901 #close

Change-Id: Ib389130489b70e36795b0003fa5fd386e2680151

This adds a new ARI method that allows for you to dial a channel that
you previously created in ARI.

By combining this with the create method for channels, it allows for a
workflow where a channel can be created, manipulated, and then dialed.
The channel is under control of the ARI application during all stages of
the Dial and can even be manipulated based on channel state changes
observed within an ARI application.

The overarching goal for this is to eventually be able to add a dialed
channel to a Stasis bridge earlier than the "Up" state. However, at the
moment more work is needed in the Dial and Bridge APIs in order to
facilitate that.

ASTERISK-25889 #close

Change-Id: Ic6c399c791e66c4aa52454222fe4f8b02483a205

This adds a new ARI method to the channels resource that allows for the
creation of a new channel. The channel is created and then placed into
the specified Stasis application.

This is different from the existing originate method that creates a
channel, dials it, and then places the answered channel into the
dialplan or a Stasis application. This method does not attempt to call
the channel at all. Dialing is left as a later step after channel
creation. This allows for pre-dialing channel manipulation if desired.

ASTERISK-25889

Change-Id: I3c96a0aba914b08e39f6256371a5bd4c92cbded8

This change introduces the concept of autohints. These are hints
which are created as a result of device state changes occurring within
the core. When this happens a hint will be created (if it does not
exist already) using the device name as the extension.

For example if a device state change is received for "PJSIP/bob"
and autohints are enabled on a context then a hint will exist in
that context for "bob" with a device of "PJSIP/bob".

For virtual or custom device states the name after the type will
be used. For example if the device state of "Custom:bob" changes
then a hint will exist in that context for "bob" with a device of
"Custom:bob".

This functionality can be enabled in extensions.conf by placing
"autohints=yes" in a context.

ASTERISK-25881 #close

Change-Id: I7e444c7da41b7b7d33374420fec658beeb18584e

Added the ability to show channel statistics to chan_pjsip (cli_functions.c)

Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c.  The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.

Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots.  Much more efficient.

Change-Id: I03b114522126d27434030b285bf6d531ddd79869

Blind transfers to a recognized parking extension need to use the parker's
channel variable values to create the dynamic parking lot.  This is
because there is always only one parker while the parkee may actually be a
multi-party bridge.  A multi-party bridge can never supply the needed
channel variables to create the dynamic parking lot.  In the multi-party
bridge blind transfer scenario, the parker's CHANNEL(parkinglot) value and
channel variables are inherited by the local channel used to park the
bridge.

* In park_common_setup(), make use the parker instead of the parkee to
supply the dynamic parking lot channel variable values.  In all but one
case, the parkee is the same as the parker.  However, in the recognized
parking extension blind transfer scenario for a two party bridge they are
different channels.  For consistency, we need to use the parker channel.

* In park_local_transfer(), pass the CHANNEL(parkinglot) value to the
local channel when blind transferring a multi-party bridge to a recognized
parking extension.

* When a local channel starts a call, the Local;2 side needs to inherit
the CHANNEL(parkinglot) value from Local;1.

The DTMF one-touch parking case wasn't even trying to create dynamic
parking lots before it aborted the attempt.

* In parking_park_call(), add missing code to create a dynamic parking
lot.

A DTMF bridge hook is documented as returning -1 to remove the hook.
Though the hook caller is really coded to accept non-zero.  See the
ast_bridge_hook_callback typedef.

* In feature_park_call(), don't remove the DTMF one-touch parking hook
because of an error.

ASTERISK-24605 #close
Reported by:  Philip Correia
Patches:
      call_park.patch (license #6672) patch uploaded by Philip Correia

Change-Id: I221d3a8fcc181877a1158d17004474d35d8016c9

This patch allows applications/APIs that access media through the core file
APIs to play media in the media cache. Prior to determining if a 'filename'
exists, the filename is passed to the media cache's retrieve API call. If
that call succeeds, the local file specified passed back by the API is
opened for streaming. When used in this fashion, the 'filename' is actually
a URI that the media cache process and understand.

ASTERISK-25654 #close

Change-Id: I73b6e2e90c3e91b8500581c45cdf9c0dc785f5f0

This patch adds a bucket backend for the core media cache that interfaces to a
remote HTTP server. When a media item is requested in the cache, the cache will
query its bucket backends to see if they can provide the media item. If that
media item has a scheme of HTTP or HTTPS, this backend will be invoked.

The backend provides callbacks for the following:
 * create - this will always retrieve the URI specified by the provided
            bucket_file, and store it in the file specified by the object.
 * retrieve - this will pull the URI specified and store it in a temporary
              file. It is then up to the media cache to move/rename this file
              if desired.
 * delete - destroys the file associated with the bucket_file.
 * stale - if the bucket_file has expired, based on received HTTP headers from
           the remote server, or if the ETag on the server no longer matches
           the ETag stored on the bucket_file, the resource is determined to be
           stale.

Note that the backend respects the ETag, Expires, and Cache-Control headers
provided by the HTTP server it is querying.

ASTERISK-25654

Change-Id: Ie201c2b34cafc0c90a7ee18d7c8359afaccc5250

This patch adds a write option to the CURL dialplan function, allowing it to
CURL files and store them locally. The value 'written' to the CURL URL
specifies the location on disk to store the file. As an example:

same => n,Set(CURL(http://1.1.1.1/foo.wav)=/tmp/foo.wav)

Would retrieve the file foo.wav from the remote server and store it in the
/tmp directory.

Due to the potentially dangerous nature of this function call, APIs are
forbidden from using the write functionality unless live_dangerously is set
to True in asterisk.conf.

ASTERISK-25652 #close

Change-Id: I44f4ad823d7d20f04ceaad3698c5c7f653c41b0d

Per RFC3325, the 'From' header is now anonymized on outgoing calls when
caller id presentation is prohibited.

TID = trust_id_outbound
PRO = Set(CALLERID(pres)=prohib)
USR = endpoint/from_user
DOM = endpoint/from_domain
PAI = YES(privacy=off), NO(not sent), PRI(privacy=full) (assumes send_pai=yes)

Conditions          |Result
--------------------|----------------------------------------------------
TID PRO USR DOM     |PAI    FROM
--------------------|----------------------------------------------------
Y   Y   abc def.ghi |PRI    "Anonymous" <sip:abc@def.ghi>
Y   Y   abc         |PRI    "Anonymous" <sip:abc@anonymous.invalid>
Y   Y       def.ghi |PRI    "Anonymous" <sip:anonymous@def.ghi>
Y   Y               |PRI    "Anonymous" <sip:anonymous@anonymous.invalid>

Y   N   abc def.ghi |YES    <sip:abc@def.ghi>
Y   N   abc         |YES    <sip:abc@<ip_address>>
Y   N       def.ghi |YES    "Caller Name" <sip:<caller_exten>@def.ghi>
Y   N               |YES    "Caller Name" <sip:<caller_exten>@<ip_address>>

N   Y   abc def.ghi |NO     "Anonymous" <sip:abc@def.ghi>
N   Y   abc         |NO     "Anonymous" <sip:abc@anonymous.invalid>
N   Y       def.ghi |NO     "Anonymous" <sip:anonymous@def.ghi>
N   Y               |NO     "Anonymous" <sip:anonymous@anonymous.invalid>

N   N   abc def.ghi |YES    <sip:abc@def.ghi>
N   N   abc         |YES    <sip:abc@<ip_address>>
N   N       def.ghi |YES    "Caller Name" <sip:<caller_exten>@def.ghi>
N   N               |YES    "Caller Name" <sip:<caller_exten>@<ip_address>>

ASTERISK-25791 #close
Reported-by: Anthony Messina

Change-Id: I2c82a5ca1413c2c00fb62ea95b0ae8e97af54dc9

Previous chan_sip behavior:

Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason).  For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize.  Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).

Previous chan_pjsip behavior:

Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason).  For an outgoing reason value, chan_pjsip
would send the reason value as passed down.

With this patch:

Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not.  RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason).  e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value.  The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.

The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).

Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent.  User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token.  Note that there are still
limitations on what characters can be put in a custom user value.  e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.

* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.

* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().

* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header().  The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.

Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87

Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html

From CHANGES:
 * To help insure that Asterisk is compiled and run with the same known
   version of pjproject, a new option (--with-pjproject-bundled) has been
   added to ./configure.  When specified, the version of pjproject specified
   in third-party/versions.mak will be downloaded and configured.  When you
   make Asterisk, the build process will also automatically build pjproject
   and Asterisk will be statically linked to it.  Once a particular version
   of pjproject is configured and built, it won't be configured or built
   again unless you run a 'make distclean'.

   To facilitate testing, when 'make install' is run, the pjsua and pjsystest
   utilities and the pjproject python bindings will be installed in
   ASTDATADIR/third-party/pjproject.

   The default behavior remains building with the shared pjproject
   installation, if any.

Building:

   All you have to do is include the --with-pjproject-bundled option on
   the ./configure command line (and remove any existing --with-pjproject
   option if specified).  Everything else is automatic.

Behind the scenes:

   The top-level Makefile was modified to include 'third-party' in the
   list of MOD_SUBDIRS.

   The third-party directory was created to contain any third party
   packages that may be needed in the future.  Its Makefile automatically
   iterates over any subdirectories passing on targets.

   The third-party/pjproject directory was created to house the pjproject
   source distribution.  Its Makefile contains targets to download, patch
   configure, generate dependencies, compile libs, apps and python bindings,
   sanitized build.mak and generate a symbols list.

   When bootstrap.sh is run, it automatically includes the configure.m4
   file in third-party/pjproject.  This file has a macro to download and
   conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
   and PJPROJECT_BUNDLED.  It also tests for the capabilities like
   PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
   trying to compile.  Of course, bootstrap.sh is only run once and the
   configure file is incldued in the patch.

   When configure is run with the new options, the macro in configure.m4
   triggers the download, patch, conifgure and tests.  No compilation is
   performed at this time.  The downloaded tarball is cached in /tmp so
   it doesn't get downloaded again on a distclean.

   When make is run in the top-level Asterisk source directory, it will
   automatically descend all the subdirectories in third_party just as it
   does for addons, apps, etc.  The top-level Makefile makes sure that
   the 'third-party' is built before 'main' so that dependencies from the
   other directories are built first.

   When main does build, a new shared library (libasteriskpj) is created that
   links statically to the pjproject .a files and exports all their symbols.
   The asterisk binary links to that, just as it does with libasteriskssl.

   When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
   python bindings are installed in ASTDATADIR/third-party/pjproject.  This
   will facilitate testing, including running the testsuite which will be
   updated to check that directory for the pjsua module ahead of the system
   python library.

Modules should continue to depend on pjproject if they use pjproject APIs
directly.  They should not care about the implementation.  No changes to any
res_pjsip modules were made.

Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103

The 'reload' mechanism actually involves closing the underlying
socket and calling the appropriate udp, tcp or tls start functions
again.  Only outbound_registration, pubsub and session needed work
to reset the transport before sending requests to insure that the
pjsip transport didn't get pulled out from under them.

In my testing, no calls were dropped when a transport was changed
for any of the 3 transport types even if ip addresses or ports were
changed. To be on the safe side however, a new transport option was
added (allow_reload) which defaults to 'no'.  Unless it's explicitly
set to 'yes' for a transport, changes to that transport will be ignored
on a reload of res_pjsip.  This should preserve the current behavior.

Change-Id: I5e759850e25958117d4c02f62ceb7244d7ec9edf

Previously you could add [!dnid] to the SIP dial string to alter the To:
header. This change allows you to alter the From header as well.

SIP dial string extra options now look like this:

    [![touser[@todomain]][![fromuser][@fromdomain]]]

INCOMPATIBLE CHANGE: If you were using an exclamation mark in your To:
header, that is no longer possible.

ASTERISK-25803 #close

Change-Id: I2457e9ba7a89eb1da22084bab5a4d4328e189db7

Warnings and errors in the pjproject libraries are generally handled by
Asterisk.  In many cases, Asterisk wouldn't even consider them to be warnings
or errors so the messages emitted by pjproject directly are either superfluous
or misleading.  A good exampe of this are the level-0 errors pjproject emits
when it can't open a TCP/TLS socket to a client to send an OPTIONS.  We don't
consider a failure to qualify a UDP client an "ERROR", why should a TCP/TLS
client be treated any differently?

A config file for res_pjproject has bene added (pjproject.conf) and a new
log_mappings object allows mapping pjproject levels to Asterisk levels
(or nothing).  The defaults if no pjproject.conf file is found are the same
as those that were hard-coded into res_pjproject initially: 0,1 = LOG_ERROR,
2 = LOG_WARNING, 3,4,5 = LOG_DEBUG<level>

Change-Id: Iba7bb349c70397586889b8f45b8c3d6c6c8c3898

A new command (pjsip export config_wizard primitives) has been added that
will export all the pjsip objects it created to the console or a file
suitable for reuse in a pjsip.conf file.

ASTERISK-24919 #close
Reported-by: Ray Crumrine

Change-Id: Ica2a5f494244b4f8345b0437b16d06aa0484452b