[SR-Users] SIP Fragments

[Daniel-Constantin Mierla]

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