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
libcs are implementing changes to fix the year 2038 issue on 32 bit
platforms (see [1]). musl libc already went ahead and implemented it,
starting with musl-1.2.0 (see [2]).
This commit adds a new definition to lib/loglib.h:
TIME_T_INT_FMT
If __USE_TIME_BITS64 is defined (by a time64 libc, see [1]), it's set to
the proper conversions for type int64_t, PRId64. If __USE_TIME_BITS64 is
not defined, the status quo remains unchanged ("%ld" is used).
The new definition is used in the different parts of rtpengine, where
appropriate.
Note: Richard confirmed that the "%u" format in daemon/cdr.c is not
needed, so this gets swept under the rug.
These changes get rid of the new warnings that appeared with musl-1.2.0.
Below an example warning:
In file included from ./log.h:6,
from ../include/obj.h:94,
from ../include/media_socket.h:9,
from ../include/call.h:26,
from ../include/redis.h:15,
from redis.c
redis.c: In function 'redis_check_conn':
../lib/loglib.h:56:30: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'time_t' {aka 'long long int'} [-Wformat=]
56 | __ilog(prio, "[%s] " fmt, log_level_names[system], ##__VA_ARGS__); \
| ^~~~~~~
../lib/loglib.h:64:39: note: in expansion of macro 'ilogsn'
64 | #define ilogs(system, prio, fmt, ...) ilogsn(log_level_index_ ## system, prio, fmt, ##__VA_ARGS__)
| ^~~~~~
../lib/loglib.h:63:30: note: in expansion of macro 'ilogs'
63 | #define ilog(prio, fmt, ...) ilogs(core, prio, fmt, ##__VA_ARGS__)
| ^~~~~
redis.c:887:17: note: in expansion of macro 'ilog'
887 | ilog(LOG_WARNING, "Redis server %s is disabled. Don't try RE-Establishing for %ld more seconds",
| ^~~~
[1] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
[2] https://musl.libc.org/time64.html
Signed-off-by: Sebastian Kemper <sebastian_ml@gmx.net>
This makes it possible to add new streams without specifying the
direction/interface again.
Reported in #1366
Change-Id: I8f320ecbe72f123d755ba80370de9c40960eb0f0
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
Richard Fuchs
Sebastian Kemper
Ricardas Stoma
