Although the dlg session count was incremented in a pjsip servant
thread, there's no guarantee that the last thread to unref this
progress object was one.  Before we decrement, we need to make
sure that this is either a servant thread or that we push the
decrement to a serializer that is one.

Because pjsip_dlg_dec_session requires the dialog lock, we don't
want to wait on the task to complete if we had to push it to a
serializer.

Change-Id: I8ff2d5d94be3ff04298394070434e22a7d3cbc41

Although refer_progress_notify() always runs in the progress
serializer, the pjproject evsub module itself can cause the
subscription to be destroyed which then triggers
refer_progress_on_evsub_state() to clean it up.  In this case,
it's possible that refer_progress_notify() could get the
subscription pulled out from under it while it's trying to use
it.

At one point we tried to have refer_progress_on_evsub_state()
push the cleanup to the serializer and wait for its return before
returning to pjproject but since pjproject calls its state
callbacks with the dialog locked, this required us to unlock the
dialog while waiting for the serialized cleanup, then lock it
again before returning to pjproject. There were also still some
cases where other callers of refer_progress_notify() weren't
using the serializer and crashes were resulting.

Although all callers of refer_progress_notify() now use the
progress serializer, we decided to simplify the locking so we
didn't have to unlock and relock the dialog in
refer_progress_on_evsub_state().

Now, refer_progress_notify() holds the dialog lock for its
duration and since pjproject also holds the dialog lock while
calling refer_progress_on_evsub_state() (which does the cleanup),
there should be no more chances for the subscription to be
cleaned up while still being used to send NOTIFYs.

To be extra safe, we also now increment the session count on
the dialog when we create a progress object and decrement
the count when the progress is destroyed.

ASTERISK-29313

Change-Id: I97a8bb01771a3c85345649b8124507f7622a8480

refer_progress_notify wasn't always being called from the progress
serializer.  This could allow clearing notification->progress->sub
in one thread while another was trying to use it.

* Instances where refer_progress_notify was being called in-line,
  have been changed to use ast_sip_push_task().

Change-Id: Idcf1934c4e873f2c82e2d106f8d9f040caf9fa1e

ASTERISK-28838

Change-Id: Ic693c3f464e35ec0db242afdb0a1415806af4e25

ASTERISK-28766 #close

Change-Id: I5ce2210062f9325db762edbf6e46075079bb2cd1

Added a new PJSIP global setting called norefersub.
Default is true to keep support working as before.

res_pjsip_refer:  Configures PJSIP norefersub capability accordingly.

Checks the PJSIP global setting value.
If it is true (default) it adds the norefersub capability to PJSIP.
If it is false (disabled) it does not add the norefersub capability
to PJSIP.

This is useful for Cisco switches that do not follow RFC4488.

ASTERISK-28375 #close
Reported-by: Dan Cropp

Change-Id: I0b1c28ebc905d881f4a16e752715487a688b30e9

When a channel snapshot was created it used to be done
from scratch, copying all data (many strings). This incurs
a cost when doing so.

This change segments the channel snapshot into different
components which can be reused if unchanged from the
previous snapshot creation, reducing the cost. In normal
cases this results in some pointers being copied with
reference count being bumped, some integers being set,
and a string or two copied. The other benefit is that it
is now possible to determine if a channel snapshot update
is redundant and thus stop it before a message is published
to stasis.

The specific segments in the channel snapshot were split up
based on whether they are changed together, how often they
are changed, and their general grouping. In practice only
1 (or 0) of the segments actually get changed in normal
operation.

Invalidation is done by setting a flag on the channel when
the segment source is changed, forcing creation of a new
segment when the channel snapshot is created.

ASTERISK-28119

Change-Id: I5d7ef3df963a88ac47bc187d73c5225c315f8423

This change adds the ability for subscriptions to indicate
which message types they are interested in accepting. By
doing so the filtering is done before being dispatched
to the subscriber, reducing the amount of work that has
to be done.

This is optional and if a subscriber does not add
message types they wish to accept and set the subscription
to selective filtering the previous behavior is preserved
and they receive all messages.

There is also the ability to explicitly force the reception
of all messages for cases such as AMI or ARI where a large
number of messages are expected that are then generically
converted into a different format.

ASTERISK-28103

Change-Id: I99bee23895baa0a117985d51683f7963b77aa190

ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer.  If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer.  Reentrancy issues could result if the
task does not execute with the right serializer.

The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936).  A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().

However, there are a few places where this unexpected behavior is still
required to avoid deadlocks.  The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer.  I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().

* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous().  ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in.  Both functions
behave the same if the current thread is not a SIP servant.

* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.

ASTERISK_26806

Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3

There is a problem when an INVITE-with-Replaces transfer targets a channel
in a ConfBridge.  The transfer will unconditionally swap out the
ConfBridge channel.  Unfortunately, the ConfBridge state will not be aware
of this change.  Unexpected behavior will happen as a result since
ConfBridge channels currently can only be replaced by a masquerade and not
normal bridge channel moves.

* We just need to pretend that the channel isn't in a bridge (like other
transfer methods already do) so the transfer channel will masquerade into
the ConfBridge channel.

Change-Id: I209beb0e748fa4f4b92a576f36afa8f495ba4c82

The transferrer's session channel was destroyed by the transferrer's
serializer thread in a race condition with the transfer target's
serializer thread during an attended transfer.  The transfer target's
serializer was attempting to clean up a deferred end status on behalf of
the transferrer's channel when it should have passed the action to the
transferrer's serializer.  When the transfer target's serializer lost the
race then both threads wind up trying to end the transferrer's session.

* Push the ast_sip_session_end_if_deferred() call onto the transferrer's
serializer to avoid a race condition that results in a crash.  The
session_end() function that could be called by
ast_sip_session_end_if_deferred() really must be executed by the
transferrer's serializer to avoid this kind of crash.

ASTERISK-27568

Change-Id: Iacda724e7cb24d7520e49b2fd7e504aa398d7238

This removes references that are no longer needed due to automatic
references created by module dependencies.

In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.

Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e

* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.

Still need to investigate dependencies among modules I cannot compile.

Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf

Prevent unload of the module as certain pjsip initialization functions
cannot be reversed.

ASTERISK-24483

Change-Id: I94597ec8b8491f5af9c57bf66dbc3b078fe2d49d

When doing an attended transfer it's possible for the transferer, after
receiving an accepted response from Asterisk, to send a BYE to Asterisk,
which can then be processed before Asterisk has time to start and/or
complete the transfer process. This of course causes the transfer to not
complete successfully, thus dropping the call.

This patch makes it so any BYEs received from the transferer, after the REFER,
that initiate a session end are deferred until the transfer is complete. This
allows the channel that would have otherwise been hung up by Asterisk to
remain available throughout the transfer process.

ASTERISK-27053 #close

Change-Id: I43586db79079457d92d71f1fd993be9a3b409d5a

This option was added to turn off notifying the progress details
on Blind Transfer. If this option is not set then the chan_pjsip
will send NOTIFY "200 OK" immediately after "202 Accepted".

Some SIP phones like Mitel/Aastra or Snom keep the line busy until
receive "200 OK".

ASTERISK-26333 #close

Change-Id: Id606fbff2e02e967c02138457badc399144720f2

When transfering to a URI without an extension, ensure that the
s extension of the dialplan is entered

ASTERISK-26869 #close

Change-Id: I07403df66cf93f09e00a40ab5b41bfc6f72b1525

ASTERISK-26684 #close

Change-Id: Ifd7e401c45015119dd5e8421dbfe3afa6381744a

refer_incoming_refer_request needed to look for the "r" header as well
as the "Refer-To" header.

ASTERISK-26655 #close
patches:
	refer_compact_fix.diff	submitted by JoshE (license 6075)

Change-Id: I610410a99b02427ea5db887aeb454d5f12c2259f

This implements the chan_sip legacy_useroption_parsing option but with a
better name.

* Made the caller-id number and redirecting number strings obtained from
incoming SIP URI user fields always truncated at the first semicolon.
People don't care about anything after the semicolon showing up on their
displays even though the RFC allows the semicolon.

ASTERISK-26316 #close
Reported by: Kevin Harwell

Change-Id: Ib42b0e940dd34d84c7b14bc2e90d1ba392624f62

The framehook container could become corrupted if the channel lock is not
held before calling.

Change-Id: If0a1c7ba0484ed3a191106a7516526b905952584

The framehook container could become corrupted if the channel lock is not
held before calling.

Change-Id: I1a6b957a1f7b899eb29a186915f8cccab886a438

pjsip_inv_end_session() is documented as being able to return the
passed in tdata parameter set to NULL on success.

Change-Id: I09d53725c49b7183c41bfa1be3ff225f3a8d3047

The "Refer-to" header of an incoming REFER request is parsed by
pjsip_parse_uri().  That function requires the URI parameter to be NULL
terminated.  Unfortunately, the previous code added the NULL terminator by
overwriting memory that may not be safe.  The overwritten memory results
could be benign, memory corruption, or a segmentation fault.  Now the URI
is NULL terminated safely by copying the URI to a new chunk of memory with
the correct size to be NULL terminated.

ASTERISK-25814 #close

Change-Id: I32565496684a5a49c3278fce06474b8c94b37342

During the transfer process, some phones (okay it was the Jitsi softphone,
but maybe others are out there) send a "bye" immediately after receiving a
SIP Notify. When a "bye" is received early for some types of transfers the
transferer channel may no longer be available during late stage transfer
processing.

For instance, during an attended transfer involving stasis bridging at one
point the created local channel looks for an associated swap channel in
order to retrieve the stasis application name. If the transferer has hung
up then the local channel will fail to find it. The local channel then has
no way to know which stasis app to enter, so it fails and hangs up as well.
Thus the transfer does not complete as expected.

This patch delays the sending of the initial notify in order to give the
transfer process enough time to gather the necessary data for a successful
transfer.

ASTERISK-25771

Change-Id: I09cfc9a5d6ed4c007bc70625e0972b470393bf16

PJSIP name formats:
pjsip/aor/<aor>-<seq> -- registrar thread pool serializer
pjsip/default-<seq> -- default thread pool serializer
pjsip/messaging -- messaging thread pool serializer
pjsip/outreg/<registration>-<seq> -- outbound registration thread pool
serializer
pjsip/pubsub/<endpoint>-<seq> -- pubsub thread pool serializer
pjsip/refer/<endpoint>-<seq> -- REFER thread pool serializer
pjsip/session/<endpoint>-<seq> -- session thread pool serializer
pjsip/websocket-<seq> -- websocket thread pool serializer

Change-Id: Iff9df8da3ddae1132cb2ef65f64df0c465c5e084

res_pjsip_refer will attempt to add Referred-By or Replaces headers to
outbound INVITEs at times. If the INVITE gets challenged for
authentication, then we will resend the INVITE. Prior to this patch, the
Referred-By or Replaces header would be re-added to the outbound INVITE,
resulting in duplicated headers.

ASTERISK-25204 #close
Reported by Mark Michelson

Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d

Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723

A race condition happened between initiating a transfer and requesting
that a dialog termination be delayed.  Occasionally, the transferrer
channels would exit the bridge and hangup before the dialog termination
delay was requested.

* Made request dialog termination delay before initiating the transfer
action.  If the transfer fails then cancel the delayed dialog termination
request.

ASTERISK-24755 #close
Reported by: John Bigelow

Review: https://reviewboard.asterisk.org/r/4460/
........

Merged revisions 432668 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432669 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Made safely get the TRANSFER_CONTEXT channel value while the channel is
locked in refer_incoming_attended_request() and
refer_incoming_blind_request().  The pointer returned by
pbx_builtin_getvar_helper() is only valid while the channel is locked.
........

Merged revisions 432594 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432595 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The lock is unused.
........

Merged revisions 432574 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432579 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Fixed hangup handling of the session->channel after answer if the
ast_channel_move() or ast_bridge_impart() fails.  We are still the thread
controlling the session->channel so we need to call ast_hangup() to kill
the channel.

* Fixed debug messages in refer_incoming_invite_request() referencing
incorrect channnels on success.  Code comments now say why the
session->channel cannot be used.

Review: https://reviewboard.asterisk.org/r/4422/
........

Merged revisions 431956 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431957 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer.  The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision.  Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.

* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.

* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.

* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.

ASTERISK-24700 #close
Reported by: Zane Conkle

Review: https://reviewboard.asterisk.org/r/4417/
........

Merged revisions 431898 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431899 65c4cc65-6c06-0410-ace0-fbb531ad65f3

These memory leaks were found and fixed by John Hardin. I'm just
committing them for him.

ASTERISK-24736 #close
Reported by Mark Michelson

Review: https://reviewboard.asterisk.org/r/4389
........

Merged revisions 431468 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431469 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This fix has two parts:

* Corrected an error message to properly state that external_replaces is an extension. The
  error message also prints what dialplan context the external_replaces extension was being
  looked for in.
* Corrected the printing of the Replaces: header in an INVITE request. We were duplicating
  "Replaces: " in the header.

ASTERISK-24376 #close
Reported by Matt Jordan

Review: https://reviewboard.asterisk.org/r/4296
........

Merged revisions 430313 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430314 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There are two methods within res_pjsip_refer for keeping track of the state of a transfer.
The first is a framehook which looks at frames passing by to determine the state. The second
subscribes to know when the channel joins a bridge. In the case when the channel joins the
bridge the framehook is *NOT* removed and this prevents the native RTP bridging technology
from getting used.

This change gets the channel and if it still exists remove the framehook.

Review: https://reviewboard.asterisk.org/r/4218/
........

Merged revisions 428760 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 428761 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428762 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.

For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
  a single message - the subscription is created, a message is published, the
  delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.

This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.

Review: https://reviewboard.asterisk.org/r/4193

ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........

Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The implementation of INVITE with Replaces in res_pjsip_refer did not expect them to
occur in-dialog. As a result it would incorrectly attempt to hang up a channel it
thought was under its control. In reality the channel would be under the control of
another thread. When the other thread accessed the channel it would be accessing freed
memory and could crash.

This change makes res_pjsip_refer not act on an in-dialog INVITE with Replaces.

ASTERISK-24528 #close
Reported by: Joshua Colp
........

Merged revisions 428304 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 428305 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428306 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There is no guarantee that when we get a Refer-To that it will be NULL terminated.
As the URI parsing function requires it to be we now NULL terminate it.

Additionally parsing the Refer-To as a 'To' header is needless and it can
simply be done as a URI. This also fixes a problem where certain Refer-To headers
would not be parsed as a 'To' header causing the REFER to fail.

ASTERISK-24508 #close
Reported by: Beppo Mazzucato

Review: https://reviewboard.asterisk.org/r/4187/
........

Merged revisions 428195 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 428196 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428197 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub
have loaded properly before attempting to load any modules that depend
on them since the module loader system is not currently capable of
resolving module dependencies on its own.

ASTERISK-24312 #close
Reported by: Dafi Ni
Review: https://reviewboard.asterisk.org/r/4062/
........

Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 425691 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425700 65c4cc65-6c06-0410-ace0-fbb531ad65f3