The entry for 'identify' was incorrectly placed in the
res_pjsip section when it should be in
res_pjsip_endpoint_identifier_ip.

ASTERISK-26785 #close

Change-Id: Ia1372b12a952bfe2df6b1b1e0e725ca306a5d41a

This reverts commit 6492e913.

The change in question was intended to prevent the need to reload in
order to update qualifies on contacts when an AOR changes. However, this
ended up causing a deadlock instead.

Change-Id: I1a835c90a5bb65b6dc3a1e94cddc12a4afc3d71e

When performing an SRV lookup using the ast_srv_lookup function it
did not properly handle the situation where 0 records are returned.
If this happened it would wrongly assume that at least one record
was present.

This change fixes the code so it will exit early if an error occurs
or if 0 records are returned.

ASTERISK-26772
patches:
  srv_lookup.patch submitted by nappsoft (license 6822)

Change-Id: I09b19081c74e0ad11c12bf54a257243b1bcb2351

The adding and removing of device state subscriptions did not protect
fully against simultaneous manipulation. In particular the subscribe
case allowed a small window where two subscriptions could be added for
the same device state instead of just one.

This change makes the code hold the subscriptions lock for the entirety
of each operation to ensure that two are not occurring at the same time.

ASTERISK-26770

Change-Id: I3e7f8eb9d09de440c9024d2dd52029f6f20e725b

Change-Id: I243a4be5e7fbfe604923764969c4ee04eee89b9d

In ari.conf, when setting the option channelvars, every Stasis channel
snapshot would create a list of variable/value that would not be freed
when the snapshot is freed, resulting in a often-recurring memory
leak.

ASTERISK-26767 #close

Change-Id: Ia37dd9d68063d7f879193df02ede293e5ded716d

Using the timerfd timing module can cause channel freezing, lingering, or
deadlock issues.  The problem is because this is the only timing module
that uses an associated alert-pipe.  When the alert-pipe becomes
unbalanced with respect to the number of frames in the read queue bad
things can happen.  If the alert-pipe has fewer alerts queued than the
read queue then nothing might wake up the thread to handle received frames
from the channel driver.  For local channels this is the only way to wake
up the thread to handle received frames.  Being unbalanced in the other
direction is less of an issue as it will cause unnecessary reads into the
channel driver.

ASTERISK-26716 is an example of this deadlock which was indirectly fixed
by the change that found the need for this patch.

* In channel.c:__ast_queue_frame(): Adding frame lists to the read queue
did not add the same number of alerts to the alert-pipe.  Correspondingly,
when there is an exceptionally long queue event, any removed frames did
not also remove the corresponding number of alerts from the alert-pipe.

ASTERISK-26632 #close

Change-Id: Ia98137c5bf6e9d6d202ce0eb36441851875863f6

A dialplan intercept routine is equivalent to an interrupt routine.  As
such, the routine must be done quickly and you do not have access to the
media stream.  These restrictions are necessary because the media stream
is the responsibility of some other code and interfering with or delaying
that processing is bad.  A possible future dialplan processing
architecture change may allow the interception routine to run in a
different thread from the main thread handling the media and remove the
execution time restriction.

* Made res_agi.c:run_agi() running an AGI in an interception routine run
in DeadAGI mode.  No touchy channel frames.

ASTERISK-25951

ASTERISK-26343

ASTERISK-26716

Change-Id: I638f147ca7a7f2590d7194a8ef4090eb191e4e43

There are several issues with deferring frames that are caused by the
refactoring.

1) The code deferring frames mishandles adding a deferred frame to the
deferred queue.  As a result the deferred queue can only be one frame
long.

2) Deferrable frames can come directly from the channel driver as well as
the read queue.  These frames need to be added to the deferred queue.

3) Whoever is deferring frames is really only doing the __ast_read() to
collect deferred frames and doesn't care about the returned frames except
to detect a hangup event.  When frame deferral is completed we must make
the normal frame processing see the hangup as a frame anyway.  As such,
there is no need to have varying hangup frame deferral methods.  We also
need to be aware of the AST_SOFTHANGUP_ASYNCGOTO hangup that isn't real.
That fake hangup is to cause the PBX thread to break out of loops to go
execute a new dialplan location.

4) To properly deal with deferrable frames from the channel driver as
pointed out by (2) above, means that it is possible to process a dialplan
interception routine while frames are deferred because of the
AST_CONTROL_READ_ACTION control frame.  Deferring frames is not
implemented as a re-entrant operation so you could have the unsupported
case of two sections of code thinking they have control of the media
stream.

A worse problem is because of the bad implementation of the AMI PlayDTMF
action.  It can cause two threads to be deferring frames on the same
channel at the same time.  (ASTERISK_25940)

* Rather than fix all these problems simply revert the API refactoring as
there is going to be only autoservice and safe_sleep deferring frames
anyway.

ASTERISK-26343

ASTERISK-26716 #close

Change-Id: I45069c779aa3a35b6c863f65245a6df2c7865496

ASTERISK-26704 #close
Reported by: Anthony Messina

Change-Id: I976a1f94cf79c5f31e76174c61f5c6a65fd6354f

ASTERISK-26765

Change-Id: I27eb97df7f8d7e624b0b9a61c0fcee4718c86d8d

If an audiohook is placed on a channel that does not require transcoding,
muting that hook will cause the underlying frames to be muted as well.

The original patch is from David Woolley but I have modified slightly.

ASTERISK-21094 #close
Reported by: David Woolley
Patches:
      ASTERISK-21094-Patch-1.8-1.txt (license #5737) patch uploaded
      by David Woolley

Change-Id: Ib2b68c6283e227cbeb5fa478b2d0f625dae338ed

Prior to this change, qualifies would only update in the following
cases:
* A reload of res_pjsip.so was issued.
* A dynamic contact was re-registered after its AOR's qualify_frequency
  had been changed
This does not work well if you are using realtime for your AORs. You can
update your database to have a new qualify_frequency, but the permanent
contacts on that AOR will not have their qualifies updated. And the
dynamic contacts on that AOR will not have their qualifies updated until
the next registration, which could be a long time.

This change seeks to fix this problem by making it so that whenever AOR
configuration is applied, the contacts pertaining to that AOR have their
qualifies updated.

Additions from this patch:
* AOR sorcery objects now have an apply handler that calls into a newly
  added function in the OPTIONS code. This causes all contacts
  associated with that AOR to re-schedule qualifies.
* When it is time to qualify a contact, the OPTIONS code checks to see
  if the AOR can still be retrieved. If not, then qualification is
  canceled on the contact.

Alterations from this patch:
* The registrar code no longer updates contact's qualify_frequence and
  qualify_timeout. There is no point to this since those values already
  get updated when the AOR changes.
* Reloading res_pjsip.so no longer calls the OPTIONS initialization
  function. Reloading res_pjsip.so results in re-loading AORs, which
  results in re-scheduling qualifies.

Change-Id: I2e7c3316da28f389c45954f24c4e9389abac1121

There are some error cases in PJSIP when sending a request that will
result in the callback for the request being invoked.  The code did not
handle this case and assumed on every error case that the callback was not
invoked.

The code has been changed to check whether the callback has been invoked
and if so to absorb the error and treat it as a success.

ASTERISK-26679
ASTERISK-26699

Change-Id: I563982ba204da5aa1428989a11c06dd9087fea91

Before Asterisk 13, signed linear was converted into network byte order by a
smoother before being sent over the network. We restore this behavior by
forcing the creation of a smoother when slinear is in use and setting the
appropriate flags so that the byte order conversion is always done.

ASTERISK-24858 #close
Reported-by: Frankie Chin

Change-Id: I868449617d1a7819578f218c8c6b2111ad84f5a9

Forgot to install it with the original patch

Change-Id: I8bdb540a6694971ae5fe21f48d532332c6482e4c

The escalator works by creating a set of startup commands in cli.conf
that set up logger channels and issue the debug commands for the
subsystems specified.  If asterisk is running when it is executed,
the same commands will be issued to the running instance.  The original
cli.conf is saved before any changes are made and can be restored by
executing '$prog --reset'.

The log output will be stored in...
$astlogdir/message.$uniqueid
$astlogdir/debug.$uniqueid
$astlogdir/dtmf.$uniqueid
$astlogdir/fax.$uniqueid
$astlogdir/security.$uniqueid
$astlogdir/pjsip_history.$uniqueid
$astlogdir/sip_history.$uniqueid

Some minor tweaks were made to chan_sip, and res_pjsip_history
so their history output could be send to a log channel as packets
are captured.

A minor tweak was also made to manager so events are output to verbose
when "manager set debug on" is issued.

Change-Id: I799f8e5013b86dc5282961b27383d134bf09e543

Issue introduced in b59956a8.  In the non-darwin case libastssl/pj
should be versioned.  This causes the symbol file for this lib
to not be generated.

Change-Id: Ib07ae8c40252813c488e2c1ac6204fd42816dd4c
(cherry picked from commit 54b02791)

LikewiseOpen creates user names with a backslash in them. A gentle
massage with sed(1) allows such strings to be inserted into build.h
properly quoted. I am also adding the same for host name and other
strings used in the script that are more or less user-controlled.

ASTERISK-26754

Change-Id: Iac5ef2b67a68ee58f35ddbf86bb818ba6eabecae

With 500+ queues and a reload every minute, a random queue disappears
upon reload. The cause is mususe of the 'dead' flag. Namely, all queues
were marked dead up front, and then "resurrected" by dropping this flag
for those found in the configuration. But a queue marked dead can be
removed also when control leaves the app entry point on a PBX thread.

With this change, the queue is marked only not found, and at the end of
reload only the queues that are still not found are actually marked as
dead, so the dead flag is never reset, and set only on positively dead
queues.

ASTERISK-26755

Change-Id: I3a4537aec9eb8d8aeeaa0193407e3523feb004bf