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:00 [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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
