[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-16 17:41 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0127070) ramonpeek (reporter) - 2010-09-16 17:41
 https://issues.asterisk.org/view.php?id=17966#c127070 
---------------------------------------------------------------------- 
Fixed it with patch-rev2.diff (for Asterisk 1.3.36)

This patch enables Asterisk to make:
------------------------------------
- RTP/T38 calls with T38 pass-through
- RTP/T38 calls with T38 switch-over to T38 Only
- T38 Only calls (without re-invites, but with fallback to T38
pass-through)

If a destination peer is programmed with all RTP codecs disallowed but
with udptl (T38) enabled,
it's considered a T38 Only peer that will be used for fax only.
These types do not support the "canreinvite" option, if tried anyway a
warning will be displayed and a fallback to T38 pass-through will occur.

If a destination peer is programmed with at least one RTP codec and udptl
(T38) enabled,
it's considered a RTP/T38 peer that will have pass-trough capability is
"canreinvite" is off, and T38 Switch-over functionality if enabled.
 

However the patch is still not quite complete, since it lacks the option
to send re-invites on "T38 only" calls.
But that is really a feature, not a bug, since Asterisk was never capable
of doing so anyway. ;-)
But please read my comments in the code and perhaps someone knows the
answer to solve this (tiny) issue too... would be real nice. :-) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-16 17:41 ramonpeek      Note Added: 0127070                          
======================================================================