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
El Mon, 26 Feb 2024 15:39:31 +0100
Benoit Panizzon via sr-users escribió:
>
> 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
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
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:
>
>
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)
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
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.
> On 26 Feb 2024, at 06:11, Benoit Panizzon via sr-users
>
