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

[Asterisk Bug Tracker]

The following issue is now READY FOR TESTING. 
====================================================================== 
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:                     ready for testing
Asterisk Version:           1.4.35 
JIRA:                       SWP-2183 
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-10-08 10:44 CDT
====================================================================== 
Summary:                    [patch] [regression] 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 
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0012437 Asterisk negotiates only T.38 when answ...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-08 10:44 ebroad         Status                   acknowledged => ready
for testing
======================================================================