[Home]

Summary:ASTERISK-13879: SendFax and T38 issues
Reporter:Mike Oliveras (moliveras)Labels:
Date Opened:2009-04-01 16:06:30Date Closed:2009-06-16 18:41:34
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast-1.6.0.3-SendFAX-T38-Fail.pcap.gz
( 1) ast-1.6.0.3-SendFAX-T38-Pass.pcap.gz
( 2) ast-1.6.2.0-beta1-SendFAX-488.pcap.gz
( 3) ast-1.6.2.0-beta1-SendFAX-T38-Fail.pcap.gz
( 4) SendFax_Fail_CarrierA.log
( 5) SendFax_Pass_CarrierB.log
( 6) SendFax_Pass_spa2102.log
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.



****** ADDITIONAL INFORMATION ******

call file: (number changed as needed)

Channel: SIP/6097209447@router165
WaitTime: 30
Maxretries: 1
RetryTime: 30
Callerid: Test<6503568820>
Application: SendFAX
Data: /tmp/fax-1-15110.tif
Comments:By: Dmitry Andrianov (dimas) 2009-04-03 19:04:58

The last problem you are reporting (ast_read() called with no recorded file descriptor) seems solved by the patch for http://bugs.digium.com/view.php?id=14769

Regarding the others... I remember recent threads on the asterisk-dev mailing list - IIRC file (Joshua Colp) did lots of changes related to T38.

See
http://reviewboard.digium.com/r/208
http://reviewboard.digium.com/r/200
http://bugs.digium.com/view.php?id=12437

not sure if all these were already committed and to which branch. Not even sure they can help with your issue. But it worth trying - they may be related.


By: Mike Oliveras (moliveras) 2009-06-08 17:19:37

I retried this scenario with 1.6.0.10 and 1.6.1.1 and continue to see the 200 response to the t38 reinvite not include t38 in the SDP.

Is there any additional information that I could provide to help to resolve this? This problem is 100% reproducible.
By: Leif Madsen (lmadsen) 2009-06-08 17:32:22

There is no change between 1.6.0.9 & 1.6.0.10, or 1.6.1.0 & 1.6.1.1 -- they were only security updates (check the ChangeLog).

You would need to test the latest SVN from the 1.6.0 or 1.6.1 branches to determine if they resolve the issue.
By: Leif Madsen (lmadsen) 2009-06-08 17:32:55

Additionally, the sip history and sip debug from the Asterisk console may prove to be useful as well.
By: Mike Oliveras (moliveras) 2009-06-08 19:54:36

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@digium.com>

* Release Asterisk 1.6.0.7-rc2

2009-03-19 15:40 +0000 [r183066-183109]  Joshua Colp <jcolp@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/ ........
By: Mike Oliveras (moliveras) 2009-06-09 09:30:07

I am attaching 3 sip logs where a fax was sent using SendFax from asterisk 1.6.0.10.  If I send the fax through SIP carrierA, asterisk does not include t38 in the 200 OK to the sip reInvite, and the fax fails.  If I send the fax to a local spa2102 device, or to SIP CarrierB, then the 200 OK to the t38 reInvite does include t38 and the fax succeeds.  I assume that asterisk does not like something in the t38 reinvite from CarrierA.
By: Mike Oliveras (moliveras) 2009-06-16 17:23:01

I spent time looking at this today, and believe that I found the problem.  When the t38 reInvite from SIP carrier A is sent to asterisk, it changes the SDP, however it does not increment the SDP version ID.  The captures for the cases where it works do increment the session version.  I also was able to reproduce this by creating a sipp script based on the capture from carrier A; as soon as I change the session version on the reInvite, asterisk lists t38 in the 200 OK.

Since this is a problem with the SIP carrier and not asterisk, this ticket can be closed.
By: Leif Madsen (lmadsen) 2009-06-16 18:41:33

Closed per reporter, and file also says kpfleming has fixed this in SVN. Thanks!