FAX output channel variables will now match the values reported by FAXOPT() and should be set in all failure and success cases.
This commit also contains a few modifications to the way FAXOPT() variables are populated in a few spots and fixes for some reference count leaks of the session details structure in some failure cases.
Also found and fixed more cases where FAXOPT(status) may not have gotten set.
FAX-214
FAX-203
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fax session initilization code for T.38 faxes has been rewritten. T.38 session initialization was removed from generic_fax_exec, and split into two different code paths for receive and send. Also the 'z' option (to send a T.38 reinvite if we do not receive one) was added to sendfax.
In the output of 'fax show sessions', the 'Type' column has been renamed to 'Tech' and replaced with a new 'Tech' column that will report 'G.711' or 'T.38'.
Control of ECM defaults has been added to res_fax
A 'fax show settings' CLI command has been added.
Support of the new AST_T38_REQUEST_PARMS control method request to handle channels that have already received a T.38 reinvite before the FAX application is start has been added.
Support for the 'fax show settings' command has been added to res_fax_spandsp and handling of the ECM flag has been slightly altered.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, values that began with whitespace were silently treated as 'no',
and all non-'yes' values were also treated as 'no'. Now the supplied value
is specifically checked for a 'yes' or 'no' (or equivalent) value, after skipping
leading whitespace. If the value is not valid, then a warning message is generated.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
