[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