ASTERISK-26775 #close

Change-Id: I86de4b1a699d6edc77fea9b70d839440e4088284

This change adds the media stream topology definition and API for
accessing and using it.

Some refactoring of the stream was also done.

ASTERISK-26786

Change-Id: Ic930232d24d5ad66dcabc14e9b359e0ff8e7f568

When PJSIP tries to call an endpoint with a domain (e.g. 1000@test.com),
the user part is stripped down as it would be a trunk with a specified user,
and only the host part is called as a PJSIP endpoint and can't be found.
This is not correct in the case of a multidomain SIP account, so the stripping
after the @ sign is done only if the whole endpoint (in multidomain case
1000@test.com) can't be found.

ASTERISK-26248

Change-Id: I3a2dd6f57f3bd042df46b961eccd81d31ab202e6

The original return value corresponded to AST_SIP_AUTHENTICATION_CHALLENGE
but we have no authenticator registered to create the challenge.

Change-Id: I62368180d774b497411b80fbaabd0c80841f8512

In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c496. This patch
restores that behavior.

This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.

ASTERISK-26115 #close
Reported by: Nasir Iqbal

Change-Id: I8afbd06725e99610e02adb529137d4800c05345d

We shouldn't unlock the channel after starting a snapshot staging because
another thread may interfere and do its own snapshot staging.

* app_dial.c:dial_exec_full() made hold the channel lock while setting up
the outgoing channel staging.  Made hold the channel lock after the called
party answers while updating the caller channel staging.

* chan_sip.c:sip_new() completed the channel staging on off-nominal exit.
Also we need to use ast_hangup() instead of ast_channel_unref() at that
location.

* channel.c:__ast_channel_alloc_ap() added a comment about not needing to
complete the channel snapshot staging on off-nominal exit paths.

* rtp_engine.c:ast_rtp_instance_set_stats_vars() made hold the channel
locks while staging the channels for the stats channel variables.

Change-Id: Iefb6336893163f6447bad65568722ad5d5d8212a

This change adds the media stream definition and API for
accessing and using it. Unit tests have also been written
which exercise aspects of the API.

ASTERISK-26773

Change-Id: I3dbe54065b55aaa51f467e1a3bafd67fb48cac87

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