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
if a delay buffer is enabled, the packets get scheduled in the future,
but media playback packets are scheduled immediately. this results
in choppy playback due to the packets coming in at the same time.
This change adds a new bool to chu_args that gets enabled when
play-media is called and passed in to codec_handlers_stop so the delay
buffer queue is cleared instead of flushed
Change-Id: Id534f9087d934481f17341bc577099dc2362f8e1
when DTMF-security is set to an option that results in a transcode,
the packets go into handler_func_transcode. This returns immediately
when handler_silence_block returns false due to block-media, resulting
in the events not being processed for sending on log-DTMF etc.
This change only uses the transcode function for transcoded DTMF if
we're not blocking media (and logically, blocking media should mean
_all_ media). It instead goes into __handler_func_supplemental as normal
so packet_dtmf can process the packet, but drop it if its in one of
these modes and media is blocked
Change-Id: I19901877f6018f3916b22ff60799e8c74d02e065
when media playback happens, all packets get scheduled at the same
time with a send time in the future. however, this results in the
output_skew calculation triggering an unnecessary shift in the send
timer, which can cause choppy playback
Change-Id: I449f221a4d348eb615c2af1dca30bec163aa4fc6
Richard Fuchs
Tom Briden