Patton ATA Inbound SIP to Fax Issues

Status
Not open for further replies.

[email protected]

Premier Customer
Joined
Jun 17, 2015
Messages
84
Reaction score
21
I have a Patton SN4118/JS/EUI that I have setup as a FXS/DECT device in 3CX v15.5 for a Konica Bizhub fax machine. I can send faxes outbound but when I dial inbound to the Patton I'm having about a 10% success rate on faxes working. If I manually call the fax number I can hear the fax line turn on for about 2 seconds then I get dead air. Occassionaly after a few seconds the fax noise will return and that's the only time faxing works. When the inbound fax fails the fax machine acts like it's taking a fax for about 60 seconds after the inbound fax fails.

I've tried testing settings on the fax machine like number of rings till pickup, disable/enable line sound monitoring, setting it as a PBX extension, and disabling/enabling auto line switching. In 3CX I've tried enabling/disabling options for t.38 and 711 codecs. I've tried configuring the fax extension as a standard extension using a SIP trunk, and I've tried a handful of different t.38 bit rates in the 3CX preferences. On the Patton I haven't found anything to test. It seems like once the Patton is configured all I have to do is hand write a few configs for the Patton and it just works.

Our trunk is configured for Out Of Band. The SIP provider doesn't officially support t.38 but they're working on it. From our previous testing on the yealink phones we know that OOB works fine and that using options like Sip Info doesn't work. Our issues doesn't appear to be DTMF related and I believe the problem exists between 3CX and the Patton.

Does anyone have any insight on this issue and any items I can troubleshoot to help find the issue.
 
Did you try a wireshark capture?
There you can see whats going on. Maybe it´s trying to send it with t38 and the receiver only supports voice codecs.
 
Yeah we tried a wireshark capture. From what we can tell everything looks good. Their doesn't seem to be a difference between working and not working. When it fails you still hear the fax machine and the Konica tries to complete the fax. After a failed fax the Konica will kick out a message if you try to use it letting it know that it's currently in use because it thinks it's processing a fax. So I know from testing that the Konica's picking up and trying to receive a fax I just can't figure out why sometimes it completes and sometimes the fax tones cut out a few seconds after pickup.

One of my major issues in troubleshooting is that there's so little info on fax over sip. If I try to lookup information on the Konica, 3CX, or the Patton I get a mixed bag of forum posts, most of which don't apply to my issue. If I could find a manual entry in 3CX that explains how fax talks to FXS/DECT devices I think that may point me in the right direction because I think the issue is between 3CX and the Patton. My best guess at this point is that it's something related to negotiation between the Patton and 3CX.

From what I was reading last Friday when I was testing all of this most people blame the issue as being a negotation problem between the Patton and 3CX. Most people who seem to have this issue give up and convert inbound to email. If that's the route I need to go then we can make it happen but I need to exhaust my troubleshooting options before I try to force the company off of fax.
 
If your provider does not support T.38 then you should really only use G711 pass-through - please advise what you mean by "does not officially support T.38".

To confirm, the Patton (to be supported) should be setup either locally to the PBX system or across a VPN connection - no support for STUN or SBC configurations.

Why i make this point is that conversions are the main reason for problems with Fax especially if there are a lot of them. For example:

T30 Fax >>> converts to T.38 to traverse the trunk >> A gateway at the ITSP converts back to T.30 for PSTN transmission >> the destination Fax may have to traverse to another ITSP and the Fax maybe converted again before sending to the other Fax.

This will add delay to T.30 signalling of Fax data. Some troubleshooting points as follow:

* Slow SIP response = T.38 Re-INVITE failure. Where a 200 OK that was answered as VoIP then receives a late INVITE to switch to T.38, the switch from voice to T.38 that causes most issues.
Use QoS for voice if possible.

* Speed of document transmission changing, change to 14,400 or even 9600 on both fax machines or disabling ECM (error correction mode) can help.

ECM is required for V.34 colour faxing and MMP (Multichassis multilink PPP) compression so this may not be an option. Must be supported on your carriers gateway. Black and White Fax only if not.

* Codecs – only G711 for passthrough. Your SIP trunks must support and use G711.

Failing that you might want to run a trace from the Patton command line to understand what is going on, this can be done via telnet or the adapter that comes with the unit:
https://www.patton.com/support/kb_art.asp?art=327&

For FXS/FAX it should be:

enable
show running‐config
debug call‐router
debug call‐control
debug fxs
debug ccfxs
debug context sip‐gateway signaling detail 5
debug context sip‐gateway transport detail 5
debug context sip‐gateway error

Then "no debug" all to cease the trace. I can help diagnose this if you want to send me a .txt output.
 
  • Like
Reactions: cobaltit
Thank you for all of the troubleshooting info. This looks really helpful. I'll try to get to this today and see what I can figure out.

As for the questions about officially supporting t.38. The company that sold us the SIP trunk is connected to my director personally. I also used to work for their parent company about 15 years ago. When I spoke to their CEO and NOC employees they told me the official answer is "we don't support fax in any way but we're working on a full implementation of t.38. If you try and use t.38 it should work but we don't actually support any of that yet." it's a pretty crappy answer and they're not really supporting us but if I call the NOC for assistance they will troubleshoot with us. In this case I think the issue is between the Patton and 3CX so I'm not trying to escalate this problem with them yet.
 
@eddv123 Makes some excellent recommendations although I wouldn't agree with the QoS part. If your connection is bad enough that 90% of your fax calls are failing due to slow SIP response (and QoS is going to fix that) then you would already have people with pitchforks at your door because of call quality issues on the voice.

My recommendation as a provider who fully supports T.38 is to stop doing FoIP :). We have a very scary sounding waiver we make customers sign who insist on doing FoIP. Otherwise we stick to a POTS line or we provide a HTTPS fax adapter. Not saying I haven't had success with FoIP, and we've pushed a lot of volume on our trunks with inbound to 3CX fax-to-email, but anything touching a physical fax machine gets our HTTPs fax adapter and everyone is a lot happier for it.
 
  • Like
Reactions: eddv123
My recommendation as a provider who fully supports T.38 is to stop doing FoIP

I agree, at least over here in the UK the only time this is a necessary is for certain customers due to legal requirements (solicitors etc), they still must legally send Fax's, unless there is a caveat like this then move over to an online service or something like that (3CX does inbound FAX to email as standard).
 
It always makes me nervous when I see this quote - it normally means "we haven't tested" so I would try getting it working with G711 Pass-through first if you can to reduce the amount of pit-falls.

I would also ensure you set it up as per: https://www.3cx.com/voip-gateways/patton-smartnode-sn4112-fxs/

You did not answer how you were setting it up though - VPN, SBC, STUN, local ? this is a very important factor.

I set up the patton based on those instructions. The patton is on the same local network as the 3CX server so it's a direct connection between Patton and 3CX. I also tried a suggestion from another 3CX form post to configure it as a normal extension and configure a SIP trunk. I got the exact same result with that setup as well.

I apologize I got caught up with some issues the past couple of days. I followed your notes above and I found some odd problems but I'm apparently not understanding them fully yet. I have some output from the Wireshark VOIP utility and a failed debug capture from the Patton. My packet captures are too big. I'll need to figure out how to properly upload them. One thing to note about both of these faxes is that there were no config changes to make them work. Occasionally I just have really good luck and it works for a while.

One thing to note about the Patton log is that we have a direct route to our PRI patton at .53. You'll notice that in the debug. The route the SIP Fax is using routes to 3cx at .22 and a secondary network 172.20.0.2 (which you'll see in there as well). The Patton this debug came from is .94.

I haven't escalated this further with our VOIP provider yet. I'm still thinking this is local to my network between 3CX and the Patton so I've left them out of it for now.

I've seen a lot of posts about people giving up and switching to fax to email conversion. I'm thinking that may be the route we go but I'd like to troubleshoot and understand faxing as best as possible.
 

Attachments

Apologies for the delay. In the trace you sent you are getting the following:

"402 Maximum number of free registrations reached"

This is coming from 10.73.0.53 which based on your response above (PRI = .53) is your Patton ISDN unit.

Please confirm - are you using a SIP trunk at all or just PRI/ISDN ? your responses about suggest SIP trunk but based on your last post I am thinking not.

Regardless however I think there maybe a possibility of a licence limit being reached perhaps. In the Patton you can confirm this in the web GUI: https://www.patton.com/support/kb_art.asp?art=292&p=122
 
Thank you for the response. I'll take a look at the licensing issues and see what's going on.

We have a PRI for our current phone lines and a SIP trunk that we're testing. The Patton this debug came from has fax lines for both the PRI and SIP trunk. The PRI fax lines work fine and are on ports 1 and 2 of this Patton. I have the SIP Fax line configured on port 3.
 
The Patton this debug came from has fax lines for both the PRI and SIP trunk

This is not a combi unit is it ? you simply have PRI lines and a SIP trunk set up FAX manually ? please advise as these details could be important - what is the model number of the PRI ?
 
It's a FXS. Ports 1 and 2 of this FXS have fax lines that route through the PRI. Port 3 routes through the SIP trunk. I unplug port 2 and move it to port 3 for testing (that fax machine doesn't get much use). This is the only option I have for testing in our environment.
 
I've gone through the licensing information you sent over and I believe our Patton has a minimum of 72 SIP connections. That is far less than the number of Patton and 3CX sip connections. When I look up the message "SIP/2.0 402 Maximum number of free registrations reached" I found people saying to just reboot the Patton. I verified the configs that I found at the below link are correct. I know that they're routing and working properly since the existing Fax lines run over those configs. I'm not sure on exactly why it's spitting out that message but I believe everything is working correctly despite it.

https://www.patton.com/voipnews/v1n1/how-to-register-sip-phones.asp
 
Other than REGISTER attempt message that was all I got from the output file.

Can you run it again and see if you get anything more, alternately a PCAP trace from 3CX would also be a good option: https://www.3cx.com/docs/capture-network-traffic/
 
I'm going to put this in my todo list but I apologize as we got new servers in and we're rolling out a new warehouse system. I'll respond to this thread with updates as soon as I can.

My testing of the 3cx to email conversion works great. I'm making the argument that we should get rid of a lot of our faxing and forward the inbound faxes to mailboxes on our exchange server, then we'll delegate those fax mailboxes to the users using Exchange delegation. If I can make a good argument we'll be getting rid of these Pattons and getting users to use email instead of fax.
 
No problem, moving over to an online FAX service is an obvious choice whether you move from ISDN completely over to SIP however is another point.

SIP is great for call costs and flexibility although I still am a bit of a fan of ISDN as it is stable and you rarely get any problems with it - over here in the UK however we don't really have a choice in the matter now.
 
I want to post a final update to this thread. I did a little troubleshooting with the provider and they officially enabled t.38 on their SIP trunk. It did not help my issues. I know the technician at the phone provider personally and we agreed that this is an issue between 3cx and the Patton.

I've started the process of migrating our inbound faxing to emails. I have my first department setup for testing and they jumped on it because it turns out they don't like faxing and this makes things easier for them. I expect that we will continue rolling out the 3cx fax to email conversion and use exchange to delegate fax mailboxes by department.

Thank you to everyone who helped. To anyone who may find this thread while troubleshooting fax issues; for all the troubleshooting that we did getting rid of faxing simplified some of our network and the users are happier without it. Faxing is the modern equivilant of dial-up and it should be removed wherever possible.
 
Faxing is the modern equivilant of dial-up and it should be removed wherever possible.

I completely agree with this point and FAX should only be used when there is only a legal requirement, online FAX services are always my first option.

and we agreed that this is an issue between 3cx and the Patton.

With that being said I think it unfair to say that it is a Patton and 3CX issue without mentioning exactly how you came to this conclusion.

I have used SN411x/JS/EU models myself several times without issue for FAX, they are full supported when in local LAN including VPN environments.
 
  • Like
Reactions: YiannisH_3CX
Status
Not open for further replies.

Forum statistics

Threads
111,933
Messages
589,809
Members
164,808
Latest member
jsbjsb