[asterisk-bugs] [Asterisk 0017966]: T.38 only invites (Fax Only Calls) are no longer possible since Asterisk 1.4.25

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17966 
====================================================================== 
Reported By:                ramonpeek
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17966
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.35 
JIRA:                        
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-09-08 03:53 CDT
Last Modified:              2010-09-08 03:53 CDT
====================================================================== 
Summary:                    T.38 only invites (Fax Only Calls) are no longer
possible since Asterisk 1.4.25
Description: 
T.38 only invites (Fax Only Calls) are no longer possible since 1.4.25.
We noticed this issue when upgrading our Asterisk Systems from 1.4.18 to
the latest 1.4.35, everything leads back to a change done in 12437, that
change is IMHO incorrect.

The original problem reported in 12437 was that Asterisk would ALWAYS send
an initial invite with only T.38 support even though the peer was
programmed to also support other codecs like alaw.

The executed change resulted in the initial invite now fully missing the
T.38 codec in SDP. But if a peer supports T.38 the initial invite MUST also
contain T.38 in SDP, because otherwise the other party won't know that the
originator supports this. Some devices really won't start any T.38
negotiation because of this. Also it won't be possible anymore to send T.38
ONLY invites.

What should have been done was to create an initial invite with T.38 + all
other allowed codecs of the peer. This would also allow T.38 only invites
by simply programming the peer in Asterisk with all codecs disallowed
(except for T.38). This is exactly what we do in our systems, see
"Additional Information" for the reason.


Please note:
I'm aware that re-invites are also an intricate part of the problem
reported in 12437 and other cases following this one. We should not forget
to also look at the correct handling of this if we were to fix the initial
invite, but should obviously first start with the INVITE 
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-08 03:53 ramonpeek      New Issue                                    
2010-09-08 03:53 ramonpeek      Asterisk Version          => 1.4.35          
2010-09-08 03:53 ramonpeek      Regression                => Yes             
2010-09-08 03:53 ramonpeek      SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================