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

Alex Balashov abalashov at evaristesys.com
Wed Apr 23 19:24:48 CEST 2014

On 04/23/2014 01:22 PM, Richard Fuchs wrote:

> Main selection criterion is whether the message is a request or a
> reply, second criterion is the SIP method (taken from the CSeq)
> and/or the response code in case of a reply. The route type is only
> marginally relevant.

Yeah, so the key question is: what is the message we are acting upon?

It it is my theory that in a request route that is called from a 
failure_route that is triggered by a 302 reply, the message being 
operated on is actually the 302 reply, and not an initial INVITE. And 
that's why it doesn't produce the offer command as expected.

The legacy rtpproxy module may well behave the same way. I hadn't tried 
to use rtpproxy_manage() in this scope before, which is why I was 
imagining it to have "always worked".

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/

More information about the sr-users mailing list