Indeed, gzcompress is a Kamailio-only concept.
On 17 December 2014 20:58:22 GMT-05:00, Marc Soda msoda@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@gmail.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?
- 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.
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.
- 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.
- 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.
- 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).
- 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.
- 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
- 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@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@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