PDA

View Full Version : How to capture DTMF callerID



schellens
10-27-11, 12:14 PM
Hello,

My application is interfacing with a Daytona Analog HMP PCIe 16T board.
The goal is to log the called- and caller-ID on a POTS phone-line.
Therefore I have enabled and started the DTMF Digit Detection functionality while passively listening on a trunk channel parallel connected with a phone-line.

Dialing a phone number works just fine, all digits pressed are captured.
However at reception of a phone call, none of the caller-id digits are captured. Can anyone explain this, knowing that the caller-id is sent in DTMF format by the phone company (the caller-id is transmitted just before the phone starts ringing).

Thanks for any answer(s).

mrecoskie
10-27-11, 02:09 PM
Hi,

Does the caller id never work or just works sometimes? I would recommend leaving the DTMF detector on all the time. If there is DTMF present it should then be captured.

You could also try capturing a recording of the line before and during the call to help verify the contents of the line. This can be done through the 'aohtest' application by starting a recording and leaving it on the whole time. I'm a little rusty on the commands but from my notes I think they are something like below assuming the call is on the first channel.



board 0 open
trunk 0-15 open
trunk 0-15 get config
trunk 0-15 set config audioFormat=alaw
trunk 0-15 start
channel 0-15 seize
dd 0 start
record 0 start output.au
(make the incoming call)
record 0 stop
dd 0 stop
channel 0-15 release
trunk 0-15 stop
trunk 0-15 close
board 0 close

schellens
10-28-11, 09:55 AM
Hi,

The DTMF detector is enabled all the time. Sometimes only the first digit of the caller-id is captured.

A channel 2 capture executed with aohtest reponses with:
DD 2: received PKH_EVENT_DD_KEY_DOWN (p0 = 0x30, p1 = 32767, p2 = 0x0)
DD 2: received PKH_EVENT_DD_ENERGY_LEVEL (p0 = 0x52fa8, p1 = 0, p2 = 0x0)
DD 2: received PKH_EVENT_DD_KEY_UP (p0 = 0x30, p1 = 36, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_ON (p0 = 0xc03a, p1 = 0x0, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_OFF (p0 = 0xc3bd, p1 = 0x0, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_ON (p0 = 0xc6ab, p1 = 0x0, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_OFF (p0 = 0xc9ca, p1 = 0x0, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_ON (p0 = 0xda33, p1 = 0x0, p2 = 0x0)
TRUNK 2: received PKH_EVENT_TRUNK_RING_OFF (p0 = 0xdc07, p1 = 0x0, p2 = 0x0)

See attached file for the corresponding audio recording.
Note: The extension has been changed from au to txt for upload purposes!

Hope to hear from you sone ...

mrecoskie
10-31-11, 10:55 AM
From the recording the DTMF caller ID seems distorted and this is why it is not being detected.
In patch 2.8.20 there is a special mode to reduce the sensitivity of detecting DTMF caller id. This is the 'callerIdModeEnabled' field in the PKH_TDDConfig structure.


PK_BOOL callerIdModeEnabled; /* The purpose of this mode is to relax the detection */
/* requirements when using the dtmf detector for caller ID */
However even when enabling this it seems like your DTMF caller still does not work - only 7 out of 12 digits are detected.

If there is no way to clean up the signals then I would imagine the solution would be to ask Pika to further tweak the DTMF algorithm.

schellens
11-04-11, 07:19 AM
So for the late reply, but other work came inbetween.

Regarding the good reputation of provider used, I was surprised to hear the DTMF signal was distorted.
So I was wondering if the connected phone also had a problem displaying the CID.
First I had to replace the batteries because they were empty.
After that the CID was shown perfectly on the phone's display, but was also captured perfectly by the trunk board!

Thus all works perfectly as long as the batteries of the tapped phone are not down.
Can you explain this?

Anyway, thanks a lot for your support!

mrecoskie
11-04-11, 09:13 AM
Likely the caller id is always present to the phone but the batteries are necessary to power the display so the caller id could be displayed.

The distortion may not be necessarily caused by the provider. A few thoughts come top of mind. First, I would confirm you are using the proper line impedence. This is set through the 'internationalControl' field in the TrunkConfig structure using the TRUNK_SetConfig function. I would also suggest examining the tap point and cable as well. How long is the tap point?

Finally as a test you might want to attach a phone to the tap and see if it detects the caller id. However you will want to avoid taking the phone offhook as this will answer the call. Just some thoughts.