[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]

A NOTE has been added to this issue. 
====================================================================== 
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:                     acknowledged
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-09-15 14:40 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0127007) ramonpeek (reporter) - 2010-09-15 14:40
 https://issues.asterisk.org/view.php?id=17966#c127007 
---------------------------------------------------------------------- 
I've uploaded a patch for the 1.4.36 release.

It enables user to place 2 types of T38 calls:

T38 + RTP
----------
This is the common method where we send an INVITE to Asterisk in which the
SDP contains an RTP codec and T38. 
The outgoing INVITE will then also contain both RTP and T38. 
Asterisk will then listen for a T38 re-invite send from the destination
peer and if it receives this re-invite it will switch-over.


T38 ONLY
--------
This is a less common but often better method if you're only making fax
calls and are sure that the destination also supports T38. 
In this method a INVITE is being send to Asterisk with ONLY T38 in SDP.
The outgoing INVITE from Asterisk will then also contain only T.38 in
SDP.



The patch is not complete since it lacks the option to send Re-Invites on
"T38 only" calls. 
However Asterisk was never capable of doing so anyway, so its not a bug
;-)
Please read my comments in the code and perhaps someone knows the answer
to solve this too... would be real nice. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-15 14:40 ramonpeek      Note Added: 0127007                          
======================================================================