The Dreaded +1 is back

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

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

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.

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

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… :frowning:

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?

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

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

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

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 [[email protected]:2] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CALLED_BLACKLIST=1") in new stack -- Executing [[email protected]:3] Return("SIP/fpbx-1-2e4ea3ce-00000000", "") in new stack -- Executing [[email protected]:3] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CDR(did)=5557778888") in new stack -- Executing [[email protected]: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 [[email protected]:5] Set("SIP/fpbx-1-2e4ea3ce-00000000", "__CALLINGPRES_SV=allowed_not_screened") in new stack -- Executing [[email protected]:6] Set("SIP/fpbx-1-2e4ea3ce-00000000", "CALLERPRES()=allowed_not_screened") in new stack -- Executing [[email protected]:7] Goto("SIP/fpbx-1-2e4ea3ce-00000000", "timeconditions,1,1") in new stack

Phone numbers changed to protect the innocent :slight_smile:

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

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

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 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)

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.

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?

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

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?

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.

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.