<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 18/12/14 02:58, Marc Soda wrote:<br>
</div>
<blockquote
cite="mid:CAFBTUUYt5qzC1RoghuMmxj5L-gvmnc4a+y=igikzSdybUJ=N5g@mail.gmail.com"
type="cite">
<div dir="ltr">So gzcompress is no good with Asterisk then? Is
that meant to be used only with another Kamailio proxy?</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAFBTUUYt5qzC1RoghuMmxj5L-gvmnc4a+y=igikzSdybUJ=N5g@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</div>
</blockquote>
<br>
This is the web world -- lot of data even for little content, like
for html pages :-)<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<blockquote
cite="mid:CAFBTUUYt5qzC1RoghuMmxj5L-gvmnc4a+y=igikzSdybUJ=N5g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<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
moz-do-not-send="true" 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 moz-do-not-send="true"
href="http://twitter.com/#%21/miconda"
target="_blank">http://twitter.com/#!/miconda</a>
- <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a></pre>
</body>
</html>