Add bridge_features structure to bridge creation.  Specifically, this
implements mute and DTMF suppression, but others should be able to be
easily added to the same structure.

ASTERISK-27322 #close
Reported by: Darren Sessions
Sponsored by: AVOXI

Change-Id: Id4002adfb65c9a8027ee9e1a5f477e0f01cf9d61

add mappings for udptl redundancy, rtptimeout, and debug flags

Change-Id: Ie73cf5c83c05dee01eb9624ede76c1a30225d73a

ASTERISK-27306

Change-Id: I3bed0edf3f55b1d4adcbabb25ec14f11dc766c72

The only caller of cdr_object_fn_table.process_party_b() explicitly does
the check before calling.

Change-Id: Ib0c53cdf5048227842846e0df9d2c19117c45618

Change-Id: I9f424f5282ca7d833592f958d95f1b2bafb549b0

Change-Id: Ib59d7d2f2a4a822754628f2c48a308d6791a6e6e

* Also some misc formatting in cdr.c.

Change-Id: Ied89a28802a662c37c43326a1aafdce596e0df4a

When "rewrite_contact" is enabled, the "max_contacts" count option can
block re-registrations because the source port from the endpoint can be
random.  When the re-registration is blocked, the endpoint may give up
re-registering and require manual intervention.

* The "remove_existing" option now allows a registration to succeed by
displacing any existing contacts that now exceed the "max_contacts" count.
Any removed contacts are the next to expire.  The behaviour change is
beneficial when "rewrite_contact" is enabled and "max_contacts" is greater
than one.  The removed contact is likely the old contact created by
"rewrite_contact" that the device is refreshing.

ASTERISK-27192

Change-Id: I64c107a10b70db1697d17136051ae6bf22b5314b

Change-Id: I65a5190b2732b2246d67472db70dd37db64ddad4

ASTERISK-27305
Reported by: David Hajek
Tested by: David Hajek

Change-Id: Ife3e289062e6cf7d0e7d342dbf79ed96feff441e

Since ASTERISK-26922, this issue affected only those chan_sip which were
* enabled for dual-stack (bindaddr=::), and
* enabled for TCP (tcpenable=yes) and/or TLS (tlsenable=yes), and
* tried to register and/or invite a IPv4-only service,
* via TCP and/or TLS.
Now, ast_tcptls_client_create does not re-bind to [::] anymore.

ASTERISK-27324 #close

Change-Id: I4b242837bdeb1ec7130dc82505c6180a946fd9b5

ASTERISK-27306

Change-Id: I2c8d3fc148f9f53715c958314e1146f9611741f3

Do not manually call sip_endpoint_apply_handler from load_all_endpoints.
This is not necessary and causes memory leaks.

Additionally reinitialize persistent->aors when we reuse a persistent
object with a new endpoint.

ASTERISK-27306

Change-Id: I59bbfc8da8a14d5f4af8c5bb1e71f8592ae823eb

Use temporary variable to prevent multiple evaluations of elem argument.
This resolves a memory leak in res_pjproject startup.

ASTERISK-27317 #close

Change-Id: Ib960d7f5576f9e1a3c478ecb48995582a574e06d

pjsip_distributor leaks references to fake_auth when the default realm
has not changed.

ASTERISK-27306

Change-Id: I3fcf103b3680ad2d1d4610dcd6738eeaebf4d202

ast_strings_match uses sscanf and checks for non-zero return to verify a
token was parsed. This is incorrect as sscanf returns EOF (-1) for errors.

ASTERISK-27318 #close

Change-Id: Ifcece92605f58116eff24c5a0a3b0ee08b3c87b1

ASTERISK-27306

Change-Id: Ib3ed47167cb697ab7bd0a56cab589893f491651b

Currently privacy requests are only granted if the Privacy header
value is exactly "id" (defined in RFC 3325). It ignores any other
possible value (or a combination there of). This patch reverses the
logic from testing for "id" to grant privacy, to testing for "none" and
granting privacy for any other value. "none" must not be used in
combination with any other value (RFC 3323 section 4.2).

ASTERISK-27284 #close

Change-Id: If438a21f31a962da32d7a33ff33bdeb1e776fe56

This provides better information to REF_DEBUG log for troubleshooting
when the system is unable to unload res_pjsip.so during shutdown due to
module references.

ASTERISK-27306

Change-Id: I63197ad33d1aebe60d12e0a6561718bdc54e4612

res_pjsip and res_pjsip_session had circular references, preventing both
modules from shutting down.
* Move session supplement registration to res_pjsip.
* Use create internal functions for use by pjsip_message_filter.c.

ASTERISK-27306

Change-Id: Ifbd5c19ec848010111afeab2436f9699da06ba6b

When we are loading the calendars, we call libical's
icalcomponent_foreach_recurrence method for each VEVENT component that
we have in our calendar.

That method has no knowledge concerning the existence of the other
VEVENT components and will feed our callback with all ocurrences
matching the requested time span.

The occurrences generated by icalcomponent_foreach_recurrence while
expanding a recurring VEVENT's RRULE and RDATE properties can be
superceded by an other VEVENT sharing the same UID.

I use an external iterator (in libical terminology) to avoid messing
with the internal ones from the calling function, and search for
VEVENTS which could supersede the current occurrence.

The event which can invalidate this occurence needs to have:

- the same UID as our recurrent component (comp)
- a RECURRENCE-ID property, which represents the start time of this
  occurrence

If one component is found, just clean and return.

ASTERISK-27296 #close
Reported by: Benoît Dereck-Tricot

Change-Id: I8587ae3eaa765af7cb21eda3b6bf84e8a1c87af8