Faxes Stopped Working – AMI Issue?

Home » Asterisk Users » Faxes Stopped Working – AMI Issue?
Asterisk Users 6 Comments

I recently upgraded from Asterisk 13.19 to 16.6.1. Everything is working fine with a few minor tweaks except outgoinf fax. Incoming works fine.

I do outgoing faxing through an AMI call. Here is the output from the security log:

[Nov 27 06:16:05] SECURITY[101222] res_security_log.c:
SecurityEvent=”ChallengeSent”,EventTV=”2019-11-27T06:16:05.566-0500″,Severity=”Informational”,Service=”SIP”,EventVersion=”1″,AccountID=”alex”,SessionID=”0x80ba54820″,LocalAddress=”IPV4/UDP/98.158.139.74/5060″,RemoteAddress=”IPV4/UDP/72.143.94.110/5060″,Challenge=”215351b4″
[Nov 27 06:16:05] SECURITY[101222] res_security_log.c:
SecurityEvent=”SuccessfulAuth”,EventTV=”2019-11-27T06:16:05.591-0500″,Severity=”Informational”,Service=”SIP”,EventVersion=”1″,AccountID=”alex”,SessionID=”0x80ba54820″,LocalAddress=”IPV4/UDP/98.158.139.74/5060″,RemoteAddress=”IPV4/UDP/72.143.94.110/5060″,UsingPassword=”1″

So I know that AMI is listening and I can talk to it. Here is the main log”

[Nov 27 06:16:00] VERBOSE[101155] asterisk.c: Remote UNIX connection
[Nov 27 06:16:00] VERBOSE[101245] asterisk.c: Remote UNIX connection disconnected
[Nov 27 06:16:01] VERBOSE[101244] manager.c: Manager ‘asterisk’ logged on from 127.0.0.1

The AMI command, after the login, looks like this:

Action: Originate Channel: SIP/outgoing/%%(destination)s Context: LocalSets CallerID: Vybe Consulting Inc Fax Service <5555551212>
Exten: sendfax Priority: 1
Timeout: 30000
Variable: faxfile=%%(faxfile)s Variable: uid=%%(uid)s Variable: destination=%%(destination)s Variable: sender_name=Vybe Consulting Inc Fax Service Variable: sender_num=5555551212

Those “%%” strings get replaced by real data. My sendfax extension has a bunch of stuff but the very first line is this:

exten => sendfax,1,Verbose(0,FAX ${faxfile} to ${destination})

So, regardless of what follows, shouldn’t I be seeing that message in my logs?

—
D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
IM:darcy@Vex.Net VoIP: sip:darcy@VybeNetworks.com

—

6 thoughts on - Faxes Stopped Working – AMI Issue?

  • Only if it was actually answered. You’d need to dig deeper by looking at the SIP trace itself (sip set debug on) to see if an attempt was made and what occurred.

  • OK, so I did that and my logs are really busy now. However, a search through them doesn’t find the phone number that I am faxing to.

    Are you sure that it needs to be answered before it starts logging?
    Logging only when something works isn’t much of a debugging tool.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/
    IM:darcy@Vex.Net VoIP: sip:darcy@VybeNetworks.com

    —

  • The way an Originate works is that upon answer the channel is directed to the dialplan at the given target. Since your dialplan has a verbose message, the verbose message would only be executed upon dialplan execution which would then only occur as a result of being answered.

    Have you tried narrowing it down at all? Using the CLI to do a test
    “channel originate” using the same dial string? Have you looked at what comes back from AMI as a result of the Originate to see if it shows anything?

  • First of all, I really appreciate the help.

    So I tried this in the CLI: (everything is on one line)

    channel originate SIP/outgoing/5556667777 extension=sendfax@LocalSets faxfile=/path/to/tiff/file priority=1

    But I got “SendFAX requires an argument”. I tried various things but I
    am poking around in the dark. Can you suggest an actual CLI command based on those options that I can try?

    Also, is there some way to have the AMI interface send back the same errors? All I get from the socket now is “Asterisk Call Manager/5.0.1”.

    Thanks again.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/
    IM:darcy@Vex.Net VoIP: sip:darcy@VybeNetworks.com

    —

  • The CLI command does not allow setting variables. It was more of a general test to confirm the SIP portion and originating in general. The aim is to narrow things down and verify things piece by piece.

    You’d be getting more from AMI than just that. A message comes back when you login, another when you actually do the originate, as well as events most likely before then. The Asterisk testsuite uses AMI heavily, as do others, so I’m confident that AMI itself is working in that regard. You’d need to look at your own AMI usage and ensure you are reading from the socket and logging out. You could even connect over telnet and do the same AMI action for Originate and test that way.

    The “SendFAX requires an argument” is a normal log message which does not go to manager.

  • I stumbled upon a message that mentioned that the interface needs two line feeds before it acts on the commands. I added that and now I can connect. I am still having some issues related to T.38 but at least the commands are making it to the server now.

    Thanks for all the help.

    —
    D’Arcy J.M. Cain Vybe Networks Inc. A unit of Excelsior Solutions Corporation – Propelling Business Forward http://www.VybeNetworks.com/
    IM:darcy@Vex.Net VoIP: sip:darcy@VybeNetworks.com

    —