24 Dec
2018
24 Dec
'18
6:23 p.m.
Hi. I resolved similar situation with
modparam("tm", "on_sl_reply", "stateless_replies")
.....
onreply_route["stateless_replies"] {
# do not allow stateless replies to be forwarded
return 0;
}
On Fri, 21 Dec 2018 at 23:31, Olli Attila <attiolli(a)gmail.com> wrote:
Hello,
The onreply route removal does not seem to work here. Am i missing
something? :
Call is routed via dispatch module:
route[DISPATCH] {
t_on_reply("MANAGE_REPLY");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
onreply_route[MANAGE_REPLY] {
remove_hf_re("^X-");
remove_hf("P-Charging-Vector");
}
route[RELAY] {
if (!t_relay()) {
sl_reply_error();
}
exit;
}
--Olli
to 20. jouluk. 2018 klo 14.31 Daniel-Constantin Mierla
(miconda(a)gmail.com) kirjoitti:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
Washington, DC, USA -- www.asipto.com
--
"Logic is the art of going wrong with confidence."
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Savolainen Dmitri
Hello,
in the failure route you have the request under processing, not the
response.
You have to use an onreply_route[x] for that transaction and do there
remove_hf()
Cheers,
Daniel
On 20.12.18 11:57, Olli Attila wrote:
> Hello,
> Any ideas about this header
manipulation?
> Cheers,
> Olli
> pe 14. jouluk. 2018 klo 12.31 Olli
Attila (attiolli(a)gmail.com)
kirjoitti:
Hello,
We have a call case where our softswitch replies to in-dialog
re-invite with "SIP 491 Request pending". This happens when a customer
sip device is trying to re-invite the session too fast even though the
softswitch is still processing the earlier request. Kamailio operates
between this customer device and the softswitch.
The softswitch is adding a P-Charging-Vector header to this SIP 491
reply which we want to drop (remove_hf...) from the reply when we
route the SIP 491 message back to the customers device.
I tried to drop this inside in-dialog failure route but it seems that
Kamailio forwards the orginal 491 message statelessly to customer and
the header still extists there eventhough failure route has deleted
it. I guess this modification should be done in a sateful manner for
Kamailio to actually write the changes to the outgoing reply towards
the customer device.
Any suggestions how the 491 reply could be edited and then forwarded
onwards to the customer device?
Cheers,
--Olli