[asterisk-bugs] [JIRA] (ASTERISK-22628) 4 way multi-party hanging up down to two participants causes FRACKs
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Tue Oct 1 17:35:03 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-22628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210724#comment-210724 ]
Matt Jordan commented on ASTERISK-22628:
----------------------------------------
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.
> 4 way multi-party hanging up down to two participants causes FRACKs
> -------------------------------------------------------------------
>
> Key: ASTERISK-22628
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-22628
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Core/Bridging, Resources/res_rtp_asterisk
> Affects Versions: 12.0.0-alpha1
> Reporter: Kevin Harwell
> Attachments: backtrace.txt
>
>
> After creating at least a 4-way multi-party call and then attempting to hang up down to two participants causes endless FRACK messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list