RTP source port change after RE-INVITE followed by 488

[Matthew H]

Hi,

I'm using rtpengine with kamaillio. The rtpengine logic is simply:

KSR.rtpengine.rtpengine_manage("SIP-source-address replace-origin RTP allow-asymmetric-codecs")

We've observed that if the caller RE-INVITEs to T.38 (with a connection different port) but the called side rejects it with a 488, rtpengine then sends RTP to the called party from a new source port, which is dropped by firewalls / NAT as it's now asymmetric. 

I suspect this is a configuration error on my side, perhaps I need to delete the rejected session? Any advice is appreciated.

Thanks
Matthew

[Richard Fuchs]

On 04/08/2026 05.48, Matthew H wrote:
> KSR.rtpengine.rtpengine_manage("SIP-source-address replace-origin RTP
> allow-asymmetric-codecs")
>
> We've observed that if the caller RE-INVITEs to T.38 (with a
> connection different port) but the called side rejects it with a 488,
> rtpengine then sends RTP to the called party from a new source port,
> which is dropped by firewalls / NAT as it's now asymmetric.
>
> I suspect this is a configuration error on my side, perhaps I need to
> delete the rejected session? Any advice is appreciated.

This is not something that is supported at the moment, unfortunately.
Running an "offer" through rtpengine (which `rtpengine_manage` does)
implies that the offer is or will be accepted. Doing this to an already
established session overwrites the previous parameters, and there's no
way to revert in case of a rejected offer.

The workaround is to intercept this in your Kamailio script and then
replay the previous offer/answer to rtpengine, to reset the session to
its previous state.

Alternatively you can play tricks with the from/to tags, to pretend to
rtpengine that this is a brand new session, so that the existing session
is left unmodified in case of a rejection.

Cheers