[SR-Users] rtpproxy_manage() issues in rtpproxy-ng

[Alex Balashov]

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/