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 ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
