[asterisk-bugs] [JIRA] (ASTERISK-26923) bridging: T.38 request is lost when channels are added to bridge

[Richard Mudgett (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-26923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=236578#comment-236578 ] 

Richard Mudgett commented on ASTERISK-26923:
--------------------------------------------

The channel locks are subordinate to bridge locks in the locking order.  You can lock a bridge lock then lock a channel lock without doing deadlock avoidance.  To lock a channel lock then a bridge lock you have to do deadlock avoidance since you are going up the locking hierarchy.

There is a locking precedence order diagram on this page: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Bridging+Project

> bridging: T.38 request is lost when channels are added to bridge
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-26923
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26923
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging, Core/Channels
>            Reporter: Torrey Searle
>            Assignee: Torrey Searle
>
> The B leg of a call gets established before the A leg does.  If the B party sends a T.38 re-invite immediately, the T38_CONTROL frame can get lost as the B party has joined the Bridge and the A party as not yet joined the bridge



--
This message was sent by Atlassian JIRA
(v6.2#6252)