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
(cherry picked from commit ff2aed5907)
While doing the A/B reassociation during an offer/answer exchange, we
don't (necessarily) want to remove all existing subscriptions. Instead
we cant to unsubscribe all subscribers so we don't do media forking, but
leaving existing subscriptions alone to make early media reception
possible. This mirros the old behaviour.
Change-Id: Ib9e6671ca2d23d1eb4509d7cf939015c816cc622
(cherry picked from commit af79ec6a91)
Multiple untagged monologues can exist at the same time which would lead
to a broken bencode dictionary. Instead use a pseudo label to
distinguish them.
Change-Id: I0f41c42df8ec17c1c4fb5cc6451ea039612e505f
(cherry picked from commit 6f0439daf3)
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
(cherry picked from commit 6c9fe540cf)
This silences a warning coming back from incorrect usage of the kernel
module
Change-Id: I2f03518a67620b92ef6b6ccd4ae6a4780087e206
(cherry picked from commit 2770bec906)
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
(cherry picked from commit 702dd9bb13)
The advertised address might be empty (trickle ICE) so use the FILLED
flag instead to see if the sink is eligible.
Change-Id: I114bd7400ccfcc3ecbc871bdcc5aee4e7d699816
(cherry picked from commit f6461ab452)
If a keyspace notification SET is received and the call already exists
as a foreign call, the call is first destroyed before being re-restored.
The call destruction involves a DEL from Redis on the "hosted DB"
number, which points to the foreign DB. This makes it impossible to then
restore the call because it's just been deleted.
closes#1308closes#1334
Change-Id: Ie895b021441b2d299f8ebb5bde1824b01e12633c
Also add a safeguard against filling the remote peer address with an
address from the wrong family
closes#1305
Change-Id: Iac18212b4d526a2f7d49a06ddcd724aa89b06060
The contents of the ->next element cannot be accessed completely lock
free as they're zeroed out during call removal. Instead grab a reference
to the linked next call before releasing the lock, and also lock the
next element before moving on. This requires a more granular locking as
not to interfere with call removal: One lock to protect the contained
call and the ->next, and another to protect the ->prev
Change-Id: I5474ea3f88e3276f93ba62a952b3be13c0c182e9
Richard Fuchs
Stefan Mititelu