Ingenico 5100 operating Manual

I advance of Howards precise explanation I would like to dig into some details.

the equipment say, the call isn't answer. It may mean the call has not been established at all, or it may mean the call has been established, but data handshaking has failed.

Despite test with phone succeeded the POS may fail to dial. Because:

1. POS consider the outgoing line is busy (based on line voltage), so it doesn't start to call at all

2. POS seize the line, but then it waits for dial tone. As it doesn't recognize the dial tone generated by ATA, no dialling occur.

3. POS is dialing, but use wrong dialing method (pulse instead of tone)

4. POS detects ringbacktone as busy tone so it hangup

5. upon detection of remote modem beacon the ATA do attempt to renegotiate SIP parameters in the way incompatible with the PBX used, the is aborted because of it

6. general parameter misconfiguration - so high communication speed set on POS (don't exceed 9600Bd), compressed codec used (use G711 only)

7. your IP connectivity (from ATA to PBX) is not good enough - roundtrip time is either so so high or unstable, unreliable line (packets are lost in transmit)

You should turn on debug on ATA and catch the messages. It may help you to analyze 1-4. You should catch SIP packets as well - it may help you to analyze 5, 6. You should check configuration of POS - especially transmission speed used (6).

It's hard to give valuable advice as there are so much possible causes.

According 2, 4 - I assume the POS is tunned for call progress tones used in particular country. It may be necesarry to localize ATA to provide same call progress toness. It use USA tones by default - and those toness are diffeerent from those used on POTS lines in your country.

According [6] - the excerpt from 5100 user manual:

HIGHEST is the default which mean the POS willl try 19200. Don't highlight HIGHEST as suggested, use lower speed - try 9600 or even less. Lower speeds are less succeptible to [7] poor IP connectivity, it may even survive [6] compressed codec (but don't use it for POS data transmission despite it may work).

Unfortunatelly, I may not visit CSC during next two weeks to analyze data you provided and offer an advices. I wish someone else will help you.

sending credit card data that is not encrypted over voip could violate the security requirements of the credit card industry. Well, it depend on local rules. Some countries claim technologic neutrality. All local loop provided by public phone operator are treated equal regardless the exact technology used (POTS, ISDN, E1, SIP...).