[Home]

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:27Date Closed:2017-06-27 17:28:04
Priority:MajorRegression?
Status:Closed/CompleteComponents: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!