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?
>

> 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.

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.

>
> 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@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
_______________________________________________
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