Non-existant Fax extensions

General Help
1

We run a Sangoma card that, until recently, had the TDMV_HW_FAX_DETECT hardware fax detection enabled. I thought that this option was designed to switch off echo cancellation upon the detection of a fax tone, but it turns out that it actually sends and event to DAHDi/Asterisk to switch to the “fax” extension, even though we receive all of our faxes on a dedicated DID. We also had “faxdetect=incoming” enabled in our chan_dahdi.conf file.

The upshot was that we were getting a lot of random disconnects because of false fax detections that redirected non-fax calls to the fax extension, which resulted in a lot of these messages showing up in the logs:

NOTICE[1537] chan_dahdi.c: Fax detected, but no fax extension

Which brings me to my question: Is there somewhere, or shouldn’t there be somewhere, that I can specify what to do with a fax call if there is no fax extension in that context? Basically, if I had been able to configure it such that all fax calls were answered by FFA, callers would have mentioned “I had a fax machine squeal in my ear!” instead of “I don’t know, it just hung up on me!”

I don’t want to specify a fax destination for all of my inbound routes, as there shouldn’t be any fax calls coming in on those DIDs. HOWEVER, I would like to be able to specify system-wide:

“If, for some reason, you get shunted to the fax extension, go here”

At least that way I can make sure that customers won’t just get hung up on, they will get directed to where I want them.

Just a thought. I never think it’s a good idea to just hang up on someone.

Tom

2

Tom,

you are more than welcome to put in a feature request to provide a default fax detection destination that could be input in the Fax Module.

This could simply be done by setting that destination as a global variable with the same name as the variable used for any individual setting such that it hasn’t been set by the specific call then it would have that default were it to happen.

Also - as mentioned, there are likely code paths where the fax extension is not placed. Right now I think it is only in the inbound routing, and in all IVRs and Announcements where it is likely for subsequent detection to still take place. I don’t think it is in anywhere else (extension dialing, follow-me’s ringgroups, queues, etc.) - meaning if a call is routed directly from and inbound route to a ringgroup, for example, if detection has not taken place during the inbound routing duration set, and then is triggered while phones are ringing or a message is being played, I don’t think it will occur. I’m not sure about all that though, it would have to be tested and reported if there were an issue with it.

p.s. at some point we might configure detection in places like the dahdi settings but at the moment, it is as you describe though we’ll have to keep your points in mind if we get to the point of making that automatic.

3

http://www.freepbx.org/trac/ticket/4708

Also, after reading your last post, I dug through the logs a little more, and I noticed that this problem may only manifest in those areas that have the fax extension added to them, such as IVRs.

If I am correct, fax detection anywhere that does contain a fax extension (such as an IVR) but does not have a destination defined in the GUI will result in hangup:

[Dec 20 06:36:23] VERBOSE[30822] pbx.c: == Spawn extension (ivr-3, fax, 1) exited non-zero on 'DAHDI/1-1' [Dec 20 06:36:23] VERBOSE[30822] pbx.c: -- Executing [fax@ivr-3:1] Goto("DAHDI/1-1", ",,") in new stack [Dec 20 06:36:23] NOTICE[30822] pbx.c: Cannot find extension context '' [Dec 20 06:36:23] WARNING[30822] pbx.c: Priority '' must be a number > 0, or valid label [Dec 20 06:36:23] VERBOSE[30822] pbx.c: == Spawn extension (ivr-3, fax, 1) exited non-zero on 'DAHDI/1-1' [Dec 20 06:36:23] VERBOSE[30822] pbx.c: -- Executing [h@ivr-3:1] Hangup("DAHDI/1-1", "") in new stack [Dec 20 06:36:23] VERBOSE[30822] pbx.c: == Spawn extension (ivr-3, h, 1) exited non-zero on 'DAHDI/1-1' [Dec 20 06:36:23] VERBOSE[30822] chan_dahdi.c: -- Hungup 'DAHDI/1-1'

However, a similar fax detection event anywhere that does not contain a fax extension in the dialplan code (a queue here) seems to result only in this message showing up in the log. The call continues as it should:

[Dec 20 08:02:11] NOTICE[31843] chan_dahdi.c: Fax detected, but no fax extension

In other words, my IVR, even though I never defined a fax extension for it in the GUI, has this entry (the queue does not):

exten => fax,1,Goto(${CUT(FAX_DEST,^,1)},${CUT(FAX_DEST,^,2)},${CUT(FAX_DEST,^,3)})

Because I have not defined a destination in the GUI (because this line should never receive faxes), the system jumps to the fax extension upon detection and then cannot proceed because I have not defined a fax destination for the incoming route that was dialed.

Thanks for your patience, Phillipe.

Tom

4

Tom,

that’s a good observation and makes sense, thus the real issue being we set an extension for it to jump to which of course does a bogus goto and thus makes things fail.

Given that, it really does make sense to have some sort of default behavior. Either that, or remove the fax extension from places like IVRs and Announcements such that all of the detection must occur during the inbound route. The down side being you can’t do something like play an IVR that says “if you are trying to send us a fax, press send now on your fax machine” to have the fax engage. (I suspect that is not very common but …). But it is nice to know if you have a DID going to an IVR with incorporated fax detection, that you can set the initial detection extremely low thus avoiding un-necessary delays, but still have the fax picked up.

So … I guess after all this rambling, the crux is … probably best to have that default destination you are suggesting…

5

Perhaps it would be wise to have the “Enable Fax Detection” option in the Inbound Routes configuration implement a configurable delay to the call processing, during which the caller hears ringing. Fax detection would take place during this delay. This would eliminate the need to have fax extensions anywhere other than the Inbound Routes. The System default would take care of any detected faxes that occurred on Inbound Routes for which a fax destination had not been defined.

As for specific implementation of the default destination, I think that the ability to have individual fax destinations at the extension level is excellent. However, many users prefer a “System Fax Destination” where all faxes go, others might start that way and graduate to individual fax destinations, and a third group might use a combination of the two. For that reason, I would suggest that a default setting be implemented as a “System Fax Destination” configured in the fax module. The “System” destination would appear in the drop-down menu along with any extension-level destinations, plus address the issue of faxes detected on routes with no defined destination. Based on time spent in various forums, I know that many users fighting the fax battle don’t initially understand that they have to add a destination at the extension level. Having both the system-wide setting, PLUS extension-level settings that override that system-wide setting might be the best of both worlds?

I might add that the ability to direct detected faxes to any other FreePBX destination, such as a queue, an inbound route, or an extension would be nice. That would be helpful for users that do not intend to receive any faxes on Asterisk (treat detected faxes as voice calls in case it was an erroneous detection) as well as users who prefer to receive faxes on a traditional fax machine (direct detected faxes to the fax machine’s extension).

I’d appreciate input, especially from Moshe, on this sort of stuff before I go modifying the feature request I created.

Tom

6

Makes sense. I presume you mean the delay setting that is available in the Trunk settings? For some reason I originally thought it would be better to have the delay configured on the Inbound Route, but I can’t really remember why I was of that opinion originally. Perhaps because it would group all of the fax related options together, so that one might not get overlooked?

I presume it’s that way currently because it’s a channel-level setting, so nevermind, I guess!

FWIW, I currently run most calls straight into a Queue, so maybe Queues ought to receive a fax extension? Or maybe I ought to convert the Join Announcement in the Queue to a FreePBX Announcement that dumps into the Queue?

Tom

7

Tom,

there already is a configurable delay that can be put to detect faxes. However, if you are running a call into an IVR then you may want to minimize the delay and just send it to the IVR since the fax can be detected there. That is the reason that the fax extension is supplied to the IVR and announcements since these are the more standard paths that a call may take.

as far as the default destination, that’s basically what you suggested for the Fax module and how it would effectively work. (e.g. if you define one there, then that will always be set in the absence of setting a destination elsewhere). One could then take the next step and have that default as one of the fax options, if it has been set…

8

Tom,

the delay is in the inbound route, not the trunk.

As far as queues, as soon as a call enters the queue (after the join announcement if you have one) it is answered by the queue anyhow so usually it wouldn’t help if it has not been detected by that time.

9

I was even looking at the Inbound Route page before I posted that.

I think I may re-enable the HW and DAHDi fax detection and implement delays in the inbound routes to compensate after this conversation.

Tom

10

Tom,

enabling FAX detection does nothing more than what you are asking, it set’s a destination to a fax extension.

They are the same thing.

11

OK, so basically the DAHDI and/or Sangoma and/or whatever other non-FreePBX settings exclusively control whether any fax detection is actually occurring. The FreePBX “Fax Detection” setting only defines the fax extension for the relevant context, it doesn’t place anything in the Dahdi, etc conf files that would actually enable the fax detection? That makes perfect sense, I and even think I got that at some point, but then forgot it and went off on a tangent.

Anyhow, I still maintain that defining a default fax destination for any route/context that does not have one explicitly defined would be a good idea and eliminate unexpected behavior. In other words, the settings for fax detection are channel wide at the DAHDi, Sangoma, SIP, etc level, but a user can (and likely will) only define a fax extension for a portion of the calls coming in on that channel (one of many DIDs). If that happens, calls will be abruptly disconnected if a fax tone is detected (spuriously or not).

I am fairly certain that a situation where a user has enabled fax detection for an entire PRI and then defined a fax destination for one DID is not unusual. Not having a defined default destination for the system means that any call pathway that does not have one specifically defined will result in calls being hung up on, which should not be possible.

I will work on implementing your workaround in the meantime, though.

12

I see what you mean, Philippe, but that would entail enabling Fax detection, which I don’t want to do. All I was thinking was that, if a default destination could be defined, any call that got bounced to the fax extension in a route that did not have a fax destination defined would not get hung up on.

In other words, the default destination is where calls go to if nothing has been defined. If you define something for that route by enabling detection, the calls go where you specify for that route.

I know that the behavior I am describing should never happen, but it can (as my misconfigured example shows), and I think it’s preferable to have a fail-safe in case something goes wrong. The alternative is that a call falls of the end of the dialplan and the caller gets hung up on, which is always a bad idea.

Just a thought.

Tom

13

Tom,

you, that option exists today, you just need to configure it.

That’s not to say there may not be some “bugs” in the logic (some flows that we have missed) which one can always file a bug for.

However - otherwise, it is configurable by the user for each inbound route which you control. You just need to enable the detection and specify the destination (which can be any destination on the system, so you can create a default and use it everywhere if you want). If doing this results in the fax going to dead air, then you just need to report a bug with the included configuration and probably a trace of the call and we can have a look to see what may be missing.

14

if the DIDs are dedicated fax DIDs, then there’s no reason to have the fax detection enabled and you can just send the call to the desired location.

If you have DIDs that are not dedicated but might get a fax, then you should enable the fax detection on the inbound route with an appropriate destination and an adequate delay to detect the fax.

If you do the latter, FreePBX will create a fax extension with the appropriate destination as that is what fax detection does. Also, the IVR contexts and the announcement contexts also have a fax extension and will recall the destination from the detection settings of an inbound routes to catch any ‘late stragglers’ if the delay was not adequate.

15

I understand what you mean, Philippe. However, I would like to have fax detection enabled in the future, in the event I decide to take advantage of FreePBXs ability to detect faxes on users’ DIDs.

Anyhow, my main point was that it might be advisable to have a “default” fax destination for contexts. That way, if the call get shunted to the fax extension for whatever reason, it won’t just get hung up on, it will go somewhere, even if it’s just an error. As it sits now, the call goes nowhere. It just gets hung up on.

Tom