I’m not sure how this worked with Flowroute sending you E.164. This pattern match won’t catch them because it doesn’t match their pattern. You’re missing the + so if you want to do this it’s
Though I’m not sure why you’re removing the first 2 characters and then returning 12, how does that make sense? If this was a NXXNXXXXXX you would have ended up with XNXXXXXX result. If it was 1NXXNXXXXXX you would have XXNXXXXXX and if this was a E.164 it would skip it. Based on your pattern matching/manipulation. If it was an International number it would be skipped too or with the + adjustment it would strip the + and 1 extra digit then only return 12. For International that will make the number invalid as it does the others as well.
Your patterns should be more targeted for what you are actually matching and not just random catchalls that can screw with things. What is below is all you need to take E.164 based US/Canada DIDs and make them 10 digits.
I know you know this, but the morning’s coffee probably hasn’t kicked in yet. He’s matching on the DID (which I guess does not come with a + ) but manipulating the caller ID (which does). However, your points are valid: this will only work for US domestic caller IDs that start with +1. Why the from-pstn-e164-us context doesn’t work for this, I don’t know, but suspect it’s because the calls aren’t going through the prescribed context at all. If you check the crosspost on pbxinaflash you will see he has a convoluted setup and hasn’t shared any logs yet, so who knows what’s really going on.
So the OP doesn’t show anything looking at the PAI header for CallerID details so they’ll get what is presented in the From header. As you can see, all formatting is E.164 so you need to have pattern matches against the DID and/or CallerID that include a + at the start of them.
So this pattern that the OP has presented will ignore anything in the E.164 format because it’s missing the +. This will match against any DID in the INVITE header that starts with 0-9 and has any number of digits including a single digit since ! matches everything from the start not just after the X.
Yes, the OP is trying to manipulate the CallerID number but only if it matches the DID pattern they have which Flowroute DIDs will not so the CallerID is never touched.
The repeated log lines are typical for deployments that started before FreePBX added logging in the mainstream gui, the solution will likely be apparent with
I have no idea how to fix my logging duplicates unless it doubles when I have the cli open and reporting?
As expected, using from-pstn-e164-us removes the “+”. It still leaves the “1”, so I get 11 digit delivery. I can, obviously live with that since redial works, but “before” I was getting 10 digit delivery and my phonebook entries are set to recognize 10 digits. Avantfax also would like 10 digits so that I can use DID routing.
I suppose I should leave well enough alone; however, is there an easy fix to drop the “1” without mangling the (very) rare international call I receive? I’ll even settle for mangling the international calls .
Why are we not seeing the custom dialplan context you posted originally being hit in this debug? Everything shows to be hitting from-pstn.
This is the first match in the from-pstn-e164-us
exten => +1NXXNXXXXXX/+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2})
exten => _+1NXXNXXXXXX/_NXXNXXXXXX,2,Goto(from-pstn,${EXTEN:2},1)
This matches on an E.164 INVITE DID and From User. The way flowroute sends things. It strips the +1 of the CallerID number and the +1 from the INVITE DID.
So a call that would match +13132224444/+12124445555 would have the CALLERID(number) set to 2134445555 and the inbound route would have to match 3132224444
Show us that is or isn’t happening when using that context.
If you never paste your logs, you will continue to be encouraged to, is it hard to understand that otherwise “nobody knows” ?
Your logs are "twice " in /var/log/asterisk/full ,and that’s because you have two logfile definitions to /var/log/asterisk/full in two/etc/asterisk/*logger* files
dicko,
I have what was installed by default. I’m happy to edit a file, but I still don’t know what file to edit to remove the duplicate entry creation.
Oddly, from-pstn-e164-us delivers 10 digit #s to all of my SIP phones. My dahdi line - which is the handset I look at most and have been using - still shows 11 digits.
In other words, extension 2000 (a Yealink) shows Andrew - Cell and the 10 digit number when I call in
extension 1000 (a handset connected to my TDM800P) shows Andrew - Cell and 1-800-555-4444.
Looking through all the logs, the +1 has been completely dropped.
So the question is what setting in my dahdi config has the +1 being shown?
Thanks for everyone’s help. I’m not sure I can expect this one to be solved.