There are lots of strategies for reducing message size, although the RFC-recommended (better said, mandated :-) approach is just to switch to TCP whenever your message sizes come within 200 bytes of the MTU, if I'm not mistaken.

Otherwise:

1) Turn on compact (abbreviated) SIP headers;

2) Strip header fields you can do without. This is dangerous territory, but clearly some headers are less important than others, like "Date" or "Allow";

3) Do not offer any unnecessary codecs, reducing SDP bloat.

-- Alex

On 26 Feb 2024, at 09:15, Benoit Panizzon benoit.panizzon@imp.ch wrote:

Hi Alex

...

Not really a great answer for you, but I think you should reconsider using `topos` to reduce SIP message size.

`topos` is complex and I'm not sure the added complexity pays off in this case, from a purely thermodynamic point of view.

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 ______________________________________________________

Sadly, there is no way to make Kamailio inject compact headers. That's up to the UAs.

Well, if your hands really are that tied, then maybe topos is worth exploring after all. However, I would carefully weigh the complexity and failure modes and overall supportability issues against short-term benefit. Consider, for example, the ways in which `topos` makes troubleshooting that much harder, since you've now got apparently different call legs in and out of the proxy.

I was trying to make a somewhat broader, methodological point: Kamailio is an eclectic grab-bag of interesting technical tools, but just because Kamailio is technically capable of something doesn't mean you should do it.

It might be worth considering the larger business impact of the solution in many cases, rather than viewing every problem as a nail and Kamailio's dazzling, kaleidoscopic array of SIP manipulation capabilities as a hammer. The simplest possible solution is often not the quickest, nor the most interesting, but may make the most sense in the long run.

If the CPE is reacting this poorly to a stack of perfectly standards-compliant Via or RR headers, it really may be worth doing the boring, tedious and time-consuming work of getting the vendor to fix, or replacing the CPE. Otherwise, you'll patch this hole and doubtless find another leak in the boat soon.

-- Alex

On 26 Feb 2024, at 09:39, Benoit Panizzon benoit.panizzon@imp.ch wrote:

Hi Alex

...

There are lots of strategies for reducing message size, although the RFC-recommended (better said, mandated :-) approach is just to switch to TCP whenever your message sizes come within 200 bytes of the MTU, if I'm not mistaken.

Those CPE do not support TCP.

...

Otherwise:

1. Turn on compact (abbreviated) SIP headers;

I would love to do that. But can I somehow instruct kamailio to translate all headers to their compact format?

...

2. Strip header fields you can do without. This is dangerous territory, but clearly some headers are less important than others, like "Date" or "Allow";

Done that, removed User-Agent and some more. Still not enough if there are 5 or more Via and RR header.

...

3. Do not offer any unnecessary codecs, reducing SDP bloat.

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 ______________________________________________________

Hi John

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.

It's not a Cisco. It's an ARRIS CPE which used to be operated as PacketCable CPE but for which also a SIP Firmware is available.

I would love to use Kamailio as Registrar, especially as NAT seems to work much better directly on Kamailio compared to when we use our commercial B2BUA SBC in between which completely messes up some 'multiple CPE behind same NAT IP' situations.

But we might have figured out, what breaks topos. It's when a call is from one CPE to another, both on the same Registrar. So we have two call legs with the same callID on one registrar and on one topos instance.

May I ask what you used as B2BUA?

Mit freundlichen Grüssen

-Benoît Panizzon-