18 Dec
2014
18 Dec
'14
3:14 a.m.
I'm having a problem reassembling UDP packets on my Asterisk servers after
passing through Kamailio (it appears to me an OS level issue, nothing to do
with Kamailio). Is there a way, with Kamailio, to limit the size of a SIP
message? I know I can just start removing headers, but that doesn't seem
like a realistic solution. I see that Kamailio can compress the message
body, but can Asterisk handle that? How do other people handle this?
Thanks in advance,
Marc
18 Dec
18 Dec
3:20 a.m.
On 12/17/2014 05:14 PM, Marc Soda wrote:
I'm having a problem reassembling UDP packets on
my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact headers.
Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others really are
mostly useless bloat commonly added by verbose UACs, and, practically
speaking, the other peer will be neither colder nor warmer if they are
removed, unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to reduce the
SDP size.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per RFC
3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing through
numerous proxies, each of which add a stackable Via header and, if
applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the bloated
headers that came in on leg A.
7. Other than these things, there are no real solutions.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
4:47 a.m.
On 17/12/14 23:20, Alex Balashov wrote:
On 12/17/2014 05:14 PM, Marc Soda wrote:
I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens of bytes.
I'm having a problem reassembling UDP packets
on my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others really are
mostly useless bloat commonly added by verbose UACs, and, practically
speaking, the other peer will be neither colder nor warmer if they are
removed, unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx module can
be handy here.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to reduce the
SDP size.
Another option to reduce the size -- sdpops module has related functions
for sdp management.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
RFC 3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing
through numerous proxies, each of which add a stackable Via header
and, if applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the bloated
headers that came in on leg A.
SEMS (like any other application layer program) had very few to do with
fragmentation. It is the kernel/operating system that sorts all this. It
the application is the same 'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.
Cheers,
Daniel
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
6:58 a.m.
So gzcompress is no good with Asterisk then? Is that meant to be used only
with another Kamailio proxy?
We're trying to do a WebRTC POC with Kamailio as the proxy. The SIP
headers and SDP are huge! I've never seen such big messages.
Thanks,
Marc
On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
On 17/12/14 23:20, Alex Balashov wrote:
On 12/17/2014 05:14 PM, Marc Soda wrote:
I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens of bytes.
I'm having a problem reassembling UDP packets
on my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others really are
mostly useless bloat commonly added by verbose UACs, and, practically
speaking, the other peer will be neither colder nor warmer if they are
removed, unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx module can
be handy here.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to reduce the
SDP size.
Another option to reduce the size -- sdpops module has related functions
for sdp management.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
RFC 3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing
through numerous proxies, each of which add a stackable Via header
and, if applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the bloated
headers that came in on leg A.
SEMS (like any other application layer program) had very few to do with
fragmentation. It is the kernel/operating system that sorts all this. It
the application is the same 'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.
Cheers,
Daniel
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:01 a.m.
Indeed, gzcompress is a Kamailio-only concept.
On 17 December 2014 20:58:22 GMT-05:00, Marc Soda <msoda(a)coredial.com> wrote:
So gzcompress is no good with Asterisk then? Is that
meant to be used
only
with another Kamailio proxy?
We're trying to do a WebRTC POC with Kamailio as the proxy. The SIP
headers and SDP are huge! I've never seen such big messages.
Thanks,
Marc
On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com
I don't think compact names for headers or joining bodies under single
can
functions
with
--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully
fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
wrote:
On 17/12/14 23:20, Alex Balashov wrote:
> On 12/17/2014 05:14 PM, Marc Soda wrote:
>
>> I'm having a problem reassembling UDP packets on my Asterisk
servers
>> after passing through Kamailio (it
appears to me an OS level
issue,
>> nothing to do with Kamailio). Is there
a way, with Kamailio, to
limit
>> the size of a SIP message? I know I can
just start removing
headers,
>> but that doesn't seem like a
realistic solution. I see that
Kamailio
>> can compress the message body, but can
Asterisk handle that? How
do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name. header name helps that much, it would be in the
range of few tens of
bytes.
>
> 2. Some headers are critical should not be removed. Others really
are
> mostly useless bloat commonly added by
verbose UACs, and,
practically
> speaking, the other peer will be neither
colder nor warmer if they
are
removed,
unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx module be handy here.
>
> 3. If one or more of your endpoints offer every codec in the known
> universe in the SDP, you can restrict the codecs offered to reduce
the
SDP size.
Another option to reduce the size -- sdpops module has related for sdp management.
>
> 4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
> RFC 3261 Section 18.1.1 ("Sending Requests"):
>
> If a request is within 200 bytes of the path MTU, or if it is
larger
> than 1300 bytes and the path MTU is
unknown, the request MUST be
sent
> using an RFC 2914 [43] congestion
controlled transport protocol,
such
> as TCP.
>
> Of course, in reality, nobody cares or follows this, and many SIP
> endpoints don't even support TCP (also mandated by RFC 3261).
>
> 5. In some situations, header bloat comes from requests passing
> through numerous proxies, each of which add a stackable Via header
> and, if applicable, a Route/Record-Route set.
>
> Reducing the number of intermediate proxies can help with this.
>
> 6. You could run the traffic through a lightweight, signalling-only
> B2BUA, such as SEMS, which deals with fragmented UDP in incoming
> requests just fine, but does not reoriginate on leg B all the
bloated
headers
that came in on leg A.
SEMS (like any other application layer program) had very few to do fragmentation. It is the kernel/operating system
that sorts all this.
It
the application is the same
'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be
run
there instead of adding another b2bua.
Cheers,
Daniel
list
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
------------------------------------------------------------------------
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:14 a.m.
And yeah, WebRTC is morbidly obese. I think your best bet is to use TCP.
--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully
fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
3:04 p.m.
On 18 Dec 2014, at 03:01, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Indeed, gzcompress is a Kamailio-only concept.
In fact we got it from Facetime...
SHould be easy to implement in Asterisk too.
/O
On 17 December 2014 20:58:22 GMT-05:00, Marc Soda <msoda(a)coredial.com> wrote:
So gzcompress is no good with Asterisk then? Is that meant to be used only with another
Kamailio proxy?
We're trying to do a WebRTC POC with Kamailio as the proxy. The SIP headers and SDP
are huge! I've never seen such big messages.
Thanks,
Marc
On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
On 17/12/14 23:20, Alex Balashov wrote:
On 12/17/2014 05:14 PM, Marc Soda wrote:
I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens of bytes.
I'm having a problem reassembling UDP packets
on my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others really are
mostly useless bloat commonly added by verbose UACs, and, practically
speaking, the other peer will be neither colder nor warmer if they are
removed, unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx module can
be handy here.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to reduce the
SDP size.
Another option to reduce the size -- sdpops module has related functions
for sdp management.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
RFC 3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing
through numerous proxies, each of which add a stackable Via header
and, if applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the bloated
headers that came in on leg A.
SEMS (like any other application layer program) had very few to do with
fragmentation. It is the kernel/operating system that sorts all this. It
the application is the same 'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.
Cheers,
Daniel
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully
fledged keyboard.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:06 p.m.
On 18/12/14 02:58, Marc Soda wrote:
So gzcompress is no good with Asterisk then? Is that
meant to be used
only with another Kamailio proxy?
Apparently Apple Facetime is using this kind of compression (as it was
reported on a blog and triggered the implementation in Kamailio), but
one cannot interconnect with them anyhow. IIRC, FreeSwitch implemented
it as well.
We're trying to do a WebRTC POC with Kamailio as the proxy. The SIP
headers and SDP are huge! I've never seen such big messages.
This is the web world -- lot of data even for little content, like for
html pages :-)
Cheers,
Daniel
Thanks,
Marc
On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
On 17/12/14 23:20, Alex Balashov wrote:
I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens
of bytes.
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On 12/17/2014 05:14 PM, Marc Soda wrote:
> I'm having a problem reassembling UDP packets on my Asterisk
servers
> after passing through Kamailio (it appears to
me an OS level issue,
> nothing to do with Kamailio). Is there a way, with Kamailio,
to limit
> the size of a SIP message? I know I can just
start removing
headers,
> but that doesn't seem like a realistic
solution. I see that
Kamailio
> can compress the message body, but can
Asterisk handle that?
How do
other
people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others
really are
mostly useless bloat commonly added by verbose
UACs, and,
practically
speaking, the other peer will be neither colder
nor warmer if
they are
removed, unless there is a specific use for
them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx
module can
be handy here.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to
reduce the
SDP size.
Another option to reduce the size -- sdpops module has related
functions
for sdp management.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
RFC 3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is
larger
than 1300 bytes and the path MTU is unknown,
the request MUST
be sent
using an RFC 2914 [43] congestion controlled
transport
protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing
through numerous proxies, each of which add a stackable Via header
and, if applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the
bloated
headers that came in on leg A.
SEMS (like any other application layer program) had very few to do
with
fragmentation. It is the kernel/operating system that sorts all
this. It
the application is the same 'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.
Cheers,
Daniel
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:57 p.m.
Content-Length: 1901.
So trimming up the headers isn't going to get me anywhere... I'm not
comfortable enough with WebRTC to know what to trim out of the SDP, either.
How can I force Kamailio to use TCP for SIP when relaying the call? I
haven't found much info on it.
Marc
On Thu, Dec 18, 2014 at 5:06 AM, Daniel-Constantin Mierla <miconda(a)gmail.com
wrote:
On 18/12/14 02:58, Marc Soda wrote:
So gzcompress is no good with Asterisk then? Is that meant to be used
only with another Kamailio proxy?
Apparently Apple Facetime is using this kind of compression (as it was
reported on a blog and triggered the implementation in Kamailio), but one
cannot interconnect with them anyhow. IIRC, FreeSwitch implemented it as
well.
We're trying to do a WebRTC POC with Kamailio as the proxy. The SIP
headers and SDP are huge! I've never seen such big messages.
This is the web world -- lot of data even for little content, like for
html pages :-)
Cheers,
Daniel
Thanks,
Marc
On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
On 17/12/14 23:20, Alex Balashov wrote:
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
On 12/17/2014 05:14 PM, Marc Soda wrote:
I don't think compact names for headers or joining bodies under single
header name helps that much, it would be in the range of few tens of
bytes.
I'm having a problem reassembling UDP packets
on my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
1. Any SIP-compliant endpoint should be able to handle compact
headers. Per RFC 3261 7.3.3 ("Compact Form"):
Implementations MUST accept both the long and short forms of
each header name.
2. Some headers are critical should not be removed. Others really are
mostly useless bloat commonly added by verbose UACs, and, practically
speaking, the other peer will be neither colder nor warmer if they are
removed, unless there is a specific use for them.
Good candidates are:
a) The "Date" header.
b) Accept: headers listing every MIME type in the known universe.
Mentioned on my previous email too -- keep_hf() from textopsx module can
be handy here.
3. If one or more of your endpoints offer every codec in the known
universe in the SDP, you can restrict the codecs offered to reduce the
SDP size.
Another option to reduce the size -- sdpops module has related functions
for sdp management.
4. You could use TCP. In fact, RFC 3261 actually mandates this. Per
RFC 3261 Section 18.1.1 ("Sending Requests"):
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
Of course, in reality, nobody cares or follows this, and many SIP
endpoints don't even support TCP (also mandated by RFC 3261).
5. In some situations, header bloat comes from requests passing
through numerous proxies, each of which add a stackable Via header
and, if applicable, a Route/Record-Route set.
Reducing the number of intermediate proxies can help with this.
6. You could run the traffic through a lightweight, signalling-only
B2BUA, such as SEMS, which deals with fragmented UDP in incoming
requests just fine, but does not reoriginate on leg B all the bloated
headers that came in on leg A.
SEMS (like any other application layer program) had very few to do with
fragmentation. It is the kernel/operating system that sorts all this. It
the application is the same 'recvfrom(...)'.
At the end, Asterisk is also a B2BUA and I guess if there is a server
with an OS that can handle udp fragmentation, the Asterisk will be run
there instead of adding another b2bua.
Cheers,
Daniel
7. Other than these things, there are no real solutions.
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:41 a.m.
The safest way is to switch to tcp if the OS cannot do defrag of UDP
packets.
Kamailio cannot do much otherwise, however, if you want to play with
removing unecessary headers, look at keep_hf() function from textopsx
module.
Cheers,
Daniel
On 17/12/14 23:14, Marc Soda wrote:
I'm having a problem reassembling UDP packets on
my Asterisk servers
after passing through Kamailio (it appears to me an OS level issue,
nothing to do with Kamailio). Is there a way, with Kamailio, to limit
the size of a SIP message? I know I can just start removing headers,
but that doesn't seem like a realistic solution. I see that Kamailio
can compress the message body, but can Asterisk handle that? How do
other people handle this?
Thanks in advance,
Marc
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
19 Dec
19 Dec
2:11 a.m.
>>>> "MS" == Marc Soda
<msoda(a)coredial.com> writes:
MS> I'm having a problem reassembling UDP packets on my Asterisk servers after
MS> passing through Kamailio
You could try having the kama->ast socket use tcp.
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
6:53 p.m.
That's how I ended up going. It's working now. Thanks.
On Thu, Dec 18, 2014 at 4:11 PM, James Cloos <cloos(a)jhcloos.com> wrote:
--
Marc Soda
Sr. Systems Architect, Production Systems // *CoreDial, LLC* //
coredial.com // [image: Twitter] <https://twitter.com/coredial> [image:
LinkedIn] <http://www.linkedin.com/company/99631> [image: Google Plus]
<https://plus.google.com/104062177220750809525/posts> [image: Blog]
<http://success.coredial.com/blog>
751 Arbor Way, Hillcrest I, Suite 150, Blue Bell, PA 19422
*P: *215.297.4400 x203 // *F: *215.297.4401 // *E: *
msoda(a)coredial.com
[image: Success Starts Here. Check out our blog and subscribe today!]
<http://cta-service-cms2.hubspot.com/cs/c/?&cta_guid=59f8a888-5f9f-4320-bd00-59436c5af213&placement_guid=9ea684ae-6f3c-407c-a8f7-1c93aa481db6&portal_id=210539&redirect_url=a/M/ef3qXLrO9PM9nt4KAyUqKgEk1bjS%2BVrjJ9WLfaFcK2fhsQYM3JV0AXyMHtXQEFZiDnBKD38%3D&iv=4s02rvvxZAY%3D&hsutk=&canon=http%3A%2F%2Fwww.stratusinteractive.com%2Fcoredial%2Femail%2Fcoredial-signature.html>
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.
>>>> "MS" == Marc Soda
<msoda(a)coredial.com> writes:
MS> I'm having a problem reassembling UDP packets on my Asterisk servers
after
MS> passing through Kamailio
You could try having the kama->ast socket use tcp.
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
3436
days inactive
3438
days old
13 comments
7 participants
participants (7)
-
Alex Balashov -
Daniel-Constantin Mierla -
James Cloos -
Juha Heinanen -
Marc Soda -
Olle E. Johansson -
Richard Fuchs