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

[Alex Balashov]

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/