Modifying Incoming Caller ID Display to Show Which Line Was Called

[Michael_Reeder]

I have exactly this participant's issue:

I have an Obi110 with a land line and single Google Voice account.  I'd like to have the caller ID on my handsets provide some indication of which number the call came in on.  Is there any way to do this? 

For example, if it comes on on the land line, display 111-XXX-XXX-XXXX and on the GV number show 222-XXX-XXXX.  I already have distinctive ringers but it would be nice to have it in the caller ID also.

Thanks!

From: https://www.obitalk.com/forum/index.php?topic=4947.0

Last time this discussion took place (in 2013) there seemed to be no solution.  I am posting a new topic thread to see if different users have had better luck or perhaps Obihai has made updates to expert configuration that make this possible.

For a variety of reasons I need to keep the ringers on my phone on silent - would love to be able to see on the phone's display which of 3 SP lines is calling in, or if its transferred from my cell phone over ObiBT.

Now... if there is a way to have the phone ring ONCE and then continue to ring silently for a time before hanging up, my environment could tolerate ringing once on low volume...

Thanks,
Michael

[azrobert]

Change the Inbound Route on each SPx Service

Voice Services -> SP1 Service -> X_InboundCallRoute:
{(<1>x.):ph},{ph}

Prefix with a single "1"

Voice Services -> SP2 Service -> X_InboundCallRoute:
{(<22>x.):ph},{ph}

Prefix with two 2's

To ring once

Ring Settings -> Ring Profile A -> Ring Pattern1: 60(2+58)

Ring for a total of 60 seconds
Pattern is ring for 2 seconds and silence of 58 seconds

Pattern3
60;(.3+.2,1+.2,.3+58)

[Lavarock7]

I do this with a toll-free line I have with Voip.ms. They allow sending info at the beginning of the caller-id.

On a different service they could send touchtones when the phone was answered, I suppose to trigger answering a prompt like extension number. I used that function to play either Beethoven's 5th (the first 4 notes) or 'Twinkle Twinkle Little Star' to tell me which number was calling.

[Taoman]

I use the following for my X_InboundCallRoute:

{(<XXX:1***>xx.):ph},{(<:1*>xxxxxxxxxx):ph}
{(<XXX:2***>xx.):ph},{(<:2*>xxxxxxxxxx):ph}
etc.

Where XXX is my local area code
I use * as a separator between line number and phone number
I use *** as a local area code substitution and separator so that calls from my local area code are very obvious to me.
Lately, calls from my own area code are where I receive most telemarketer calls.

[Michael_Reeder]

azrobert, Lavarock7, Taoman:  I want you all to know that I really appreciate the highly detailed and personal responses to help me with this!

Lavarock7: A great idea.  I confirmed with Callcentric and, unfortunately, they will not do this.

azrobert, Taoman:  I have spent hours playing with this.  I've typed it in verbatim, I've tried multiple small variations.  This morning I have been reading the Obihai device administrative guide to better understand digimaps and see where I am making a mistake. I've tried to watch syntax carefully.

So far I either get:
a. No change - the incoming caller id is not modified, or
b. The handset fails to display anything

I will get back to this when I have fresh ideas - I'm not sure what to even ask for as guidance at this point - using X_InboundCallRoute changes just don't seem to work for me.  They work for too many other people, so I've got to be doing something wrong. 

I note that in the old 2013 thread people were having trouble getting their digimaps to function too and in other conversations on this board involving X_InboundCallRoute success has seemed to be hit or miss.  Novices are doing something slightly wrong... or there is something elsewhere that effects this too.

-- Michael

[azrobert]

If you are using Taoman's suggestion, there are potentially 3 problems.

If your service provider includes country code, you need to allow for it in the rule.
{(<1XXX:2***>xx.):ph},{(<1:2*>xxxxxxxxxx):ph}

Anything to the left of the colon is used to match the callerid and is removed upon a match. Anything to the right of the colon is added.

Some phones won't display the callerid if it contains non-digits. Remove the asterisks.

{(<XXX:2>xx.):ph},{(<:2>xxxxxxxxxx):ph}

Anonymous (no callerid) won't ring. You might want this.

My suggestion isn't as sophisticated, but I tried to include all possibilities.

{(<1>x.):ph},{ph}

x. will match zero or more digits, so it will also match anonymous calls and 10-11 digit callerids.
When you are only adding digits, the colon is optional.
I included {ph} just in case the callerid didn't match the 1st rule, the callerid will be unchanged.
I just tested my suggestion on an OBi110 and it worked.
I did a cut and paste from my post.
I don't know why it's not working for you.

[Michael_Reeder]

azrobert (and all):

Thanks once again!

Okay - I found the stupid problem.

The problem was having the phone number I was test-calling from programmed into my Panasonic handset phone book attached to the Obi device.  The phone book entry in the handset overrode the changes specified in X_InboundCallRoute, such that:

a. A correct digimap in X_InboundCallRoute resulted in the handset displaying whatever was in the handset phonebook (ignoring X_InboundCallRoute),

b. An incorrect error-filled digimap in X_InboundCallRoute resulted in the handset displaying nothing,

c. Deleting the handset phone book entry for the calling phone number resulted in THIS WORKING FINE! (X_InboundCallRoute specifications being displayed on the handset)


So I now have this working on SP1 through SP4.  Yeah!


Riddle me this: (Follow-On Question)

My handset is attached to PH2 on my Obi.

I have learned and removed all testing phone numbers from the handset phone book as well as from my cell phone phonebook.

For BT1 (blue tooth call from my cell phone routed through my Obi):

{(<7*>x.):ph2},{ph2} = The unmodified inbound call ID being shown.  X_InboundCallRoute is ignored.

{(<7*>x.):ph2} = NOTHING being shown on the inbound caller ID on the handset.

This suggests that for BT1 (blue tooth connections) the conditions on the inbound call thru bluetooth are somehow not met in the digimap.

Of course - if I have to - I can stop here.  I have a number in front of each SPx line, and inbound caller id without a preceding number is my clue that its a blue tooth call.

-- Michael

[azrobert]

{(<7*>x.):ph2} = NOTHING being shown on the inbound caller ID on the handset.

{(<7*>x.):ph2}
If "x." doesn't match the callerid then the phone shouldn't ring. I don't understand if it's ringing without callerid.

The only explanation I know is the callerid from BT contains a special character. This character might not be displayable. Try the following:
{(<7*>@.):ph2}

@ will match any character.

[Michael_Reeder]

{(<7*>x.):ph2}
If "x." doesn't match the callerid then the phone shouldn't ring. I don't understand if it's ringing without callerid.

The only explanation I know is the callerid from BT contains a special character. This character might not be displayable. Try the following:
{(<7*>@.):ph2}

@ will match any character.

azrobert -- You nailed it.

Yes - The problem was the special character.

Thanks,
Michael