[asterisk-dev] Proposal for T.38 transparent gateway design in Asterisk

[Kevin P. Fleming]

Klaus Darilion wrote:

> I think the faxdetect feature is not consistent if it is only available 
> in a few channel drivers. What if the faxdetect feature is completely 
> moved out of the cannel driver into the gateway object? Then, it can be 
> used for all channel drivers which "do not support T.38". (I 
> intentionally did not wrote "all TDM" channels because IMO it makes 
> sense also to use gatewaying on IP channels which do not support T.38 
> like IAX, H323 ...) and configuration would be consistent over all 
> channel drivers. Probably then FAXOPT needs to cover the "faxdetect" 
> setting too (fax-extension, gateway or none).

The FAX detection code is not part of the gateway at all, it would be
provided by res_fax as a 'fax detector' object. However, it needs to be
channel-driver specific, because some channel drivers have the ability
to do the preamble detection themselves (since they service hardware
with onboard DSP resources), so they have no need of a generic 'fax
detector' at all. Instead, they just need to implement the same
configuration options and behavior, and the 'faxdetect' feature itself
is not very much code.

Personally, I am not at all interested in (and will be against)
providing audio FAX support over non-TDM channels of any kind. It's not
reliable, and making it part of Asterisk will cause unsuspecting users
to try to use it, and then complain (and expect support) when it does
not provide the reliability they expect.

H.323 does support T.38, and I believe that there is already a branch on
origsvn where the chan_ooh323 module has been updated to support T.38
(it may have been merged by now... I've lost track).

> Further, FAXOPT should be allow configure the faxdetection flexible, 
> e.g. CNG and/or CED tone, incoming or outgoing)

CED tone is not a reliable discriminator for FAX. CNG tone is, for
detection of calling FAX machines, and is already supported by
chan_dahdi (and could easily be supported by the other TDM channel
drivers as well). It's not really involved with gateway mode, though;
CNG detection is really only used to redirect calls to a different
extension after they've arrived at the PBX. Gateway mode should *only*
be triggered (at least for non-V.34 FAX) by detection of the preamble on
the receiving side, which will generally mean also outgoing Asterisk
channels. If you can describe a scenario where Asterisk would need to
listen for the FAX preamble on an incoming channel, I'll certainly
listen :-)

>> One of the areas that has required a lot of work in the past few months
>> (and Asterisk is not the only platform dealing with this... it's
>> industry-wide) is how T.38 session negotiation is handled. The result of
>> that is that there are various options that must be used based on the
>> behavior of the T.38 carrier (SIP trunking provider, or similar), and
>> each carrier might require a different set of options (which may be
>> different depending on the call direction). This means that for
>> transparent gateway mode to be effectively usable, it must be possible
>> for these options to be set (via FAXOPT) based on what the dialplan
>> author knows about the SIP provider(s) that are being used.
> 
> Are these options defined per call or per channel? E.g. may it happen 
> that the incoming and outgoing channels need different settings or are 
> there single settings for a gatewaying session?

In a gateway session, there is only one T.38 channel, by definition,
since the other channel is a TDM channel. These settings are used on the
channel that is operating in T.38 mode, to properly negotiate the T.38
session with the far T.38 endpoint. They would generally be setup by the
administrator on a per-endpoint (peer) basis, but to communicate them to
the gateway code they need to be fed into the FAXOPT() dialplan function
on any call (channel) that will need them.

>> In these examples I've used DAHDI and SIP since they will be the most
>> common technologies involved in transparent gatewaying, but in reality
>> you can consider 'DAHDI' to be 'any channel that supports TDM devices
>> and has no T.38 support of its own' and 'SIP' to be 'any channel that
>> supports T.38-capable devices'.
> 
> IMO it is very important that the gateway object is not only for TDM 
> channels, but for ALL channels, TDP+IP, also T.38 capable channels.

As I said I above, I disagree. We should not do anything specifically to
support audio FAX over non-TDM channels. If the code that gets written
can be used that way and people attempt to do so, that's their choice,
but no specific efforts should be made to support those configurations.

> For example
>    SIP-ATA<---SIP+T.38--->Asterisk<----IAX+G711----> IAX peer
> is a valid scenario, for example when trunking with other Asterisk 
> servers or using IAXmodem+Hylafax over LAN or high quality networks 
> (e.g. direct peerings between service providers).

There are least two other ways to do this: HylaFAX can support T.38
directly using t38modem (so then the T.38 session would just pass
through Asterisk), and IAX2 could be extended (fairly easily) to be able
to transport T.38 directly. In the latter case, the 'IAX2 peer' would
need to have a FAX origination/termination application, or be able to
pass the T.38 session onwards over a T.38-supporting channel technology.

> Also
>    SIP-ATA 1<---SIP+T.38--->Asterisk<---SIP+G711----> SIP-ATA 2
> is a valid scenario and should be supported. In this case Asterisk 
> should reINVITE to G711 if the T.38 reINVITE was rejected by SIP-ATA 2.

I would say this should *not* be supported; if someone has a FAX machine
attached to a SIP ATA, and that ATA does not support T.38, then they
should get one that does. Even if we did support this scenario (assuming
SIP-ATA1's FAX machine is the caller), the call is likely to not switch
to T.38 at all since there is no gateway that will detect the FAX
preamble on a TDM channel. If you configured Asterisk to do that, it
would detect the preamble from SIP-ATA2 and send a T.38 re-INVITE to
SIP-ATA2, not SIP-ATA2.

If SIP-ATA1's FAX machine is the recipient of the call, then SIP-ATA1
might send a T.38 re-INVITE to Asterisk, which would then pass it on to
SIP-ATA2. In this scenario, SIP-ATA2 would respond with a 488
(presumably), which Asterisk would pass back to SIP-ATA1... which would
then have the obligation to switch back to audio mode if it can do so.
It is still not Asterisk's responsibility to trigger the fallback, and
Asterisk would not accept SIP-ATA1's T.38 re-INVITE just so that it can
setup a gateway session to SIP-ATA2. Using T.38 for only half the path
is really not much better than not using it at all.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org