[SR-Users] SIP Fragments

[Olle E. Johansson]

On 18 Dec 2014, at 03:01, Alex Balashov <abalashov at evaristesys.com> wrote:

> Indeed, gzcompress is a Kamailio-only concept. 
In fact we got it from Facetime...

SHould be easy to implement in Asterisk too.
/O
> 
> 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
> _______________________________________________
> 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/20141218/1b808015/attachment.html>