<html><head></head><body>Indeed, gzcompress is a Kamailio-only concept. <br><br><div class="gmail_quote">On 17 December 2014 20:58:22 GMT-05:00, Marc Soda <msoda@coredial.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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>
<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br />sr-users@lists.sip-router.org<br /><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br /></pre></blockquote></div><br>
--<br>
Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. <br>
<br>
Alex Balashov - Principal <br>
Evariste Systems LLC<br>
235 E Ponce de Leon Ave<br>
Suite 106<br>
Decatur, GA 30030<br>
United States<br>
Tel: +1-678-954-0671<br>
Web: <a href="http://www.evaristesys.com">http://www.evaristesys.com</a>/, <a href="http://www.alexbalashov.com">http://www.alexbalashov.com</a></body></html>