Summary:	ASTERISK-16698: large memory consumption of udptl.c module
Reporter:	under (under)	Labels:
Date Opened:	2010-09-18 05:35:23	Date Closed:	2012-01-16 13:15:34.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-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.