[asterisk-dev] [Code Review] Fax Gateway Implementation T30<->T38

[Kevin P. Fleming]

On 04/05/2011 11:33 AM, Klaus Darilion wrote:
>
>
> Am 31.03.2011 21:25, schrieb Kevin Fleming:
>> The second is detection of a *called* FAX terminal which is
>> indicating that it is ready to initiate a FAX transaction (receiving,
>> or being polled to send). This is done by detecting the V.21 preamble
>> at the beginning of the called FAX terminal's first message after
>> CED. When this is detected by the T.38 gateway code (*NOT* the
>> channel driver), then T.38 negotiation should be initiated to the
>> calling channel, and if it succeeds, a T.38 gateway session would be
>
> Just a question: Asterisk is responsible to switch the incoming channel
> to T.38, and the outgoing channel may be switched to T.38 by the callee?

Using terms like 'incoming' and 'outgoing' will end up confusing the 
discussion; it's better to refer to the endpoints themselves (and the 
network elements in between) when describing the proper behavior.

In a situation where a call is received by Asterisk and routed to a FAX 
machine (the 'called FAX terminal'), if Asterisk is able to provide T.38 
gateway services for that call, then Asterisk is *sole* element in the 
entire call path that is responsible for determining whether T.38 should 
be used or not. It should do this by listening for the V.21 preamble 
generated by the called FAX terminal, and initiate a T.38 negotiation 
request towards the caller. The caller (or a gateway or other network 
element in the path towards the caller) will then decide whether to 
accept the switch to T.38 or not; if it does, then Asterisk will provide 
T.38 gateway services between the calling channel (in T.30-over-T.38 
mode) and the called channel (in T.30-over-modem mode).

There are calling endpoints (quite a number of 1- and 2-port ATAs, for 
example) that can be configured to request a switch to T.38 themselves; 
they usually do this based on detecting the CNG tone generated by their 
own FAX machine (the 'calling FAX terminal'). This method is unreliable 
and really shouldn't be used, because the switch to T.38 is requested 
before the gateway even knows that the device accepting the call is a 
FAX terminal (or in some cases, the switch is requested before the call 
is even answered).

In a situation where a call is received by Asterisk *from* a FAX machine 
(a 'calling FAX terminal'), as far as T.38 gateway services are 
concerned Asterisk doesn't need to do anything at all until it receives 
a T.38 negotiation request from the called channel. If it receives such 
a request, and has been configured to provide T.38 gateway services, and 
the request is acceptable, then Asterisk would respond affirmatively and 
that channel would be switched to T.38 mode.

>
>> One more note: the faxdetect code (triggered by CNG) does *NOT*
>> disable echo cancellation. Echo cancellers that are G.168 compliant
>> detect CED tones generated by *called* FAX terminals and take action
>> themselves to reconfigure properly so as to not interfere with a FAX
>> transaction.
>
> What about the software echo cancellers in DAHDI, are they G.168 compliant?

The HPEC echo canceller available for DAHDI is compliant with G.168, 
yes. For the others, I can only speak about this particular issue (CED 
detection and reaction to it)... for them, the DAHDI core itself detects 
CED and tells the echo canceller to take action; for the various echo 
cancellers included with DAHDI, they will disable themselves completely 
when this occurs.

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