1 Apr
2019
1 Apr
'19
4:33 p.m.
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.
1 Apr
1 Apr
4:42 p.m.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:11 p.m.
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.n…
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(a)gmail.com
<mailto:igorolhovskiy@gmail.com>> wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
5:18 p.m.
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(a)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(a)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.
[image: Sent from Mailspring]
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:30 p.m.
On 01/04/2019 11.22, Fred Posner wrote:
On 4/1/19 11:18 AM, Steve Davies wrote:
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
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.
5:44 p.m.
On 4/1/19 11:30 AM, Richard Fuchs wrote:
I blame my initial response on a lack of coffee and attention to
Kamailio Managed Cloud ;)
--fred
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
6:51 p.m.
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-seco…
пн, 1 апр. 2019 г. в 18:44, Fred Posner <fred(a)palner.com>om>:
On 4/1/19 11:30 AM, Richard Fuchs wrote:
I blame my initial response on a lack of coffee and attention to
Kamailio Managed Cloud ;)
--fred
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
5:23 p.m.
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(a)connection-telecom.com>om>, 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(a)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(a)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.
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users(a)lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:26 p.m.
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(a)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(a)gmail.com <mailto:igorolhovskiy@gmail.com>> wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
11:44 p.m.
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.
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
5:18 p.m.
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.
--
"Measuring average network latency is about as useful as measuring the mean
temperature of patients in a hospital."
- Stéphane Bortzmeyer
Please reply to the list;
please *don't* CC me.
2138
days inactive
2138
days old
11 comments
8 participants
participants (8)
-
Alex Balashov -
Antony Stone -
Daniel-Constantin Mierla -
Fred Posner -
Igor Olhovskiy -
Richard Fuchs -
Sergey Safarov -
Steve Davies