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
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
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
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
Make sure janus_session lock is obtained first and websocket_conn lock
second, in order to prevent a possible deadlock.
Change-Id: I3db1d5cea0c0295cc10c71edd20c86ce054f520b
Warned-by: Coverity
This isn't really necessary as at this point the janus_session object is
private to the thread, but we add the locking anyway to silence the
warning.
Warned-by: Coverity
Change-Id: I0b192f2f5827ad917cf5110ce486fc6cd49e1a71
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
Ricardas Stoma
Stefan Mititelu