Hi again Richard et al,
In the meanwhile I've figured out what was causing the issue. The problem
was related to the way I had my iptables rules defined. I had :
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
and only after that
-A INPUT -p udp -m udp --dport 16384:32768 -j RTPENGINE --id 0
-A INPUT -p udp -m udp --dport 49152:65535 -j RTPENGINE --id 0
I basically changed that to:
...
-A INPUT -m state --state RELATED,ESTABLISHED -m udp -p udp --dport
16384:32768 -j RTPENGINE --id 0
-A INPUT -m state --state RELATED,ESTABLISHED -m udp -p udp --dport
49152:65535 -j RTPENGINE --id 0
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
...
-A INPUT -p udp -m udp --dport 16384:32768 -j ACCEPT
-A INPUT -p udp -m udp --dport 49152:65535 -j ACCEPT
and now everything works as expected.
Thanks for all the support anyway.
Cheers,
--
Nuno Miguel Reis
Departamento de Engenharia Informática
Faculdade de Ciências e Tecnologia
Universidade de Coimbra
On Thu, Jan 16, 2020 at 10:10 PM Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 16/01/2020 12.29, Nuno Miguel Reis wrote:
Hi again.
Thanks for all the help and suggestions. I realized the issue happens if
using kernel forwarding only. If I change rtpengine to start at userspace
without the kernel module enabled everything works fine as expected.
Do you have any hints on why this could be happening with the kernel
module?
I'm running rtpengine like this:
usersapece: $ rtpengine -f -L 7 --interface=100.100.100.100 --listen-ng=
127.0.0.1:2223 --tos=184 --sip-source
kernel: $ rtpengine -f -L 7 --table=0 --interface=100.100.100.100
--listen-ng=127.0.0.1:2223 --tos=184 --no-fallback --sip-source
The kernel module receives its instructions from the userspace daemon, so
there's no reason there should be a difference. Can you post 1) logs and 2)
the flags you use for your offers/answers?
Cheers
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users