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/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
