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:23Date Closed:2013-10-29 07:35:05
Status:Closed/CompleteComponents:Core/Bridging Resources/res_rtp_asterisk
Versions:12.0.0-alpha1 Frequency of
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


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:

exten => 101,1,Dial(PJSIP/${EXTEN},20,Tt)
     same => n,Hangup

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.