a change in the management portal would have no impact on this. It must have broken at some other point and you just now are catching it. Has your asterisk version changed? I am no fan of NVFaxDetect. It makes no sense to me and customer whine about 'long pauses during call setup'. The long pause is actually the 4 second wait for fax tones. If you're in a pure voip environment, why not assign an entirely different number for the fax number? The only time it makes sense is when you cannot specify a DID (like analog lines). But in that case, there is a fax detection built right into dahdi so even then its not needed.

Our previous non-MTE system had this feature, single phone number for calls or faxes and users got to really liking it.

Will update the post once we have it fixed.

Going to dedicated fax numbers is an option, but if we go that route, I'd probably use Ring Central, as it has a ton of useful fax management features and is cost effective.

NVFaxDetect is not part of asterisk and is poorly maintained (last update 2007). Newman Telecom is no more, the domain exists but no website. Getting it to even work in 1.4 was a matter of post revision patching. In fact if you search for app_nv_faxdetect you wont even find a maintainer at this point; you're scrounging for fragments of former source code. I would not get too comfortable with it. You may find that it will not even compile on future versions that, for security reasons, an upgrade was unavoidable. At least knowing it will one day just stop working takes the surprise and sting out of it a little.

Just built a fresh system, upgraded to latest version MTE PBX Manager 6.0.1.72

Retested

NVFaxDetect still hangs the call when enabled.

Looks like the new update to PBX Manager 6.0.1.72 broke it.

NVFaxdetect is a asterisk module. IT has nothing to do with a gui. If its hanging, its because NVFaxdetect is broken. Not your GUI. In fact the dialplan that invokes it isnt even dynamic. Its written in menus.include which doesnt change until you click save on an inbound route. Did you install the right version of spandsp?

when you compiled nvfaxdetect did you apply the patches to it to make it work in 1.4?

We did a 1.4 ISO install, downloaded from TL's website, then did a simple upgrade in the GUI.

did you check to see if the module is present? Are you sure its hanging? and not failing for a non existent application?

Looks like it is there alright:

thirdlane*CLI> core show application nvfaxdetect

thirdlane*CLI>

-= Info about application 'NVFaxDetect' =-

[Synopsis]

Detects fax sounds on all channel types (IAX and SIP too)

[Description]

NVFaxDetect([waitdur[|options[|sildur[|mindur[|maxdur]]]]]):

This application listens for fax tones (on IAX and SIP channels too)

for waitdur seconds of time. In addition, it can be interrupted by digits,

or non-silence. Audio is only monitored in the receive direction. If

digits interrupt, they must be the start of a valid extension unless the

option is included to ignore. If fax is detected, it will jump to the

'fax' extension. If a period of non-silence greater than 'mindur' ms,

yet less than 'maxdur' ms is followed by silence at least 'sildur' ms

then the app is aborted and processing jumps to the 'talk' extension.

If all undetected, control will continue at the next priority.

waitdur: Maximum number of seconds to wait (default=4)

options:

'n': Attempt on-hook if unanswered (default=no)

'x': DTMF digits terminate without extension (default=no)

'd': Ignore DTMF digit detection (default=no)

'f': Ignore fax detection (default=no)

't': Ignore talk detection (default=no)

sildur: Silence ms after mindur/maxdur before aborting (default=1000)

mindur: Minimum non-silence ms needed (default=100)

maxdur: Maximum non-silence ms allowed (default=0/forever)

Returns -1 on hangup, and 0 on successful completion with no exit conditions.

For questions or comments, please e-mail support@newmantelecom.com.

PROGRESS:

We have found that NVFaxDetect only hangs on calls from the outside, calls that come from within the system work properly.

I think we are getting close!

What could be causing that?

NVFaxdetect not recognizing talk detection perhaps. what version of asterisk do you last remember it working with? Its possible that something has changed in the sip channel driver that has made it change behavior.

Successful internal call with fax detect on

-- Executing [s@test-elp:1] GotoIf("SIP/X.X.X.X-b7801498", "0?start") in new stack

-- Executing [s@test-elp:2] Set("SIP/X.X.X.X-b7801498", "TL_LEVEL=1") in new stack

-- Executing [s@test-elp:3] Answer("SIP/X.X.X.X-b7801498", "") in new stack

-- Executing [s@test-elp:4] NVFaxDetect("SIP/X.X.X.X-b7801498", "4|dt") in new stack

-- Executing [s@test-elp:5] NoOp("SIP/X.X.X.X-b7801498", "") in new stack

-- Executing [s@test-elp:6] Set("SIP/X.X.X.X-b7801498", "TIMEOUT(digit)=2") in new stack

-- Digit timeout set to 2

-- Executing [s@test-elp:7] Set("SIP/X.X.X.X-b7801498", "TIMEOUT(response)=1") in new stack

-- Response timeout set to 1

-- Executing [s@test-elp:8] BackGround("SIP/X.X.X.X-b7801498", "ogm/elp/sampleopen") in new stack

-- Playing 'ogm/elp/sampleopen' (language 'en')

== Spawn extension (test-elp, s, 8) exited non-zero on 'SIP/X.X.X.X-b7801498'

Failed external call with fax detect on

-- Executing [s@test-elp:1] GotoIf("SIP/X.X.X.X-b7802a38", "0?start") in new stack

-- Executing [s@test-elp:2] Set("SIP/X.X.X.X-b7802a38", "TL_LEVEL=1") in new stack

-- Executing [s@test-elp:3] Answer("SIP/X.X.X.X-b7802a38", "") in new stack

-- Executing [s@test-elp:4] NVFaxDetect("SIP/X.X.X.X-b7802a38", "4|dt") in new stack

Really destroying SIP dialog '14dbeee02ed521682cde17671e031a77@X.X.X.X' Method: OPTIONS

Really destroying SIP dialog '711aba5829511ef9374603ea4d2ef9e1@X.X.X.X' Method: BYE

Both the once working and the new install are just ISO loads. We did have Andrew of TL, do some work on our "once working" install, so he may have fixed it then.

It just appears that pause for 4 seconds is not being activated and the call just sits there.

Where can we edit the logic of that script?

Slightly different behavior with an IAX trunk.

-Still hangs but when I hang up the phone, the rest of the script runs

-- Executing [s@test-elp:1] GotoIf("IAX2/X.X.X.X:4569-10917", "0?start") in new stack

-- Executing [s@test-elp:2] Set("IAX2/X.X.X.X:4569-10917", "TL_LEVEL=1") in new stack

-- Executing [s@test-elp:3] Answer("IAX2/X.X.X.X:4569-10917", "") in new stack

-- Executing [s@test-elp:4] NVFaxDetect("IAX2/X.X.X.X:4569-10917", "4|dt") in new stack

hung up the phone here.....

-- Executing [s@test-elp:5] NoOp("IAX2/X.X.X.X:4569-10917", "") in new stack

-- Executing [s@test-elp:6] Set("IAX2/X.X.X.X:4569-10917", "TIMEOUT(digit)=2") in new stack

-- Digit timeout set to 2

-- Executing [s@test-elp:7] Set("IAX2/X.X.X.X:4569-10917", "TIMEOUT(response)=1") in new stack

-- Response timeout set to 1

-- Executing [s@test-elp:8] BackGround("IAX2/X.X.X.X:4569-10917", "ogm/elp/sampleopen") in new stack

-- Playing 'ogm/elp/sampleopen' (language 'en')

one thing I noticed is that your channels are ip addresses. This is completely wrong. Are you screwing up your trunks? An IP address equals an unmatched channel driver or you named your trunk an IP (another bad idea). do this...

in sip.conf under [general] set

allowguest=no

then reload.

if your calls stop working then you are screwing up your trunk configurations.

allowguest=no same end result.

However, I have been seeing this error occasionaly after a faxdetect call hangs:

[May 31 19:36:26] WARNING[7117]: chan_sip.c:1976 retrans_pkt: Maximum retries exceeded on transmission 688808646_48048247@x.x.x.x for seqno 20554 (Critical Response) -- See doc/sip-retransmit.txt.

[May 31 19:36:26] WARNING[7117]: chan_sip.c:1998 retrans_pkt: Hanging up call 688808646_48048247@x.x.x.x - no reply to our critical packet (see doc/sip-retransmit.txt).

Does it look related to:

https://issues.asterisk.org/view.php?id=12746

Here is a recent post related:

Re: [asterisk-dev] Bug or not - "no reply to our critical packet" ?

http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg36632.html

there isn't any NAT between your carrier and your pbx is there?

RESOLVED:

Firewall change: Allowed any sender of RTP packets to us.

That and a fresh build of TL, and we are good to go!

Man that took alot of time.