News:

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

Main Menu

Caller ID Mangling

Started by Transient, July 01, 2014, 08:45:21 PM

Previous topic - Next topic

Transient

I have an OBi110 connected to a PSTN line. Occasionally (maybe 1 in 50 calls), the inbound PSTN caller ID information sent from the OBi110 has the date and time prepended to the number and name.

The mangled information is formatted is like this: MMDDHHMM [Phone Number][Name]

It looks like this in the call history log:

QuoteCall 65   07/01/2014    16:55:28
Terminal ID   LINE1
Peer Name   
Peer Number   07011655 1234567890JOHN DOE
Direction   Inbound
16:55:28   Ringing

The caller ID unit connected to the OBi110's phone port shows a blank name line and "0-701-165-5123" for the number. I have another caller ID unit connected directly to the PSTN line that displays the information correctly.

Does anyone know what's causing this and how I can fix it?

Transient

#1
This happened again today with an incoming call, so I thought I would include a picture of the caller ID units. This seems to be happening much more frequently than I originally thought.



OBi110 call log information for this call:

QuoteCall 4   07/07/2014    13:08:32   
Terminal ID   LINE1   
Peer Name      
Peer Number   07071308 9013824574O   
Direction   Inbound
13:08:32   Ringing

My OBi110's information:

QuoteHardwareVersion   3.4
SoftwareVersion    1.3.0 (Build: 2815M)

I seem to have the latest firmware version, so I don't know what to think other than maybe my OBi110 is defective. This is starting to be a very frustrating problem.

Any ideas?

azrobert

Build 2824 is the current version, not 2815M.

If that doesn't work you can strip off the unwanted data.

Change Physical Interfaces -> Line Port -> InboundCallRoute to:
{(<xxxxxxxx@:>xxxxxxxxxx<@.:>):ph},{ph}


Transient

Quote from: azrobert on July 07, 2014, 08:32:49 PM
Build 2824 is the current version, not 2815M.

Thanks for pointing out the newer build. I've upgraded to it and will see if it helps.

Quote from: azrobert on July 07, 2014, 08:32:49 PM
If that doesn't work you can strip off the unwanted data.

Change Physical Interfaces -> Line Port -> InboundCallRoute to:
{(<xxxxxxxx@:>xxxxxxxxxx<@.:>):ph},{ph}

Wouldn't this always strip off the first 8 digits, whether the date and time are prepended or not?

drgeoff

Can you discern which of these is/are happening:

The CID on

1.  an incoming call from a number which the OBi has previously decoded correctly is always decoded correctly.

2.  an incoming call from a number which the OBi has previously decoded correctly is not always (= only sometimes) correctly decoded.

3.  an incoming call from a number which the OBi has previously decoded incorrectly is always decoded incorrectly.

4.  an incoming call from a number which the OBi has previously decoded incorrectly is not always (= only sometimes) decoded incorrectly.

azrobert

#5
Quote from: Transient on July 08, 2014, 03:37:02 AM
Wouldn't this always strip off the first 8 digits, whether the date and time are prepended or not?

No.

{(<xxxxxxxx@:>xxxxxxxxxx<@.:>):ph},{ph}

xxxxxxxx@ will match the timestamp and the following blank.
xxxxxxxxxx will match the callerid.
@. will match the name.

If all the above match then:
<xxxxxxxx@:> will remove the timestamp.
<@.:> will remove the name.
:ph will route the call to the phone port.

If the above does not match then the 1st rule is ignored and
{ph} will route the call unchanged to the phone port.


Transient

Quote from: drgeoff on July 08, 2014, 04:21:59 AM
Can you discern which of these is/are happening:

The CID on

1.  an incoming call from a number which the OBi has previously decoded correctly is always decoded correctly.

2.  an incoming call from a number which the OBi has previously decoded correctly is not always (= only sometimes) correctly decoded.

3.  an incoming call from a number which the OBi has previously decoded incorrectly is always decoded incorrectly.

4.  an incoming call from a number which the OBi has previously decoded incorrectly is not always (= only sometimes) decoded incorrectly.

It's cases 2 and 4. It seems random whether or not a particular call's caller ID information will be decoded properly.

Quote from: azrobert on July 08, 2014, 06:43:34 AM
No.

{(<xxxxxxxx@:>xxxxxxxxxx<@.:>):ph},{ph}

xxxxxxxx@ will match the timestamp and the following blank.
xxxxxxxxxx will match the callerid.
@. will match the name.

If all the above match then:
<xxxxxxxx@:> will remove the timestamp.
<@.:> will remove the name.
:ph will route the call to the phone port.

If the above does not match then the 1st rule is ignored and
{ph} will route the call unchanged to the phone port.



Okay, I understand now. Thanks for the idea and thorough explanation! I'll definitely try this if the firmware upgrade didn't fix it.