Summary:ASTERISK-16698: large memory consumption of udptl.c module
Reporter:under (under)Labels:
Date Opened:2010-09-18 05:35:23Date Closed:2012-01-16 13:15:34.000-0600
Versions:Frequency of
is related toASTERISK-16794 Early bind of UDPTL ports can create a DoS condition
Environment:Attachments:( 0) udptl_20120113.diff
Description:sizeof(struct ast_udptl) = 167592.
This structure is allocated for each SIP leg in case if t38_udptl is enabled.
For 600 calls this gives 600 * 2 * 167592 = 200M consumed even though NONE of these calls transfers fax at the moment.

IMO this structure should be allocated only when fax starts.
Comments:By: Leif Madsen (lmadsen) 2010-09-21 13:06:50

After discussions, while 200M on a system processing 1200 calls doesn't seem like that big of a deal, it has been agreed we should improve it so that the memory allocation is not done until necessary. Thanks!

By: under (under) 2010-12-27 03:24:23.000-0600

lmadsen, well it's not 1200 calls but 1200 channels :-).
The number of calls is 600.

By: Stefan Schmidt (schmidts) 2010-12-27 03:41:46.000-0600

i have done some load tests with and without these udptl allocation in sip_alloc and its much faster without it. so if we can make sure that we have the udptl structure when we need it, it should be removed from the sip_alloc function.

but look at issue 18121 for this discussion.

By: Matt Jordan (mjordan) 2012-01-13 17:49:05.049-0600

I've attached a patch that moves the initialization of the udptl object until later in the lifetime of a dialog.  In current 1.8, we create the udptl object in sip_alloc, handle_request_invite, and create_addr_from_peer - two of these, at least, nearly guarantee that any sip_pvt associated with a peer that support T.38 will have a udptl object assigned to it.  This patch only creates the udptl object if we (a) receive a media invite that specifies image as a supported media, or (b) chan_sip receives a T38 control frame.

I've passed this through the udptl tests in the Asterisk testsuite, and will be testing it with the T.38 gateway tests in Asterisk 10 when I create a patch for that version.  That being said, given the complexities of media negotiation, this patch needs some additional testing.