Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is SigComp
Compact Header form
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not.
The customary inter-Kamailio solution is jumbo frames (if you control network end-to-end) or TCP.
— Sent from mobile, with due apologies for brevity and errors.
On Apr 1, 2019, at 10:33 AM, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is SigComp Compact Header form As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
using tcp would be an option, as Alex mentioned, if you can control the udp mtu size. The alternative can be also sctp transport, which should be better that tcp. If you have a recent kernel, that could be better. However, I have to say that I haven't seen much use of sctp lately myself, so do a little testing yourself before pushing to production.
Then, looking at the compress option, enhancing gzcompress also for headers should be easy. But I think that it would require sort of encoding at the beginning, to know is an encrypted packet and eventually specify the algorithm for compression. Not sure if such protocol is defined somewhere else and we can reuse it, or we just brew one ourselves.
Actually, the proposal above with gzcompress module would be to make it simpler (as I thought of doing at some point when I sent packages over long distance and narrow band), because that is already possible if you use an embedded scripting language and corex module -- the example there is pretty much what you are looking for:
* https://www.kamailio.org/docs/modules/stable/modules/corex.html#async.evr.ne...
Cheers, Daniel
On 01.04.19 16:42, Alex Balashov wrote:
The customary inter-Kamailio solution is jumbo frames (if you control network end-to-end) or TCP.
— Sent from mobile, with due apologies for brevity and errors.
On Apr 1, 2019, at 10:33 AM, Igor Olhovskiy <igorolhovskiy@gmail.com mailto:igorolhovskiy@gmail.com> wrote:
Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is
- SigComp
- Compact Header form
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not. Sent from Mailspring _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Never quite got this. UDP packets can be up to 64k, right? And fragmentation is a standard IP feature if a packet is bigger than MTU size.
Steve
On Mon, 1 Apr 2019 at 16:43, Alex Balashov abalashov@evaristesys.com wrote:
The customary inter-Kamailio solution is jumbo frames (if you control network end-to-end) or TCP.
— Sent from mobile, with due apologies for brevity and errors.
On Apr 1, 2019, at 10:33 AM, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is
- SigComp
- Compact Header form
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not. [image: Sent from Mailspring]
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On 01/04/2019 11.22, Fred Posner wrote:
On 4/1/19 11:18 AM, Steve Davies wrote:
Never quite got this. UDP packets can be up to 64k, right? And fragmentation is a standard IP feature if a packet is bigger than MTU size.
Steve
of course, you're hoping that the fragmented packets arrive in order.
That really makes no difference. The network stack takes care of reassembling the fragments no matter what order they arrive in.
Issues only arrive from broken routers or firewalls, or if you have to deal with packet loss.
Cheers
On 4/1/19 11:30 AM, Richard Fuchs wrote:
of course, you're hoping that the fragmented packets arrive in order.
That really makes no difference. The network stack takes care of reassembling the fragments no matter what order they arrive in.
Issues only arrive from broken routers or firewalls, or if you have to deal with packet loss.
Cheers
I blame my initial response on a lack of coffee and attention to Kamailio Managed Cloud ;)
--fred
Issue with fragmented UDP is NAT routers that cannot forward second and follow fragments to SIP device. Connection tracking must be enabled on router.
https://serverfault.com/questions/533704/why-is-iptables-rejecting-the-secon...
пн, 1 апр. 2019 г. в 18:44, Fred Posner fred@palner.com:
On 4/1/19 11:30 AM, Richard Fuchs wrote:
of course, you're hoping that the fragmented packets arrive in order.
That really makes no difference. The network stack takes care of reassembling the fragments no matter what order they arrive in.
Issues only arrive from broken routers or firewalls, or if you have to deal with packet loss.
Cheers
I blame my initial response on a lack of coffee and attention to Kamailio Managed Cloud ;)
--fred
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Idea is to fit whole packet in MTU size. Mainly cause fragmentation is not best option in case of UDP. Causes retransmissions on a high CPS values.
Regards, Igor On Apr 1, 2019, 6:20 PM +0300, Steve Davies steve-lists-srusers@connection-telecom.com, wrote:
Never quite got this. UDP packets can be up to 64k, right? And fragmentation is a standard IP feature if a packet is bigger than MTU size.
Steve
On Mon, 1 Apr 2019 at 16:43, Alex Balashov abalashov@evaristesys.com wrote:
The customary inter-Kamailio solution is jumbo frames (if you control network end-to-end) or TCP.
— Sent from mobile, with due apologies for brevity and errors.
On Apr 1, 2019, at 10:33 AM, Igor Olhovskiy igorolhovskiy@gmail.com wrote:
Hi!
Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
What I googled is
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Indeed, such issues related to UDP fragmentation should not happen, the packets can be up to 64k, bigger than MTU size. I think linux had it for more than 20 years and most of routers are based on it.
But surprisingly, there are still some routers that cannot cope with that -- I get hit from time to time (not too often, I have to say it) with support requests related to this matter and I also wonder how that is still the case today.
Cheers, Daniel
On 01.04.19 17:18, Steve Davies wrote:
Never quite got this. UDP packets can be up to 64k, right? And fragmentation is a standard IP feature if a packet is bigger than MTU size.
Steve
On Mon, 1 Apr 2019 at 16:43, Alex Balashov <abalashov@evaristesys.com mailto:abalashov@evaristesys.com> wrote:
The customary inter-Kamailio solution is jumbo frames (if you control network end-to-end) or TCP. — Sent from mobile, with due apologies for brevity and errors. On Apr 1, 2019, at 10:33 AM, Igor Olhovskiy <igorolhovskiy@gmail.com <mailto:igorolhovskiy@gmail.com>> wrote:Hi! Was looking on some way to compress SIP signalling between internal servers. But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info. What I googled is 1. SigComp 2. Compact Header form As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime? All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not. Sent from Mailspring _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Mon, Apr 01, 2019 at 05:18:57PM +0200, Steve Davies wrote:
Never quite got this. UDP packets can be up to 64k, right? And fragmentation is a standard IP feature if a packet is bigger than MTU size.
The issue is that the UDP header is only present in the first fragment.
Some routers cannot deal with this intelligently, especially in concert with NAT.
On Monday 01 April 2019 at 16:33:17, Igor Olhovskiy wrote:
Hi!
Was looking on some way to compress SIP signalling between internal servers.
What problem are you trying to solve by compressing SIP?
But found out, there are no some pre-defined or recommended mechanism of doing this. Yes, I found gzcompress module, but it will help only in case of big body, but not whole message itself. Like in some cases you can have 4-5 RR headers, which is already a lot of info.
Surely you're still only talking about 100s to 1000s of bytes - how is that a problem for you?
What I googled is SigComp
Compact Header form
As I found, SigComp is really not widely-used method and it support along opensource SIP servers/PBXes is not documented. For Compact Header form - is there any way of using Kamailio to compress message this way? Maybe also there is a way of having some intermediate proxy-layer software, that will gzip/gunzip SIP signalling in realtime?
All of this actually cause info in SIP/SDP grows rapidly, unfortunately MTU size is not.
So, are you trying to restrict the total amount of data being sent in a SIP request / response, or are you trying to control the MTU size of the packets / frames that data is sent in?
Antony.
-
Alex Balashov -
Antony Stone -
Daniel-Constantin Mierla -
Fred Posner -
Igor Olhovskiy -
Richard Fuchs -
Sergey Safarov -
Steve Davies