If the timer thread is already scheduled to wake before the timer that
we want to schedule, then there is no need to wake it up for nothing.
Change-Id: I5e6174bb0347954dfc5d012befe31625fad9961a
This should prevent multiple threads from fighting over the same shared
structures (GTree + mutex + condition). Downside is that it may lead to
load not being perfectly balanced between threads.
Change-Id: I8127b98dcfbeafd692d74e60cdf6d60e3e572ba7
skb_copy() copies the GSO state of the skb as well, but we have
converted the skb to a flat linear skb with skb->next being NULL.
__udp_gso_segment() by way of __udp_gso_segment_list() expects skb->next
to be non NULL if GSO flags are present, causing a page fault. Reset the
GSO flags to make sure this doesn't happen.
closes#1792
Change-Id: Idae561120940e407e435e361316383fe5a5c5b7e
Ref: https://github.com/sipwise/rtpengine/issues/1792
Honour the capabilities of the output net devices and only perform
partial checksumming if GRO is in use.
closes#1792
Ref: https://github.com/sipwise/rtpengine/issues/1792
Change-Id: Ic524e3649aefcb274b4bf362970b10f0743d484a
poller_new used to have the side effect of initialising rtpe_now.
Restore this side effect explicitly in the startup code, so that timers
are launched with the correst start time instead of zero.
Change-Id: I590061a9665b52c4aed00c06dc330d2a226c73d3
We cannot directly use the rule_scratch area when checking for the
nftables status, as this scratch area is re-initialised for each rule.
Instead add check_matched_flag() to be called after each rule was
parsed, and use it to set a corresponding iterate_scratch flag.
closes#1794
Change-Id: Ie954a91949d09887b9a293f4010bb08e78100145
These aren't only used to match "immediate" rules, so rename them
accordingly. Make it more clear what check_matched_queue() does.
Change-Id: Ie2d48c075e79c24ac120673bc7c0445c3686326f
Fix a regression from 4291c858
send_timer_rtcp() does its own locking of the SSRC. Release the lock
before calling it.
Change-Id: I185fb2fb4b47a343ab4be00d16629b5f330ee965
The monologue label (and possibly other) get set during the offer/answer
routine. Do the call recording setup after this has been done.
closes#1791
Change-Id: Ie1b1a7d5a1df7058ba90c3dd5cbd79159f48683d
Since skb is a copy of the ingress skb, ->dev still points to the device
the packet was received on. For sending, set it to the outgoing device,
taken from the dst object.
Change-Id: Ia27b4318925dec4396e485a389d818dd46bcac78
As per [1], quote:
It’s very important that you recognize the limited scope in which
automatic variable values are available: they only have values within
the recipe. In particular, you cannot use them anywhere within the
target list of a rule; they have no value there and will expand to the
empty string. Also, they cannot be accessed directly within the
prerequisite list of a rule. A common mistake is attempting to use $@
within the prerequisites list; this will not work.
Based on the patch by S-P Chan <shihping.chan@gmail.com>
[1] https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.htmlcloses#1754
Thanks: S-P Chan <shihping.chan@gmail.com>
Change-Id: Ia5f9d7a75f04d9533afaace8ed49cc222e4307a8
Ref: https://github.com/sipwise/rtpengine/issues/1754
For convenience we provide extra HTTP and WS endpoints that accept a
cookie-less NG or JSON message string. Not all commands are sensitive to
retransmits and this makes it easier to query call status etc.
Change-Id: Iffbc4ef9a5fdf916a374dfdd4042c61b437d18c9
Create a separate function that actually processes a message packet
without dealing with the cookie
Change-Id: I163a48ff3d508ae95617eaa76403bf2cf702cff8
Distinguish between functions that enagage or disengage the recording
daemon and functions acting on actual recording, which eliminates the
need to deal with the flags separately.
Change-Id: Ia2d718d9e6f95d7621a2ba186c60b501f7404fe7
If base chain is "none", the admin is responsible for jumping into the
custom chain. Don't remove jumps the admin migth have setup.
closes#1787
Change-Id: I9980acb12fb1abb0883b22aceab2719087768763
When base chain is "none", the admin is required to manage jumping into the
rtpengine chain. The chain can't be deleted if it is still referenced by
another rule, which is common in this configuration.
closes#1787
Change-Id: I8a72e1041a364db60870b5acececc234c8452bab
Telling netlink to create a chain that already exists should technically
be a no-op, BUT it still sets the policy to whatever was given as a side
effect. Make sure we don't change the policy by explicitly checking for
the chain's existence.
closes#1785
Change-Id: I526a4e2a0f9d1dcc6e0e00a6e273e4df55863d6c