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

Change validation on reload module because now used the cli function for
reload. The sip_reload() function never fail and ever return NULL for this
reason on reload() now use the call the sip_reload() and return
AST_MODULE_LOAD_SUCCESS.

This problem is dectected on reload by PUT method on ARI, getting always
404 http code when the module is reloaded.

ASTERISK-25325 #close
Reporte by: Rodrigo Ramírez Norambuena

Change-Id: I41215877fb2cfc589e0d4d464000cf6825f4d7fb

Change-Id: I2b8db18eac36c01a5c7eb9467699124e203fd093

Change-Id: Ie62ff1f4b7adc1a12fa0303f53926af249b25e20

We should not try to send a SIP response message because we may be
restoring a persistent subscription where we are not responding to a SIP
request.

Change-Id: Id89167ef90320c5563f37e632db0dda6cb9e7dec

Fix off-nominal visited vector leak in build_resource_tree().

Change-Id: If0399c7941c9c0b1038bcfb7b9a371760977831c

ast_sip_pubsub_register_body_generator() did not account for the null
terminator set by sprintf() in the allocated output buffer.

Change-Id: I388688a132e479bca6ad1c19275eae0070969ae2

Change-Id: Ia396096b4fedc2874649ca11137612c3f55e83e3

Change-Id: I15debd0f717f16ee2f78e7f56151c3b3b97b72fc

Change-Id: I364906d6d2bad3472929986704a0286b9a2cbe3f

The default_from_user retrieval function was pulling the
default_from_user from the global configuration struct in an unsafe way.
If using a database as a backend configuration store, the global
configuration struct is short-lived, so grabbing a pointer from it
results in referencing freed memory.

The fix here is to copy the default_from_user value out of the global
configuration struct.

Thanks go to John Hardin for discovering this problem and proposing the
patch on which this fix is based.

ASTERISK-25390 #close
Reported by Mark Michelson

Change-Id: I6b96067a495c1259da768f4012d44e03e7c6148c

We will only rewrite the Contact header if there is no Record-Route header in
the received request. If a malfunctioning proxy places a Record-Route header
into a REGISTER request, we will decide that we shouldn't update the IP/port
in the Contact header, and we will end up storing a contact with an AoR that
contains the NAT'd IP address.

While it is nice to have the proxy *not* send a Record-Route in a REGISTER
request, it's also a good idea to not process the header in a non-dialog
message. This patch updates the code to explicitly ignore the Record-Route
header in REGISTER requests.

ASTERISK-25387 #close

Change-Id: I4bd3bcccc4003d460cc354d986b0dea2e433ef3f

Add ProgressIndicator IE with inband info present to Progress and
Alerting Q.931 message

ASTERISK-25227 #close
Reported by: Alexandr Dranchuk

Change-Id: I326ad13cb1db9a72b3fd902bafed3c28a3684203

Make certain that the pjsip session has not failed to
allocate the format capabilities structure, which can
otherwise cause a crash when referenced.

ASTERISK-25323

Change-Id: I602790ba12714741165e441cc64a3ecde4cb5750

In Asterisk 11, the announcer channel would receive channel variables
from the channel being parked by means of normal channel inheritance.
This functionality was lost during the big res_parking project in
Asterisk 12. This patch restores that functionality.

ASTERISK-25369 #close
Review: https://gerrit.asterisk.org/#/c/1180/

Change-Id: Ie47e618330114ad2ea91e2edcef1cb6f341eed6e

In working through a recent ICE negotiation bug, I found the debug
logging in res_rtp_asterisk to be lacking. This patch adds a number of
debug and warning statements that were helpful.

Change-Id: I950c6d8f13a41f14b3d6334b4cafe7d4e997be80

pthread_attr_init() defaults to PTHREAD_EXPLICIT_SCHED on FreeBSD
too.

ASTERISK-25310 #close
Reported by: Guido Falsi

Change-Id: Iae6befac9028b5b9795f86986a4a08a1ae6ab7c4

In the wild it is possible for Contact URIs to be quite long as
parameters can exist on them. This can present a problem when storing
them in the AstDB as the URI is used as part of the object name and
there is a fixed length limit for the AstDB. This will cause
the contact to not get stored.

This change uses the MD5 hash of the Contact URI as part of the
object name instead. This has a fixed length which is guaranteed
to not exceed the AstDB length limit.

ASTERISK-25295 #close

Change-Id: Ie8252a75331ca00b41b9f308f42cc1fbdf701a02

    Call ast_rtp_instance_stop on ooh323_destroy to free resources
    allocated by rtp instance

    ASTERISK-25299 #close
    Report by: Alexandr Dranchuk

Change-Id: I455096bd7da016b871afe90af86067c2c7c9f33f

When an AoR is deleted by an external mechanism, such as through ARI, we
currently do not remove dynamic contacts that were created for that AoR as a
result of a received REGISTER request. As a result, re-creating the AoR will
cause the dynamic contact to be interpreted as a persistent contact, leading
to some rather strange state being created for the contacts/endpoints.

This patch adds a sorcery observer for the 'aor' object. When a delete is
issued on the underlying sorcery object, the observer is called, and all
contacts created and persisted in sorcery for that AoR are also removed. Note
that we don't want to perform this action when an AO2 object that is an AoR is
destroyed, as the AoR can still exist in the backing storage (and we would
thus be removing valid contacts from an AoR that still "exists".)

ASTERISK-25381 #close

Change-Id: I6697e51ef6b2858b5d63401f35dc378bb0f90328

This patch adds a new option to the CHANNEL function that allows for the
extraction of the SIP call-id. It is used in conjunction with the 'pjsip'
option, and will return the Call-ID of the INVITE request that established
the PJSIP channel.

ASTERISK-25352

Change-Id: I278d1f8bcfe3a53c5aa1dadebc14e92b0abd476a

We were passing the wrong count into pj_ice_sess_create_check_list(),
causing the create to fail if we ever received more than PJ_ICE_MAX_CAND
candidates.

Change-Id: I0303d8e1ecb20a8de9fe629a3209d216c4028378

When Asterisk sends an outbound SIP request, if there is no direct
reason to place a specific value for the username in the From header,
Asterisk would generate a UUID. For example, this would happen when
sending outbound OPTIONS requests when qualifying or when sending
outbound INVITE requests when originating (if no explicit caller ID were
provided). The issue is that some SIP providers reject these sorts of
requests with a "Name too long" error response.

This patch aims to fix this by changing the default outbound username in
From headers to "asterisk". This value can be overridden by changing the
default_from_user option in the global options if desired.

ASTERISK-25377 #close
Reported by Mark Michelson

Change-Id: I6a4d34a56ff73ff4f661b0075aeba5461b7f3190

In ast_endpoint_snapshot_create(), a failure to init the
string fields results in two attempts to ao2_cleanup the
same pointer.  Removed RAII_VAR to eliminate problem.

ASTERISK-25375 #close
Reported by: Scott Griepentrog

Change-Id: If4d9dfb1bbe3836b623642ec690b6d49b25e8979

Pjsip is refusing to use unsecure transport with "sips" in url.
WSS should be considered as secure transport.

ASTERISK-24602 #comment Partially fixed by setting WSS as secure

Change-Id: Iddac406c6deba6240c41a603b8859dfefe1a5353

When sending a stateful response, creation of the transaction can fail,
most commonly because we are trying to create a transaction from a
retransmitted request. When creation of the transaction fails, we end up
leaking a reference to a contact that was bumped when the response was
created.

This patch adds the missing deref and fixes the reference leak.

Change-Id: I2f97ad512aeb1b17e87ca29ae0abacb4d6395f07

When issuing the "core show hints" CLI command a combination of both
the hint extension and context is created. This uses a fixed size
buffer expecting that the extension will not exceed maximum extension
length. When the extension is actually a pattern match this constraint
does not hold true, and the extension may exceed the maximum extension
length. In this case extra characters are written past the end of the
fixed size buffer.

This change makes it so the construction of the combined hint extension
and context can not exceed the size of the buffer.

ASTERISK-25367 #close

Change-Id: Idfa1b95d0d4dc38e675be7c1de8900b3f981f499

A recent change to res_pjsip_pubsub switched to using pjsip_msg_print as
a means of writing an appropriate packet to persistent storage. While
this partially solved the issue, it had its own problems.
pjsip_msg_print will always add a Content-Length header to the message
it prints. Frequent restarts of Asterisk can result in persistent
subscriptions being written with five or more Content-Length headers. In
addition, sometimes some apparent corruption of individual headers could
be seen.

This aims to fix the problem by not running a parsed message through an
interpreter but rather by taking the raw message and saving it. The
logic for what to save is going to be different depending on whether a
SUBSCRIBE was received from the wire or if it was pulled from
persistence. When receiving a packet from the wire, when using a
streaming transport, the rdata->pkt_info.packet may contain multiple SIP
messages or fragments. However, the rdata->msg_info.msg_buf will always
contain the current SIP message to be processed. When pulling from
persistence, though, the rdata->msg_info.msg_buf will be NULL since no
transport actually handled the packet. However, since we know that we
will always ever pull one SIP message from persistence, we are free to
save directly from rdata->pkt_info.packet instead.

ASTERISK-25365 #close
Reported by Mark Michelson

Change-Id: I33153b10d0b4dc8e3801aaaee2f48173b867855b