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 <attio...@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 > (mico...@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 (attio...@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 > -- Savolainen Dmitri
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users