News:

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

Main Menu

CallerID stops after update on Obi202

Started by JohnH, July 12, 2017, 08:50:31 AM

Previous topic - Next topic

JohnH

Updated firmware on my Obi202 and now the CallerID feature has stopped on one of my lines, but still works on the other line. Here is some other info that might work.

Provider: Vestalink
CallerID working on Vestalink system: YES
Could problem be the phone: NO, two phones are connected and neither work for that line, but work for other line.

Any ideas? I'd like to avoid a factory reset because there were some customizations to the CallerID code that I'd rather not lose (they've been working fine for several years) and I can't remember everything that I changed back then.

Thanks in advance for your help.

drgeoff

There are two aspects to CallerID:

1.  It has to be received by the OBi in SIP messages and extracted from them.

2.  It needs to be encoded as 'tones' and sent to the phone.

Check the first by looking at the Call History.  Log in to the 202's local web GUI, click on Status, then on Call History.  Does the left column show the Caller ID on calls to the number where it is not showing on the phone?

You can check the second by forking incoming calls on the problem number to both phone ports.  If you configure your OBi via the Obitalk portal there is a setting for each SP which determines which phones should ring.  If you configure locally then set the InboundCallRoute on the appropriate SP to ph,ph2.

JohnH

Thanks for your help drgeoff! Here's what I found...

1. Caller ID is showing up in history.

2. Regarding the InboundCallRoute field, they're both very different...

The field for line SP1 (the line that works) says {>(XXXX):ph} where XXXX is my obfuscated AuthUserName.

The field for line SP3 (rings, but no caller id) says {(<1:>@@.):ph2},{ph2}

I tried changing SP3 to {>(XXXX):ph2} where XXXX is my AuthUserName for that line, but it made no difference.

drgeoff

Temporarily set the InboundCallRoute for SP1 to ph2 .  Then a call in to the SP1 number should send CallerID to ph2.  Does it appear?

You should also check that the ph2 port is set to send CallerID to the phone using the correct protocol.  Compare the Physical Interfaces, Phone Port1, Port Settings section, the CallerIDMethod and CallerIDTrigger fields with those of Port 2.  The defaults, which match US 'standards' are FSK(Bell 202) and Before First Ring.

SteveInWA

Quote from: drgeoff on July 12, 2017, 12:38:56 PM
Temporarily set the InboundCallRoute for SP1 to ph2 .  Then a call in to the SP1 number should send CallerID to ph2.  Does it appear?

You should also check that the ph2 port is set to send CallerID to the phone using the correct protocol.  Compare the Physical Interfaces, Phone Port1, Port Settings section, the CallerIDMethod and CallerIDTrigger fields with those of Port 2.  The defaults, which match US 'standards' are FSK(Bell 202) and Before First Ring.

The US default for caller ID is AFTER the first ring.  That's how the old-skool PTSN caller ID has always worked here.

drgeoff

Yes, 'after' is correct for the US and is the OBi's default.

JohnH

Thanks drgeoff! Your suggestion to set the InboundCallRoute for SP1 to ph2 put me on the right path. This all got started from a power outage (which later led to a firmware upgrade) and it turns out that both of my phones stopped showing CID for that one line (go figure). When I did a factory reset on each phone, CID started working again.