RTPEngine: selecting the right destination interface

[Ibe Van de Veire]

Hi all,

I am currently working on a VoIP setup with a (Kamailio-based) SBC and SIP server. All things are set up and running as desired, except one thing. RTPEngine is used on the SBC to handle the bridging and the NAT of the client networks.

The config file of RTPEngine on the SBC has currently described two network interfaces: internal and external. I want to use the SBC as a bridge between the external and internal networks.

I managed to create calls from external to internal (over NAT) and external to external (via the SBC (hairpinning??). This was done by manually forcing the direction using "direction=external direction=internal" and "direction=external direction=external".

The problem is, I don't want to manually change the direction. But I did not find any way to detect the direction at the right moment. I am especially having a hard time finding the destination interface when calling RPTengine_manage for the first time. At that moment, the SIP server did not respond with the destination IP. So there seems to be no way to know the desired interface?

Can I redefine the direction after initialising the session on the first call?
How are these situations handled normally?
Is RTPEngine able to handle this automatically?

Kind regards,

Ibe Van de Veire

[Richard Fuchs]

On 07/10/2025 03.44, 'Ibe Van de Veire' via Sipwise rtpengine wrote:
> The problem is, I don't want to manually change the direction. But I
> did not find any way to detect the direction at the right moment. I am
> especially having a hard time finding the destination interface when
> calling RPTengine_manage for the first time. At that moment, the SIP
> server did not respond with the destination IP. So there seems to be
> no way to know the desired interface?
>
> Can I redefine the direction after initialising the session on the
> first call?
> How are these situations handled normally?
> Is RTPEngine able to handle this automatically?

I'm a bit confused by the question.

At the moment the call is being established, you have a SIP invite with
an offer SDP going to the intended recipient. Surely at this moment you
must know through which network interface the recipient can be reached?
How else could this SIP invite be delivered? And this network interface
then also determines which interface ought to be used for media to the
same recipient. This is what you need to communicate to rtpengine.

Since rtpengine has no implicit knowledge of where a particular SIP
invite or SDP offer will be sent, it cannot automatically determine the
appropriate network interface to use.

It's possible to adjust the network interfaces used for a call after the
initial invite, but only during a re-invite, since obviously changing
the interface also changes the address and the ports and this needs to
be communicated to the involved parties. And at that point some media
might have already been lost if the wrong interface was used originally.

Cheers

[Ibe Van de Veire]

Thanks for the response!

I captured the flow to clear up my situation.

The sip flow for an external device calling to an internal device is the following:

The first time rtpengine_manage is called (onreply_route[MANAGE_REPLY] in kamailio), is on the first invite from the calling device to the public SBC interface.

At that moment, the SIP server has not given any information about what the destination IP should be.

Is this the right moment to start the rtpengine session?

Feel free to correct me if I am telling something contradictory :)

Kind regards
Ibe Van de Veire

Op dinsdag 7 oktober 2025 om 13:43:57 UTC+2 schreef rfuchs:

[Richard Fuchs]

On 07/10/2025 08.38, 'Ibe Van de Veire' via Sipwise rtpengine wrote:
> The first time rtpengine_manage is called (onreply_route[MANAGE_REPLY]
> in kamailio), is on the first invite from the calling device to the
> public SBC interface.
> At that moment, the SIP server has not given any information about
> what the destination IP should be.
> Is this the right moment to start the rtpengine session?

What does "SIP server" represent? Is it some kind of application server
that is also managing media? Or is it a proxy that is sending the invite
onward to some other SIP endpoint? Or something else entirely?

Or IOW: does the SIP server anchor media on its own network interface or
not?

If it does: Then in the first call leg you should already know that this
invite is coming from the public internet (first `direction=`) and is
going to an endpoint (the SIP server) which uses the private interface
for media (second `direction=`).

If it doesn't then you may want to invoke rtpengine at a different
point. You need to have some kind of knowledge which network interface
can be used to establish media flow to the eventual recipient. You don't
need to know the actual media address, but you should know which local
interface can be used to reach whatever address would be returned.

Cheers

[Ibe Van de Veire]

The "SIP server" does not handle any media.
It only handles the registrations and sends the invites to the right device (proxy).

In my situation, the only way to know which interface to use is by knowing the actual media address.
I will try to adapt Kamailio to invoke RTPengine later in the call flow.

Thanks a lot!

Op dinsdag 7 oktober 2025 om 14:57:06 UTC+2 schreef rfuchs:

[Ibe Van de Veire]

I did try to invoke rtpengine at a different point (after the reply of the SIP proxy server containing the destination IP).

But it seems important to also call rtpengine_manage at the invite stage to have a functional call.

I also tried to only define the direction when the destination IP is known. But here, it seems that if the direction is not defined,
it will just take the first defined interface for the whole call (even after defining the direction afterwards).

Do you have any ideas how to solve this?

"It's possible to adjust the network interfaces used for a call after the
initial invite, but only during a re-invite, since obviously changing
the interface also changes the address and the ports and this needs to
be communicated to the involved parties. And at that point some media
might have already been lost if the wrong interface was used originally."

Am I be able to send this re-invite using the SBC server?

Or can this only be done from the caller?

(The lost media does not seem to be that big of a problem)

Kind regards

Ibe Van de Veire

Op dinsdag 7 oktober 2025 om 15:12:18 UTC+2 schreef Ibe Van de Veire:

[Richard Fuchs]

On 08/10/2025 10.01, 'Ibe Van de Veire' via Sipwise rtpengine wrote:
> I did try to invoke rtpengine at a different point (after the reply of
> the SIP proxy server containing the destination IP).
> But it seems important to also call rtpengine_manage at the invite
> stage to have a functional call.

Ok, that's not what I meant with "invoke at a different point."

I meant invoke it not between caller and SBC, but say between SBC and
SIP server, or even after the SIP server. Wherever you have knowledge of
where the invite will be sent to.

> I also tried to only define the direction when the destination IP is
> known. But here, it seems that if the direction is not defined,
> it will just take the first defined interface for the whole call (even
> after defining the direction afterwards).

Instead of giving two `direction=...` attributes, you can individually
choose the interfaces for the "from" direction and the "to" direction
using `from-interface=...` and `to-interface=...`.

I don't think this would solve your problem though.

> Am I be able to send this re-invite using the SBC server?
> Or can this only be done from the caller?

Any party to the call may initiate a re-invite at any time. If your SBC
acts as a B2B user agent, then it would certainly be able to do that. If
the SBC is just a proxy then it might still be possible, but maybe more
difficult. How you would do it I don't know, since you didn't say what
kind of SBC it is.

> In my situation, the only way to know which interface to use is by
> knowing the actual media address.
> I will try to adapt Kamailio to invoke RTPengine later in the call flow.

Again I am somewhat confused by this statement.

If you have control over the "SIP server" then the SIP server certainly
must know where to send the invite to. If the SIP server knows this,
then it should also be possible to give this information to rtpengine.

And if you don't have control over the "SIP server" and don't know where
it would send the invite to, then there must be some other way to know
which local interface must be used for media towards the final
recipient. Say, the same interface that is used to communicate with the
SIP server would be a logical choice.

A SIP endpoint which appears as a black box and may respond to an invite
sent to it with a media address that can be reached only through
different local interfaces and which cannot be anticipated seems like a
very odd setup, to say the least.

Cheers