Alphabet Character In Destination Number (CDR)
Dear all,
I have PBX with asterisk 13.x
a couple of IPPhone that connect to that asterisk PBX send an alphanumeric dialed phone number.
for example, in my CDR table, field DST, it show dialed phone number like
– 0C81318304632C (it should be 081318304632)
– 08D11157112 (it should be 0811157112).
Why it’s happening ? and how can I prevent it to happen ?
Thanks in advance,
Ikka Jakarta – Indonesia
3 thoughts on - Alphabet Character In Destination Number (CDR)
Hi Ikka,
The last time I had this kind of problem the numbers in DB were altogether different and the reason for that was inappropriate columns data-types in DB. You can also print out some CDR(${variable}) AFAIK in the dialplan and verify that those are in original condition there or not.
Regards, Sammy
A, B, C and D are actually valid DTMF digits (they belong in a column to the right of 3, 6, 9 and # respectively, and have the “high” frequency 1633 Hz).
TTBOMK they were never actually used for anything in practice, they just keep kicking around like a vestigial organ (compare how computer software for the UK financial industry still includes code to deal with mediaeval pounds, shillings and pence).
Is it possible for a 1633 Hz tone, loud enough to swamp the “high” frequency of a dialled digit, to be finding its way somehow into the microphone of the affected phone and confusing it when digits are dialled?
J Montoya or A J Stiles wrote:
A,BC & D were used in the US in the AutoVon Military system, and telephones that have that keypad often bring pretty good money.
Some external Voice mail systems use one or more of the codes as well ( Toshiba systems for one ) Probably because they are an easy way to prevent most users from messing around in the system It was and in some cases still used for network signalling. Not that computer telephony designers believe in standards but the 16 button tone pad is an ITU-T standard. I believe in the UK it is known as MF-4
Asterisk DTMF detection leaves a lot to be desired. It certainly is not Exchange grade. There may be a way to diddle the code to remove the false detection but this should only happen with in-band signalling.I thought all SIP data was normally sent as data though sip.conf does allow in-band
John Novack