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".