Re: [hylafax-users] hylafax (suddenly) won't send faxes

[Aidan Van Dyk <aidan@xxxxxxxx>]

* Ben Hodgens <bhodgens@xxxxxxxxxxxxxxx> [100720 18:28]:
> I figured out the likely cause of my failures, and it's really, really
> stupid. Apprently, the HylaFSP client we use is now presenting the dial
> string differently to hylafax (as of the last update). Whereas it used
> to be presented as this:
> 
> "555 555 5555"
> 
> ... it is now getting presented to hylafax as this:
> 
> "(555) 555 5555"
> 
> Hylafax isn't liking this; the hylafax log looks OK (all +15554443333
> format), and I didn't initially flag it as a concern (or even noteworthy
> - I wasn't familiar enough with what I should be looking at). The end
> result is that HylaFAX only seems to dial 7 numbers despite logging that
> the full dialstring is getting used: the area and prefix, with one from
> the relay.
> 
> No, I suppose I should say I'm not 100% certain this is the cause of
> this problem - but I know that it exactly coincides with the failed
> faxes. If xferfaxlog entries have parenthesis, they will fail with one
> of the errors
> 
> > - "No carrier detected"
> > - "Busy signal detected" (not 100% on increase in frequency)
> > - "No answer (T.30 T1 timeout)"
> > - "Ringback detected, no answer (timeout)"

Well, check in your session logs, and look at what's being dialed.  If
you increase session logging, you'll even see th edialsting rules
processing.  That will at least tell you if your correlation matches
your modem/phone/pbx not taking your () in the dials

> I do have this in my dialrules:
> 
> [^+0-9]+                =                       ! strip white space etc.
> 
> .. which I understand to mean "strip any characters not 0 through 9 or
> parenthesis from the dial string".
> 
> However, if I try to run a number with parenthesis through dialrules, I get:
> ready> (555) 555 5555
> Apply  rules to "555"
> --> return result "555"
> (555) = "555"
> ready> 555-555-5555
> Apply CanonicalNumber rules to "555-555-5555"
> --> match rule "[^+0-9]+", result now "555555-5555"
> --> match rule "[^+0-9]+", result now "5555555555"
> --> match rule "^[0-9]{10}$", result now "15555555555"
> --> match rule "^1", result now "+15555555555"
> --> return result "+15555555555"
> Apply DialString rules to "555-555-5555"
> --> match rule "[- 	.]+", result now "555555-5555"
> --> match rule "[- 	.]+", result now "5555555555"
> --> match rule "^[0-9]{10}$", result now "15555555555"
> --> return result "15555555555"
> Apply DisplayNumber rules to "555-555-5555"
> --> return result "555-555-5555"
> canonical = "+15555555555"
> dial-string = "15555555555"
> display = "555-555-5555"
> 
> It doesn't appear to see the parenthesis at all. I'm wondering if
> dialrules isn't being properly applied, or if it's even able to handle
> parenthesis - it appears the parentheses aren't being escaped and are
> getting evaluated as a dial rule themselves?

The rule above is in your CanonicalNumber set, but not your DialString
set.  The DialString set is what's applied to prepare the number for the
ATDT... modem command.

But dialtest is whitespace/command oriented, so should probably be
running it like:
	ready> CanonicalNumber((555) 555-5555)
	Apply CanonicalNumber rules to "(555) 555-5555"
	--> match rule "[^+0-9]+", result now "555) 555-5555"
	--> match rule "[^+0-9]+", result now "555555-5555"
	--> match rule "[^+0-9]+", result now "5555555555"
	--> match rule "^[^+]", result now "+14155555555555"
	--> return result "+14155555555555"
	CanonicalNumber((555) 555-5555) = "+14155555555555"

Of course, if you're wanting to see what wil lbe used for the ATDT, you
want to check DialString, not CanonoicalNumber.  But you'll have to add
a rule to remove the non-number digits in it...


> 
> On 07/19/2010 11:24 AM, Ben Hodgens wrote:
> > Hi, I've got a problem with our hylafax server I'm hitting my head against.
> > 
> > We had an issue last Thursday with our Windows frontend server, HylaFSP.
> > It was several versions behind and had a time-related bug, which we
> > resolved around noon. Since that time, I've had a lot of problems
> > inhibiting user-sent faxes from being received which I can't narrow down
> > to any single thing, such as:
> > 
> > - a specific modem (we have two which send)
> > - a specific user (there are multiple which are demonstrating the issue,
> > but it is not a 100% failure rate for any but one of the users)
> > - a specific error (see below)
> > - a specific dialed number (there are at least 20 that are failing on
> > one of the below).
> > 
> > These are all errors ultimately resulting in the user getting a faxing
> > failure notification. The xferfaxlog shows a lot of these failures
> > (where they were not previously, and these are known good fax numbers):
> > 
> > - "No carrier detected"
> > - "Busy signal detected" (not 100% on increase in frequency)
> > - "No answer (T.30 T1 timeout)"
> > - "Ringback detected, no answer (timeout)"
> > 
> > I'm ripping my hair out trying to figure out. There is evidence in the
> > logs that (at least most of) these now-failing numbers were able to be
> > successfully faxed to.
> > 
> > As it stands the faxstat -s queue keeps growing (100+ at the moment)
> > with a number (20+) of the above error messages as the TTS Status column.
> > 
> > I'm pretty new to this; could someone point me in the right direction as
> > to what might be causing this?
> > 
> > Thanks,
> > 
> 
> 
> ____________________ HylaFAX(tm) Users Mailing List _______________________
>   To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
>  On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
>   *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*



-- 
Aidan Van Dyk                                             aidan@xxxxxxxx
Senior Software Developer                          +1 215 825-8700 x8103
iFAX Solutions, Inc.                                http://www.ifax.com/

Attachment: signature.asc
Description: Digital signature