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

Change-Id: Id6350b3c7d4ec8df7ec89863566645e2b0f441fd

chan_sip could not handle AST_T38_TERMINATED frames being sent to it when
the channel left the bridge.  The action resulted in overlapping outgoing
reINVITEs.  The testsuite tests/fax/sip/directmedia_reinvite_t38 was not
happy.

* Force T.38 to be remembered as locally bridged.  Now when the channel
leaves the native RTP bridge after T.38, the channel remembers that it has
already reINVITEed the media back to Asterisk.  It just needs to terminate
T.38 when the AST_T38_TERMINATED arrives.

* Prevent redundant AST_T38_TERMINATED from causing problems.  Redundant
AST_T38_TERMINATED frames could cause overlapping outgoing reINVITEs if
they happen before the T.38 state changes to disabled.  Now the T.38 state
is set to disabled before the reINVITE is sent.

ASTERISK-25582 #close

Change-Id: I53f5c6ce7d90b3f322a942af1a9bcab6d967b7ce

This backs out item 4 of the 4875e5ac
commit.  Item 4 added the t38_bye_supplement.  Unfortunately, the frame
that it puts into the bridge may or may not be processed by the time the
bridged peer is kicked out of the bridge.  If it is processed then all is
well.  However, if it is not processed then that channel is stuck in fax
mode until it hangs up or maybe if it joins another bridge for T.38
faxing.

ASTERISK-25582

Change-Id: Ib20a03ecadf1bf8a0dcadfadf6c2f2e60919a9f7

The channel is now going to get T.38 terminated when it leaves the
bridging system and the bridged peers are going to get T.38 terminated as
well.

ASTERISK-25582

Change-Id: I77a9205979910210e3068e1ddff400dbf35c4ca7

ASTERISK-25582

Change-Id: I69451920b122de7ee18d15bb231c80ea7067a22b

Local channel optimization could cause DTMF digits to be duplicated.
Pending DTMF end events would be posted to a bridge when the local channel
optimizes out and is replaced by the channel further down the chain.  When
the real digit ends, the channel would get another DTMF end posted to the
bridge.

A -- LocalA;1/n -- LocalA;2/n -- LocalB;1 -- LocalB;2 -- B

1) LocalA has the /n flag to prevent optimization.
2) B is sending DTMF to A through the local channel chain.
3) When LocalB optimizes out it can move B to the position of LocalB;1
4) Without this patch, when B swaps with LocalB;1 then LocalB;1 would
settle an owed DTMF end to the bridge toward LocalA;2.
5) When B finally ends its DTMF it sends the DTMF end down the chain.
6) Without this patch, A would hear the DTMF digit end when LocalB
optimizes out and when B ends the original digit.

ASTERISK-25582

Change-Id: I1bbd28b8b399c0fb54985a5747f330a4cd2aa251

Frame hooks can conceivably return a control frame in exchange for an
audio frame inside ast_write().  Those returned control frames were not
handled quite the same as if they were sent to ast_indicate().  Now it
doesn't matter if you use ast_write() to send an AST_FRAME_CONTROL to a
channel or ast_indicate().

ASTERISK-25582

Change-Id: I5775f41421aca2b510128198e9b827bf9169629b

The ast_sorcery_create, update and delete function have been refactored
to better deal with caches and errors.

The action is now called on all non-caching wizards first. If ANY succeed,
the action is called on all caching wizards and the observers are notified.
This way we don't put something in the cache (or update or delete) before
knowing the action was performed in at least 1 backend and we only call the
observers once even if there were multiple writable backends.

ast_sorcery_create was never adding to caches in the first place which
was preventing contacts from getting added to a memory_cache when they
were created.  In turn this was causing memory_cache to emit errors if
the contact was deleted before being retrieved (which would have
populated the cache).

ASTERISK-25811 #close
Reported-by: Ross Beer

Change-Id: Id5596ce691685a79886e57b0865888458d6e7b46

There are a few cases where we're emitting notices or warnings
for things that really need neither, like a client retrying to subscribe
to mwi when they're not conifgured for it.  They get a 404 so there's no
need for non-debug messages.

Change-Id: I05e38a7ff6c2f2521146f4be6a79731b9864e61f

A few of the CLI commands weren't checking for enough arguments
and were SEGVing.

Change-Id: Ie6494132ad2fe54b4f014bcdc112a37c36a9b413

Change-Id: Ib462633d396fa941379dfef648dcd2245e350084

Use the correct comparison function since we only care if the address
without the port is the same.

Change-Id: Ibf6c485f843a1be6dee58a47b33d81a7a8cbe3b0

Introduced realloaction of ast_str buf in sqlite3_escape functions in case
the returned buffer from threadstorage was actually too small.

Change-Id: I3c5eb43aaade93ee457943daddc651781954c445

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

When Asterisk receives a 412 (Conditional Request Failed) response
it has to recreate publish session.
There is bug in res_pjsip_outbound_publish.c
The function sip_outbound_publish_client_alloc is called with wrong object
while processing 412 (Conditional Request Failed) response.
This patch fixes it.

ASTERISK-25229 #close

Change-Id: I3b62f2debf6bb1e5817cde7b13ea39ef2bf14359

The threadpool_auto_increment test fails infrequently for a couple of
reasons
* The threadpool listener was notified of fewer tasks being pushed than
  were actually pushed
* The "was_empty" flag was set to an unexpected value.

The problem is that the test pushes three tasks into the threadpool.
Test expects the threadpool to essentially gather those three tasks, and
then distribute those to the threadpool threads. It also expects that as
the tasks are pushed in, the threadpool listener is alerted immediately
that the tasks have been pushed. In reality, a task can be distributed
to the threadpool threads quicker than expected, meaning that the
threadpool has already emptied by the time each subsequent task is
pushed. In addition, the internal threadpool queue can be delayed so
that the threadpool listener is not alerted that a task has been pushed
even after the task has been executed.

From the test's point of view, there's no way to be able to predict
exactly the order that task execution/listener notifications will occur,
and there is no way to know which listener notifications will indicate
that the threadpool was previously empty.

For this reason, the test has been updated to only check the things it
can check. It ensures that all tasks get executed, that the threads go
idle after the tasks are executed, and that the listener is told the
proper number of tasks that were pushed.

Change-Id: I7673120d74adad64ae6894594a606e102d9a1f2c

The return type of ast_cel_track_event() is not large enough to return all
64 potential bits of the event enable mask.  Fortunately, the defined CEL
events do not really need all 64 bits and the return value is only used to
determine if the requested CEL event is enabled.

* Made the ast_cel_track_event() return 0 or 1 only so the return value
can fit inside an int type instead of zero or a truncated 64 bit non-zero
value.

Change-Id: I783d932320db11a95c7bf7636a72b6fe2566904c

Fix calculate of average time for talktime is wrong when is completed the
first call beacuse the time for talked would be that call.

ASTERISK-25800 #close

Change-Id: I94f79028935913cd9174b090b52bb300b91b9492

res_odbc.exports.in was missing a few symbols.
Changed to wildcards.

Change-Id: Ieadd76df24e43ea92577f651d478a0f7b742c30c