Re: Kamailio SBC using RTPproxy

Ibe Van de Veire via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Message-ID <PA3PR07MB106662406824C399FC7D3DB62F61AA@PA3PR07MB10666.eurprd07.prod.outlook.com>
Thanks for the reply!

After struggling a bit to set up RTPEngine for RHEL 9, I was finally able to run RTPEngine on the master branch.
Currently, I'am trying to match the exact situation as the one I had with RTPproxy.
Does anyone have any suggestions on what flags to use in kamalio when sending rtpengine_manage?

Currently, I also receive a warning saying: " Interface 'int' not found, using default". Any thoughts on this?
I have configured an "ext" and "int" network interfaces in the rtpengine configuration.

Kind regads
Ibe Van de Veire
System Engineer
[email protected]
Auguste Reyerslaan 52
B-1043 Brussel



-----Oorspronkelijk bericht-----
Van: Alex Balashov <[email protected]>
Verzonden: donderdag 25 september 2025 15:18
Aan: Kamailio (SER) - Users Mailing List <[email protected]>
CC: Ibe Van de Veire <[email protected]>
Onderwerp: Re: [SR-Users] Kamailio SBC using RTPproxy

[U ontvang niet vaak e-mail van [email protected]. Meer informatie over waarom dit belangrijk is, vindt u op https://aka.ms/LearnAboutSenderIdentification]

You may have more luck with RTPEngine in this regard.

> On Sep 25, 2025, at 9:02 AM, Ibe Van de Veire via sr-users <[email protected]> wrote:
>
> Dear Kamailio community,
>  I am currently developing a VoIP system using 2 instances of Kamailio. One as SBC and one as SIP server.
> The SBC is configured to work in bridge mode (one NIC on the public side, one NIC on the private side).
> The SIP server works as expected.
>  But the SBC server seems to have some difficulties to route the RTP traffic.
> I am using RTPproxy to handle NAT traversals.
>  Currently, I handled the following situations:
>     • Internal to internal call
>     • External (both NAT and CG-NAT) to internal call
>     • Internal to external (both NAT and CG-NAT) call  The situation
> that does not work is the following:
>     • External (both NAT or CG-NAT) to External (both NAT or CG-NAT)
> The SBC seems to always translate the IN IP4 field from external to internal (as desired when calling from external to internal), but this seems not to be desired when calling from external to external.
> This way, both external devices try to send the RTP data to the internal (inaccessible) address of the SBC.
> How can I configure the SBC to stop translating the IN IP4 field when both devices are external?
>  I have the following configuration that talks to the RTPproxy service:
>  ==========================
>     if(nat_uac_test("8")) {
>         if($Ri == "MY_PUBLIC_IP") {
>             rtpproxy_manage("coiew");
>         } else {
>             rtpproxy_manage("faei");
>         }
>     } else {
>         rtpproxy_manage("cor");
>     }
> ==========================
>   Also, is this the desired way to handle NAT traversal with RTPproxy?
>  Kind regards
> Ibe Van de Veire
> System Engineer
>
> -- Disclaimer --
> Vlaamse Radio- en Televisieomroeporganisatie Auguste Reyerslaan 52
> 1043 Brussel
>
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> VRT Gebruikersvoorwaarden
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected] To unsubscribe send an email to
> [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the sender!


--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com/, https://www.csrpswitch.com/
Tel: +1-706-510-6800


-- Disclaimer --
Vlaamse Radio- en Televisieomroeporganisatie
Auguste Reyerslaan 52
1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.