26 Feb
2024
26 Feb
'24
2:11 p.m.
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
______________________________________________________
26 Feb
26 Feb
3:33 p.m.
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
<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:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
5:15 p.m.
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
______________________________________________________
5:26 p.m.
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(a)imp.ch> wrote:
Hi Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
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
______________________________________________________
5:39 p.m.
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
______________________________________________________
6:04 p.m.
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(a)imp.ch> wrote:
Hi Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
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
______________________________________________________ 
8:18 p.m.
El Mon, 26 Feb 2024 15:39:31 +0100
Benoit Panizzon via sr-users <sr-users(a)lists.kamailio.org> 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 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).
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.
Not sure if this is the same case but it didn't have to do with the length of
the message but rather with a limitation on the number of vias in the firmware.
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
27 Feb
27 Feb
10:34 a.m.
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-
--
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
______________________________________________________
269
days inactive
270
days old
7 comments
3 participants
participants (3)
-
Alex Balashov -
Benoit Panizzon -
Jon Bonilla (Manwe)