[asterisk-bugs] [JIRA] (ASTERISK-26923) bridging: T.38 request is lost when channels are added to bridge
Richard Mudgett (JIRA)
noreply at issues.asterisk.org
Tue Apr 18 11:19:57 CDT 2017
[ 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)
More information about the asterisk-bugs
mailing list