Using `l->next` as a test for whether only one element is left in the
list is not reliable. Use the actual list length instead.
Update one affected test.
Closes#1961
Change-Id: I5773715700220cd762e61090bac941ddd33afd9b
(cherry picked from commit 02897ccb46)
SDP attributes have been moved to the call's memory arena in 5115fe000.
Make sure the redis restore code uses the same.
Remove some redundant null checks as well.
Closes#1959
Change-Id: I2f37869f5f2c95999d028c811c6a0eb10215f576
(cherry picked from commit a7a43c9b75)
RFC says that annex B is the default in the absence of the annexb=no
format string. Consider the alias "G729a" as annex A.
Closes#1951
Change-Id: I9a8483ee5520bf4688601123f1ebec4f1f480642
Multiple writers may operate on a single WS connection simultaneously.
Make sure they don't get in each other's way while constructing their
messages/responses by holding the lock from the beginning of the
response until the point when it's fully ready. This fixes a problem of
parts of multiple messages getting mixed up with each other.
Change-Id: If84224fc06b423cd65c12981a5b09ee99b121df2
Looks like partial writes are handled automatically internally, but add
a request for a "writeable" callback anyway so we know when we can write
more.
Closes#1943
Change-Id: I86a8e1924febc0524b90dc6559753e12e0de9dfb
this fixes an edge case where `DTMF-security=silence`, `block-media`
is enabled and the endpoint sends silence packets in between each RTP
event packet of a single DTMF hit. When that happens, the DTMF doesn't
get processed as `packet_sequencer_next_packet` returns NULL, and the
while loop is broken due to the ts_diff being 0
By checking if media is currently blocked and that the current packet
is a supplemental DTMF, we can force the packet to be processed so the
dropped packet is considered lost and we don't lose the DTMF event
Change-Id: I78bc8e273e872b3ab88f7a84e26a79fad1793476
A simple mechanism to track whether a given media endpoint has been
advertised to the public. If it hasn't, then any media received on it is
considered suspicious, and source addresses are ignored for learning
purposes.
Change-Id: I76a08e3f442f263dad192ff496a5d734a9349d26
The internally used VALID flag doesn't reflect the "valid" state from
the RFC, possibly leading to legitimate packets (DTLS etc) to be
ignored. Introduce a new flag to track which ICE pairs have been
authenticated through requests or responses.
Change-Id: I11b8e2bb6a7638ab9405304c6f45c29b20d3739c
EXTRA_CFLAGS is deprecated and stopped working in 6.15(ish)
Ref: https://bugs.debian.org/1106709
Ref: e966ad0edd
Change-Id: Iba835c7dca89106ff2ca7ffba8a7de947c9a4ff8
If DTX audio has already been produced for a particular timestamp and a
late packet matching that timestamp is encountered, we should just
discard the packet instead of immediately doing a timestamp reset. This
prevents unwanted TS resets. Only do a timestamp reset if this happens
multiple times in a row, as we don't want to have to discard too much
audio.
Change-Id: I46c8c20b08787f7e45145bd88463bb6878f36f15