Fixed #2172: Avoid double reference counter decrements in
timer in the scenario of race condition between
pj_timer_heap_cancel() and pj_timer_heap_poll().

Change-Id: If000e9438c83ac5084b678eb811e902c035bd2d8

This ensures that Asterisk responds properly to frames received from a
client with opcode 8 (CLOSE) by echoing back the status code in its own
CLOSE frame.

Handling of the CLOSE opcode is moved up with the rest of the opcodes so
that unmasking gets applied. The payload is no longer returned to the
caller, but neither ARI nor the chan_sip nor pjsip made use of the
payload, which is a good thing since it was masked.

ASTERISK-28231 #close

Change-Id: Icb1b60205fc77ee970ddc91d1f545671781344cf

The transport management code that checks for idle connections keeps a
reference to PJSIP's transport for IDLE_TIMEOUT milliseconds (32000 by
default). Because of this, if the transport is closed before this
timeout, the idle checking code will keep the transport from actually
being shutdown until the timeout expires.

Rather than passing the AO2 object to the scheduler task, we just pass
its key and look it up when it is time to potentially close the idle
connection. The other transport management code handles cleaning up
everything else for us.

Additionally, because we use the address of the transport when
generating its name, we concatenate an incrementing ID to the end of the
name to guarantee uniqueness.

Related to ASTERISK~28231

Change-Id: I02ee9f4073b6abca9169d30c47aa69b5e8ae9afb

If the Monitor is started with the i option the read_stream will be
NULL. One code path in channel.c checks if write_stream is set but than
uses read_stream instead causing a segfault.

ASTERISK-28249

Change-Id: I1bae9126537be54895c7fea2d08dd9488d8cc525

Change-Id: I66b8b2b2778f186919d73ae9bf592104b8fb1cd5

When --enable-dev-mode is used, pjsip_tpmgr_receive_packet() will assert
if passed a payload length of 0, so treat empty frames as if we didn't
receive them.

Change-Id: I9c5fdccd89cc8d2f3ed7e3ee405ef0fc78178f48

During Bridging of two channels if masquerade operation is performed on a
channel (clone channel) which was created with endpoint details
(ast_channel_alloc_with_endpoint()) and the original channel which is created
without endpoint details (ast_channel_alloc()) then both the channels must
exchange their endpoint details or else after masquerade when clone channel
is being destroyed the endpoint cleanup callbacks will be destroyed too and
after call completion unique_id of original channel will still be there in
ast_endpoint structure's channel_ids container.

ASTERISK-28197

Change-Id: I97ce73da390af20fd082fb09d722a6fe9cb2f39d

The commit I2f97ebfa79969a36a97bb7b9afd5b6268cf1a07d removed sending out
the ContactStatus AMI event when a contact is updated.
Thist change broke things which rely on old behavior.

This patch adds a new PJSIP global configuration option
'send_contact_status_on_update_registration' to be able to preserve old
ContactStatus behavior.
By default new behavior, i.e. the ContactStatus event will not be sent when a
device refreshes its registration.

Change-Id: I706adf7584e7077eb6bde6d9799ca408bc82ce46

For video streams it was possible for the abs-send-time information
to be placed into RTP streams even if not negotiated. Depending on
the endpoint in use this could cause video to not flow.

We now only enable abs-send-time for negotiation if WebRTC is enabled.

ASTERISK-28230

Change-Id: I0eb682302f8da3a4ea3c42e839208d55f825ed0c

This prevents use-after-scope issues when unwinding the stack,
which happens in reverse order. The varname variable needs to
remain alive for the destruction to be able to access it.
Issue was found using clang + address-sanitizer.

ASTERISK-28232 #close

Change-Id: I00811c34ae910836a5fb6d22304528aef92624db

The remote side may start a new stream when renegotiating RTP.
Need to reset the DTMF last sequence number and the timestamp
of the last END packet on RTP renegotiation.

If the new time stamp is lower then the timestamp of the last DTMF END packet
the asterisk drops all DTMF frames as out of order.

This bug was caught using Cisco ip-phone SPA5XX and codec g722.
On SIP session update the SPA50X resets stream and a new timestamp is twice
smaller then the previous.

ASTERISK-28162 #close

Change-Id: Ic72b4497e74d801b27a635559c1cf29c16c95254

If a voicemail is marked "urgent" then the VM_MESSAGEFILE channel variable is
not updated correctly since urgent messages are in a different directory. The
fix is to update the channel variable when the path to the urgent message is
created.

ASTERISK-28225

Change-Id: I8efbace06e6122ea0793f7bdb073d4378e8274ca

When using the 'b' option to Queue with a queue that was not configured
for ring all a crash would occur as the wrong pointer would be used.

ASTERISK-28218

Change-Id: If1390f64e321047dff24fd2410c95dde74904980

An int64_t is not likely the same size as a long.

* Changed the int64_t values in the statistics structs to longs so casting
is not necessary when generating the formatted CLI output.  The offending
members did not need to be int64_t anyway as they were only set by an int
type variable which was already truncating bits.

* Reordered the statistics structs to reduce potential padding bytes.

Change-Id: Ic090a070e9dc4ca650ebdb9c01ed50a581289962

Eliminate differences with DEVMODE prototypes for public functions.

ASTERISK-28212 #close

Change-Id: I872c04842ab6b61e9dd6d37e4166bc619aa20626

This reverts commit 5ec6d2c3.

This commit caused issues with polling when combined with
the revert commit "Revert "app_voicemail: Remove need to subscribe to stasis"

ASTERISK-28222
Reported by: abelbeck

Change-Id: I1e83a433e4202574181bc128dce876ef24936a52

In order to get a dump of the running process, we need to find the
pid of the main asterisk process.  This can be tricky if there are
also instances of "asterisk -r" running or if an alternate location
for asterisk.conf was specified on the command line with the -C
option that also specified an alternation location for the pid file.

So now...

1. We find the asterisk executable with "which" or the --asterisk-bin
   command line option.
2. If there's only 1 process with an executable path that matches,
   we use that pid.  If not...
3. We try "<asterisk-bin> -rx 'core show settings'" and parse the
   output to find the pidfile, then read that for the pid.  If that
   didn't work...
4. We get a list of all the pids matching <asterisk-bin> and look
   in /proc/<pid>/cmdline for a -C argument and retry the "core show
   settings" using the same -C option.  We can't parse the output
   of "ps" to get the -C path because it may contain spaces.  The
   contents of /proc/<pid>/cmdline are delimited by NULLs.  For BSDs
   we may have to mount /proc first. :(

ASTERISK-28221
Reported by: Andrew Nagy

Change-Id: I8aa1f3f912f949df2b5348908803c636bde1d57c

The backtrace library bfd.h include file does not get the sizes of
pointers and ints right on some platforms.  On my old test box the size
of bfd_vma is 8 while the size of a pointer is 4.  gcc on the box
complains of the integer casting to/from pointers size mismatch.

* uintptr_t to the rescue by doing an appropriate two stage cast.

Change-Id: Icb2621583f50c8728de08a3c824d95fe53cc45d0

The free_user function was automatically deleting the stasis mailbox
state but this only makes sense when the mailbox is actually
deleted, not just the structure freed.  This was causing issues
where leave_voicemail would publish the mwi message to stasis and
delete the state before the message could be processed by
res_pjsip_mwi.

* Removed the delete of state from free_user().

* Created a new free_user_final() function that both frees the data
  structure and deletes the state.  This function is only called
  during module load/unload where it's appropriate to delete the
  state.

ASTERISK-28215

Change-Id: I305e8b3c930e9ac41d901e5dc8a58fd7904d98dd

All of the fields that were removed were no longer referenced except for
'lastrxts' and 'rxseqno' which were only ever written to.

Change-Id: I5a5d31eb33e97663843698f58d0d97f22a76627c

The profile-iop octet (the 2nd) of profile-level-id can be zero
according to RFC 6184 Section 8.1. So we ignore its value when deciding
to include profile-level-id in the outgoing SDP.

ASTERISK-27959 #close
Reported by: David Kuehling

Change-Id: Id28cd916a3d7748058fe9609b585d07d9e243f73