[asterisk-bugs] [JIRA] (ASTERISK-25482) Faxes are randomly not sent using T.38 when faxing over a local channel

[Joshua Colp (JIRA)]

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

Joshua Colp commented on ASTERISK-25482:
----------------------------------------

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.

> Faxes are randomly not sent using T.38 when faxing over a local channel
> -----------------------------------------------------------------------
>
>                 Key: ASTERISK-25482
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25482
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_fax, Channels/chan_local, Channels/chan_sip/T.38
>    Affects Versions: 13.5.0
>         Environment: Debian wheezy, 32bit
>            Reporter: Filip Jenicek
>         Attachments: asterisk_13_5_0_orig_488err.log, asterisk_13_5_0_patched_didnt_happen.log, asterisk_13_5_0_patched_fixed.log
>
>
> 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 at 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 at 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}
> 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.



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