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 http://www.vrt.be/gebruiksvoorwaarden
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 sr-users@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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
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 ibe.vandeveire@vrt.be Auguste Reyerslaan 52 B-1043 Brussel
-----Oorspronkelijk bericht----- Van: Alex Balashov abalashov@evaristesys.com Verzonden: donderdag 25 september 2025 15:18 Aan: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org CC: Ibe Van de Veire Ibe.VandeVeire@VRT.BE Onderwerp: Re: [SR-Users] Kamailio SBC using RTPproxy
[U ontvang niet vaak e-mail van abalashov@evaristesys.com. 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 sr-users@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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
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 ibe.vandeveire@vrt.be Auguste Reyerslaan 52 B-1043 Brussel
-----Oorspronkelijk bericht----- Van: Alex Balashov abalashov@evaristesys.com Verzonden: donderdag 25 september 2025 15:18 Aan: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org CC: Ibe Van de Veire Ibe.VandeVeire@VRT.BE Onderwerp: Re: [SR-Users] Kamailio SBC using RTPproxy
[U ontvang niet vaak e-mail van abalashov@evaristesys.com. 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 sr-users@lists.kamailio.org 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 -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org 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
On 30/09/2025 08.29, Ibe Van de Veire via sr-users wrote:
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.
I would contest that statement because if they had been (correctly) defined in the config file, the log message wouldn't be emitted. 🙃
A common mistake is to put multiple `interface=` lines in the config file when in reality all interfaces must be listed on the same single line. Use the `list interfaces` CLI command to double check what's in the config.
Cheers
Can you try with rtpengine, instead of rtpproxy?
Thank you, Chandramouli.
On Thu, Sep 25, 2025 at 6:53 PM Ibe Van de Veire via sr-users < sr-users@lists.kamailio.org> 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 http://www.vrt.be/gebruiksvoorwaarden
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Ibe,
Thank you for your interest. Please see my comments below:
On Thu, Sep 25, 2025 at 6:18 AM Ibe Van de Veire via sr-users sr-users@lists.kamailio.org wrote:
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"); }==========================
I'd say you also need section with "EE" (i.e. external-external) section too, please insert your own logic into the [DESTINATION_INTERNAL] placeholder.
if(nat_uac_test("8")) { if($Ri == "MY_PUBLIC_IP") { rtpproxy_manage("coiew"); } else { + if ([DESTINATION_INTERNAL]) { rtpproxy_manage("faei"); + } else { + rtpproxy_manage("faee"); + } } } else { rtpproxy_manage("cor"); }
Hope it helps. You may also consider using R ("remote") or L ("local") options to pin the media address explicitly, which are orthogonal methods of doing media pinning.
Regards,
-
Alex Balashov -
Chandramouli P -
Ibe Van de Veire -
Maxim Sobolev -
Richard Fuchs