ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: I7f04d5c8bee1126fee5fe6afbc39e45104469f4e

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: I97ecebc1ab9b5654fb918bf1f4c98c956b852369

* Make ast_rtp_codecs_payload_code() get the current mapping or create a
rx payload type mapping.

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: Ia4b2d45877a8f004f6ce3840e3d8afe533384e56

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: I34e23bf5b084c8570f9c3e6ccd19b95fe85af239

There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk.  It uses only one mapping structure to
associate payload types to codecs.  The single mapping is overkill if all
of the payload type values are well known values.  Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive.  Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.

1) An independent payload type mapping is needed for sending and
receiving.

2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.

3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.

* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.

* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.

* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created.  All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.

* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP.  We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.

ASTERISK-25166
Reported by: Kevin Harwell

ASTERISK-17410
Reported by: Boris Fox

Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac

This is a type mismatch fix of the debugging commit
c63316ee made to find out why
a testsuite test was failing only on one of the continuous
integration build agents.

Change-Id: Iba34f6e87cec331f6ac80e4daff6476ea6f00a75

Asterisk needs the sqlite 3 library, which is package
sqlite-devel in CentOS. By adding this package to the
script, a problem with configure failing is resolved.

ASTERISK-25331 #close
Reported by: Kevin Harwell

Change-Id: I90efaf6a01914fea03f21e5cdbd91c348f44b0ec

ASTERISK-25308 #close
Reported by: Joshua Colp

Change-Id: I592785bf70ff4b63d00e535b482f40da8e82a082

Change-Id: I228df6adecd4cb450d03e09e9a38c86bb566e811

* Remove extraneous unlock on off-nominal path.
* Add missing HTTP error reply.

Change-Id: I1f402bfe448fba8696b507477cab5f060ccd9b2b

Change-Id: I0c5e7b34057f26dadb39489c4dac3015c52f5dbf

Setting the 'paused' and 'ringinuse' options on a queue member using the
dialplan function QUEUE_MEMBER did not behave the same way as the
equivalent dialplan applications or AMI actions.

* Made queue_function_mem_write() call the set_member_paused() and
set_member_value() for the 'paused' and 'ringinuse' options respectively.
A beneficial side effect is that the queue name is now optional and sets
the value in all queues the interface is a member.

* Update QUEUE_MEMBER XML documentation.

* Fix error checking in QUEUE_MEMBER() write.

ASTERISK-25215 #close
Reported by: Lorne Gaetz

Change-Id: I3a016be8dc94d63a9cc155295ff9c9afa5f707cb

* Extract set_queue_member_pause() from set_member_paused() for simpler
and more consistent code.

* Extract set_queue_member_ringinuse() from
set_member_ringinuse_help_members() for simpler code.

Change-Id: Iecc1f4119c63347341d7ea6b65f5fc4963706306

Change-Id: I7294e13d27875851c2f4ef6818adba507509d224

When allocating a sorcery object, fail if the
id value was not allocated.

ASTERISK-25323
Reported by: Scott Griepentrog

Change-Id: I152133fb7545a4efcf7a0080ada77332d038669e

When sending an RTP keepalive, we need to be sure we're not dealing with
a NULL RTP instance. There had been a NULL check, but the commit that
added the rtp_timeout and rtp_hold_timeout options removed the NULL
check.

Change-Id: I2d7dcd5022697cfc6bf3d9e19245419078e79b64

Change-Id: I58bed58631a94295b267991c5b61a3a93c167f0c

The built frame format in audiohook_read_frame_both() is now set to a
signed linear format before the rx and tx frames are duplicated instead of
only for the mixed audio frame duplication.

ASTERISK-25322 #close
Reported by Sean Pimental

Change-Id: I86f85b5c48c49e4e2d3b770797b9d484250a1538

In chan_sip, after handling an incoming invite a security event is raised
describing authorization (success, failure, etc...). However, it was doing
a lookup of the peer by extension. This is fine for register messages, but
in the case of an invite it may search and find the wrong peer, or a non
existent one (for instance, in the case of call pickup). Also, if the peers
are configured through realtime this may cause an unnecessary database lookup
when caching is enabled.

This patch makes it so that sip_report_security_event searches by IP address
when looking for a peer instead of by extension after an invite is processed.

ASTERISK-25320 #close

Change-Id: I9b3f11549efb475b6561c64f0e6da1a481d98bc4

Due to the use of ast_websocket_close in session termination it is
possible for the underlying socket to already be closed when the
session is terminated. This occurs when the close frame is attempted
to be written out but fails.

Change-Id: I7572583529a42a7dc911ea77a974d8307d5c0c8b

The res_http_websocket module will currently attempt to close
the WebSocket connection if fatal cases occur, such as when
attempting to write out data and being unable to. When the
fatal cases occur the code attempts to write a WebSocket close
frame out to have the remote side close the connection. If
writing this fails then the connection is not terminated.

This change forcefully terminates the connection if the
WebSocket is to be closed but is unable to send the close frame.

ASTERISK-25312 #close

Change-Id: I10973086671cc192a76424060d9ec8e688602845

This patch adds the .get callback to the format attribute module, such
that the Asterisk core or other third party modules can query for the
negotiated format attributes.

Change-Id: Ia24f55cf9b661d651ce89b4f4b023d921380f19c

Pressing DTMF digits on a phone to go out on a DAHDI channel can result in
the digit not being recognized or even heard by the peer.

Phone -> Asterisk -> DAHDI/channel

Turns out the DAHDI behavior with DTMF generation (and any other generated
tones) is exposed by the "buffers=" setting in chan_dahdi.conf.  When
Asterisk requests to start sending DTMF then DAHDI waits until its write
buffer is empty before generating any samples for the DTMF tones.  When
Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI
immediately stops generating the DTMF samples.  As a result, the more
samples there are in the DAHDI write buffer the shorter the time DTMF
actually gets sent on the wire.  If there are more samples in the write
buffer than the time DTMF is supposed to be sent then no DTMF gets sent on
the wire.  With the "buffers=12,half" setting and each buffer representing
20 ms of samples then the DAHDI write buffer is going to contain around
120 ms of samples.  For DTMF to be recognized by the peer the actual sent
DTMF duration needs to be a minimum of 40 ms.  Therefore, the intended
duration needs to be a minimum of 160 ms for the peer to receive the
minimum DTMF digit duration to recognize it.

A simple and effective solution to work around the DAHDI behavior is for
Asterisk to flush the DAHDI write buffer when sending DTMF so the full
duration of DTMF is actually sent on the wire.  When someone is going to
send DTMF they are not likely to be talking before sending the tones so
the flushed write samples are expected to just contain silence.

* Made dahdi_digit_begin() flush the DAHDI write buffer after requesting
to send a DTMF digit.

ASTERISK-25315 #close
Reported by John Hardin

Change-Id: Ib56262c708cb7858082156bfc70ebd0a220efa6a

There is a window of opportunity for DTMF to not go out if an audio frame
is in the process of being written to DAHDI while another thread starts
sending DTMF.  The thread sending the audio frame could be past the
currently dialing check before being preempted by another thread starting
a DTMF generation request.  When the thread sending the audio frame
resumes it will then cause DAHDI to stop the DTMF tone generation.  The
result is no DTMF goes out.

* Made dahdi_write() lock the private struct before writing to the DAHDI
file descriptor.

ASTERISK-25315
Reported by John Hardin

Change-Id: Ib4e0264cf63305ed5da701188447668e72ec9abb

If the saved SUBSCRIBE message is not parseable for whatever reason then
Asterisk could crash when libpjsip tries to parse the message and adds an
error message to the parse error list.

* Made ast_sip_create_rdata() initialize the parse error rdata list.  The
list is checked after parsing to see that it remains empty for the
function to return successful.

ASTERISK-25306
Reported by Mark Michelson

Change-Id: Ie0677f69f707503b1a37df18723bd59418085256

iLBC 20 was advertised in a SIP/SDP negotiation. However, only iLBC 30 is
supported. Removes "a=fmtp:x mode=y" from SDP. Because of RFC 3952 section 5,
only iLBC 30 is negotiated now.

ASTERISK-25309 #close

Change-Id: I92d724600a183eec3114da0ac607b994b1a793da

Some codecs that may be a third party library to Asterisk need to have
knowledge of the format attributes that were negotiated. Unfortunately,
when the great format migration of Asterisk 13 occurred, that ability
was lost.

This patch adds an API call, ast_format_attribute_get, to the core
format API, along with updates to the unit test to check the new API
call. A new callback is also now available for format attribute modules,
such that they can provide the format attribute values they manage.

Note that the API returns a void *. This is done as the format attribute
modules themselves may store format attributes in any particular manner
they like. Care should be taken by consumers of the API to check the
return value before casting and dereferencing. Consumers will obviously
need to have a priori knowledge of the type of the format attribute as
well.

Change-Id: Ieec76883dfb46ecd7aff3dc81a52c81f4dc1b9e3