<div dir="ltr">So gzcompress is no good with Asterisk then?  Is that meant to be used only with another Kamailio proxy?<div><br></div><div>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.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Marc</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17/12/14 23:20, Alex Balashov wrote:<br>
<div><div class="h5">> On 12/17/2014 05:14 PM, Marc Soda wrote:<br>
><br>
>> I'm having a problem reassembling UDP packets on my Asterisk servers<br>
>> after passing through Kamailio (it appears to me an OS level issue,<br>
>> nothing to do with Kamailio).  Is there a way, with Kamailio, to limit<br>
>> the size of a SIP message?  I know I can just start removing headers,<br>
>> but that doesn't seem like a realistic solution.  I see that Kamailio<br>
>> can compress the message body, but can Asterisk handle that?  How do<br>
>> other people handle this?<br>
><br>
</div></div>> 1. Any SIP-compliant endpoint should be able to handle compact<br>
> headers. Per RFC 3261 7.3.3 ("Compact Form"):<br>
><br>
>    Implementations MUST accept both the long and short forms of<br>
>    each header name.<br>
<br>
I don't think compact names for headers or joining bodies under single<br>
header name helps that much, it would be in the range of few tens of bytes.<br>
<br>
><br>
> 2. Some headers are critical should not be removed. Others really are<br>
> mostly useless bloat commonly added by verbose UACs, and, practically<br>
> speaking, the other peer will be neither colder nor warmer if they are<br>
> removed, unless there is a specific use for them.<br>
><br>
> Good candidates are:<br>
><br>
> a) The "Date" header.<br>
> b) Accept: headers listing every MIME type in the known universe.<br>
<br>
Mentioned on my previous email too -- keep_hf() from textopsx module can<br>
be handy here.<br>
<br>
><br>
> 3. If one or more of your endpoints offer every codec in the known<br>
> universe in the SDP, you can restrict the codecs offered to reduce the<br>
> SDP size.<br>
<br>
Another option to reduce the size -- sdpops module has related functions<br>
for sdp management.<br>
<br>
><br>
> 4. You could use TCP. In fact, RFC 3261 actually mandates this. Per<br>
> RFC 3261 Section 18.1.1 ("Sending Requests"):<br>
><br>
>    If a request is within 200 bytes of the path MTU, or if it is larger<br>
>    than 1300 bytes and the path MTU is unknown, the request MUST be sent<br>
>    using an RFC 2914 [43] congestion controlled transport protocol, such<br>
>    as TCP.<br>
><br>
> Of course, in reality, nobody cares or follows this, and many SIP<br>
> endpoints don't even support TCP (also mandated by RFC 3261).<br>
><br>
> 5. In some situations, header bloat comes from requests passing<br>
> through numerous proxies, each of which add a stackable Via header<br>
> and, if applicable, a Route/Record-Route set.<br>
><br>
> Reducing the number of intermediate proxies can help with this.<br>
><br>
> 6. You could run the traffic through a lightweight, signalling-only<br>
> B2BUA, such as SEMS, which deals with fragmented UDP in incoming<br>
> requests just fine, but does not reoriginate on leg B all the bloated<br>
> headers that came in on leg A.<br>
<br>
SEMS (like any other application layer program) had very few to do with<br>
fragmentation. It is the kernel/operating system that sorts all this. It<br>
the application is the same 'recvfrom(...)'.<br>
<br>
At the end, Asterisk is also a B2BUA and I guess if there is a server<br>
with an OS that can handle udp fragmentation, the Asterisk will be run<br>
there instead of adding another b2bua.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
><br>
> 7. Other than these things, there are no real solutions.<br>
><br>
> -- Alex<br>
<div class="HOEnZb"><div class="h5">><br>
<br>
<br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a><br>
<br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br clear="all"><div><br></div>
</div></div></div>