This patch fixes a crash which would occur when an audiohook was
applied to a channel using an audio codec that could not be translated
to signed linear (such as when using pass-through codecs like OPUS or
when the codec translator module for the format in use is not loaded).

ASTERISK-25498 #close
Reported by: Ben Langfeld

Change-Id: Ib6ea7373fcc22e537cad373996136636201f4384

When dns_parse_answer_ex was iterating over the answers it
wasn't incrementing the answer pointer correctly after the first
answer.  The result was that no answers after the first
were being returned.  For results where multiple records should
have been sorted by priority, weight, etc., there was nothing
to sort so the only the first record was returned even if it
wouldn't have been the correct record based on the sort.

ASTERISK-25565 #close
Reported-by: Daniel Tryba
Tested-by George Joseph

Change-Id: I8622604fefdcd3c11e2c5609a6382e53b1467b0b

The hashtab API is pretty NULL tolerant which has resulted
in remaining callers not doing much checks themselves.
Unfortunately the function to destroy an iterator does not
do a NULL check and will result in a crash if passed NULL.
This change fixes that.

ASTERISK-25552 #close

Change-Id: Ic1bf8eec3639e5a440f1c941d3ae3893ac6ed619

In practical tests, we have seen certain taskprocessors, specifically
Stasis subscription taskprocessors, cross the recently-added high-water
mark and emit a warning. This high-water mark warning is only intended
to be emitted when things have tanked on the system and things are
heading south quickly. In the practical tests, the Stasis taskprocessors
sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in
any danger at all.

As such, this ups the high-water mark to 500 tasks instead. It also
redefines the SIP threadpool request denial number to be a multiple of
the taskprocessor high-water mark.

Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce

In Asterisk 13, cached formats are created before their corresponding format-
attribute module is registered. Cached formats are involved when a local
extension is called. Therefore, ast_format_generate_sdp_fmtp did not work
on local extensions. This change affects the Opus Codec, H.263 (Plus), H.264,
and format-attribute modules provided externally.

ASTERISK-25160 #close

Change-Id: I1ea1f0483e5261e2a050112e4ebdfc22057d1354

We have observed situations where the SIP threadpool may become
deadlocked. However, because incoming traffic is still arriving, the SIP
threadpool's queue can continue to grow, eventually running the system
out of memory.

This change makes it so that incoming traffic gets rejected with a 503
response if the queue is backed up too much.

Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816

When appending all formats of a type all the codecs are iterated
and added. This operation was incorrectly adding the ast_format_none
format which is special in that it is supposed to be used when no
format is present. It shouldn't be appended.

ASTERISK-25535

Change-Id: I7b00f3bdf4a5f3022e483d6ece602b1e8b12827c

This change adds handling of dead worker threads when moving them
to be active. When this happens the worker thread is removed from
both the active and idle threads container. If no threads are able
to be moved to active then the pool grows as configured.

A unit test has also been added which thrashes the idle timeout
and thread activation to exploit any race conditions between the
two.

ASTERISK-25546 #close

Change-Id: I6c455f9a40de60d9e86458d447b548fb52ba1143

Previously, format-attribute modules relied on an existing fmtp line in SDP
negotiation. However, fmtp is optional for several formats like the Opus Codec.
Now, the format-attribute module is called with an empty fmtp, which allows the
module to initialise itself to RFC defaults. Furthermore now, Asterisk is able
to differentiate between internally and externally created formats.

ASTERISK-25537 #close

Change-Id: I28f680cef7fdf51c0969ff8da71548edad72ec52

ABI compatibility stubs existed for ast_app_separate_args and ast_verbose,
this is not needed in master.

Change-Id: I07b4d2c16079da3c2c6efa55df4a74368e0bd453

Change-Id: I3185735db42064bab00d3e073aed703385a00bf4

ASTERISK-25533 #close

Change-Id: Ie1a9d1a6511b3f1a56b93d04475fbf8a4e40010a

Since Asterisk 13, formats are immutable and cached. However while loading a
module like chan_sip, some formats were created instead using cached ones.

ASTERISK-25535 #close

Change-Id: I479cdc220d5617c840a98f3389b3bd91e91fbd9b

dns_parse_answer_ex was not converting ans->ttl from network
by order to host byte order which was causing certain ttls
it to go negative. In turn this was causing answer edit checks
to fail.

ASTERISK-25528 #close
Reported-by: Daniel Tryba
Tested-by: George Joseph

Change-Id: I31505132d6321c46d2f39fd06c20ee808a864037

Previously, the wrapping did both lookahead and lookback, which,
together with color escape sequences, caused some lines to be wrapped
way earlier than other lines.  This led to inconsistent output.

This simplifies the wrapping code and makes it more sane: if maxcolumns
is hit, we simply jump back to the last space and wrap there.

ASTERISK-25527 #close

Change-Id: I56d01c6f9a812642b1b05535c98d4db48d17c957

If a taskprocessor's queue grows large, this can indicate that there
may be a problem with tasks not leaving the processor or else that
the number of available task processors for a given type of task is
too low. This patch makes it so that if a taskprocessor's task queue
grows above 100 queued tasks that it will emit a warning message.
Warning messages are emitted only once per task processor.

ASTERISK-25518 #close
Reported by: Jonathan Rose

Change-Id: Ib1607c35d18c1d6a0575b3f0e3ff5d932fd6600c

When a dial attempt is made that involves a requesting channel, we previously
were not:
a) Protecting access to the native format capabilities structure on the
   requesting channel. That is inherently unsafe.
b) Reference bumping the lifetime of the format capabilities structure.

In both cases, something else could sneak in, blow away the format
capabilities, and we'd be holding onto an invalid format_cap structure. When
the newly created channel attempts to construct its format capabilities, things
go poorly.

This patch:
a) Ensures that we get a reference to the native format capabilities while
   the requesting channel is locked
b) Holds a reference to the native format capabilities during the creation
   of the new channel.

ASTERISK-25522 #close

Change-Id: I0bfb7ba8b9711f4158cbeaae96edf9626e88a54f

A previous commit reduced the AST_BUILDOPTS compiler define to
only include options that affected ABI.  This included some options
that were previously displayed by cli "core show settings".  This
change corrects the CLI display while still restricting buildopts.h
to ABI effecting options only.

ASTERISK-25434 #close
Reported by: Rusty Newton

Change-Id: Id07af6bedd1d7d325878023e403fbd9d3607e325

The JSON packing for the ContactStatusChange event forgot to include the
roundtrip_usec field. As a result, the field never showed up in any event,
even when the data was available. This patch corrects that error by properly
packing the JSON blob with the data.

Change-Id: I8df80da659a44010afbd48f645967518ff5daa17

A crash was seen on a system that ran out of memory due to Asterisk not
checking for vector allocation failures in format_cap.c. With this
change, if either of the AST_VECTOR_INIT calls fail, we will return a
value indicating failure.

Change-Id: Ieb9c59f39dfde6d11797a92b45e0cf8ac5722bc8

Users of functions which call __ast_str_helper() such as the ones listed
below are likely to not check the return value for failure so ensuring
that the string is always nil terminated is a good safety measure.

ast_str_set_va()
ast_str_append_va()
ast_str_set()
ast_str_append()

Change-Id: I36ab2d14bb6015868b49329dda8639d70fbcae07

Change-Id: I0c2cdcd53727bdc6634095c61294807255bd278f

In September 2006, the maximum packetization time (ptime) were set to such a
low value, packetization was disabled for many codecs actually. This was fixed
for many codecs but not for iLBC 30. This enables packetization for iLBC which
can be enabled for example via allow=ilbc:60,gsm,alaw,ulaw in the file sip.conf.

ASTERISK-7803

Change-Id: I2ef90023d35efb7cb8fe96ed74f53f6846ffad12

This patch adds the functions

	ast_cdr_modifier_register()
	ast_cdr_modifier_unregister()

That work much like ast_cdr_register() and ast_cdr_unregister().

Modules registered will be given a chance to modify (or to do whatever
they want) CDR fields just before they are passed to registered engines.

Thus, for instance, if a module change the "userfield" field of a CDR,
the modified value will be passed to every registered CDR backend for
logging.

ASTERISK-25479 #close

Change-Id: If11d8fd19ef89b1a66ecacf1201e10fcf86ccd56

Change-Id: I06e346e9a5c63cc5071e7eda537310c4b43bffe0

The memory corruption could happen if the [section](+) is the last section
in the file with trailing comments.  In this case process_text_line() has
left *last_cat is set to newcat and newcat is destroyed.

Change-Id: I0d1d999f553986f591becd000e7cc6ddfb978d93

An #include right after a [section](+) would associate any variable
assignments before a new section in the #include with the wrong section.

* Fix section association by setting the current section to the appended
section.

* Fix '+' and '!' section flag interaction corner case depending upon
which flag came first.  If the '!' came first then it would be ignored.
If the '!' came after then it would affect the appended section.  The '!'
will now no longer be ignored.

ASTERISK-25461 #close
Reported by: Sean Pimental

Change-Id: Ic9d3191c8758048e2cbce6432f854b32531731c3

When GetConfigJSON was introduced back in 1.6, it returned each
section as an array of strings: ["key=value", "key2=value2"].
Afterwards, it was changed a few times and became
["key": "value", "key2": "value2"], which is not a correct JSON.
This patch fixes that by constructing a JSON object {} instead of
an array [].

Also, the keys "istemplate" and "tempates" that are used to
indicate templates and their inherited categories are now wrapped in
quotes.

ASTERISK-25391 #close
Reported by: Bojan Nemčić

Change-Id: Ibbe93c6a227dff14d4a54b0d152341857bcf6ad8

Change-Id: Ib91435fb45b7f5f7c0fc83d0eec20b88098707bc

When Asterisk is part of a larger distributed system, log files are often
gathered using tools (such as logstash) that prefer to consume information
and have it rendered using other tools (such as Kibana) that prefer a
structured format, e.g., JSON. This patch adds support for JSON formatted
logs by adding support for an optional log format specifier in Asterisk's
logging subsystem. By adding a format specifier of '[json]':

full => [json]debug,verbose,notice,warning,error

Log messages will be output to the 'full' channel in the following
format:

{
  "hostname": Hostname or name specified in asterisk.conf
  "timestamp": Date/Time
  "identifiers": {
    "lwp": Thread ID,
    "callid": Call Identifier
  }
  "logmsg": {
    "location": {
      "filename": Name of the file that generated the log statement
      "function": Function that generated the log statement
      "line": Line number that called the logging function
    }
    "level": Log level, e.g., DEBUG, VERBOSE, etc.
    "message": Actual text of the log message
  }
}

ASTERISK-25425 #close

Change-Id: I8649bfedf3fb7bf3138008cc11565553209cc238

There was a problem observed where the "logger add channel" CLI command
would allow for a channel with the same name to be added multiple times.
This would result in each message being written out to the same file
multiple times.

The problem was due to the difference in how logger channel filenames
are stored versus the format they are allowed to be presented when they
are added. For instance, if adding the logger channel "foo" through the
CLI, the result would be a logger channel with the file name
/var/log/asterisk/foo being stored. So when trying to add another "foo"
channel, "foo" would not match "/var/log/asterisk/foo" so we'd happily
add the duplicate channel.

The fix presented here is to introduce two new methods in the logger
code:
 * make_filename(): given a logger channel name, this creates the
   filename for that logger channel.
 * find_logchannel(): given a logger channel name, this calls
   make_filename() and then traverses the list of logchannels in order
   to find a match.

This change has made use of make_filename() and find_logchannel()
throughout to more consistently behave.

ASTERISK-25305 #close
Reported by Mark Michelson

Change-Id: I892d52954d6007d8bc453c3cbdd9235dec9c4a36

When leaving a bridge, indications on a channel could be swallowed by
the internal indication logic because it appears that the channel is on
its way to be hung up anyway. One such situation where this is
detrimental is when channels on hold are redirected out of a bridge. The
AST_CONTROL_UNHOLD indication from the bridging code is swallowed,
leaving the channel in question to still appear to be on hold.

The fix here is to modify the logic inside ast_indicate_data() to not
drop the indication if the channel is simply leaving a bridge. This way,
channels on hold redirected out of a bridge revert to their expected "in
use" state after the redirection.

ASTERISK-25418 #close
Reported by Mark Michelson

Change-Id: If6115204dfa0551c050974ee138fabd15f978949

Page uses the async method of dialing with the dial API.  When a call gets
forwarded there is no calling channel available.  If the predial handler
was set then the calling channel could not be put into auto-service
for the forwarded call because it doesn't exist.  A crash is the result.

* Moved the callee predial parameter string processing to before the
string is passed to the dial API rather than having the dial API do it.
There are a few benefits do doing this.  The first is the predial
parameter string processing doesn't need to be done for each channel
called by the dial API.  The second is in async mode and the forwarded
channel is to have the predial handler executed on it then the
non-existent calling channel does not need to be present to process the
predial parameter string.

* Don't start auto-service on a non-existent calling channel to execute
the predial handler when the dial API is in async mode and forwarding a
call.

ASTERISK-25384 #close
Reported by: Chet Stevens

Change-Id: If53892b286d29f6cf955e2545b03dcffa2610981

Currently, Asterisk will log to the last configured syslog
channel in logger.conf. This is due to the fact that the
final call to openlog() supersedes all of the previous calls.
This commit removes the call to openlog() and passes the
facility to ast_log_vsyslog(), along with utilizing the
LOG_MAKEPRI macro to ensure that the message is routed to
the correct facility and with the correct priority.

ASTERISK-25407 #close
Reported by: Elazar Broad
Tested by: Elazar Broad

Change-Id: Ie2a2416bc00cce1b04e99ef40917c2011953ddd2

This patch adds support for receiving events regarding Peer status changes
and Contact status changes. This is particularly useful in scenarios where
we are subscribed to all endpoints and channels, where we often want to know
more about the state of channel technology specific items than a single
endpoint's state.

ASTERISK-24870

Change-Id: I6137459cdc25ce27efc134ad58abf065653da4e9

Now with menuselect "DEBUG_FD_LEAKS" and CLI "core show fd", a timestamp is
shown with each file descriptor. This helps to debug leaked UDP/TCP ports on
long-lived servers, for example.

ASTERISK-25405 #close

Change-Id: I968339e5155a512eba1032a5263f1ec8b5e1f80b

When changing a hint extension without removing the hint first the
device state and presence state is not updated. This causes the state
of the hint to be that of the previous extension and not the current
one. This state is kept until a state change occurs as a result of
something (presence state change, device state change).

This change updates the hint with the current device and presence
state of the new extension when it is changed. Any state callbacks
which may have been added before the hint extension is changed are
also informed of the new device and presence state if either have
changed.

ASTERISK-25394 #close

Change-Id: If268f1110290e502c73dd289c9e7e7b27bc8432f

When Asterisk translates between codecs, each with a different frame size (for
example between iLBC 30 and Speex-WB), too large frames were created by
ast_trans_frameout. Now, ast_trans_frameout is called with the correct frame
length, creating several frames when necessary. Affects all transcoding modules
which used ast_trans_frameout: GSM, iLBC, LPC10, and Speex.

ASTERISK-25353 #close

Change-Id: I2e229569d73191d66a4e43fef35432db24000212

It has been observed that on long-running busy systems, a scheduler
context can eventually hit INT_MAX for its assigned IDs and end up
overflowing into a very low negative number. When this occurs, this can
result in odd behaviors, because a negative return is interpreted by
callers as being a failure. However, the item actually was successfully
scheduled. The result may be that a freed item remains in the scheduler,
resulting in a crash at some point in the future.

The scheduler can overflow because every time that an item is added to
the scheduler, a counter is bumped and that counter's current value is
assigned as the new item's ID.

This patch introduces a new method for assigning scheduler IDs. Instead
of assigning from a counter, a queue of available IDs is maintained.
When assigning a new ID, an ID is pulled from the queue. When a
scheduler item is released, its ID is pushed back onto the queue. This
way, IDs may be reused when they become available, and the growth of ID
numbers is directly related to concurrent activity within a scheduler
context rather than the uptime of the system.

Change-Id: I532708eef8f669d823457d7fefdad9a6078b99b2

Asterisk can load and register an object type while still having an invalid
sorcery mapping. This can cause an issue when a creation call is invoked.
For example, mis-configuring PJSIP's endpoint identifier by IP address mapping
in sorcery.conf will cause the sorcery mechanism to be invalidated; however, a
subsequent ARI invocation to create the object will cause a crash, as the
internal type may not be registered as sorcery expects.

Merely checking for a NULL pointer here solves the issue.

Change-Id: I54079fb94a1440992f4735a9a1bbf1abb1c601ac