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
