Please note that I am not just fixing this issue I am adding numerous fixes and additions to the modules, such as E911 address updates and failover (that you can change in the module)
So this isn’t an overnight change
I dont think so.
Let me try to address some of these questions and changes. There have been some changes due to issues brought up by customers.
First off, I do not believe the delivery of DIDs has changed in SIPStation. They have been delivered as 10 digit DIDs and have thus not required the use of the from-pstn-e164-us context. The context that the SIPStation module configured is in fact the from-pstn context.
An issue that was addressed from customer feedback a few weeks ago was that the CallerID Numbers were being sent in e164 format. Since we don’t yet have a way for the user to configure their desired format (which is on the list of things we want to do), we had to make a decision and in order to standardize the format on the ‘most widely’ used CID format, we chose an 11 digit CID or in the case of an international number, an 011 prefixed CID. This was done so that the majority of customers would get a CID consumable on their phones that they could just hit the “Callback” button and make a call based on their Caller ID, 11-digit being more ‘universal’ then 10 digit.
It appears from this thread that some of you chose to implement the from-pstn-e164-us context to solve the previous problem of receiving an e164 formatted Caller ID and thus getting it formatted in a more consumable way. For that I express my apologies since, as it turns out, the from-pstn-e164-us context in fact delivers you a 10 digit Caller ID thus the reason that you ran into the problem.
These two lines of that context is what would have been catching your numbers and consuming them:
exten => _[0-9+]./_+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2})
exten => _[0-9+]./_NXXNXXXXXX,n,Goto(from-pstn,${EXTEN},1)Since we have normalized the format to 11 digits, and hadn’t assumed the use of this context (since that is not what the SIPStation module configured), your calls would be caught by this section:
exten => _[0-9+].,1,Goto(from-pstn,${EXTEN},1)Which does nothing for your Caller ID.
We could modify that context to add the following line which would address the problem, but of course that could break someone else. However, it does seem appropriate to keep more consistent but we would most likely only add it to 2.11 since the general stance on ‘questionable’ changes is to avoid changes it the oldest supported release (2.10 in this case). The added line would be:
exten => _[0-9+]./_1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):1})The real solution is for us to make this configurable in SIPStation so you can have the CallerID delivered ‘raw’ (e164), or normalized choosing 10 or 11 digits for North American numbers and as mentioned, it’s on the list.
Please also note, for any of you trying to follow the flow of from-pstn-e164-us, it is very confusing. You effectively have what might be considered ‘self modifying code’ in as far as, as you change the CallerID within the dialplan, it actually effects which line of the context will be next matched, so it may appear there are errors in the existing dialplan or even my suggested fix, which I’m pretty sure there are not (though … there are always bugs 
)
Thanks for the information on how this works.
I have applied the context to my extension_custom/conf and sip_custom.conf and in the following ways with no luck:
Alone:
exten => _[0-9+]./_1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):1})
With the current context:
[from-ptsn-custom]
exten => _X!,1,GotoIf($["${CALLERID(num):0:2}" != “+1”]?noplusatstart)
exten => _X.,n,NoOp(Changing Caller ID number from ${CALLERID(num)} to ${CALLERID(num):2})
exten => _X.,n,Set(CALLERID(num)=${CALLERID(num):2})
exten => _X.,n,Set(CALLERID(ANI)=${CALLERID(num)})
exten => _X!,n(noplusatstart),Goto(from-trunk,${EXTEN},1)
exten => _[0-9+]./_1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):1})
type = friend
In the just "Incoming Settings" for each trunk"
exten=> _[0-9+]./_1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):1})
Am I not applying this correctly? I have reloaded and restarted Asterisk for each process and even rebooted the server during each change and I still have a 1 for my incoming CID’s.
Let me first say thank you to yourself and to Philippe for responses and hard work on FPBX. I really appreciated Philippe post which sort of helped clarify the issue at hand.
On my end of things, I will inform my users to take a deep breathe and deal with the inconvenience a little longer as a solution is in the works. I personally would rather sit tight for an update from you guys then trying to make contextual changes that could break something else and create a new headache.
On your end of things I can only say thank you. In the short time that FPBX, SIPStation, and Schmooze have been together some great things have started to happen. The addition of Failover support (even in it’s current state) is fantastic and a real plus for the service. I’m excited to see it integrated into module. As for E911 address updates and of course CID context control, they are welcomed new features. Although I can’t wait to see them, I, like my users will employ a little patience and leave you to polish the code.
Keep up the awesome work and thank you for your support.
Cheers!