[asterisk-bugs] [Asterisk 0014807]: SendFax and T38 issues

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14807 
====================================================================== 
Reported By:                moliveras
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14807
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.0-beta1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-04-01 16:06 CDT
Last Modified:              2009-06-08 19:54 CDT
====================================================================== 
Summary:                    SendFax and T38 issues
Description: 
I am trying to get SendFax to work using a call file.

I initially tried it with asterisk-1.6.0.3 (spandsp-0.0.5pre4).

When I sent a call to a local spa2102 TA, the far end sent a re-invite to
switch over to T38, and the call went through as T38.

asterisk1.6.0.3 --> SBC --> ast1.4 --> spa2102

When I sent the call out to a land line via a carrier (SIP trunk),
asterisk receives the T38 reinvite, however the 200 OK that it sends back
only has g711 as a codec choice, and not udptl t38.  As a result, the fax
failes.

asterisk1.6.0.3 --> SBC --> SIP trunk

I then tried upgrading to asterisk-1.6.2.0-beta1 (spandsp-0.0.6pre7).
Now when I make the call to the land line over the SIP trunk the behavior
is the same, however when I call the spa2102 line, ast1.6.2.0-beta1 rejects
the SIP reinvite with a 488, and the fax completes inband.

Also, the 1.6.2.0-beta1 spits out these errors while the fax in in
progress:

[Apr  1 13:53:41] ERROR[10228]: channel.c:2539 __ast_read: ast_read()
called with no recorded file descriptor.

I will attach packet captures for these scenarios momentarily.  I can
reproduce this behavior consistently and can provide whatever info/debug is
needed.


====================================================================== 

---------------------------------------------------------------------- 
 (0106147) moliveras (reporter) - 2009-06-08 19:54
 https://issues.asterisk.org/view.php?id=14807#c106147 
---------------------------------------------------------------------- 
I did check the change log.. the version I originally tested against was
1.6.0.3 and there are more than security fixes since that build. I thought
that the following item might have fixed the problem..   I will attach the
debugs yo u mention tomorrow.

2009-03-19  Leif Madsen <lmadsen at digium.com>

	* Release Asterisk 1.6.0.7-rc2

2009-03-19 15:40 +0000 [r183066-183109]  Joshua Colp <jcolp at digium.com>

	* /, channels/chan_sip.c: Merged revisions 183108 via svnmerge from
	  https://origsvn.digium.com/svn/asterisk/trunk ........ r183108 |
	  file | 2009-03-19 12:37:23 -0300 (Thu, 19 Mar 2009) | 11 lines
	  Improve our triggering of a T38 switchover internally when
	  triggered by a received reinvite. Previously we reached across
	  the channel bridge to get the other party's SIP dialog structure
	  in order to trigger an outgoing reinvite. This is extremely
	  dangerous to do and only works if bridged to another SIP channel.
	  This patch changes this to use the T38 control frame method of
	  requesting a switchover. This change also causes the SIP channel
	  driver to propogate back whether the switchover worked or not
	  instead of blindly accepting the incoming T38 reinvite. Review:
	  http://reviewboard.digium.com/r/200/ ........ 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-06-08 19:54 moliveras      Note Added: 0106147                          
======================================================================