Summary:	ASTERISK-22628: 4 way multi-party hanging up down to two participants causes FRACKs
Reporter:	Kevin Harwell (kharwell)	Labels:
Date Opened:	2013-10-01 15:58:23	Date Closed:	2013-10-29 07:35:05
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/Bridging Resources/res_rtp_asterisk
Versions:	12.0.0-alpha1	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt ( 1) full_log.txt
Description:	After creating at least a 4-way multi-party call and then attempting to hang up down to two participants causes endless FRACK messages.
Comments:	By: Matt Jordan (mjordan) 2013-10-01 17:35:02.247-0500 Comment: One problem here is that the {{bridged}} pointer on an {{ast_rtp_instance}} is {{0xdeaddead}}. Before calling {{bridge_p2p_rtp_write}}, {{ast_rtp_read}} checks for the presence of the pointer - however, since that pointer is technically non-NULL, it goes ahead and calls the packet 2 packet write function. Even if it wasn't {{dead}}, we'd just have a stale pointer there, since the object was ref counted away. We need to cleanup the bridged pointer when the {{ast_rtp_instance}} is blown away. By: Kinsey Moore (kmoore) 2013-10-16 09:07:15.756-0500 What types of channels were in the 4-way bridge (all chan_sip, a mix)? How was the bridge setup (ARI/Stasis, transfers, etc)? By: Kevin Harwell (kharwell) 2013-10-16 09:35:32.044-0500 I had 4 phones bridged via transfers using PJSIP - example: {noformat} exten => 101,1,Dial(PJSIP/${EXTEN},20,Tt)      same => n,Hangup {noformat} Also had "atxfer => *2" under featuremap enabled in features.conf By: Kinsey Moore (kmoore) 2013-10-22 12:31:24.095-0500 The patch provided in https://reviewboard.asterisk.org/r/2905/ also appears to fix this issue.