[Home]

Summary:ASTERISK-14560: T.38 re-INVITE received after T.38 already negotiated fails
Reporter:sean20090717 (huangtx2009)Labels:
Date Opened:2009-07-29 16:16:41Date Closed:2009-08-06 12:49:57
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_fax
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) console_sender_488_Not_acceptable_here.log
( 1) console_sender_the_HDLC_carrier_did_not_stop_in_a_timely_manner.log
( 2) console_sender_unexpected_message_received.log
Description:I used the latest asterisk1.6.1 and spandsp0.0.6pre12. I tried to send Fax to a Fax service provider supporting SIP T.38 (They claim their Fax service can work with many devices well).

It is seldom successful.

But it often fails. Moreover, the error is different.
Sometimes, the error is "Unexpected message received".
Sometimes, the asterisk sender responds with 488 Not acceptable here to the Re-INVITE for T.38.
Sometimes, the error is "the HDLC carrier did not stop in a timely manner".

I wonder it is buggy or I do not configure something correctly. Thanks a lot.

Comments:By: Kevin P. Fleming (kpfleming) 2009-08-04 10:09:29

Nearly all messages that appear from app_fax itself are FAX protocol related, and thus are outside the influence of Asterisk; they would indicate some sort of protocol incompatibility between the spandsp T.38 implementation and your provider's implementation.

Your second uploaded log does demonstrate an actual issue that needs to be addressed; I'll edit this issue report to have a proper summary for it.
By: Digium Subversion (svnbot) 2009-08-06 12:47:23

Repository: asterisk
Revision: 210817

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r210817 | file | 2009-08-06 12:47:23 -0500 (Thu, 06 Aug 2009) | 11 lines

Accept additional T.38 reinvites after an initial one has been handled.

Discussion of this subject has yielded that it is not actually acceptable to change
T.38 parameters after the initial reinvite but declining is harsh and can cause the
fax to fail when it may be possible to allow it to continue. This patch changes things
so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
the fax a fighting chance.

(closes issue ASTERISK-14560)
Reported by: huangtx2009

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210817
By: Digium Subversion (svnbot) 2009-08-06 12:48:15

Repository: asterisk
Revision: 210818

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r210818 | file | 2009-08-06 12:48:14 -0500 (Thu, 06 Aug 2009) | 18 lines

Merged revisions 210817 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210817 | file | 2009-08-06 14:47:04 -0300 (Thu, 06 Aug 2009) | 11 lines
 
 Accept additional T.38 reinvites after an initial one has been handled.
 
 Discussion of this subject has yielded that it is not actually acceptable to change
 T.38 parameters after the initial reinvite but declining is harsh and can cause the
 fax to fail when it may be possible to allow it to continue. This patch changes things
 so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
 the fax a fighting chance.
 
 (closes issue ASTERISK-14560)
 Reported by: huangtx2009
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210818
By: Digium Subversion (svnbot) 2009-08-06 12:49:16

Repository: asterisk
Revision: 210819

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r210819 | file | 2009-08-06 12:49:16 -0500 (Thu, 06 Aug 2009) | 18 lines

Merged revisions 210817 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210817 | file | 2009-08-06 14:47:04 -0300 (Thu, 06 Aug 2009) | 11 lines
 
 Accept additional T.38 reinvites after an initial one has been handled.
 
 Discussion of this subject has yielded that it is not actually acceptable to change
 T.38 parameters after the initial reinvite but declining is harsh and can cause the
 fax to fail when it may be possible to allow it to continue. This patch changes things
 so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
 the fax a fighting chance.
 
 (closes issue ASTERISK-14560)
 Reported by: huangtx2009
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210819
By: Digium Subversion (svnbot) 2009-08-06 12:49:56

Repository: asterisk
Revision: 210820

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r210820 | file | 2009-08-06 12:49:56 -0500 (Thu, 06 Aug 2009) | 18 lines

Merged revisions 210817 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r210817 | file | 2009-08-06 14:47:04 -0300 (Thu, 06 Aug 2009) | 11 lines
 
 Accept additional T.38 reinvites after an initial one has been handled.
 
 Discussion of this subject has yielded that it is not actually acceptable to change
 T.38 parameters after the initial reinvite but declining is harsh and can cause the
 fax to fail when it may be possible to allow it to continue. This patch changes things
 so that additional T.38 reinvites are accepted but parameter changes ignored. This gives
 the fax a fighting chance.
 
 (closes issue ASTERISK-14560)
 Reported by: huangtx2009
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=210820