Mulţumesc, Ovidiu.
The actual issue was the mapping of From and To tags - the rtpengine
module was sending them swapped as compared to their expected roles in
the answer command, which is understandable given that
rtpengine_offer("force-answer ... is being used on a request route
rather than reply route. So the rtpengine itself interpreted that as a
change of the remote peer and has allocated a new port.
What was a bigger quest was to override some internal optimization in
the rtpengine module, as using just "from-tag=$sig_local_totag
to-tag=$ft" was not enough - the rtpengine module seems to have its own
mind and swap the tags the way it thinks is correct if the ones from the
SIP message are used verbatim. So I had to add an "x-" prefix to the
actual tags to blindfold this "spell checker". Of course, this requires
to use a manual setting of the from-tag to "x-$ft" already when invoking
the actual rtpengine_offer() before.
Pavel
Dne 10.03.2026 v 13:00 [email protected] napsal(a):
1. Re: rtpengine_answer() is silently ignored on request route
handling the initial INVITE when acting as an UAS - what am I
missing? (Ovidiu Sas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 9 Mar 2026 17:21:50 -0400
From: Ovidiu Sas<[email protected]>
To: OpenSIPS users mailling list<[email protected]>
Subject: Re: [OpenSIPS-Users] rtpengine_answer() is silently ignored
on request route handling the initial INVITE when acting as an UAS -
what am I missing?
Message-ID:
<cand0lkswxt1eqi2j+oklfnbnkpjn8bdzczekonqy_wknynj...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Take a look at the port-latching option for the port change.
-ovidiu
On Mon, Mar 9, 2026 at 3:25 PM Pavel Sindelka<[email protected]> wrote:
Hello Andrea,
which particular aspect are you interested in?
The behavior can be demonstrated using just this simple route:
route {
if (is_method("INVITE") && !has_totag()) {
t_newtran();
rtpengine_use_set(1);
rtpengine_offer( , , $var(sdp-offer), $rb(application/sdp));
# ... forward the SDP offer as modified by rtpengine using another
protocol
# ... receive the SDP answer from the other protocol and store it into
$var(orig-sdp-answer)
#### rtpengine_answer("to-tag=$sig_local_totag", , $var(new-sdp-answer),
$var(orig-sdp-answer));
rtpengine_offer("force-answer to-tag=$sig_local_totag", ,
$var(new-sdp-answer), $var(orig-sdp-answer));
$var(contact) = "<sip:" + $socket_in(ip) + ":" + $socket_in(port) +
">";
append_to_reply("Contact: $var(contact)\r\n");
append_to_reply("Content-Type: application/sdp\r\n");
t_reply_with_body(200, "OK", $var(new-sdp-answer));
exit;
}
#### handle other methods & reINVITEs ####
}
I am currently trying to understand why, upon receiving the answer command,
rtpengine changes the port it has indicated in its modified SDP offer and
chooses another one for actually forwarding the media received from the calling
party, but that's off-topic here.
Pavel
Dne 09.03.2026 v 13:[email protected] napsal(a):
Date: Sun, 8 Mar 2026 08:14:09 -0500
From: Andrea Sannucci<[email protected]>
To: OpenSIPS users mailling list<[email protected]>, Pavel
Sindelka<[email protected]>
Subject: Re: [OpenSIPS-Users] rtpengine_answer() is silently ignored
on request route handling the initial INVITE when acting as an UAS -
what am I missing?
Message-ID:<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello,
can you show your configuration?
Regards
-----
Andrea Sannucci - @AS
El 8/03/2026 a las 8:01 a. m., Pavel Sindelka escribió:
Hello,
https://opensips.org/docs/modules/3.6.x/rtpengine.html#func_rtpengine_answer
doesn't mention any restrictions on use of this function, but in
reality opensips does not send anything to rtpengine if
|rtpengine_answer()| is called on a request route handling the INVITE.
Nothing in the log, no UDP exchange on the rtpengine control port,
regardless whether |rtpengine_offer()| is called earlier on that route
or not. If it is, the information exchange with rtpengine related to
|rtpengine_offer()| can be seen both in the log and on the rtpengine
control port.
The intended overall workflow is to call |rtpengine_offer()|, handle
the mangled SDP offer internally and generate the SDP answer, and get
it "mangled back" using |rtpengine_answer()| before using it as the
body of a locally generated 200 response to the INVITE. Could it be
that as of now, |rtpengine_manage()| not only "combines the
functionality ... based on message type and method ..." but the three
individual methods have actually become just aliases of
|rtpengine_manage()| for backward compatibility? Or is the actual
execution of |rtpengine_answer()| suppressed thanks to some
undocumented plausibility check?
Is there any way to enforce execution of |rtpengine_answer()| on a
request route handling the INVITE?
Thank you for advice.
Pavel
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:<http://lists.opensips.org/pipermail/users/attachments/20260308/028ddb67/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
------------------------------
End of Users Digest, Vol 212, Issue 6
*************************************
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
------------------------------
Subject: Digest Footer
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
------------------------------
End of Users Digest, Vol 212, Issue 8
*************************************
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
