Quick idea. Have you tried playing with the decibel settings or impedance settings. I had a cisco ata that wouldnt relay the caller id to an old avaya until i turned down or up the decibels.
See page 14 of
Set Syslog Server to the private IP address of your PC, assuming that it’s on the same LAN subnet as the Grandstream. Set Syslog Level to Debug (maximum verbosity).
Use a syslog server on the PC if you have one. Otherwise, run Wireshark and type ‘syslog’ (without the quotes) into the display filter bar.
Then, make a test call in and you should see lots of messages. Report any that are related to caller ID.
no i have not i will give it a shot
tested with no effect
Then maybe it is not bellcore
To be honest I’m not quite certain myself, given the fact that my “useful” pstn provider can’t get back to me yet as to which one we use but I can confirm on a working grandstream and PIAF system that they use bellcore/telcordia
Is it the same provider with the same technology on both clients?
Did you ever do the dahdi_monitor thing?
yes its a monopoly here there is only one PSTN provider
dahdi monitor?
[00:0B:82:D6:18:62][000][9660000223A][1.4.1.5] 1835 cm_utility.c CID data avail: 0,0,0,0,0,0,0,0,0 lens:0,0,0,0,0,0
00:0B:82:D6:18:62][000][9660000223A][1.4.1.5] FXO_CID: Port: 0 Alert signal(FXO_CID_ALERT_RING) detected.
[00:0B:82:D6:18:62][000][9660000223A][1.4.1.5] FXO_CID: Port: 0 Start data capture for CID Type: BELLCORE(FSK)
Assuming that you were referring to setting Rx from PSTN Audio Gain to -6 and also to 6, then I’m pretty much out of ideas.
If you want to pursue this further, find a way to listen on the line to see if the Bellcore format is being followed. If you have one, a butt set is easiest. See
By ear, you can determine whether the modem tones are present between the first and second rings as the Grandstream is expecting. If that looks correct, record the tones on a computer or smartphone and open the file in an audio editor. You should be able to see whether the channel seizure signal and mark signal is as expected.
IMO, the issue is likely one of:
- Your telco is sending other than Bellcore format. You will either need to find a compatible gateway, find a way to trick the GXW into decoding it, replace the POTS lines with a SIP trunk, or give up on caller ID.
- The format is Bellcore, but electrical noise or another disturbance is preventing the GXW from decoding it. With luck, you’ll hear it on the butt set. A DSL filter might reduce it adequately.
- The format is Bellcore, but the sequence of bytes sent do not match what the GXW is expecting. Perhaps newer firmware is available that is compatible.
I believe that would be for my other client
dahdi_monitor is used with DAHDI hardware, so it doesn’t apply if you have a gateway.