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
What if you do:
remove_hf(“Record-Route”);
?
— Sent from mobile, with due apologies for brevity and errors.
On Apr 27, 2019, at 7:00 PM, Sergiu Pojoga pojogas@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Alex, tried that, remove_hf doesn't produce desired result because the received request has no Record-Route header.
Cheers,
On Sun, Apr 28, 2019 at 1:32 AM Alex Balashov abalashov@evaristesys.com wrote:
What if you do:
remove_hf(“Record-Route”);
?
— Sent from mobile, with due apologies for brevity and errors.
On Apr 27, 2019, at 7:00 PM, Sergiu Pojoga pojogas@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi, Have you tried to do the record route manipulations in a branch_route (both for the first branch and for the one after the failure)?
Regards,
Federico
On Sun, 28 Apr 2019, 14:02 Sergiu Pojoga, pojogas@gmail.com wrote:
Hi Alex, tried that, remove_hf doesn't produce desired result because the received request has no Record-Route header.
Cheers,
On Sun, Apr 28, 2019 at 1:32 AM Alex Balashov abalashov@evaristesys.com wrote:
What if you do:
remove_hf(“Record-Route”);
?
— Sent from mobile, with due apologies for brevity and errors.
On Apr 27, 2019, at 7:00 PM, Sergiu Pojoga pojogas@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Federico Cabiddu -
Julien Chavanton -
Sergiu Pojoga