News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

CID difference between Obi200 and Obi202 - progress

Started by rob613, April 07, 2019, 10:17:15 AM

Previous topic - Next topic

rob613

I think I found a workaround for my Obi202 CID bug problem and also found some interesting additional information.  Obi support remains 110% silent.

The problem I was having is incoming calls were causing my older Panasonic 2-line phone system to display CID of a prior (and more important) call.  Not always, of course.

This same phone system never had a problem when connected to a Linksys ATA driven by Asterisk even with simultaneous presentation of calls, or before that when I had a telco hunt group, or when fed by two different Obi110s monitoring the PSTN CID and adding VoIP to the lines.

Compatible 1-line Panasonic phone system never has had any problem driven by an Obi200.

In case it was a defective Obi202 I replaced that, despite the first Obi202 being new.  And I even obtained a newer Panasonic 2-line phone system, which has some different issues.


Finally, I played around with the CID signalling on both phone ports, to change to the other FSK - V.23 -, and also to send the CID before the first ring (CallerIDTrigger parameter).
It now seems a bit more reliable and the newer phone system is also displaying data a bit sooner after a call starts.

There must be a difference between how Obi200 and Obi202 generate CID!

The problem can happen when I have 1 line in use (off hook) or the more usual when both lines are idle.  Accordingly I don't think I can dismiss the problem as only due to simultaneous presentation of the calls on both lines.  But I also don't know enough about call-waiting-caller-ID to know if that could preserve the symptom's of being simultaneous presentation.

The Obi202 now seems to possibly generate CID data before each ring until answered.

Additional data:

I took out some old telco-supplied 9V-battery-powered CID boxes.  They accept CID numbers to log from the Obi200 but report "error" on any data from Obi202.

I also took out an old telco-supplied phone with an integrated CID log and with the new settings it is accepting CID data from the Obi202 on the one port it is listening to.

This additional data tells me that the problem is not a bug in the old Panasonic 2-line phone system but definitely a change between Obi200 and Obi202.

Panasonic kindly told me that they comply with Bell202 signalling, which is the default on the Obi202.  But it is the other US setting that seems to work better, V.23.

I also tried deploying an Obi110 paper weight with the Obi202 output as if a PSTN line and it happily logged the data, but I didn't keep this running long enough to catch anything in the act.

I am relieved that after 9 months of effort, no thanks to Obihai support I'll add, I might have finally made things a bit more reliable.  No return call from Obihai and no reply email other than to demand Obi numbers of the devices.  At one point Obihai (by their 2nd name) even declared that the national from whom I purchased the Obi202 devices was not an authorized dealer.  Perhaps now with their 3rd name they might return to some level of responsiveness?

If anyone knows of techniques, perhaps with a digital processing oscilloscope, to better diagnose the generated CID signals, I'll remain interested.