[SR-Users] SIP Fragments

[Alex Balashov]

Indeed, gzcompress is a Kamailio-only concept. 

On 17 December 2014 20:58:22 GMT-05:00, Marc Soda <msoda at coredial.com> wrote:
>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
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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

--
Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. 

Alex Balashov - Principal 
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0671
Web: http://www.evaristesys.com/, http://www.alexbalashov.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141217/c30b4beb/attachment.html>