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 > <mico...@gmail.com <mailto:mico...@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@lists.sip-router.org <mailto:sr-users@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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
