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?
Thanks in advance, Marc
On 12/17/2014 05:14 PM, Marc Soda wrote:
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.
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.
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.
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.
7. Other than these things, there are no real solutions.
-- Alex
On 17/12/14 23:20, Alex Balashov wrote:
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.
Mentioned on my previous email too -- keep_hf() from textopsx module can be handy here.
Another option to reduce the size -- sdpops module has related functions for sdp management.
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
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@gmail.com
Indeed, gzcompress is a Kamailio-only concept.
On 17 December 2014 20:58:22 GMT-05:00, Marc Soda msoda@coredial.com wrote:
-- 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
And yeah, WebRTC is morbidly obese. I think your best bet is to use TCP. -- 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
On 18 Dec 2014, at 03:01, Alex Balashov abalashov@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 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
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 <miconda@gmail.com
The safest way is to switch to tcp if the OS cannot do defrag of UDP packets.
Kamailio cannot do much otherwise, however, if you want to play with removing unecessary headers, look at keep_hf() function from textopsx module.
Cheers, Daniel
On 17/12/14 23:14, Marc Soda wrote:
"MS" == Marc Soda msoda@coredial.com writes:
MS> I'm having a problem reassembling UDP packets on my Asterisk servers after MS> passing through Kamailio
You could try having the kama->ast socket use tcp.
-JimC
That's how I ended up going. It's working now. Thanks.
On Thu, Dec 18, 2014 at 4:11 PM, James Cloos cloos@jhcloos.com wrote: