Daniel,
I do like rtpengine_manage() philosophically, and agree it's easier to use and handles the case where the SDP offer is in the reply from the UAS.
I used to use it. However, it doesn't behave correctly in certain route script contexts. Here's an example from my own environment:
--- route[XYZ_TRY] { # Lots of stuff that can be executed either with or without # transaction already having been created, e.g. use send_reply(), # never just sl_send_reply() or t_reply(), etc.
t_on_branch("XYZ_BRANCH"); t_on_failure("XYZ_FAILURE");
t_relay(); }
branch_route[XYZ_BRANCH] { rtpengine_manage(); }
failure_route[XYZ_FAILURE] { if(t_is_canceled()) exit;
# Load some more routes maybe, create new # branch.
$rd = "new_host";
route(XYZ_TRY); } ---
This behaves mostly as you'd expect, _except_ in the case of a branch timeout. If there's a _timeout_ per se, e.g. branch #1 host did not respond, then in the subsequent branch #2 attempt, rtpengine_manage() in the branch_route will send a 'delete' command rather than an updated 'offer' command.
Perhaps the root of the problem is that I am calling a request_route from a failure_route, but I don't know how else to recycle the huge corpus of logic that's in XYZ_TRY. I'm open to better suggestions.
Notwithstanding that, there may be other exotic cases as well where rtpengine_manage() doesn't do the right thing. Either way, for this reason I do not use it.
-- Alex