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

[Kevin P. Fleming]

After many months of working with the SIP Forum FoIP working group and
on Asterisk's T.38 origination/termination implementation (as well as
Digium's Fax For Asterisk product), I think it's time we got moving on
adding T.38 transparent gateway support as well. There have been T.38
gateway patches available in the issue tracker for some time, but those
patches only provide dialplan-initiated gateway mode, which only solves
part of the problem. I know that CallWeaver has this functionality
already, and that the AttraFAX guys have done it as well, but since
neither of those code bases are candidates for merging into Asterisk,
we've got to look at doing it ourselves (and we might just end up doing
it differently).

This message contains a proposed design for the development community to
review, criticize, expand upon, etc. Feel free to provide any input you
feel is useful!

First, the gateway core functionality would live in res_fax.c, like the
current SendFAX and ReceiveFAX applications do. res_fax would contain
the basic gateway 'object' implementation, which handles T.38 session
negotiation and a few other tasks, but delegates the actual TDM<->T.38
gateway mechanism to a technology module. The first module to provide
this would be res_fax_spandsp, using the existing patches in the issue
tracker as a starting point, but it's of course likely that Digium would
also add gateway mode to Fax For Asterisk, and there's no reason that a
technology module couldn't be produced using the AttraFAX stack as well
if someone is interested in doing so.

The gateway core would respect FAX session options set via the FAXOPT
dialplan function (just like SendFAX and ReceiveFAX do now), and for
consistency's sake we would expand FAXOPT to be able to provide the same
functionality that the 'f', 'z', 's' and 'd' options do for
SendFAX/ReceiveFAX. This is important because when transparent gateway
mode is employed, there isn't any opportunity to provide 'options' to
the gateway code at the time it is started; they must have been already
stored on the channel for later use, and that's what FAXOPT does. (This
might result in these options being removed from SendFAX/ReceiveFAX as
well, to avoid duplication, but that's another discussion).

The gateway core would provide gateway 'objects' that channel drivers
can request when necessary; the primary example of this would be
chan_dahdi, which only services TDM devices, but needs to be able to
appear to support T.38 to the rest of Asterisk. A gateway 'object' would
essentially be a shim that sits in front of the channel driver's native
read/write operations, and also use the *real* read/write operations
provided by the channel driver to send/receive audio to the TDM
endpoint. While the gateway object is attached to a channel, that
channel would support T.38 negotiation and transport, even though the
underlying channel driver has no such support.

chan_dahdi would then be extended in two ways: to be able to accept
incoming T.38 negotiation requests, and to initiate them based on
detecting a FAX preamble generated by an attached TDM device. These
would be enabled via extension of the existing 'faxdetect' configuration
option, allowing the administrator to control which mode should be used
('fax' extension, gateway, or none), and in which direction (incoming or
outgoing calls).

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.

For calls that arrive over SIP (to be potentially sent to a DAHDI
channel and then gatewayed if a FAX occurs), this is fairly easy: FAXOPT
can be called in the dialplan before invoking Dial() to send the call
onwards, or FAXOPT can be set using 'setvar' in the sip.conf peer
section for that provider. The data stored by FAXOPT (in a channel
datastore) will be automatically inherited to the DAHDI channel created
by Dial(), and thus the correct options will be available if the
transparent gateway is triggered.

For calls that arrive from DAHDI, though, the situation is more complex.
The FAXOPT dialplan function can't be called on the DAHDI channel before
calling Dial() if Dial() will be dialing multiple SIP peers, because
those peers might require different T.38 options. If only one peer is
dialed, then calling FAXOPT first will work; if multiple peers are
dialed, then a combination of the Dial() 'U' option and the
MASTER_CHANNEL dialplan function would allow for FAXOPT to be called on
the DAHDI channel *after* the outbound SIP channel is answered, and when
it is known which SIP peer answered, so the correct options can be set.
The correct options could even have been specified in sip.conf via
'setvar', so that the subroutine that is called by 'U' only has to read
a channel variable or two and copy the information to the MASTER_CHANNEL.

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'.

I think that about covers it, although I won't be surprised if I've
missed something :-) Comments and thoughts are welcome, so jump in!

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