Maybe it's not a bug. I think I've got a theory about what may be happening. Admittedly, it's not trivial to follow, but bear with me.
The invocation of rtpproxy_manage() is happening in a REQUEST_ROUTE that is actually being triggered out of a FAILURE_ROUTE, because we are pulling routing info from a redirect server. So, it looks like this (obviously, greatly simplified):
# Main request route.
route { ...
t_on_failure("FAIL"); t_relay(); }
route[PROCESS_CALL] { rtpproxy_manage("o"); }
failure_route[FAIL] { if($T_rpl($rs) == 302) { ...
route(PROCESS_CALL); } }
Now, "PROCESS_CALL" is a request route and the things that are done inside it are all safe to do inside a FAILURE_ROUTE, e.g. no stateless replies. However, because it's being called from a FAILURE_ROUTE, I'll bet what's happening is that the evaluative context tells rtpproxy_manage() that it's dealing with a _reply_ (the 302 redirect), not a _request_, so it should be sending an 'answer' on that basis.
Does that sound reasonable? I don't have an easy way of testing this thesis right now since it's production.