Hi Daniel, The location was always wrong, but it wasn't noticed because it doesn't cause calls to fail straight away. It's only after a while that encryption stops working. This can be verified by watching to see if the values in /proc/rtpengine/0/list change, or do not change which indicates the kernel module isn't receiving packets.
Step 2 should be solved by a reboot, yes. On Mon, 7 Jan 2019 at 21:15, Daniel-Constantin Mierla <[email protected]> wrote: > Hello, > > thanks for sharing, very useful to know. > > Was the wrong location of the iptables module a result of ugrading some > packages (like kernel or iptables)? I assume the initial installation > deploys the module in the right location. Asking to see if one needs to do > a re-install of the rtpengine after kernel or other specific updates. > > Can step 2 be solved by a reboot of the server? > > Cheers, > Daniel > On 07.01.19 02:42, David Cunningham wrote: > > Hello all, > > We solved this issue with the help of Richard Fuchs. There were two issues: > > 1. The iptables module was in the wrong location and thus wasn't loaded. > The daemon thought that the kernel was handling packets and took the ROC > updates from it, but didn't actually see any packets and so the ROC reset, > resulting in decryption errors. The correct location can be found with > "pkg-config xtables --variable=xtlibdir". > > 2. Even after fixing the above, the iptables module didn't load properly > until rtpengine was stopped, the iptables rules removed, the kernel module > unloaded, and then this process reversed to load everything again. > > I hope this helps someone else in the future. > > > On Wed, 12 Dec 2018 at 11:05, David Cunningham <[email protected]> > wrote: > >> Hello, >> >> We're having an issue with rtpengine (used by Kamailio) where audio works >> initially, but then after an apparently random amount of time stop working. >> We see that when audio stops working rtpengine logs this: >> >> Dec 10 09:58:57 hostname rtpengine[376]: WARNING: >> [Pl1SeGDssOsDNWQdvey4lg.. port 48766]: Discarded invalid SRTP packet: >> authentication failed >> >> It then logs similar messages until the call hangs up. No such messages >> were logged while audio was working. >> >> Searching for this error message suggests that a change in the SSRC can >> cause the problem, but we don't see any such change in the PCAP. The source >> IP, port, codec, and SSRC all stay the same, and the Sequence increments as >> normal. >> >> Does anyone have suggestions on where to look next? We can share the PCAP >> privately if that would help anyone. >> >> Thanks for any advice! >> >> -- >> David Cunningham, Voisonics Limited >> http://voisonics.com/ >> USA: +1 213 221 1092 >> New Zealand: +64 (0)28 2558 3782 >> > > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ > USA: +1 213 221 1092 > New Zealand: +64 (0)28 2558 3782 > > _______________________________________________ > Kamailio (SER) - Users Mailing > [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- > www.linkedin.com/in/miconda > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com > Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in > Washington, DC, USA -- www.asipto.com > > -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
