Summary: | ASTERISK-26923: bridging: T.38 request is lost when channels are added to bridge | ||
Reporter: | Torrey Searle (tsearle) | Labels: | |
Date Opened: | 2017-04-05 06:40:27 | Date Closed: | 2017-06-27 17:28:04 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Core/Bridging Core/Channels |
Versions: | Frequency of Occurrence | Frequent | |
Related Issues: | |||
Environment: | Attachments: | ||
Description: | 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 | ||
Comments: | By: Asterisk Team (asteriskteam) 2017-04-05 06:40:28.075-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-04-06 17:12:48.004-0500 Hey Torrey! Do you have any debug logs or configuration to help us out? I don't have a setup to easily reproduce T.38 issues at the moment. By: Torrey Searle (tsearle) 2017-04-07 00:56:09.087-0500 Hi Rusty, I have a asterisk testsuite case up in gerrit if you want to reproduce the issue By: Friendly Automation (friendly-automation) 2017-04-12 11:23:36.405-0500 Change 5460 merged by zuul: bridging: Ensure successful T.38 negotation [https://gerrit.asterisk.org/5460|https://gerrit.asterisk.org/5460] By: Friendly Automation (friendly-automation) 2017-04-12 15:35:44.831-0500 Change 5459 merged by zuul: bridging: Ensure successful T.38 negotation [https://gerrit.asterisk.org/5459|https://gerrit.asterisk.org/5459] By: Friendly Automation (friendly-automation) 2017-04-12 17:40:12.599-0500 Change 5409 merged by Joshua Colp: bridging: Ensure successful T.38 negotation [https://gerrit.asterisk.org/5409|https://gerrit.asterisk.org/5409] By: Richard Mudgett (rmudgett) 2017-04-14 17:32:05.049-0500 Have to revert the patch. It causes a deadlock. You cannot call ast_channel_get_t38_state() at that point in the code because a bridge lock is already held and that function will attempt to get another bridge lock if the channel happens to be a local channel. By: Torrey Searle (tsearle) 2017-04-18 07:27:39.522-0500 thanks for your insights @rmudgett What would you think of this as an alternative solution chan_pjsip proposes t.38 re-invite, sets a timer (500ms) upon completion of negotiation (success or failure) timer is stopped if timer expires, t.38 re-invite is re-proposed, timer reset for another (500ms) at the end of 6 seconds (the existing timeout handler) timeout happens as normally but this re-invite rentransmission timer also gets cleared. By: Torrey Searle (tsearle) 2017-04-18 07:32:13.959-0500 also can you elaborate a bit more on the deadlock? from what I see ast_channel_make_compatible also acquires the channel locks, so why is the former unsafe and the latter safe exactly? Torrey By: Richard Mudgett (rmudgett) 2017-04-18 11:18:56.596-0500 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 By: Rusty Newton (rnewton) 2017-04-25 18:16:52.728-0500 [~tsearle] or [~rmudgett] do you think this issue ASTERISK-26948 could be related to this issue? By: Torrey Searle (tsearle) 2017-04-26 02:34:58.040-0500 [~rnewton] I had a look at the pcaps of the other jira & I see that the T.38 re-invite is getting forwarded. In this jira, the control frame to instruct the other leg to send a re-invite gets lost. So I don't think these two are related. By: Rusty Newton (rnewton) 2017-04-26 15:43:10.664-0500 [~tsearle] thanks for your input! |