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
Hi,
We had the same problem. As you noted, this is due to a race where the initial INVITE is processed by a different worker thread than the re-INVITE.
We solved this by introducing a (very!) small asynchronous delay in handling all reinvites, around 30 ms or so. That was lazy and probably could be improved by using 'table' or 'dialog' variables to track whether the reinvite received is the first reinvite for a given dialog, and only delay it then.
Regardless, a litany of features is available to make this easy:
https://kamailio.org/docs/modules/5.2.x/modules/async.html#async.f.async_sle... https://kamailio.org/docs/modules/5.2.x/modules/rtimer.html https://kamailio.org/docs/modules/5.2.x/modules/mqueue.html
Though I take no pleasure in saying it, this is probably the most fruitful solution.
-- Alex
Hello,
Any ideas about this header manipulation?
Cheers, Olli
pe 14. jouluk. 2018 klo 12.31 Olli Attila (attiolli@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
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@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
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@gmail.com) kirjoitti:
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@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
-- 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
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@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@gmail.com) kirjoitti:
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@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
-- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Daniel-Constantin Mierla -
Dmitri Savolainen -
Olli Attila