Not only check for the presence of a sink, but also check for a sink FD.
Treat a sink without an FD as if there is no sink.
Closes#1401
Change-Id: I04c0be33f8cae39399674ca0a87185a729daa843
Flag a socket with an error strike when packets are received too fast,
and refuse processing once too many strikes have occurred. This should
prevent forwarding loops from taking down the system.
Change-Id: Idc574f2f1dbbcb156efc37a80e903dc4e60ef1b1
Distinguish between unconfirming the learned peer address and
retriggering the kernel stream. In particular we don't want to unconfirm
the sinks every time we confirmed our own peer, as that starts an
unconfirm/reconfirm loop.
Change-Id: I1f172385aefeacbc4585729bce25fbc68f04c2bd
We may have multiple subscribers, some of which may be dead/unused. We
don't care if we have these since we don't forward to them anyway.
possibly relevant for #1337
Change-Id: I3cded5080aa2005e9dd615cccf60bd4cba5feb7d
Set NO_KERNEL_SUPPORT when we don't actually kernelise the stream, and
use that flag when trying to pull stream stats.
probably closes#1337
Change-Id: I46af55e353d87c5afdda3c106d1f3470273105bf
The advertised address might be empty (trickle ICE) so use the FILLED
flag instead to see if the sink is eligible.
Change-Id: I114bd7400ccfcc3ecbc871bdcc5aee4e7d699816
This fixes a race condition: Peer sends updated SDP with new address,
but an older RTP packet from the old address is received afterwards.
Thsi triggers learning of this old address is the "correct" endpoint.
Afterwards the peer stops sending RTP until a packet to the new endpoint
is received there, which never happens because the new endpoint has been
discarded in favour of the "learned" old one.
closes#817
Change-Id: I508f465a669f03e35ddcc6e770d5e7859e57569f
Move RTCP processing down into the egress section and run the processing
function once for each output, because the output media must be known
when processing RTCP RRs during transcoding.
closes#1298
Change-Id: I1797bef336e27a7064b9f42ab8c25f0aade02e47
This solves problems when the same SSRC is looped through the same call
multiple times in different mono/dialogues, with different parameters.
Change-Id: I1d033cb1f012574d82b5bcbfffe11eb5f983cfd8
GLib 2.68 deprecates g_memdup() in favour of g_memdup2() as the former
was using a guint second argument which could lead to integer overflows
(gsize should be used instead).
Change-Id: Iaa3e3b1ecaab00d1ac887c915397b15b7204dd11
The SSRC mapping strategy can change if a re-invite disengages
transcoding, therefore we always need to update the output SSRC mapping
even if the SSRC entry has already existed, to avoid stray SSRC changes.
Change-Id: Ib6f14ede1a4e615ff5eb8372cc68bf1acdd4b6c8
(cherry picked from commit dd7acd2644)