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

[Klaus Darilion]

Hi Kevin!

Am 27.04.2010 17:45, schrieb 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.

Good news!

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

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

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

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

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

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.

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

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.

regards
Klaus