[Home]

Summary:ASTERISK-25482: Faxes are randomly not sent using T.38 when faxing over a local channel
Reporter:Filip Jenicek (phill)Labels:
Date Opened:2015-10-21 06:00:29Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Applications/app_fax Channels/chan_local Channels/chan_sip/T.38
Versions:13.5.0 Frequency of
Occurrence		Frequent
Related
Issues:
Environment:Debian wheezy, 32bitAttachments:( 0) asterisk_13_5_0_orig_488err.log
( 1) asterisk_13_5_0_patched_didnt_happen.log
( 2) asterisk_13_5_0_patched_fixed.log
Description:After upgrading to Asterisk 13.5.0 from the 1.8 branch I discovered, that faxes are randomly not sent using the T.38 codec, but instead fall back to G.711. The remote endpoint is another Asterisk on a local network. There are no differences in SIP signalization. It all happens inside asterisk.

I am sending the fax over a local channel using an AMI command:
{code}
Action: Originate
ActionID: 08ca8820897b702508b256b8d1ec343a
Channel: Local/999@sip-locals/n
CallerID: "Admin" <10>
Context: faxSend
Exten: faxSend
Priority: 1
Timeout: 180000
Variable: ktsFrom="Admin"<10>,ktsFromName=Admin,ktsFromNum=10,ktsTo=999,ktsFaxFile=/var/spool/operator/fax/prepareFax.p5VrO67F8i.tiff
{code}

Asterisk extensions.conf is simple:
extensions.conf:
{code}
[faxSend]
exten => faxSend,1,NoOp(Send fax ${ktsFaxFile} from ${ktsFrom} to ${ktsTo})
exten => faxSend,n,Set(FAXOPT(headerinfo)=From ${ktsFromName})
exten => faxSend,n,Set(FAXOPT(localstationid)= )
exten => faxSend,n,SendFax(${ktsFaxFile},dfz)
exten => h,1,NoOp(Status: ${FAXSTATUS} (${FAXERROR}) ${FAXMODE} ${REMOTESTATIONID} ${FAXPAGES} ${FAXBITRATE} ${FAXRESOLUTION})

[sip-locals]
exten => 999,1,Dial(SIP/213@i-borg-outbound)
{code}

I have been able to localize the issue, but I can't come up with a proper fix. The problem first happens in core_unreal.c in function ast_unreal_queryoption. The Local channel is sometimes not bridged yet. As a result, the function returns a zero, and several functions later, asterisk sends a 488 reply and falls back to G.711.

By adding a simple for loop to the ast_unreal_queryoption function, I was able to mitigate the issue. This is not a fix, but rather a proof that there is a race condition.
{code}
int attempt = 0;
for (attempt = 0; attempt < 100; attempt++) {
peer = ast_channel_bridge_peer(other);
if (peer) {
ast_debug(3, "Peer bridged (attempts %d).\n", attempt);
break;
}
ast_debug(3, "Peer not bridged yet, retry (attempts %d).\n", attempt);
usleep(10000);
}
{code}

Another way to overcome the issue is by using a sleep:
{code}
[faxSend]
exten => faxSend,1,NoOp(Send fax ${ktsFaxFile} from ${ktsFrom} to ${ktsTo})
exten => faxSend,n,Set(FAXOPT(headerinfo)=From ${ktsFromName})
exten => faxSend,n,Set(FAXOPT(localstationid)= )
exten => faxSend,n,Wait(1)                                           ;<-- Deal with the race
exten => faxSend,n,SendFax(${ktsFaxFile},dfz)
{code}


Three log files are attached:
* asterisk_13_5_0_orig_488err.log - Displays the 488 error response and fallback to G.711.
* asterisk_13_5_0_patched_fixed.log - Contains the for loop fix, the fax was successfully transmitted over T.38.
* asterisk_13_5_0_patched_didnt_happen.log - The race didn't happen this time, the fax was successfully transmitted over T.38.
Comments:By: Asterisk Team (asteriskteam) 2015-10-21 06:00:31

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: Filip Jenicek (phill) 2016-01-13 06:25:53.922-0600

Are there any updates? Could I do anything to help?

The issue is linked to SWP-8482. I can't access it, how can I view it?
By: Joshua C. Colp (jcolp) 2016-01-13 06:29:32.178-0600

SWP issues are internal Digium issues used for planning. Any updates or requests for information are posted on this issue. As there are none there are no updates and nothing is waiting on you.