SPA112 problem with transmitting DTMF signals

[Luki Luk]

Hello,

I have the problem with modulation of transmitted tones.

To communication with two device I use the CONTACT ID communication protocol.

When I use SPA112 the devices cannot connected.

The problem is in modulating DTMF signals.

Sending DTMF signal from Device A have a width 50ms but DTMF signal witch is receive Device B have 230ms width and Device B didn't recognize transmit message.

(To proper communications the DTMF signal must have  50-60ms width) 

I don't know what's happening and where. I thing that SPA112 extends time of sending tones.

This si the schema of configuration:

This is the CONTACT ID protocol:

In SPA112 are someware configuration field of transmit DTMF signals?

[Dan Lukes]

I suspect SPA112 is not guilty here. SPA112 doesn't generate 230ms signal by self. In your particular case it mean either:

1. SPA112 doesn't generate DTMF at all (DTMF is transmitted in-band by someone on the path)
2. SPA112 generate 230ms DTMF signal because it has been ordered to do it by data received from upstream

Turn on syslog&debug of Voice Application on SPA112 and capture messages.  It will helpyou/ us to analyze the issue.  Also it would be nice to have a call captured (both SIP and RTP packets between SPA112 and VoIP provider). Ask your network administrator for help.

Just side note - while your alarm system (DTMF transmitter) seems to follow DTMF specification correctly (50ms of valid DTMF signal with 50ms of silence in-between is OK), the central station (DTMF receiver) seems to be broken. DTMF digit should be recognized if valid signal is present for >=40ms (there's no upper limit) with >=40ms space in-between. So 230ms is still valid single DTMF digit and should be recognized correctly. See chapter 4.2.2. of  ETSI ES 201 235-3 for details.

[Luki Luk]

The CONTACT ID standard specifies how wide the DTMF signal should be - and if the signal goes to the receiver with a different width (not 50-60ms) and pauses then it does not recognize it, and connection is closed.

That's right, SPA112 doesn't generate a 230ms signal, but if I release a 50ms wide signal and pass through SPA112, the receiver receives a 230ms wide signal.
In the analog network without using SPA112, the receiver receives a 50ms wide signal and everything is OK.
I have the impression that the signal is changing in SPA112.

[Dan Lukes]

CONTACT ID standard specifies how wide the DTMF signal should be OK.

It mean CONTACT ID protocol violates DTMF standard because of incompatible definition of signal width. Because of it, protocol may not pass thru DTMF compliant (but CONTACT ID unaware) device.

But it's not the matter so we can forget it now.

if I release a 50ms wide signal and pass through SPA112, the receiver receives a 230ms wide signal. In the analog network without using SPA112, the receiver receives a 50ms wide signal and everything is OK.

While I'm respecting your opinion, it's just hypothesis with no evidence. Nothing you told so far confirms it's the SPA112 who's changing the length of DTMF signal - and according my experience, it's not SPA112 who is behind. The difference between "analog network with no SPA112" and "SIP with SPA112" is much complex. It's not just about SPA112. There's conversion between transmitter's PSTN and VoIP operator. There's VoIP operator itself. Yes, I don't dispute it, there's SPA112 as well.

Don't waste your time in attempt to modify SPA112 behavior unless you verified it's the SPA112 behavior behind the issue (and according my best knowledge, the chances are rather low). 

As I advised already: Turn on syslog&debug of Voice Application on SPA112 and capture messages. It will help you/us to analyze the issue. Also it would be nice to have a call captured (both SIP and RTP packets between SPA112 and VoIP provider). Ask your network administrator for help.

It's the best advice I have for you, based on my knowledge and experience. Of course, I may be wrong - in such case, I hope someone else will offer you a better advice.