On 26 Feb 2024, at 06:11, Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org> wrote: Hi I'm having another go at topos trying to solve an issue of sip messages getting to big for certain clients to process. Unfortunately some methods (ACK/PRACK/BYE probably CANCEL) do not contain a contact header, therefore the topology is still revealed (and potentially a lot of via header inserted increasing message size). Is it safe to set methods_nocontact to an empty string to force creation of a Contact header for every SIP method? Is there another way to completely hide topology aka keeping header small? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:

On 26 Feb 2024, at 09:15, Benoit Panizzon <benoit.panizzon(a)imp.ch> wrote: Hi Alex So, any idea how to solve the issue? At the moment, we have a commercial B2BUA SBC in front of Kamailio. This SBC has some severe limitations and bugs, costs a lot for licensing and is declared end of life next year. I would love to just get rid of it and let kamailio handle everything. So far, thinks look much cleaner and work more like expected, without the SBC. Even IPv6 and tls and even rtp-crypto work thanks to rtpengine. We loose T.38 fallback, but who cares, this also was not reliable before. But I must make sure, all existing CPE still work and can cope with the additional Via and RR header and this is where I stumbled over one vendor which seems to have messed that up by allocating a too small buffer for composing the reply message. Yes, we will contact that vendor, but I would not wonder if the reply will be that those devices have reached end of life and no bugfixes will be made. Now I am just fighting with topos again. When a CPE to which topology was hidden is sending an UPDATE. topos is unable to route that update. Investigating. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

On 26 Feb 2024, at 09:39, Benoit Panizzon <benoit.panizzon(a)imp.ch> wrote: Hi Alex Those CPE do not support TCP. I would love to do that. But can I somehow instruct kamailio to translate all headers to their compact format? Done that, removed User-Agent and some more. Still not enough if there are 5 or more Via and RR header. The message body is not the issue, this seems to be handled in a different memory buffer. The CPE crashed with a 'memory buffer too small' when composing the reply to an invite with 5 or more Via and RR even with minimalistic SDP. On the other hand, I threw a huge SDP with ICE and Crypto to that CPE and it handled it well when only one Via and no RR was present (after being handled by topos). Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

Those 5 vias remind me an old firmware of Cisco equipment. I think I found that once and solved with sems or something else acting as b2bua.