Caller ID generating bogus information - displaying last caller's number

[rob613]

I have a relatively brand new Obi202.  I already had a few Obi110 and an Obi200 devices on my network.
I switched over my primary home 2-line service from a non-Obi ATA connected with asterisk to the Obi202.
On my Panasonic 2-line cordless handset I started to get false caller ID of incoming calls.
I have not been able to get any response from Obihai / Polycom for how to debug this problem.

When an incoming call comes in, regardless of whether there is already a call on one line, the handset displays caller ID information of a previous call,  say that of a family member who might have an emergency, rather than the new call's actual data, which might well be a telemarketer.  This is causing a lot of problems.

I have not seen this sort of problem when using the Obi200 (single line) with a similar Panasonic cordless single line phone, that has been in use for several years.

I don't see any configuration options for whether there are any sort of timing issues or protocol versions for the SS7/CID data, and I don't know if there have been any updates to the signalling protocol.

The problem doesn't happen on every call, but often enough to trick me into answering at incorrect priority.

I tried to diagnose the problem further by buying an even newer Obi202 but it doesn't appear to be easy to clone the configuration, with multiple GV and SIP providers.  Is there a specific procedure, using the Obi cloud or a local backup file, that should work to preserve the entire configuration to confirm whether the problem is specific to the device or common to the model design?

It would be great if Obi developers would provide an instrumented firmware that logs all the CID signalling it generates, and when, and to be able to compare that with the call log and handset display.  I even thought about trying to hook up some Obi110's to monitor things in parallel to the Panasonic phone system.

[zapattack]

OBi has a Backup and Restore function under System Management.
Backup  the old unit and Restore to the new.
The only thing you must manually enter is the passwords.
Strongly suggest a different phone or caller-id unit for testing to
try and isolate the problem.
The OBi merely passes on what it receives which is FSK(Bell202),
See the Phone, Port Settings options.
They should all be Default.

[rob613]

Thanks!  Yes, I tried all that.
I tried both local and cloud backup and restore and each time ended up with far more differences than just no password.

Which backup method do you think is more accurate / complete?  I think there were some local settings, for actual SIP provider in SP2, and cloud configuration for GV setup.  Cloud backup either triggers local full backup or it only backs up the cloud configuration portion.  I don't see that clarified.

As for the bug, or original problem:

So hours after an inbound priority call, with some outbound calls in between, the Panasonic handset rings with a new incoming call and is provided by the Obi202 with the SS7 data it received from the previous incoming call?  That would mean that the Obi is storing that data for these hours.

I've been trying to find another 2-line CID phone system to try with.

And with the simultaneous GV capability (Obi200+ - multiple Obi devices logged into the same GV account ringing simultaneously) I figured I could just compare the handset displays after the bug repeats.

I've never had this problem on my long standing Obi200 and a family member's GV account - single line configuration with a nearly identical phone.  And I never had this problem when this same 2-line phone when it was serviced by POTS lines or ATA (non-Obi).

If only Obihai support would take an interest.

[zapattack]

SS7 is between Telco switches only.
The OBi uses SIP to connect and send information.
Not sure why  a phone that displays incorrect information would be an OBi problem
until you prove that ANY phone does the same thing.

[rob613]

What do you call the caller-ID signalling that a caller-ID phone, expecting that data from a phone company line, but in this case, is getting that data from an Obi202?

So a well working Panasonic 2-line cordless phone system with caller ID with name previously got reliable information when it was connected to PSTN service, and also got reliable information when it was connected to a 2-line Linksys ATA serviced by Asterisk.

As of the last Google Voice changes I moved the service and the telephone over to a brand new Obi202.

That is when the problems began.  Frequently caller-ID information is displayed on the handset that matches a prior caller's information upon the occasion of a new call coming in.

We have been unable to get a response from Obihai support.

The device was purchased from Newegg.  Even Newegg seems to have been unable to get any attention from Obihai suppport (Polycom) about this.

In parallel to all this I have two obsolete Obi110s (they used to sit on the two PSTN lines) unused.
And a family member has an Obi200 connected to a single line Panasonic phone system of similar vintage.
In all the time of the Obi200 (and prior on the Obi110s) I never saw this type of bogus Caller ID information.

The Obi200 series permits the same GV account to be used simultaneously by multiple Obi devices and I added my primary GV account to the Obi200 but usually don't have its handset.

And the Obi202 is left at its default of incoming GV calls ringing both telephone lines simultaneously.

So each incoming call should be simultaneously ringing all 3 phone lines with the same CID information.

Whatever is the problem I assume that it is either a subtle timing or protocol difference between what the Obi202 generates and the Panasonic phone expects (unlikely - this seems like a fairly old protocol), or just a bug in the 2-line generation uniquely found in the Obi202.

The problem can show up either when I have 1 line in use or when no line is in use.

I would like to see some instrumented firmware that logs the caller-ID data that the Obi202 generates, and I would also be willing to run some instrumented Obi110 firmware that serves to log the caller-ID data that is seen on the lines.

I'm open to (and seeking) any other suggestions for how to catch this in the act better.

[dboling]

You can see the incoming CallerID info via syslog server.

the lines in syslog are:

Oct 12 18:04:56 obi202  fxst_ccapi_new_call: +18707360000->18707360000 name Peter Rabbit
Oct 12 18:04:56 obi202  [SLIC] CID to deliver: 'Peter Rabbit' 18707360000

These CallerID lines are through a Google Voice incoming call to OBI202.