Content-Length: 1901.
So trimming up the headers isn't going to get me anywhere... I'm not
comfortable enough with WebRTC to know what to trim out of the SDP, either.
How can I force Kamailio to use TCP for SIP when relaying the call? I
haven't found much info on it.
Marc
On Thu, Dec 18, 2014 at 5:06 AM, Daniel-Constantin Mierla <mico...@gmail.com
> wrote:
>
>
> 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> 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@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
> --
> Daniel-Constantin Mierlahttp://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
