from-outside as a Macro

from-outside must remain a context as all the inbound trunks need a context to declare. I just read through your thread and believe I have a better solution for you. The nature of your problem is not much different than one I had with 10 digit callerID and the customer connects directly to the PSTN. If the customer dials 11 digits on a call designated within a local calling area, it will fail or the caller pays a toll depending on the area. If the customer dials 10 digits and its long distance the call again fails. I needed a way to intelligently distinguish between a local call an LD call, and modify the dial pattern accordingly so that the customer can seamlessly press redial on their phone and connect a call. I have an agi-script based on php-agi that looks up a number and either strips or adds digits to the pattern depending on whether or not there is a match. In my case, it looks up a 10 digit pattern in a database of local npa nxx and returns a 7 digit pattern. I then match on length, if it is 7 digits then send the original 10 to the pstn, if the result is still 10 digit add a 1 in front of it to send 11 digits.

I think your solution is best handled in the sending side of the dialing versus modifying callerid(num). Just fix it for them no matter how they choose to dial it, even if they press 644 manually. In your case you might not even need the full agi database if all _644. is subject to the same behavior, just have an outbound pattern of _644XXXXXXX,1,Dial(SIP/provider/0${EXTEN:2}).

Its generally not a good idea to alter callerid(num) as that changes entries in your CDR. You never know when you need those CDR records as some sort of legal proof or proof to authorities something happened (an employee/customer is getting death/stalking/rape threats at work). If you engage in the activity of altering callerid(num) the integrity of the CDR could be argued away in court as 'tampered evidence subject to human error and thusly accusing the wrong defendant'.