Random CID behavior on LINE
RevKev:
Quote
Now that OBiTalk provisioning is turned off, I cannot get the CID to work after I update the configuration in OBiTalk
If you have provisioning disabled, nothing you do on OBiTalk will have any effect.
FreeSpeech:
Now I want to enable OBiTalk autoprovisioning again, but I can't find the original value of the ConfigURL parameter. The default value seems to be Disabled.
RonR:
Quote from: FreeSpeech on January 14, 2012, 04:04:32 pm
Now I want to enable OBiTalk autoprovisioning again, but I can't find the original value of the ConfigURL parameter. The default value seems to be Disabled.
Checking the Default box always puts the original/default value back.
Stewart:
At this point I believe that caller ID is not being read from the LINE port at all; the times it appeared to work was when the bypass relay was de-energized, i.e. in bypass.
So, why is this happening? There is credible evidence that it's related to a firmware "upgrade", but it must be something fairly subtle, otherwise there would be many more complaints!
Possibly, it only fails under certain timing or noise conditions or is sensitive to ringing characteristics. Do you have any possible source of noise on the POTS, e.g. DSL, alarm system, fax machine, multi-line phones with an intercom function, etc?
An interesting test would be to connect the LINE port to a different source, e.g. another ATA, or a line at a friend's or neighbor's.
If that's difficult, you could use the OBi itself. Temporarily set the LINE port to route to the AA. Run a cord from LINE port to PHONE port. Call into the SP1 service, which should ring the PHONE port. The LINE port should then answer and you should hear the AA. Then, hang up and see whether Call History shows a valid caller ID on the incoming call to the LINE port.
If the LINE port can get caller ID from another source, we can try adjusting the ring detection parameters or a DSL filter. If not, we can try a factory reset and reconfigure (in case of a corrupted config), or try reverting to older firmware.
FreeSpeech:
Quote from: Stewart on January 15, 2012, 09:22:15 am
If that's difficult, you could use the OBi itself. Temporarily set the LINE port to route to the AA. Run a cord from LINE port to PHONE port. Call into the SP1 service, which should ring the PHONE port. The LINE port should then answer and you should hear the AA. Then, hang up and see whether Call History shows a valid caller ID on the incoming call to the LINE port.
If the LINE port can get caller ID from another source, we can try adjusting the ring detection parameters or a DSL filter. If not, we can try a factory reset and reconfigure (in case of a corrupted config), or try reverting to older firmware.
I did the experiment you suggested (connecting LINE to PHONE and setting LINE to forward to the AA), and after I dialed in to SP1 and heard the AA the call did show up in the Call History correctly (twice actually, once on SP1 and also on LINE1). So it seems to be a problem with the OBi recognizing CID, perhaps due to noise on the line. I do not have DSL on the line, but I do have an alarm system tied in to it.
More information: I tried connecting an old BellSouth CID device I had lying around to the phone line and it failed to recognize the CID. However, a newer Panasonic cordless phone does correctly recognize the CID when connected directly to the phone line. Thus, it seems that the signal on my phone line may be marginal or for some other reason not is detected by the old CID device or the OBi but *is* detected by the Panasonic phone!
Other information: I did have DSL on this line some time ago (like a year) but I now use a cable modem. I wonder if putting a DSL filter on the line could do some good? I'll give it a try and post the result.
Navigation
[0] Message Index
[#] Next page
[*] Previous page