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.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
