Don't blindly take over a source DTMF PT if one is present. Check if the
destination has _some_ DTMF PT, and only then take over the source. This
makes the behaviour more closely match the documentation.
One test is affected and seems to improve its outcome.
Closes#2091
Change-Id: Ibb9c1f79099fa30ac69ec71b4a4c71af0b88b327
Instead of always blindly picking the matching supp codec for the
receiver codec, pick it only if there is no appropriate sink supp codec,
or both are compatible (which implies a payload type mismatch).
Closes#2084
Change-Id: Ie401db500a038f60f3b4286e2067f90674c611df
Provide an extra codec-store for the lookup of the answer codec. This is
needed for codec switches during an extra answer, as the original codecs
are kept in a different codec-store.
Closes#2073
Change-Id: I7e2efc434789ecc8d3b5fcf97240e5c3f7c84652
Fixes regression from Ib4285e7aae
RTCP multiplexing requires the RTCP sender to maybe lock the same output
stream, maybe lock some other one. Allow for both.
Change-Id: I6fcef32e656f8f0de46ad777f11a19c259ce35c7
With selected_sfd being protected by in_lock, we pretty much have to
hold at least in_lock everywhere, and end up requiring both locks in
many places. The distinction has become pointless.
Change-Id: Ic0ad976c2d68d9639b9434da7f0e6e9c0d84c185
PTs that were remembered from a previous handshake to save codec options
must be flagged as such so that they're not considered as having been
present in the current offer, so that they can be flagged as transcoding
PTs.
closes#1989
Change-Id: I19c2aff7e83ed338a81be99544645821165304cd
... from packetizer function instead of putting it into the AVPacket.
Remove AVPacket from callback function arguments.
Fix up PTS/duration adjustments where they were missing.
Closes#1963
Change-Id: Ib36b36bb6648b0579dd83155c7217317dda29cc3
Allow restarting the DTX buffer upon reception of a packet iff shutdown
occurred due to the max-dtx time being exceeded.
Change-Id: I9cbb9e946e6f495526cbef8f468f4e0a5aff0096
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
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