cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2924
Views
0
Helpful
6
Replies

Transfer line to use with POS credit card (Machine (Ingenico 5100) SPA3102 FXO to SPA122 FXS

conrado.szulzyk
Level 1
Level 1

I make the setup to transfer the line to another point using wireless equipment, i make and receive calls, without a problems, Calls in and out functionals.

I call to POS Credit card number, and the machine, answer the call.

When i put the Credit Card Machine (Ingenico 5100 and others brands and models), the equipment say, the call isn't answer.

But if, i make the call with a telephone, i hear the answer tone, like a fax machine on the other side.

I try to modified the ECO, but no have good response.

Any help?

Thanks, Conrado Szulzyk.

 

----------------------------------------------------------

----------------------------------------------------------

 

Hice la configuración para transferir una linea a otro punto usando enlaces inalámbricos, puedo hacer y recibir llamadas sin problemas. Llamadas funcionales.

Si yo llamo al numero de teléfono del sistema que marcaría la terminal POS de Tarjetas de Crédito, la llamada es contestada.

Cuando coloco el equipo POS de tarjeta de Crédito (Ingenico 5100 y otras marcas y modelos), el equipo informa que la llamda no es contestada.

Pero, si realizo la llamada usando un teléfono, se escucha cuando se contresta, el tono similar a una maquina de fax desde el otro lado.

He probado y cambiado la configuración del ECO, pero no tuve buenos resultados.

Alguna ayuda?

Gracias, Conrado Szulzyk.

 

2 Accepted Solutions

Accepted Solutions

Sending digital data originally in an analog format over voip can be very difficult.  This is because the data must be converted to a digital format for transmission and then at some point converted back to analog.  The conversions must be very precise.

In addition, sending credit card data that is not encrypted over voip could violate the security requirements of the credit card industry.

Sending data over voip is somewhat similiar to sending a fax over voip.  The SPA3102 and SPA122 Administration Guides have sections recommending special settings for sending fax data over voip using the G711 codec.

SPA3102 Administration Guide: (page 50 Step 1, Step 2, Step 3)
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpvga/ata/administration/guide/ATA_AG_v3_NC-WEB.pdf

SPA122 Administration Guide: (page 136-137 Step 1 thru Step 6)
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide_SPA100/spa100_ag_1_3_5.pdf

View solution in original post

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:

CONFIG DIAL RATE
HIGHEST 19200 9600 2400 1200
 
Highlight HIGHEST and press [ENTER]
SELECTING HIGHEST WILL ALLOW THE TERMINAL AND VC TO DECIDE WHAT SPEED IS BEST

 

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, ...).

 

View solution in original post

6 Replies 6

Sending digital data originally in an analog format over voip can be very difficult.  This is because the data must be converted to a digital format for transmission and then at some point converted back to analog.  The conversions must be very precise.

In addition, sending credit card data that is not encrypted over voip could violate the security requirements of the credit card industry.

Sending data over voip is somewhat similiar to sending a fax over voip.  The SPA3102 and SPA122 Administration Guides have sections recommending special settings for sending fax data over voip using the G711 codec.

SPA3102 Administration Guide: (page 50 Step 1, Step 2, Step 3)
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpvga/ata/administration/guide/ATA_AG_v3_NC-WEB.pdf

SPA122 Administration Guide: (page 136-137 Step 1 thru Step 6)
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/csbpvga/spa100-200/admin_guide_SPA100/spa100_ag_1_3_5.pdf

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:

CONFIG DIAL RATE
HIGHEST 19200 9600 2400 1200
 
Highlight HIGHEST and press [ENTER]
SELECTING HIGHEST WILL ALLOW THE TERMINAL AND VC TO DECIDE WHAT SPEED IS BEST

 

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, ...).

 

Thanks Dan!.

As I told Howard, tomorrow, I will make every possible test.
I think that mistakes can be in 1, 4 or 6 but will perform all tests.

Thank You.

You marked thread answered. It seems you solved the issue. I'm curious to know how you solved it - we offered so many possible causes to you ...

Hi Dan!
I made changes to fax settings, as suggested Harold.

He connected with the POS terminal, but not end the communication correctly.

Continue with your suggestions, I considered that could be causes of error, 1, 4 and 6. But still with the same error, with the tests I got new ideas. But continuing with your help, and read a little more of both manual equipment, the ATA's, I made some new settings.

So look all options Codecs and G711a marked as being a country other than USA.

Use Fax options T.38 and reINVITE and there started to run correctly.

A little help from Harold, and a little help from you.

 

Thank you so much for everything.

 

Conrado Szulzyk

Hi Howard, thanks for reply.

Tomorrow I will test the Fax settings.

As for security, not working on a WAN, but directly in a private secured link.

Thanks