<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello,</p>
<p><a class="moz-txt-link-freetext"
href="https://opensips.org/docs/modules/3.6.x/rtpengine.html#func_rtpengine_answer">https://opensips.org/docs/modules/3.6.x/rtpengine.html#func_rtpengine_answer</a>
doesn't mention any restrictions on use of this function, but in
reality opensips does not send anything to rtpengine if <code>rtpengine_answer()</code> is
called on a request route handling the INVITE. Nothing in the log,
no UDP exchange on the rtpengine control port, regardless whether <code>rtpengine_offer()</code> is
called earlier on that route or not. If it is, the information
exchange with rtpengine related to <code>rtpengine_offer()</code> can
be seen both in the log and on the rtpengine control port.</p>
<p>The intended overall workflow is to call <code>rtpengine_offer()</code>,
handle the mangled SDP offer internally and generate the SDP
answer, and get it "mangled back" using <code>rtpengine_answer()</code>
before using it as the body of a locally generated 200 response to
the INVITE. Could it be that as of now, <code>rtpengine_manage()</code>
not only "combines the functionality ... based on message type and
method ..." but the three individual methods have actually become
just aliases of <code>rtpengine_manage()</code> for backward
compatibility? Or is the actual execution of <code>rtpengine_answer()</code> suppressed
thanks to some undocumented plausibility check?</p>
<p>Is there any way to enforce execution of <code>rtpengine_answer()</code>
on a request route handling the INVITE?</p>
<p>Thank you for advice.</p>
<p>Pavel</p>
</body>
</html>