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

[Kevin Fleming]

> On 2011-03-29 10:38:33, Matthew Nicholson wrote:
> > /trunk/apps/app_faxdetect.c, line 58
> > <https://reviewboard.asterisk.org/r/1116/diff/8/?file=15881#file15881line58>
> >
> >     A new application specifically for fax detection should not be necessary.
> 
> irroot wrote:
>     There is a application for this indeed esp with T.38
>     
>     previously when i wanted to receive a fax id answer / playtones / wait on the channel for the fax tone the channel driver will then divert it to fax exten [and disable ec] where i could check on the routing and even route it back to the same channel it would have gone to in the first place. once answered by the device diverting to the fax extension would leave the fax machine "negotiating" and not available for a fax so if im only using local fax app im fine here and it is not needed a perhaps WaitForFax is a more appropriate name for this app. this also removes the "i got a hangup" complaint where a fax would come in the user answers does not hear the initial tone and there is no call and assumes a call was dropped even if there was a fax in the inbox.
>     
>     this faxdetect is a enhancement on wait in that it runs DSP and will "queue" T.38 negotiation on detect making the switchover more painless.
>     
>     for outbound faxes this will have little application as the framehook bellow will cater for it.
>     
>     i find this most useful and have been using it for a long time.
> 
> Matthew Nicholson wrote:
>     For the use case you describe, you should just be able to turn on fax detection in chan_sip and do a Wait() on the channel in question before connecting the call.  chan_sip will detect the fax and send it to the fax exten.

I have a feeling you guys are talking about two different things here, and this needs to be cleared up.

Once we have T.38 gateway support, there are two *entirely different* kinds of FAX detection possible.

The first is what we have always had, where we listen for a CNG tone which is an indication that a calling endpoint is indeed a (non-V.34) FAX terminal trying to initiate a FAX transaction (sending, or polling to receive). When this type of detection is enabled, the channel is generally sent to a different extension in the dialplan, so the dialplan can decide how it wants to route the call.

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 setup between the channel connected to the called FAX terminal (where the FAX transaction will occur in T.30 mode over modems) and the channel connected to the calling FAX terminal (where the FAX transaction will occur in T.38 mode). This has *nothing* to do with call routing, and switching into and back out of gateway mode can (and should) occur without the dialplan even being aware that it happened. This is explained on the wiki page that Matt linked to earlier, but if it's not clear then we might need to improve the page.

So, in many cases, a single call could easily end up using *both* forms of FAX detection: first, the call arrives and the caller hears some prompts, or is sent to a queue, or a device is dialed to accept the call... but while that is happening, the 'faxdetect' code hears a CNG from the calling end, and redirects the call to the 'fax' extension. The dialplan then calls out to a FAX machine connected via some mechanism, and when that machine answers, it sends CED followed by one of a few initial FAX transaction messages. When it does this, the V.21 preamble at the beginning of that message is detected, and the T.38 gateway code is triggered to start doing its thing.

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.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1116/#review3257
-----------------------------------------------------------


On 2011-03-16 08:40:59, irroot wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1116/
> -----------------------------------------------------------
> 
> (Updated 2011-03-16 08:40:59)
> 
> 
> Review request for Asterisk Developers, Russell Bryant, dimas, Leif Madsen, and dafe_von_cetin.
> 
> 
> Summary
> -------
> 
> Hi there the patch that was going around circa 2008 to implement this in 1.4/1.6 app_fax has been moved to trunk [1.10]
> ive made some cleanups and moved it into res_fax res_fax_spandsp this is the framework and not production code
> unfortunately i have no means of testing it at the moment and require help.
> 
> i have cleaned the code up substantially it is related to R459
> 
> hope this is found useful and aids in the goal to get it in 1.10.
> 
> Adds application FaxGateway / FaxDetect
> Adds alternate bridge to Dial with new option.
> 
> 
> This addresses bug 13405.
>     https://issues.asterisk.org/view.php?id=13405
> 
> 
> Diffs
> -----
> 
>   /trunk/apps/app_faxdetect.c PRE-CREATION 
>   /trunk/channels/chan_sip.c 310546 
>   /trunk/channels/sip/include/sip.h 310546 
>   /trunk/configs/res_fax.conf.sample 310546 
>   /trunk/configs/sip.conf.sample 310546 
>   /trunk/include/asterisk/channel.h 310546 
>   /trunk/include/asterisk/res_fax.h 310546 
>   /trunk/main/channel.c 310546 
>   /trunk/res/res_fax.c 310546 
>   /trunk/res/res_fax_spandsp.c 310546 
> 
> Diff: https://reviewboard.asterisk.org/r/1116/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> irroot
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110331/9edf5654/attachment.htm>