[SR-Users] SIP Fragments

[Marc Soda]

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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141217/46ff50f6/attachment.html>