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

[Klaus Darilion]

On 06.05.2010 00:17, Kevin P. Fleming wrote:
> 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 :-)

Indeed ... :-)

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

So what is the "preamble"? .. Google is my friend [1] :-)

So the first preamble is in the DIS message. Even in polling mode the 
DIS is the first message. Thus you are right: when listening for a 
preample it should be sufficient to do this on the outgoing channel.

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

That's good. And it should be configureable, because sometimes it causes 
problems (overlapping reINVITEs with reINVITE-deadlocks) if both parties 
initiate the T.38 reINVITE.

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

Fine, copy-paste from chan_dahdi to chan_iax shouldn't be that difficult :-)

regards
Klaus

[1] http://books.google.com/books?id=mmocBBbJaa0C&printsec=frontcover