Created new SCOPE_ functions that don't depend on RAII_VAR.  Besides
generating less code, the use of the explicit SCOPE_EXIT macros
capture the line number where the scope exited.  The RAII_VAR
versions can't do that.

 * SCOPE_ENTER(level, ...): Like SCOPE_TRACE but doesn't use
   RAII_VAR and therefore needs needs one of...

 * SCOPE_EXIT(...): Decrements the trace stack counter and optionally
   prints a message.

 * SCOPE_EXIT_EXPR(__expr, ...): Decrements the trace stack counter,
   optionally prints a message, then executes the expression.
   SCOPE_EXIT_EXPR(break, "My while got broken\n");

 * SCOPE_EXIT_RTN(, ...): Decrements the trace stack counter,
   optionally prints a message, then returns without a value.
   SCOPE_EXIT_RTN("Bye\n");

 * SCOPE_EXIT_RTN_VALUE(__return_value, ...): Decrements the trace
   stack counter, optionally prints a message, then returns the value
   specified.
   SCOPE_EXIT_RTN_VALUE(rc, "Returning with RC: %d\n", rc);

Create an ast_str helper ast_str_tmp() that allocates a temporary
ast_str that can be passed to a function that needs it, then frees
it.  This makes using the above macros easier.  Example:

   SCOPE_ENTER(1, Format Caps 1: %s  Format Caps 2: %s\n",
       ast_str_tmp(32, ast_format_cap_get_names(cap1, &STR_TMP),
       ast_str_tmp(32, ast_format_cap_get_names(cap2, &STR_TMP));

The calls to ast_str_tmp create an ast_str of the specified initial
length which can be referenced as STR_TMP.  It then calls the
expression, which must return a char *, ast_strdupa's it, frees
STR_TMP, then returns the ast_strdupa'd string.  That string is
freed when the function returns.

Change-Id: I44059b20d55a889aa91440d2f8a590865998be51

The outbound proxy for an AOR was not being applied to
any statically configured Contacts. This resulted in the
OPTIONS requests being sent to the wrong target.

This change sets the outbound proxy on statically configured
contacts once the AOR configuration is done being
applied.

ASTERISK-28965

Change-Id: Ia60f3e93ea63f819c5a46bc8b54be2e588dfa9e0

Given a scenario where a module has a dependency on both
an external library and a module if the external library was
available and the module was not an infinite loop would
occur. This happened due to the code changing the dependecy
status to no failure on each dependency checking loop
iteration, resulting in the code thinking that it had
gone from no failure to failure each time triggering another
dependency check.

This change makes it so that the old dependency status is
preserved throughout the dependency checking allowing it to
determine that after the first iteration the dependency
status does not transition from no failure to failure.

ASTERISK-28930

Change-Id: Iea06d45d9fd6d8bfd068882a0bb7e23a53ec3e84

chan_sip handle_response() function, for a 400 response to an INVITE,
calls handle_response_invite() and does not generate ACK.
handle_response_invite() does not recognize 400 response and has no
default response processing for unexpected responses, thus it does not
generate ACK either.
The ACK on response repetition comes from handle_response() mechanism
"We must re-send ACKs to re-transmitted final responses".

According to code history, 400 response specific processing was
introduced with commit
"channels/chan_sip: Add improved support for 4xx error codes"
This commit added support for :
- 400/414/493 in handle_response_subscribe() handle_response_register()
  and handle_response().
- 414/493 only in handle_response_invite().

This fix adds 400 response support in handle_response_invite().

ASTERISK-28957

Change-Id: Ic71a087e5398dfc7273946b9ec6f9a36960218ad

A patch made a reference to the PJSIP_SC_NULL enumeration value, which
was added to pjproject 2.8 and above thus making it so Asterisk would
fail to compile with prior versions of pjproject.

This patch removes the reference, and instead initializes the value
to '0'.

ASTERISK-28886 #close

Change-Id: I68491c80da1a0154b2286c9458440141c98db9d7

1) Fix memory-leaks
   Added code to release ast_events extracted from corosync and stasis messages

2) Clean stasis cache when a member of the corosync cluster leaves the group
   Added code to remove from the stasis cache of the members remained on the
   group all the messages with the EID of the left member.
   If the device states of the left member remain in the stasis cache of other
   members, they will not be updated anymore and high priority cached values,
   like BUSY, will take precedence over current device states.

3) Stop corosync event propagation when node is not joined to the group
   Updated dispatch_thread_handler code to detect when asterisk is not joined
   to the corosync group and added some condition in publish_event_to_corosync
   code to send corosync messages only when joined.
   When a node is not joined its corosync daemon can't send messages:
   the cpg_mcast_joined function append new messages to the FIFO buffer until
   it's full and then it blocks indefinitely.
   In this scenario if the stasis_message_cb callback, registered by
   res_corosync to handle stasis messages, try to send a corosync messages,
   the thread of the stasis thread-pool will be blocked until the node join
   the corosync cluster.

ASTERISK-28888
Reported by: Università di Bologna - CESIA VoIP

Change-Id: Ie8e99bc23f141a73c13ae6fb1948d148d4de17f2

ASTERISK-28949

Change-Id: Id465030f2b1997b83d408933fdbabe01827469ca

When stream support was added to Asterisk the stream state
was used inconsistently, resulting in odd behavior. This
was then standardized to be the state of a stream from the
perspective of Asterisk.

This change updates the StreamEcho dialplan application
to use the correct state, send only, since we are only
sending to the endpoint and not expecting them to send us
multiple video streams.

ASTERISK-28954

Change-Id: I35bfd533ef1184ffe62586b22bbd253c82872a56

The change to how setvar works for various channels performed in
ASTERISK~23756 missed some required change in the dahdi channel,
where the variables are actually set while reading configuration.
This change should fix the issue.

ASTERISK-28955

Change-Id: Ibfeb7f8cbdd735346dc4028de6a265f24f9df274

When a re-INVITE is received we create a new set of
streams that are then swapped in as the active streams.
We did not preserve the SDP label from the previous
streams, resulting in the label getting lost.

This change ensures that if an SDP label is present
on the previous stream then it is set on the new stream.

ASTERISK-28953

Change-Id: I9dd63b88b562fe96ce5c791a3dae5bcaca258445

The AMI action and CLI command did not take into account the properties
of full backend caching. This resulted in an expired object remaining
removed until a full backend update occurred, instead of having the
object updated when needed.

This change makes it so that the AMI action and CLI command for object
expire will now fail instead of putting the cache into an undesired
state. If full backend caching is enabled then only operations
which act on the entire cache are available.

ASTERISK-28942

Change-Id: Id662d888f177ab566c8e802ad583083b742d21f4

Integrated STIR/SHAKEN support with outgoing INVITEs. When an INVITE is
sent, the caller ID will be checked to see if there is a certificate
that corresponds to it. If so, that information will be retrieved and an
Identity header will be added to the SIP message. The format is:

header.payload.signature;info=<public_key_url>alg=ES256;ppt=shaken

Header, payload, and signature are all BASE64 encoded. The public key
URL is retrieved from the certificate. Currently the algorithm and ppt
are ES256 and shaken, respectively. This message is signed and can be
used for verification on the receiving end.

Two new configuration options have been added to the certificate object:
attestation and origid. The attestation is required and must be A, B, or
C. origid is the origination identifier.

A new utility function has been added as well that takes a string,
allocates space, BASE64 encodes it, then returns it, eliminating the
need to calculate the size yourself.

Change-Id: I1f84d6a5839cb2ed152ef4255b380cfc2de662b4

Because ring_entry() is not called, outgoing->chan is not touched here
either.

ASTERISK-28950
ASTERISK-28644

Change-Id: I564613715dfaf45af868251eb75a451f512af90f

Change-Id: I24b5453df412232cf7f9a171ea4a34b35ad3ae78

Before this changeset, it was possible that a queue member (agent) was
called even though they just got out of a call, and wrapuptime seconds
hadn't passed yet.

This could happen if a member ended a call _between_ a new call attempt
and asterisk trying that particular member for a new call.

In that case, Asterisk would check the hangup time of the
call-before-the-last-call instead of the hangup time of the-last-call.

ASTERISK-28952

Change-Id: Ie0cab8f0e8d639c01cba633d4968ba19873d80b3

This patch makes the usual necessary changes when upgrading to a new
version pjproject. For instance, version number bump, patches removed
from third-party, new *.md5 file added, etc..

This patch also includes a change to the Asterisk pjproject Makefile to
explicitly create the 'source/pjsip-apps/lib' directory. This directory
is no longer there by default so needs to be added so the Asterisk
malloc debug can be built.

This patch also includes some minor changes to Asterisk that were a result
of the upgrade. Specifically, there was a backward incompatibility change
made in 2.10 that modified the "expires header" variable field from a
signed to an unsigned value. This potentially effects comparison. Namely,
those check for a value less than zero. This patch modified a few locations
in the Asterisk code that may have been affected.

Lastly, this patch adds a new macro PJSIP_MINVERSION that can be used to
check a minimum version of pjproject at compile time.

ASTERISK-28899 #close

Change-Id: Iec8821c6cbbc08c369d0e3cd2f14e691b41d0c81

When requesting a Local channel the requested stream topology
or a converted stream topology will now be placed onto the
resulting channels.

Frames written in on streams will now also preserve the stream
identifier as they are queued on the opposite channel.

Finally when a stream topology change is requested it is
immediately accepted and reflected on both channels. Each
channel also receives a queued frame to indicate that the
topology has changed.

ASTERISK-28938

Change-Id: I4e9d94da5230d4bd046dc755651493fce1d87186

If channelId parameters were passed in the body, the Asterisk doesn't parsing it correctly.

Fixed it to parse the channelId, other_channel_id parameter correclty.

ASTERISK-28948

Change-Id: I59b49161a94869169ee19c1ffab5afcef7026157

The "value" passed in when setting an RTP property determines
whether it should be enabled or disabled. The RTP send and
receive retrans props did not examine this to know if the
buffers should be enabled. They assumed they always should be.

This change makes it so that the "value" passed in is
respected.

ASTERISK-28939

Change-Id: I9244cdbdc5fd065c7f6b02cbfa572bc55c7123dc

There are three states that an old stream can be in to allow
becoming a source stream in a new stream:

1. Removed
2. Inactive
3. Sendonly

This change adds the two missing ones, inactive and sendonly,
so if a stream transitions from those to a state where they are
providing video to Asterisk we properly re-negotiate the other
participants.

ASTERISK-28944

Change-Id: Id8256b9b254b403411586284bbaedbf50452de01

When fax_gateway_framehook is called and a gateway hasn't already
been started, the framehook gets the t38 state for both the current
channel and the peer.  That call trickles down to the channel
driver which determines the state.  If either channel is hung up
(or in the process of being hung up), the channel driver's tech_pvt
is going to be NULL which, in the case of chan_pjsip, will cause a
segfault.

* Added a hangup check for both the channel and peer channel
  before starting a fax gateway.

* Added a check for NULL tech_pvt to chan_pjsip_queryoption
  so we don't attempt to reference a tech_pvt that's already
  gone.

ASTERISK-28923
Reported by: Yury Kirsanov

Change-Id: I4e10e63b667bbb68c1c8623f977488f5d807897c

When send_events is enabled for a user, we were leaking a reference
to the bridge channel in confbridge_manager.c:send_message().  This
also caused the bridge snapshot to not be destroyed.

Change-Id: I87a7ae9175e3cd29f6d6a8750e0ec5427bd98e97

This patch fixes a few compile warnings/errors that now occur when using gcc
10+.

Also, the Makefile.rules check to turn off partial inlining in gcc versions
greater or equal to 8.2.1 had a bug where it only it only checked against
versions with at least 3 numbers (ex: 8.2.1 vs 10). This patch now ensures
any version above the specified version is correctly compared.

Change-Id: I54718496eb0c3ce5bd6d427cd279a29e8d2825f9

Added default variable value to fix a compiler error.

Change-Id: I7b592adbb1274dc5464dea1c5e5de0685c928553

If parameters were passed in the body as JSON to the
create route they were not being parsed before checking
to ensure that required fields were set.

This change moves the parsing so it occurs before
checking.

ASTERISK-28940

Change-Id: I898b4c3c7ae1cde19a6840e59f498822701cf5cf

You cannot cast a pjsip_uri to a pjsip_sip_uri using pjsip_uri_get_uri,
without checking that it's a PJSIP_URI_SCHEME_IS_SIP(S).

ASTERISK-28936

Change-Id: I9f572b3677e4730458e9402719e580f8681afe2a

Integrated STIR/SHAKEN support with incoming INVITES. Upon receiving an
INVITE, the Identity header is retrieved, parsing the message to verify
the signature. If any of the parsing fails,
AST_STIR_SHAKEN_VERIFY_NOT_PRESENT will be added to the channel for this
caller ID. If verification itself fails,
AST_STIR_SHAKEN_VERIFY_SIGNATURE_FAILED will be added. If anything in
the payload does not line up with the SIP signaling,
AST_STIR_SHAKEN_VERIFY_MISMATCH will be added. If all of the above steps
pass, then AST_STIR_SHAKEN_VERIFY_PASSED will be added, completing the
verification process.

A new config option has been added to the general section for
stir_shaken.conf. "signature_timeout" is the amount of time a signature
will be considered valid. If an INVITE is received and the amount of
time between when it was received and when it was signed is greater than
signature_timeout, verification will fail.

Some changes were also made to signing and verification. There was an
error where the whole JSON string was being signed rather than the
header combined with the payload. This has been changed to sign the
correct thing. Verification has been changed to do this as well, and the
unit tests have been updated to reflect these changes.

A couple of utility functions have also been added. One decodes a BASE64
string and returns the decoded string, doing all the length calculations
for you. The other retrieves a string value from a header in a rdata
object.

Change-Id: I855f857be3d1c63b64812ac35d9ce0534085b913

If a frame is written to a channel in a bridge we
would normally queue this frame up and the channel
thread would then act upon it. If this frame had no
stream mapping on the channel it would then be
discarded.

This change adds a check before the queueing occurs
to determine if a mapping exists. If it does not
exist then the frame is not even queued at all. This
stops a frame duplication from happening and from
the channel thread having to wake up and deal with
it.

Change-Id: I17189b9b1dec45fc7e4490e8081d444a25a00bda

In a particular fax gateway scenario whereby it would
have to translate using the read translation path on a
channel the frame being translated would be consumed.
When the frame is in the write path it is not permitted
to free the frame as the caller expects it to continue
to exist.

This change makes it so that the frame is only consumed
on the read path where it is acceptable to free it.

ASTERISK-28900

Change-Id: I011c321288a1b056d92b37c85e229f4a28ee737d

The previous change missed that 'make' uses 'PJPROJECT_BUNDLED' anyway.

ASTERISK-28929

Change-Id: I7ef0e78a06ea391b59d95b99d46bbed3fec4fed9

When writing tx messages to pcap files, Asterisk is using the wrong
pointer resulting in lots of wasted space. This patch fixes it to use
the correct pointer.

ASTERISK-28932 #close

Change-Id: I5b8253dd59a083a2ca2c81f232f1d14d33c6fd23

If the bridge show all command could not get the bridge snapshot, it causes null pointer exception.
Fixed it to check the snapshot is null.

ASTERISK-28920

Change-Id: I3521fc1b832bfc69644d0833f2c78177e1e51f58

What's wrong with ast_debug?

  ast_debug is fine for general purpose debug output but it's not
  really geared for scope tracing since it doesn't present its
  output in a way that makes capturing and analyzing flow through
  Asterisk easy.

How is scope tracing better?

  Scope tracing uses the same "cleanup" attribute that RAII_VAR
  uses to print messages to a separate "trace" log level.  Even
  better, the messages are indented and unindented based on a
  thread-local call depth counter.  When output to a separate log
  file, the output is uncluttered and easy to follow.

  Here's an example of the output. The leading timestamps and
  thread ids are removed and the output cut off at 68 columns for
  commit message restrictions but you get the idea.

--> res_pjsip_session.c:3680 handle_incoming PJSIP/1173-00000001
	--> res_pjsip_session.c:3661 handle_incoming_response PJSIP/1173
		--> res_pjsip_session.c:3669 handle_incoming_response PJSIP/
			--> chan_pjsip.c:3265 chan_pjsip_incoming_response_after
				--> chan_pjsip.c:3194 chan_pjsip_incoming_response P
					    chan_pjsip.c:3245 chan_pjsip_incoming_respon
				<-- chan_pjsip.c:3194 chan_pjsip_incoming_response P
			<-- chan_pjsip.c:3265 chan_pjsip_incoming_response_after
		<-- res_pjsip_session.c:3669 handle_incoming_response PJSIP/
	<-- res_pjsip_session.c:3661 handle_incoming_response PJSIP/1173
<-- res_pjsip_session.c:3680 handle_incoming PJSIP/1173-00000001

  The messages with the "-->" or "<--" were produced by including
  the following at the top of each function:

  SCOPE_TRACE(1, "%s\n", ast_sip_session_get_name(session));

  Scope isn't limited to functions any more than RAII_VAR is.  You
  can also see entry and exit from "if", "for", "while", etc blocks.

  There is also an ast_trace() macro that doesn't track entry or
  exit but simply outputs a message to the trace log using the
  current indent level.  The deepest message in the sample
  (chan_pjsip.c:3245) was used to indicate which "case" in a
  "select" was executed.

How do you use it?

  More documentation is available in logger.h but here's an overview:

  * Configure with --enable-dev-mode.  Like debug, scope tracing
    is #ifdef'd out if devmode isn't enabled.

  * Add a SCOPE_TRACE() call to the top of your function.

  * Set a logger channel in logger.conf to output the "trace" level.

  * Use the CLI (or cli.conf) to set a trace level similar to setting
    debug level... CLI> core set trace 2 res_pjsip.so

Summary Of Changes:

  * Added LOG_TRACE logger level.  Actually it occupies the slot
    formerly occupied by the now defunct "event" level.

  * Added core asterisk option "trace" similar to debug.  Includes
	ability to specify global trace level in asterisk.conf and CLI
	commands to turn on/off and set levels.  Levels can be set
	globally (probably not a good idea), or by module/source file.

  * Updated sample asterisk.conf and logger.conf.  Tracing is
    disabled by default in both.

  * Added __ast_trace() to logger.c which keeps track of the indent
    level using TLS. It's #ifdef'd out if devmode isn't enabled.

  * Added ast_trace() and SCOPE_TRACE() macros to logger.h.
    These are all #ifdef'd out if devmode isn't enabled.

Why not use gcc's -finstrument-functions capability?

  gcc's facility doesn't allow access to local data and doesn't
  operate on non-function scopes.

Known Issues:

  The only know issue is that we currently don't know the line
  number where the scope exited.  It's reported as the same place
  the scope was entered.  There's probably a way to get around it
  but it might involve looking at the stack and doing an 'addr2line'
  to get the line number.  Kind of like ast_backtrace() does.
  Not sure if it's worth it.

Change-Id: Ic5ebb859883f9c10a08c5630802de33500cad027

files

fwrite() does return the number of elements written and not the
number of bytes. However asterisk is currently comparing the return
value to the size of the written element what means that asterisk logs
five WARNING messages on every packet written to the pcap file.

This patch changes the code to check for the correct value, which will
always be 1.

ASTERISK-28921 #close

Change-Id: I2455032d9cb4c5a500692923f9e2a22e68b08fc2

When replacing the user portion of the Contact URI the code
was using the ephemeral pool instead of the tdata pool. This
could cause the Contact user value to become invalid after a
period of time.

The code will now use the tdata pool which persists for the
lifetime of the message instead.

ASTERISK-28794

Change-Id: I31e7b958e397cbdaeedd0ebb70bcf8dd2ed3c4d5

While asterisk is filtering out the x-ast-orig-host parameter from the
contact on response messages, it is not filtering it out from the
request URI and the to header on SIP requests (for example INVITE).

ASTERISK-28884 #close

Change-Id: Id032b33098a1befea9b243ca994184baecccc59e

When bridging channels we were trying to match the audio
formats of both sides in combination with the configured
formats. While this is allowed in SDP in practice this
causes extra reinvites and problems. This change ensures
that audio streams use the formats of the first existing
active audio stream. It is only when other stream types
(like video) exist that this will result in re-negotiation
occurring for those streams only.

ASTERISK-28871

Change-Id: I22f5a3e7db29e00c165e74d05d10856f6086fe47

When a configuration file in Asterisk is loaded
information about it is stored such that on a
reload it is not reloaded if nothing has changed.
This can be problematic when an error exists in
a configuration file in PJSIP since the error
will be output at start and not subsequently on
reload if the file is unchanged.

This change makes it so that if an error is
encountered when res_sorcery_config is loading
a configuration file a reload will always read
in the configuration file, allowing the error
to be seen easier.

Change-Id: If2e05a017570f1f5f4f49120da09601e9ecdf9ed

The flags of a previous selection could have been set within the
object 'srtp', for example, when the previous selection returned
failure after setting just 'some' flags. Now, not to clutter the
code, all possible flags are cleared first, and then the selected
flags are set as before.

ASTERISK-28903

Change-Id: I1b9d7aade7d5120244ce7e3a8865518cbd6e0eee

When receiving audio from a channel we determine if it
is talking or silence based on a threshold value. If
this threshold is met we always mix the audio into the
conference bridge. If this threshold is not met we also
mix the audio into the conference bridge UNLESS the
drop silence option is enabled.

The code that removed the audio from the mixed frame
assumed that it was always not present if it did not
meet the threshold to be considered talking. This is
incorrect. If it has been stated that the audio was
mixed into the mixed frame then it has been mixed into
the mixed frame. By not removing audio that was
considered non-talking it was possible for a channel
to receive a slight echo of audio of itself at times.

This change ensures that the audio is always removed
from the mixed frame going back to the channel so it
no longer receives the slight echo.

ASTERISK-28898

Change-Id: I7b1b582cc1bcdb318ecc60c9d2e3d87ae31d55cb