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

Amar Tinawi amar.tinawi at gmail.com
Wed Sep 12 19:36:57 CEST 2018


Hello Sergiu
I assum you are trying to reduce the packet size right ?

How benefit is removing one header ?


On Wed, Sep 12, 2018, 8:34 PM Sergiu Pojoga <pojogas at gmail.com> wrote:

> 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
>>
>> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180912/eda16074/attachment.html>


More information about the sr-users mailing list