The users are having trouble to use the redial feature for the incoming or missed calls. The issue is the incoming call shows only 10 digits caller ID. It’s missing the leading prefix “9” to send to call to the SIP trunk. When the user hit call back or redial on the phone, it won’t call out because of missing the leading digit. I’m looking for a way to prepend the leading digit “9” to the incoming caller ID. The Set Caller ID Module doesn’t help because it requires to set the destination. I can’t just add it there by adding the rule for all the extensions. I tried add the following code to the extensions_custom.conf file.
[from-pstn-custom]
exten =>_x.,1,set(CALLERID(NUM) = 9${CALLERID(NUM)}) ;
However, that seems to have no affect. The caller ID is still showing 10 digits. Any idea why added the above code to the extensions_custom.conf doesn’t work? is there any better way to make it work and simple? BTW, we don’t want to remove the leading digit from the dial plan.
Think about NOT requiring an initial 9 on your outbound calls, it’s a legacy from Centrex systems and just not relevant anymore. Just make sure both 10 (NXXNXXXXXX) and 11 digit (1NXXNXXXXXX) calls are accepted and your trunks also massage the number dialled if needed. This process is often called ‘normalization’ so phone-books and callbacks are all copasetic, Your users, ideally should be able to dial exactly as they can from either their cell phones or their landlines.
Originally CallerID in the US was NXXNXXXXXX, the trick here is N is 2-9 as the ‘most significant number’ , so as we get into the 21st century 1NXXNXXXXXX will identify a NANP number , similarly 4416977XXX (yep check that out, it’s an outlier) will identify a number in Brampton, UK.
Cell Phones/Mobiles need to know where they are so an initial + was added by GSM
such that a long press on 0 will replace the current ‘national code’ to make international calls as appropriate and a forceful + is now honored by reputable VSPs.
So, by Most significant number , today an initial 9 which 20 years a go would get you an ‘outside line’ now should direct insert a + and send you to
So, ideally you will have a rigid set of rules that your users are accustomed to, perhaps 7 digits perhaps 10 digits instate and 11 digits out-of-state, 011 (+) would be needed to make an international call . (More and more the 1NXXNXXXXXX will be enforced in the US. )
If your clients expect 7 digits , you will need to prepend the area code
If your VSP accept only 11 digits, you probably need to prepend a 1 for your 10 digit or AC+7 disgits
If your VSP requires E164 you probably need to prepend +1 for US calls and replace 011N. with +N. for international calls
If your VSP send you an initial + you might (or might not) want to replace that with 1 for 11 digit long CID’s and 011 for CID’s longer than 11 (always E164) so you can redial them
As I mentioned in my original post, we don’t want to remove the leading digit in the dial plan. I know that is a technical option but it’s not an option for us. I need to figure out a way to insert the leading digit.
Can you please explain? I can think of many reasons why you may need to accept a leading 9 (you have existing directories, speed dials, predictive dialer, fax machines, alarm systems configured to dial 9), but it’s hard to think of a reason why you must require a leading 9.
accept their stubborness, it is often real in ‘the world’ (as old fashioned as they are) , allow all dial patterns but in the middle between outbound routes and trunks and inbound calls, normalize both in and out to be fully e164 compliant, (with a + or not , 10 or 11 or 7 by your locale accept centrex gracefully but mask it in your CallerID(num))
My question is why the system ignore the code in extensions_custom.conf?? the extensions.conf includes [from-pstn-custom] context. Why is it ignoring it?
[from-pstn]
include => from-pstn-custom ; create this context in extensions_custom.conf to include customizations
My sip trunk is set to context=from-pstn. If I set it to context=from-pstn-custom, the incoming call won’t get through. The system just doesn’t know where [from-pstn-custom] is.
The context from-pstn-custom doesn’t exist until you create it. BUT, you are strongly discouraged from using this context. If you want to preprocess inbound calls use your own context like in this post: Context for scripts (incoming calls)
Please try the following. Add this to extensions_custom.conf :
[from-pstn-prefix-cid]
exten => _.,1,NoOp(Entering user defined context from-pstn-prefix-cid in extensions_custom.conf)
exten => _.,n,set(CALLERID(num) = 9${CALLERID(num)})
exten => _.,n,Goto(from-pstn,${EXTEN},1)
Change the Context for your incoming trunk from from-pstn to from-pstn-prefix-cid and test.
If the call fails, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.
Sorry, it appears that the spaces in set(CALLERID(num) ... may have caused trouble.
But I also didn’t know that your provider is sending E.164 format.
If you want to show 914086346448 then try
[from-pstn-prefix-cid]
exten => _.,1,NoOp(Entering user defined context from-pstn-prefix-cid in extensions_custom.conf)
exten => _.,n,set(CALLERID(num)=9${CALLERID(num):1})
exten => _.,n,Goto(from-pstn,${EXTEN},1)
or if you want to show 94086346448 then try
[from-pstn-prefix-cid]
exten => _.,1,NoOp(Entering user defined context from-pstn-prefix-cid in extensions_custom.conf)
exten => _.,n,set(CALLERID(num)=9${CALLERID(num):2})
exten => _.,n,Goto(from-pstn,${EXTEN},1)