[asterisk-bugs] [Asterisk 0014849]: [patch] SendFax function not working as expected on > 1.6.0.7

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14849 
====================================================================== 
Reported By:                afosorio
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14849
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     new
Target Version:             1.6.0.10
Asterisk Version:           1.6.0.7 
Regression:                 Yes 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-04-07 15:51 CDT
Last Modified:              2009-05-31 16:28 CDT
====================================================================== 
Summary:                    [patch] SendFax function not working as expected on
> 1.6.0.7
Description: 
When trying to send a fax via callfile using T.38 in asterisk version
1.6.0.5 it works fine, but after upgrading to asterisk 1.6.0.7 or newer it
does not work. When receiving re-INVITE from media gateway (Cisco AS-5400)
Asterisk ends call answering 488 Not acceptable here. I am running Asterisk
under Debian kernel 2.6.18-6-686. I am attaching captures both for scenario
which works and scenario which does not work. 
====================================================================== 

---------------------------------------------------------------------- 
 (0105821) dimas (reporter) - 2009-05-31 16:28
 https://issues.asterisk.org/view.php?id=14849#c105821 
---------------------------------------------------------------------- 
Ivan,
the idea is that application does not know internals of the channel
driver. For SIP, yes, when re-invite is received you may be sure that
accepting it will result in established T38 session. But that is SIP
specific and application should not rely on it. If T38 will be supported in
future on any other protocol in addition to SIP, you may not know in
advance how that protocol would work. It is possible that even when you
accept incoming T38 offer, the protocol requires few extra packet exchanges
before the T38 negotiation is complete. Because of this, you shoul not rely
on the fact that as soon as you respond to T39 offer it means T38 is on.
And you should just tell channel driver "yes, I agree" and wait when
channel driver confirms transition. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-31 16:28 dimas          Note Added: 0105821                          
======================================================================