[SR-Users] Manipulate sip header on an in-dialog negative reply

Dmitri Savolainen savolainen at erinaco.ru
Mon Dec 24 14:23:23 CET 2018


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 at 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 at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Savolainen Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20181224/665af349/attachment.html>


More information about the sr-users mailing list