Add "+1" to incoming caller ID

I am looking to add “+1” to caller ID coming from a POTs trunk. We use this POTS with several SIP trunks (which present +1NPXNXXXXXX). I’ve found that OpenCNAM does not respond to not having a +1 in the Caller ID, and would like all trunks to present the caller ID the same.

I created a new context in extensions_custom.conf:

[from-prepend]
exten = _X!,1,Set(CALLERID(num)=+1${CALLERID(num)})
exten = _X!,n,Goto(from-trunk,${EXTEN},1

I added the context from-prepend to the trunk. When a new call comes in from the POTS line, no +1 is seen and the logs show the call going to from-trunk.

Any thoughts on how to make this work?

I recommend against this. I recommend stripping all of the extra cruft off your numbers with in inbound context modeled on the “e182” context in extensions.conf so that the '*69" function of your phone will work and the number can be stored correctly in your return dialing directory.

I would normalize all of the inbound numbers to something that your sales/service/support staff people will type. This makes it possible to transition to a CRM system (if you aren’t there already). Once you’ve settled on your ‘corporate’ phone number format, convert all of the dogs and cats numbers you have lying around to that format. Since almost no one is trained to use “+” on a number (001 in NANP is common, for example) you can easily change the numbers on the fly on the way out.

Once all of the numbers in the system are normalized, use your Outbound Route and Trunk Number Manipulation Rules to modify the numbers so that the trunk can use the numbers the way you want to use them. THis way, if you add a trunk provider later on that doesn’t do “+1” for outbound, you don’t have to completely revamp your internal number database to remove them all so only add them when you need them.

1 Like

Totally agree with @cynjut even if he can’t count :slight_smile: , the + meta character although now well understood remains a ‘meta’ character, you can mostly dial it with a long press of 0 on your cell phone or but depending on where you re then it means something other so what works for you in East Bumstead, North Virginia, won’t work in Khasakstan, no matter how long you look it is not on your granma’s old 2500/250/princess phone, there is no + key. Normalize within your locale always, add the state next door if they have 10 and you have 11 digit dialling (o vice-versa) Remember your clients are your users, they likely never even heard of + when dialing.

2 Likes

Thank you both. I agree and originally was striping they +1 so we only had a ten digit number. It looks cleaner and is more functional to the end user (as you pointed out). Perhaps I am looking at this from the wrong angle then…

Using Superfecta (my provider does not provide CNAM), OpenCNAM requires the +1. Is there a way to manipulate the digits being sent to superfecta?

(BTW, loved those 2500s - nothing is built that sturdy anymore lol)

I just did some tests with Superfecta and OpenCNAM and lookups on NANP numbers in 10 digit and 1+10 digit worked fine. I didn’t need to include a leading +, and as far as I can remember, non-digits characters are stripped by Superfecta anyway.

edit - Kudos to OpenCNAM, I had not logged into my acct in YEARS, and all the credit I had from testing back in 2012 is still sitting there waiting for me to start using it again.

2 Likes

Hi Jason,

As long as the default country is set to “United States” in the Delivery settings on your OpenCNAM control panel, OpenCNAM will append the ‘+1’ if only the 10-digit phone number is queried. There is no need to manipulate the phone number sent by your trunk provider on an inbound call. If you are still having issues, the OpenCNAM support team ([email protected]) will be able to look at your account and assist as needed!

2 Likes

Thanks @lgaetz. That is what I assumed but wasn’t working.

@Telo, I received your message through your support portal as well - it seems I did not have US set as the default county.

Thanks all!!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.