POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.

Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc

These flags are non-portable GNU extensions. Make their use
optional. This fixes complication error on e.g. musl c-library
based systems.

Change-Id: I0aa06efc62aa8995f091445c8b762a75a91042f3

The stringfields refactor to allow adding stringfields to the end of a
structure (f6f4cf45) exposed some
incomplete cleanup code by some stringfield users.

The most noticeable leaker is the logging system where there is a leak for
every log message generated.

ASTERISK-26078 #close
Reported by:  Etienne Lessard
Patches:
      jira_asterisk_26078_v13.patch (license #5621) patch uploaded
      by Richard Mudgett

Change-Id: If6a08b31336b492c3de6f9dfd07c447f8d5a8782

The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.

Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799

Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543

Re-ordered the body items so Message-Account is second.

Messages-Waiting: no
Message-Account: sip:1571@<IP Removed>:5060
Voice-Message: 0/0 (0/0)

ASTERISK-26065 #close
Reported-by: Ross Beer

Change-Id: If5d35a64656eac98c2dd5e490cc0b2807bed80c3

Although all the patches we had against 2.4.5 were applied by Teluu,
a new bug was introduced preventing re-use of tcp and tls transports
This patch removes all the previous patches against 2.4.5, updates
the version to 2.5, and adds a new patch to correct the transport
re-use problem.

Change-Id: I0dc6c438c3910f7887418a5832ca186aea23d068

Added notes about when you can read or write headers. Specifically
about being able to read on the inbound channel and write on an
outbound channel.

ASTERISK-26063 #close
Reported by: Private Name
Tested by: Rusty Newton

Change-Id: Ibeb64af17d1f6451028b3c29855a3f151a01d8c5

This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:

* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP

ASTERISK-26068 #close
Reported by Mark Michelson

Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219

ARI dial had been implemented using the Dial API. This made great sense
when dialing was 100% separate from bridging. However, if a channel were
to be added to a bridge during the dial attempt, there would be a
conflict between the dialing thread and the bridging thread. Each would
be attempting to read frames from the dialed channel and act on them.

The initial attempt to make the two play nice was to have the Dial API
suspend the channel in the bridge and stay in charge of the channel
until the dial was complete. The problem with this was that it was
riddled with potential race conditions. It also was not well-suited for
the case where the channel changed which bridge it was in during the
dial.

This new approach removes the use of the Dial API altogether. Instead,
the channel we are dialing is placed into an invisible ARI dialing
bridge. The bridge channel thread handles incoming frames from the
channel. If the channel is added to a real bridge, it is departed from
the invisible bridge and then added to the real bridge. Similarly, if
the channel is removed from the real bridge, it is automatically added
back to the invisible bridge if the dial attempt is still active.

This approach keeps the threading simple by always having the channel
being handled by bridge channel threads.

ASTERISK-25925

Change-Id: I7750359ddf45fcd45eaec749c5b3822de4a8ddbb

As res_pjsip_nat rewrites contact's address, only the last Via header
can contain the source address of registered endpoint.
Also Call-Id header may contain the source address of registered
endpoint.

Added "via_addr", "via_port", "call_id" to contact.
Added new fields ViaAddress, CallID to AMI event ContactStatus.

ASTERISK-26011

Change-Id: I36bcc0bf422b3e0623680152d80486aeafe4c576

There are a lot of verbose messages about Endpoint and Contact status
changes if there are many dynamic endpoints.
The patch sets verbose level 2 for Endpoint status changes
and verbose level 3 for Contact status changes.

ASTERISK-26055 #close

Change-Id: Ie64e261ddbbc41bfff0f0190241152cc123fe6d7

Fixed some bugs:
- create dirpath when save downloading message from IMAP storage.
- create IMAP folder if not exists when saving to IMAP storage
- check if file successfully opened before write to it
- some IMAP checks
- remove non-standard flag 'Unseen'
etc

Change to debug IMAP mm_status log instead of verbose.

Remove unused X-Asterisk-VM-Caller-channel message header
for security reason. The clients should not know name of peer/endpoint.

ASTERISK-26045 #close

Change-Id: I7f83d88b69b36934e2539c114b9fb612deed971b

The pjproject doxygen for rdata->msg_info.info says to call
pjsip_rx_data_get_info() instead of accessing the struct member directly.
You need to call the function mostly because the function will generate
the struct member value if it is not already setup.

Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2

Add the option 'enable_callee_prompt' to followme.conf. Enabled by
default. If disabled, a callee is not prompted to accept or reject
the forwarded call.

ASTERISK-26064 #close

Change-Id: I0a8b19d4cf95c86a07c992813babb9e4a4acfff5
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

worker_start checked for ZOMBIE status without holding a lock.  All
other read/write of worker status are performed with a lock, so this
check should do the same.

ASTERISK-25777 #close

Change-Id: I5e33685a5c26fdb300851989a3b82be8c4e03781

Recent changes to res_pjsip_outbound_publish have introduced a
race condition at shutdown where an outbound publish may be shutdown
twice. In this case the first succeeds as a result of the unpublish.
In the second invocation since it's been unpublished a task is
queued to just destroy the client. This task holds no ref to the
publish and as a result the publish may be destroyed before the
task is run, causing a crash.

This explicit destruction task now holds a reference to the publish
to ensure it remains valid.

ASTERISK-26053 #close

Change-Id: I10789b98add3e50292ee3b33a55a1d9061cec94b

Invisible bridges function the same as normal bridges, but they have the
following restrictions:

* They never show up in CLI, AMI, or ARI queries.
* They do not have Stasis messages published about them.

Invisible bridges' main use is for when use of the bridging system is
desired, but the bridge should not be known to users of the Asterisk
system.

ASTERISK-25925

Change-Id: I804a209d3181d7c54e3d61a60eb462e7ce0e3670

The send request callback function currently assumes that it
will only ever be called on transaction state changes. This is
not always true. If our own timer callback occurs we will call
the callback with a timer event instead of a transaction state
change event. In this case the transaction on the event is
invalid and accessing it will result in a crash.

ASTERISK-26049 #close

Change-Id: I623211c8533eb73056b0250b4580b49ad4174dfc