[SR-Users] SIP Fragments

[Daniel-Constantin Mierla]

On 18/12/14 02:58, Marc Soda wrote:
> So gzcompress is no good with Asterisk then?  Is that meant to be used
> only with another Kamailio proxy?

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.

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

This is the web world -- lot of data even for little content, like for
html pages :-)

Cheers,
Daniel

>
> Thanks,
> Marc
>
> On Wed, Dec 17, 2014 at 6:47 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto: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://twitter.com/#%21/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 <mailto:sr-users at lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141218/3a50c092/attachment.html>