[Kamailio-Devel] [ openser-Bugs-2135667 ] Disapearance of message length check in default kamailio.cfg

SourceForge.net noreply at sourceforge.net
Wed Oct 1 14:15:39 CEST 2008


Bugs item #2135667, was opened at 2008-09-29 09:09
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2135667&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: ver 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jerome Martin (tramjoe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Disapearance of message length check in default kamailio.cfg

Initial Comment:
In kamailio/openser.cfg since revision 3421, the check for message length has disapeared. This affects 1.2, 1.3 and 1.4, plus of course dev.

Furthermore, the check before that was: 

if (msg:len >=  2048 ) ....

This was bad anyway as 2048 is probably too much for most setups. The RFC 3261 advises to perform this check in a way that leaves room for adding headers/attributes. A reasonable value for maximum message lentgth would be :

MTU - 30B (for packet headers) - 270B (leave room for SIP extra headers/attributes), which amounts to MTU - 300, i.e. 1200B for a typical 1500B MTU.

Wrt feature request 1831764, I suggest that the core keyword "max_len" is replaced by a "$mtu" PV that would be used along with the existing $ml PV like this :

# This should be enabled only for UDP transport
# Reject excessively long requests as per RFC3261 
# MTU - 300B => 270B margin for reply + 30B headers

$max_len = $mtu - 300
if ($ml > $max_len) {
    sl_send_reply("513", "Message too big");
}

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-01 12:15

Message:
IMO the length checks are not useful at all.

RFC 3261 also says that the proxy should switch from udp to tcp if the
message gets too big, but as most clients are behind NAT this will not work
in 99.999999%.

Further, big messages do happen (heavy SDP with lots of video codecs and
parameters, XML bodies for presence ...) thus limitiating the maximum
message size only breaks services.

klaus

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2135667&group_id=139143



More information about the Devel mailing list