The Dreaded +1 is back

deanot26508 · May 11, 2013, 12:42am

I have been running using a context=from-pstn-e164-us which has been stipping the +1 from the numbers leaving me with a 10 digit number.

Since the core update I did last night, the dreaded +1 has returned. I looked at all of my trunks and they are still using the same context=from-pstn-e164-us, as they did before.

Can anyone shed some light on this for me? according to my directory structure, the file extension_additional.conf has been over written with yesterdays date and time of the core upgrade, which is probably nothing to be concerned about as asterisk updates this file anyway.

Looking at the file extensions.conf, I see the date is quite old and has not been touched, and the following code still exists within the file.

[from-pstn-e164-us] exten => +1NXXNXXXXXX/+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2}) exten => _+1NXXNXXXXXX/_NXXNXXXXXX,2,Goto(from-pstn,${EXTEN:2},1) exten => +1NXXNXXXXXX/+X.,1,Set(CALLERID(number)=011${CALLERID(number):1}) exten => _+1NXXNXXXXXX/_011X.,n,Goto(from-pstn,${EXTEN:2},1) exten => _+1NXXNXXXXXX,1,Goto(from-pstn,${EXTEN:2},1) exten => [0-9+]./+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2}) exten => _[0-9+]./_NXXNXXXXXX,n,Goto(from-pstn,${EXTEN},1) exten => [0-9+]./+X.,1,Set(CALLERID(number)=011${CALLERID(number):1}) exten => _[0-9+]./_011X.,n,Goto(from-pstn,${EXTEN},1) exten => [0-9+].,1,Goto(from-pstn,${EXTEN},1) exten => s/+1NXXNXXXXXX,1,Set(CALLERID(number)=${CALLERID(number):2}) exten => s/NXXNXXXXXX,n,Goto(from-pstn,${EXTEN},1) exten => s/+X.,1,Set(CALLERID(number)=011${CALLERID(number):1}) exten => s/_011X.,n,Goto(from-pstn,${EXTEN},1) exten => s,1,Goto(from-pstn,${EXTEN},1)

Anyone have a clue as to what has changed? or what to look for?

Asterisk version : 10.12.0
FreePBX Firmware : 2.210.62-5
FreePBX Service pack : 1.0.0.0

The_Buck · June 15, 2013, 4:17am

It doesn’t get more better then that. Thanks a lot. This will work for FreePbx 2.8x right?

tm1000 · June 13, 2013, 4:19pm

I’ll do one better. I will write this functionality into the new sipstation module. That should help out. Once I get to that step I will figure out a working dialplan and send it your way for the time being.

johnjces · May 11, 2013, 1:15am

try putting it under your Trunk, Edit SIP Trunk and under PEER Details.

deanot26508 · May 11, 2013, 1:30am

Thanks for the reply, that is where it is now, always has been. Not sure what happened, but it worked up until yesterday, which is when my headaches begun…lol

I would not mind so much, but I use a lot of 10 digit numbers that are blocked, adding the +1 infront of the 10 digit is allowing them in again…

johnjces · May 11, 2013, 5:09am

A final thought, you might try and change something and change it back in your trunk config, save it and Apply the config and see what happens. Had a similar incident some time ago and that rewrote the the trunk config and then of course the reload. If that doesn’t work then… I dunno.

What version of FPX and Core?

deanot26508 · May 11, 2013, 1:50pm

I will give that a try…
Asterisk version : 10.12.0
FreePBX Firmware : 2.210.62-5
FreePBX Service pack : 1.0.0.0

deanot26508 · May 11, 2013, 1:54pm

I tried that, same result. For the life of me, I can’t figure this out… very weird.

stonet · May 12, 2013, 12:31pm

Post your CLI log that should show what’s happening.

deanot26508 · May 12, 2013, 9:09pm

Interesting, I can see the script is still using “from-pstn” when my trunk “Peer Details” are as follows.


context=from-pstn-e164-us
type=peer
insecure=very
qualify=yes
sendrpid=yes
trustrpid=yes
dtmfmode=rfc2833
username=xxxxxxxx
secret=xxxxxxx
host=trunk1.freepbx.com
disallow=all
allow=ulaw&g729

and here is the Cli output showing obvious useage of another “context=from”


Executing [s@app-blacklist-check:2] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CALLED_BLACKLIST=1") in new stack
    -- Executing [s@app-blacklist-check:3] Return("SIP/fpbx-1-2e4ea3ce-00000000", "") in new stack
    -- Executing [5557778888@from-pstn:3] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CDR(did)=5557778888") in new stack
    -- Executing [5557778888@from-pstn:4] ExecIf("SIP/fpbx-1-2e4ea3ce-00000000", "0 ?Set(CALLERID(name)=15557778888)") in new stack
[2013-05-12 16:52:11] WARNING[4545]: func_callerid.c:817 callerpres_read: CALLERPRES is deprecated.  Use CALLERID(name-pres) or CALLERID(num-pres) instead.
[2013-05-12 16:52:11] WARNING[4545]: func_callerid.c:817 callerpres_read: CALLERPRES is deprecated.  Use CALLERID(name-pres) or CALLERID(num-pres) instead.
    -- Executing [5557778888@from-pstn:5] Set("SIP/fpbx-1-2e4ea3ce-00000000", "__CALLINGPRES_SV=allowed_not_screened") in new stack
    -- Executing [5557778888@from-pstn:6] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CALLERPRES()=allowed_not_screened") in new stack
    -- Executing [5557778888@from-pstn:7] Goto("SIP/fpbx-1-2e4ea3ce-00000000", "timeconditions,1,1") in new stack

Phone numbers changed to protect the innocent

deanot26508 · May 13, 2013, 10:11pm

Anyone else have any insight on this? Seems like I am not the only one having this issue now.

The_Buck · May 13, 2013, 11:10pm

I have posted the fix that I used for now. I am looking into why the better solution does not work. My preferred method (better solution) is to use the smarter code that checks the number for the +1 and not strip the number if that is not present. This simple one strips the 1st 2 digits no matter what.
[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},) type = friend

The fix is posted here:
http://forums.freepbx.org/forum/general-help/stripping-1-from-cid-has-changed

deanot26508 · May 17, 2013, 10:44pm

I appreciate your work and help, I am still not sure why the code was changed to mess with this standard context. Maybe a bug that needs looking into by whomever the code belongs to?

The_Buck · June 8, 2013, 9:39pm

The tempory fix no longer works. I think this might have something to do with sip stations or shmooze the our provider. Today or dtmfmode=rfc2833 part of our context stopped working from the automatic setup provided from the account key. I had to change this to dtmfmode=auto to get this to work and allow callers to press keys during the IVR. Also the callers were no longer directed to the right queue due to the 1 returning back to the CID.

Does anyone know how to strip 3 digits using this context:
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)

deanot26508 · June 9, 2013, 2:50am

Really? Why do they keep changing things? I understand that changes are for the better, but breaking a working system is not for the better.

deanot26508 · June 9, 2013, 2:55am

Saying that… I just did a test call to my Sipstaion dids, and it is still formatting with a 10 digit number. I thought, maybe after the new upgrade of freepbx framework, maybe it was the cause, but I am not affected.

Weird?

tm1000 · June 10, 2013, 3:48pm

All of the things you say are changing are things we aren’t touching.

The_Buck · June 11, 2013, 3:35pm

Thank you for the response. Well if nothing has changed on Schmoozecom’s end. How come this method no longer works? Even better, how do we fix it?

For me, the code only now removes the +. How do I remove one more digit?

deanot26508 · June 13, 2013, 7:47pm

I think that is where the changes have been happening, but as I said, mine is still working. I just don’t understand why, when called for the context=from-pstn-e164-us, I see it is being looked at but ignored by the system.

I appreciate you looking into this, but it was not something I nor The_Buck did, we changed nothing on our end, but with updates it had changed.

sholight · June 27, 2013, 1:54pm

Hey,
Just wanted to see if you’ve had any luck with a fix for removing the (+)1 from inbound SIPStation CID? I too have been having the same issue since the server switch a few weeks back. Like the rest of the gang I had been using the from-pstn-e164-us context to accomplish this but it no longer removes the 1. This in-turn has wreaked havoc on our ability to deliver known CID lookups from Superfecta and is causing daily complaints from our end-users. As a result of the complaining we have discussed doing a phonebook export and adding the 1 prefix to all the numbers (not something I’m looking forward to doing). However, before I take rash action I thought I would check in here and see if a solution was close to being implemented. Hopefully things are progressing with a SIPStation fix and I can keep the dogs at bay a little longer.