News:

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

Main Menu

SOLVED: Expert settings - CID prefix?

Started by QuantiumTech, April 23, 2016, 12:06:15 PM

Previous topic - Next topic

QuantiumTech

I have more than one business and more than 1 Google voice account setup on my Obi200. Everything is working great but I would like to make one small improvement... I have GV configured to display my Google Voice number - so I'll know which business they're calling and can answer with the appropriate greeting. What I'd LIKE to do is to set GV to display the caller's number and then configure the Obi to add a prefix to the caller ID. A single number or letter would work, but a three letter abbreviation would be really nice.

Is anyone out there super knowledgeable about all the expert settings? Is there any way I can prepend a code to the incoming caller ID?

Taoman

You can try this. Set your X_InboundCallRoute for each line to be:

{(<aaa:X***>xx.):ph},{(<:X*>xxxxxxxxxx):ph}

aaa=local area code (I like to more easily see if the caller is calling from my own area code)
X   =line number (1, 2, 3, or 4)

Haven't tested it extensively but pretty sure "X" must be a number.

Note: The number of "*" used is determined, in part, by how many digits your phone can display. I use them just as a separator between the line number and calling number. I'm using Panasonic DECT phones.

PS. I assume you realize you can set a different ring pattern for each line so you can tell just by the ring pattern which line is ringing?

QuantiumTech

Thanks very much for the help, Taoman!

I went into Expert Configuration > Voice Service > SP1 Service

I wasn't able to change X_InboundCallRoute until I unchecked ObiTalk Settings and Device Default. When I tried making the change you suggested, my phone would no longer ring when I called it from another line. When I rechecked the ObiTALK settings box, then it would ring again.

Here's what my X_InboundCallRoute looks like when the ObiTALK settings box is checked:

{(5205551212|5205551313):aa},{ph}

The two 520 numbers (which, of course, I've changed) are my and my wife's mobile numbers which are setup as trusted callers. Note that these are *not* the phones I'm using to place inbound test calls.

Any idea what I might be doing wrong or what else I might try?

P.S. I do know about the ringtones, but I actually have 4 incoming lines - 3 businesses plus the parent LLC, so trying to memorize the ringtones - especially when two of those lines almost never ring - isn't really a viable solution for me.

QuantiumTech

UPDATE:

Progress? With this string, the phone connected to the Obi at least rings...
{(<:3**>xxxxxxxxxxx):ph}
The Caller ID simply shows "UNKNOWN NAME" with no phone number. (The line number, "3" doesn't show up either.)
With the ObiTALK settings box checked, it shows "UNKNOWN CALLER" and the phone number. I'll keep messing around with it and post back with any further "progress"...

ianobi

I'll go for a more permissive answer. My basic rule for the relevant X_InboundCallRoute is this:
{(<**1>@.):ph}

This will prepend **1 to any incoming CallerID or none if no CallerID is available. For your specific X_InboundCallRoute it would look like:
{(5205551212|5205551313):aa},{(<**1>@.):ph}

You may replace **1 with almost any alphanumeric characters. I have tried letters rather than digits some time ago when I first looked at this and the OBi device does pass them through to the Phone Port, even though they may not show up in the Call History or Phone Status. The problem is having a phone or some other device that will display anything that is not a numeric digit.

My dect phones do not display prepended letters within the CallerID section of the display and I seem to remember ignore the CallerID completely as they do not understand it. My OBi1032 IP phone displays the prepended letters correctly and also shows them within the call register. I think I did my original testing by sending the altered CallerIDs from the OBi device to a softphone (PhonerLite) and that displayed the CallerID with prepended letters correctly.

Make changes via the OBi Expert Configuration pages. From your OBi Dashboard, click on your OBi number and follow the prompts to get there. To change a value uncheck both boxes to the right of the value and leave them unchecked. After changing the values on one page, press submit at the bottom of the page and wait a few minutes for the OBi to reboot. Then move on to another page if required.

Taoman

Quote from: QuantiumTech on April 25, 2016, 09:48:12 AM

Any idea what I might be doing wrong or what else I might try?


Yes, listen to anything ianobi tells you.  ;D  Only reason I learned how to do this was because of him.

QuantiumTech

#6
Thanks so much for the help, ianobi!

With no modifications, the phone connected to my Obi200 shows
UNKNOWN CALLER
15205551456
Using your suggested string, my phone shows "UNKNOWN CALLER" with a blank line below it.
If I change <**1> to just <1>, I get "UNKNOWN CALLER" with a line below it showing the phone number - with an extra 1 prepended to the phone number. (now we're getting somewhere!) That extra 1 at the beginning, however, causes the separating dashes to be omitted.
If I change <1> to <H>, I get "Private Caller" - which, based on what you said, I think probably means that my phone is freaking out over any non-numeric character in the phone number line.
If I try to use <3->, it shows "UNKNOWN CALLER" and the phone number (no dashes) - with a 3 prepended. (The dash appears to be ignored.)
I thought maybe if I used some sort of text delimiter around an alpha character... so I tried <'H'>  That gave me the same result as using the default value - "UNKNOWN CALLER" followed by the phone number. Interestingly, it does restore the separating dashes in the phone number: 1-520-555-1466 so basically it's ignoring everything within the "<>"
I got the exact same result when trying to use double quotes instead of single quotes as text delimiters. I also tried back ticks (``) as text delimiters- again, same result.

I'm giving up (for now) on using alpha characters and just trying to get "3" plus a dash or star or space or any sort of separator between it and the phone number that follows. However, it would be really nice to use an alpha prefix as opposed to numeric and I'm wondering... so far, everything I'm doing is only affecting the lower line (where the phone number is displayed) - is there any way to modify the UPPER line (which actually is alphanumeric)?

QuantiumTech

#7
No matter what I do, I can't seem to get any separation between the prepended 3 and the rest of the phone number. All the below have the exact same result:
<3>
<3->
<3 >
If I include a star or a # or anything non-numeric (other than dash or space), it goes back to showing "UNKNOWN CALLER" with a blank line below it.

To some extent, the whole purpose of this exercise is to not only allow my office manager to know which number is being called - so she can answer with the appropriate greeting - but also to be able to pop the last seven digits of the phone number into the search field of our customer database. Having the caller ID shown as 3-15205551466 is only marginally better than 315205551466. Yes, the prepended 3 does tell her which business is being called, but the omitted dashes make it much harder to get the last 7 digits for the database search. If there's a way to prepend "H-" to the upper line, it would be a much, much better solution as the letter prefix is much more intuitive (all 4 of my businesses start with a different letter) but also, the dashes would be displayed in the phone number.

ianobi

QuoteWith no modifications, the phone connected to my Obi200 shows
UNKNOWN CALLER
15205551456

I'm guessing that your phone is attempting to show:
CNAME
CallerID

There's some guesswork here as we have no knowledge of what your phone is capable of displaying. OBi devices cannot modify CNAME. If a CNAME is sent, then it will forward it to the Phone Port exactly as it receives it from the telco or SIP provider or GV. I do not know much about GV, but I'm assuming that it does not send CNAME. I don't know if your phone may add in CNAME if it has a number in its database.

All we can do from an OBi point of view is to transform CallerID. It appears that your phone will not display letters in the CallerID (lower line), I guess that this is not unusual. If you only require the final seven digits of the incoming CallerID to be displayed, then you could experiment with something like this:
{(<xxxx:1111>xxxxxxx):ph}
This will replace the first four digits of an eleven digit number with 1111 followed by the remaining seven digits unchanged. This may be more obvious on the phone display.

Getting late in my part of the world, so I'm signing off for today. If you wish to carry on experimenting, then I'm happy to help if I can tomorrow.


QuantiumTech

Quote from: ianobi on April 25, 2016, 12:34:50 PM
I do not know much about GV, but I'm assuming that it does not send CNAME. I don't know if your phone may add in CNAME if it has a number in its database.
I have no idea about what GV does or does not do with CNAME but my phone definitely adds it when it's in my phone's database.
QuoteAll we can do from an OBi point of view is to transform CallerID. It appears that your phone will not display letters in the CallerID (lower line), I guess that this is not unusual. If you only require the final seven digits of the incoming CallerID to be displayed, then you could experiment with something like this:
{(<xxxx:1111>xxxxxxx):ph}
This will replace the first four digits of an eleven digit number with 1111 followed by the remaining seven digits unchanged.
PERFECT! I really just wanted to replace the first digit, so I used {(<x:3>xxxxxxxxxx):ph}
and now it replaces the "1" (before the area code) with a 3 - and I still get the separator dashes! Tremendously helpful, ianobi! Thank you!!!

ianobi

I'm glad we got there!

One small modification I would recommend. Some calls may come in with no CallerID and you may not wish to miss them if you are running a business. A "ph" rule will pick them up. I suggest:

{(5205551212|5205551313):aa},{(<x:3>xxxxxxxxxx):ph},{ph}

The rules are evaluated from left to right, the first to match being used. The {ph} will pick up any calls that do not match any of the other rules.

QuantiumTech

Done! Thanks, again, ianobi! You're awesome! :)