[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:                     ready for review
Target Version:             1.6.0.11
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-06-16 06:50 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. 
====================================================================== 

---------------------------------------------------------------------- 
 (0106456) Ivan (reporter) - 2009-06-16 06:50
 https://issues.asterisk.org/view.php?id=14849#c106456 
---------------------------------------------------------------------- 
Dima, two:
1. SIP the package has overtaken package UDPTL in a network and has got to
queue of the channel earlier
2. The QUEUE of events on SIP transport will be processed faster than
UDPTL and will fall in QUEUE of the channel earlier

I really observed such situations and not only on the Asterisk 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-16 06:50 Ivan           Note Added: 0106456                          
======================================================================