Thanks all for your inputs,
Julien: that worked like a charm! There's even no need to do
remove_record_route() in the failure route, everything reverts back to
original message by magic. As a bonus, it fixed my old-time problem where
multiple append_hf headers would be added for as many failure branches
existed and remove_hf wouldn't help.
Cheers!
On Sun, Apr 28, 2019 at 2:51 PM Julien Chavanton <jchavanton(a)gmail.com>
wrote:
This should restore the message in failure route as it was before you
modify it from the main route , call it before anything else that could
modify the message.
t_save_lumps()
On Sat, Apr 27, 2019, 16:02 Sergiu Pojoga <pojogas(a)gmail.com> wrote:
Hi ppl,
After a branch route fails, I need to re-evaluate the next destination
and adjust RR parameters, if need be, like for example adjust the
nat=yes|priv.
failure_route[MANAGE_PSTN_FAILURE] {
...
remove_record_route();
record_route();
route(NATMANAGE);
...
route(RELAY);
}
The result is that the new branch is stripped of "Record-Route:
<sip:MYIP>", but the params remained. Moreover, record_route hasn't been
re-added as instructed in the failure route.
Request headers of the initial branch that will eventually timeout and
fail:
2019/04/27 18:29:18.034992 10.22.0.1:5060 -> 10.22.0.100:5060
INVITE sip:1514XXXXXXX@10.22.0.100 SIP/2.0
Record-Route: <sip:10.22.0.1;r2=on;lr=on;did=9e2.3dd2;nat=priv>
Record-Route: <sip:65.XX.XX.1;r2=on;lr=on;did=9e2.3dd2;nat=priv>
New request branch after failure:
2019/04/27 18:29:19.538292 65.XX.XXX.1:5060 -> 65.XX.XX.2:5060
INVITE sip:1514XXXXXXX@65.XX.XX.2 SIP/2.0
;lr=on;did=9e2.3dd2;nat=priv>
kamailio -v
version: kamailio 5.1.6 (x86_64/linux) 7d1964
Much obliged.
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users