Solved 3CX disconnects calls to a POTS modem

[benthook]

I work at an airport. We have a pay-at-the-pump fueling station that is connected to a POTS line with an analog modem. Once or twice a month our accounting department needs to call the fueling station to download the transaction data. For some reason 3CX disconnects calls from any device/extension to this number after the modem on the other end picks up (about 10 seconds into the call) every time. We had no problems using a modem connected to our previous voip provider to call this device (it only communicates at 9600 baud). I can use my cell phone to call the modem and listen to it try to handshake, the call stays connected no problem. I am aware of the issues with modems over voip. Just not sure why 3CX stops the call 10 seconds in no matter what device I call from. Any suggestions?

 

[Evolute IT]

I work at an airport. We have a pay-at-the-pump fueling station that is connected to a POTS line with an analog modem. Once or twice a month our accounting department needs to call the fueling station to download the transaction data. For some reason 3CX disconnects calls from any device/extension to this number after the modem on the other end picks up (about 10 seconds into the call) every time. We had no problems using a modem connected to our previous voip provider to call this device (it only communicates at 9600 baud). I can use my cell phone to call the modem and listen to it try to handshake, the call stays connected no problem. I am aware of the issues with modems over voip. Just not sure why 3CX stops the call 10 seconds in no matter what device I call from. Any suggestions?

How is that modem (gateway I suppose) connected to 3CX?

The only supported way is locally (VPN included). If remote, you might be facing UDP timeout.

 

[cobaltit]

So if you call the modem from any device behind 3CX (modem, soft phone, IP phone) and it disconnects after 10 seconds, it sounds like an issue with your provider. Since you've provided very little information in as far as your 3CX version, what you were on before when it worked, etc and the fact that this is a very fringe case you're going to have to do some leg work. I'd start by providing the information requested here:

https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

And then elaborate what you were doing before that worked. Then you probably want to get your dial tone provider involved to see what they say about the call disconnecting.

 

[leejor]

I can use my cell phone to call the modem and listen to it try to handshake, the call stays connected no problem.

This being the case, have you checked the Activity Log, to be certain that it isn't the other end, dropping the call, because it could not sync? Not sure if it is going to work using g.711, but 9600 is going to be pretty much the reliable limit, even if it were a fax machine. What type of trunking is 3CX using? What Codec(s) are being used to the provider?

 

[eddv123]

I would run a PCAP trace and see where the disconnect message is coming from: https://www.3cx.com/docs/capture-network-traffic/

Telephony >> VoIP calls >> Flow sequence.

This would be a good indication of where the issue lies.

 

[nub]

I work at an airport. We have a pay-at-the-pump fueling station that is connected to a POTS line with an analog modem. Once or twice a month our accounting department needs to call the fueling station to download the transaction data. For some reason 3CX disconnects calls from any device/extension to this number after the modem on the other end picks up (about 10 seconds into the call) every time. We had no problems using a modem connected to our previous voip provider to call this device (it only communicates at 9600 baud). I can use my cell phone to call the modem and listen to it try to handshake, the call stays connected no problem. I am aware of the issues with modems over voip. Just not sure why 3CX stops the call 10 seconds in no matter what device I call from. Any suggestions?

Just as a test try this,
edit trunk > Options > Codec priority > remove all but one codec and make the test call, remove and add codecs tell you find one that stays connected longer than 10 seconds, I am guessing that will be g711a.

Just changing the priority will not work I dont know why.

best of luck.

 

[JohnS_3CX]

Hi @benthook

Please provide your setup info as @cobaltit suggested. You gave very little information so far, and also did not say what is on the other end of the line receiving the data from the pump. For example it could be a modem, installed in a PC running the app the collects the data, connected to an ATA, registered to 3CX running via your trunk provider, calling the the POTS line, answered by the pump modem, establishing a FAX-like connection and possibly exchanging DTMF first to authenticate. The above is a logical chain with points of failure, that's why I'm being so specific.

Then check your Activity log as @leejor suggested to see who is terminating the call (you did not specify how you established the facts, we don't know who/what/why is terminating the call).

You are creating a data connection that is audio based, there are more factors that come into play versus the good ole' POTS days, a lot has changed and you will need to make sure things are setup properly before the two ends can speak to each other. The previous provider worked but we don't have any info on that either so we don't know why that worked versus now. Hence, get as detailed and technical as you can and maybe we can help pinpoint the issue

Some general advice:

• Ensure G.711 is used throughout (it's the preferred codec for dial-up voice connections)
• Ensure no transcoding takes place
• Ensure that the local analog endpoint is not experiencing loss or attenuation
• Switch logs to Verbose from the Activity Log so you can get more details
• Check your local application that collects the data for any error indications
• Dial from an analog phone if you can to hear for noise in the line, but using the local enpoint's FXS port, try without echo cancellation on the FXS port also because modems can handle echo but don't fare so well with noise.

 

[benthook]

I figured out the issue after some time, I had g.711 selected on the extension and device, but the top codec on the sip trunk settings was set as G.722 with G.711 in second place. Put .711 in the top spot and it worked flawlessly. Is there somewhere that I can see what codec each call is using and why?

 

[leejor]

The why would be because of settings, the which can be seen in the Activity Log, which may have to be set to verbose, for addition detail.

 

[eddv123]

Is there somewhere that I can see what codec each call is using and why?

PCAP trace, INVITE -SDP Body: https://www.3cx.com/docs/capture-network-traffic/

 

[JohnS_3CX]

So when you changed VoIP provider the codec list must have also changed.

G.711 is the preferred codec for dialup connections (ie. faxes and modems) so I guess the settings were incompatible with your use case.

As I mentioned earlier, if you ensure G.711 is used throughout you should be fine so it should be the top priority codec in all call legs. This means ATA-PBX-Provider the whole chain basically.

I'm glad to hear this was resolved.