23 Apr
2014
23 Apr
'14
12:59 p.m.
The reason I had not previously considered this possibility is because
the documentation says--or, at least to my lackadaisical
interpretation--that rtpproxy_manage() will only call rtpproxy_answer()
if it is operating on a 1xx/2xx reply with SDP, otherwise it'll send
rtpproxy_offer(), or send a delete command if it's a >= 300 reply.
On 04/23/2014 12:51 PM, Alex Balashov wrote:
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/