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

[Sergiu Pojoga]

Precisely what I need, thanks Daniel.

On Wed, Sep 12, 2018 at 12:59 PM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> 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> 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> 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>
>>> 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
>>>> 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
>>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.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/ec9a9253/attachment.html>