[OpenSIPS-Users] rtpengine_answer() is silently ignored on request route handling the initial INVITE when acting as an UAS - what am I missing?

[Pavel Sindelka]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20260308/3cfa59d2/attachment.html>