[SR-Users] remove_hf("Bla") for all requests

[Daniel-Constantin Mierla]

Hello,

no need to arm onreply_route[x] for all requests, you can just define:

reply_route {

  ...

}

It is the the equivalent of request_route, but for handling the replies
received by kamailio.

Cheers,
Daniel

On 12.09.18 18:20, Sergiu Pojoga wrote:
> That did the trick, sorry to have bothered.
>
> All that was to put SIP on a strict diet, as suggested by Alex in his
> article
> <http://www.evaristesys.com/blog/sip-udp-fragmentation-and-kamailio-the-sip-header-diet/>.
>
> Cheers!
>
>
> On Wed, Sep 12, 2018 at 11:50 AM Sergiu Pojoga <pojogas at gmail.com
> <mailto:pojogas at gmail.com>> wrote:
>
>     Hi Joel.
>
>     Yes, and it works fine, but only for the INVITE|SUBSCRIBE|UPDATE
>     methods or otherwise if I remove the /if
>     (is_method("INVITE|SUBSCRIBE|UPDATE"))/ statement entirely, which
>     will arm the /onreply_route/ for all types of methods, e.g.
>     OPTIONS or REGISTER, consequently go to NATMANAGE, which isn't
>     strictly necessary for all methods.
>
>     My dilema is mainly how to distinguish them within the same
>     /onreply_route/ block. Or may be I can put an /else/ to the
>     if(is_method()) and arm a different /onreply_route/ for the sole
>     purpose of /remove_hf()/... let me see.
>
>     On Wed, Sep 12, 2018 at 11:20 AM Joel Serrano <joel at textplus.com
>     <mailto:joel at textplus.com>> wrote:
>
>         I don't know if I understood correctly, but have you tried
>         just adding the remove_hf("User-Agent") in the onreply_route
>         just as you did in the request_route?
>
>         On Wed, Sep 12, 2018 at 7:37 AM, Sergiu Pojoga
>         <pojogas at gmail.com <mailto:pojogas at gmail.com>> wrote:
>
>             Hi there,
>
>             Say I need to remove_hf("User-Agent") for all requests,
>             back and forth. So I add it at the top of /request_route
>             /section. However, replies don't seem to be affected by it.
>
>             Do I really need to arm a /t_on_reply route/ for this
>             simple purpose? "Problem" with that is that /route[RELAY]/
>             already has some /onreply_route/ block doing things like
>             /NATMANAGE /for some methods and as far as I know - only
>             one/onreply_route/ can be armed for a request?
>
>             route[RELAY] {
>
>                 ...
>
>                 if (is_method("INVITE|SUBSCRIBE|UPDATE")) {
>                     if(!t_is_set("onreply_route"))
>                 t_on_reply("MANAGE_REPLY");
>                 }
>                 t_relay();
>
>             }
>
>             onreply_route[MANAGE_REPLY] {
>
>                 ...
>
>                 route(NATMANAGE);
>
>             }
>
>             Any suggestions? Thanks.
>
>             _______________________________________________
>             Kamailio (SER) - Users Mailing List
>             sr-users at lists.kamailio.org
>             <mailto:sr-users at lists.kamailio.org>
>             https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>         _______________________________________________
>         Kamailio (SER) - Users Mailing List
>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180912/5ba0da51/attachment.html>