Summary:	ASTERISK-16658: [patch] [regression] T.38 only invites (Fax Only Calls) are no longer possible since Asterisk 1.4.25
Reporter:	Ramon Peek-Fares (ramonpeek)	Labels:	patch
Date Opened:	2010-09-08 03:53:20	Date Closed:
Priority:	Minor	Regression?	Yes
Status:	Open/New	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch.diff ( 1) patch-rev2.diff ( 2) patch-rev3.diff ( 3) patch-rev4.diff ( 4) patch-rev5.diff ( 5) T.38_only_invite.pcap
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 ****** ADDITIONAL INFORMATION ****** Using T.38 Only invites is allowed according to the ITU norm and we have been using it successfully on 1.4.18 in combination with AudioCodes and Sipura/Cisco gateways. The reason for using T.38 ONLY invites instead of using G.711 invites with T.38 support is that the last option means the gateway has to detect whether or not a call is fax or speech. Detection of fax or speech often fails, so switching off this detection in cases where we know it's always a fax message reduces failures drastically. Using T.38 ONLY invites is the way to do this, but the gateway should supports it (Most of them do). Detection of fax calls has always been problematic and still causes lots of problems in many gateways today. The biggest problem is that the CED or CNG signal are not relayed correctly, they're either partially send, duplicated or not send at all. The preamble signal that follows is usually relayed OK and most faxes will recognize this signal and successfully receive the fax. But as I said; "Most faxes", so not all! Especially faxes with automatic analog fax/speech switches or even MicroSoft fax will need to hear the CNG signal on sending faxes or CED signal on receiving faxes. Since lots of faxes are dedicated faxes it makes absolutely no sense at all to introduce a "fax-detection" mechanism just because we are using a VoIP/FoIP system. So in these case using T.38 ONLY invites is a great solution. Note: Obviously, you can only do this if your SIP to PSTN gateway also supports this. We use AudioCodes gateways all over our sites and they all support this. Even some of our SIP Providers do and we are very happy about this fact ;-)
Comments:	By: Ramon Peek-Fares (ramonpeek) 2010-09-08 04:01:52 I've uploaded a PCAP trace to see what Asterisk now does on an T.38 ONLY invite. A quick look at it shows that its really not what one would expect to happen, it appears there is absolutely no check about what the capabilty of the outbound SIP pear is and also the SDP message return by the SIP provider is simply translated into a T.38 Session in Progress message? Please note: The peer at 192.618.161.207 support only T.38 and all other codecs are disallowed. The SIP Provider at 89.146.39.150 supports only G.729a and T.38 By: Ramon Peek-Fares (ramonpeek) 2010-09-15 14:40:05 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. By: Ramon Peek-Fares (ramonpeek) 2010-09-16 17:41:19 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. :-) By: Ramon Peek-Fares (ramonpeek) 2010-09-24 02:14:31 Uploaded rev3 of my patch because I detected several situation in which T38 was not enabled in the channel when it really should. I've now tested 8 different scenario's that I could think of. But I need testers!! By: Ramon Peek-Fares (ramonpeek) 2010-10-06 08:37:55 Found a problem in the code which caused one-way audio on normal calls in certain scenarios, fixed this in the rev4 patch. By: Ramon Peek-Fares (ramonpeek) 2010-10-08 05:42:02 New rev5 because of a small typo I made when preparing a patch for a non-forked 1.4.36. :-( PS: I heavily tested with the correct patch ;-) By: Ramon Peek-Fares (ramonpeek) 2010-10-13 12:50:29 PLEASE NOTE: ------------ I have tested this patch with SIP to SIP calls, in these scenarios: - T38 only from AudioCodes Mediant 1000 to AudioCodes MP-114FXS - T38 only from AudioCodes AudioCodes MP-114FXS to Mediant 1000 - T38 + RTP from AudioCodes Mediant 1000 to AudioCodes MP-114FXS - T38 + RTP Outbound from AudioCodes AudioCodes MP-114FXS to Mediant 1000 - T38 + RTP & Reinvite from AudioCodes Mediant 1000 to AudioCodes MP-114FXS - T38 + RTP & Reinvite Outbound from AudioCodes AudioCodes MP-114FXS to Mediant 1000 - T38 + RTP & Switch-Over from AudioCodes Mediant 1000 to AudioCodes MP-114FXS - T38 + RTP & Switch-Over Outbound from AudioCodes AudioCodes MP-114FXS to Mediant 1000 In all scenarios everything worked as expected. HOWEVER!!!! I do not use, nor own, any Asterisk Fax module or Analog cards with T.38, so I have not been able to test this. So besides my own SIP to SIP tests, I think its important to have someone test this too before adding it to trunk!