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

[Kevin P. Fleming]

On 04/29/2010 02:43 AM, Klaus Darilion wrote:
> 
> 
> Am 28.04.2010 22:52, schrieb Kevin P. Fleming:
>> Klaus Darilion wrote:
> ...
> 
>> 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 :-)
> 
> Just for more flexibility. I know service providers whose gateways 
> support T.38 but they always require the SIP client to initiate T.38, 
> regardless if it is an outgoing or incoming call. Also some clients are 
> really really slow in detecting fax (10 seconds or more), so allowing 
> fax-detecing and T.38 initiation in all directions would help in some 
> scenarios.

You didn't answer my question :-) The point I'm trying to make is that
Asterisk should never need to listen for the far end to be sending a FAX
preamble on a channel that was incoming to Asterisk. If the channel was
incoming to Asterisk, then the far endpoint should (must?) be a calling
FAX endpoint, not an answering FAX endpoint, and it won't be generating
the preamble.

It is unlikely that the FAX detection and T.38 initiation code will not
be usable in the way you describe, but it's certainly not going to be
recommended behavior. We too have been working with providers that
refuse to initiate the switch to T.38, even when the answering FAX
endpoint is on the other side of the provider's gateway, so I'm already
planning on some sort of method of Asterisk being able to initiate the
switch to T.38 when gateway mode will be used.

>>> 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
> 
> Have you every tried t38modem? I tried several times and always failed. 
> There are also many more people reporting that they failed to use t38modem.
> 
>> 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.
> 
> Of course having T38 support for IAX and IAXModem would be nice. But 
> anyway - if you have the proper setup than it works also with IAX 
> rock-solid.
> 
> I have several installations with IAXmodem and Hylafax and it is really 
> very stable. It is just a matter of network quality. I also have a setup 
> with 
> Iaxmoden<-iax->Asterisk<-sip/g711->Asterisk<-sip/g711->openser/rtpproxy<-sip/g711->gateway 
> from one service provider to another one and it is really stable! If you 
> have a good network with low delay/jitter it just works!
> 
> I use the t38-gateway patch from the bugtracker with SIP-T.38<->IAX and 
> it just works.
> 
> And there are really lots of users which use Asterisk with IAXmodem and 
> it works. Thus, it would be a pitty if TDM<->IAX works but T.38<->IAX not.
> 
> Of course it will not work if you try to use FoVoIP over networks with 
> higher delay/jitter. But if you increase delay even more then also T.38 
> will fail. That would be something like "we do not implement T.38 
> because it does not work over satellite links".

Agreed. I see no reason why you would not be able to use the gateway
functionality on non-TDM channels, but I don't expect to be spending any
of our developers' time to make that work... if community members want
to extend it in that direction once the basic code has been merged,
that's certainly reasonable.

>>> 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
> 
> There are lots of installed gateways (e.g. Asterisk < 1.8 servers) which 
> do not support T.38 gatewaying but wont be replaced because of this. 
> Gateways are often connected to other equipment via good networks (LAN). 
> Thus in such cases it would work reliable.
> 
> So please, just implement the T.38 gatewaying so that it may work will 
> all channels - do not limit the gatewaying object itself to TDM channels 
> only.

There's no way it would be restricted to such usage; as I said above,
the only 'restriction' would be that the first implementation merged
won't have that available, but there's nothing stopping anyone from
adding support for it.

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