News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

WARNING: The new SIP GV CallerID has changed

Started by azrobert, May 07, 2018, 09:48:26 PM

Previous topic - Next topic

azrobert

The new SIP GV is prepending a plus sign to the CallerID.
The CallerID will look like this: +18005551212

If you are blocking or routing calls based on CallerID, it will might stop working with the new firmware.

Taoman

Quote from: azrobert on May 07, 2018, 09:48:26 PM
The new SIP GV is prepending a plus sign to the CallerID.
The CallerID will look like this: +18005551212

If you are blocking or routing calls based on CallerID, it will stop working with the new firmware.


Interestingly, forking to Nomorobo in X_InboundCallRoute still seems to work. I used firertc and spoofed a known spammer number and Nomorobo stopped it. Call history showed "ui=+17035747035" but it worked.

LTN1

On my PBX system, I have the option of using the ending numbers--and find that to be better with different providers that pass on numbers with or without a 1 or +1. So for +18005551212, I just use route for the numbers ending in 8005551212 instead of using route with the numbers beginning with....

aberson

Thanks for this thread!  It helped me!

My inboundcallroute suddenly stopped working a few months ago, and a few nights ago I discovered this thread which turned out to be the problem.   (discovered b/c it was linked from here: http://www.obitalk.com/forum/index.php?topic=13969.0)

Unfortunately I had no default route to ph, all my routes were based on caller ID, so it seemed as if the GV integration had just stopped entirely with no explanation.  Turns out the call logs don't show a call if it ends up having no destination to ring to, which is extremely frustrating.

Also frustrating - at one point I noticed the caller ID had + in it, so I tried adding that to my inboundcallroute and it didn't work.  I also tried adding "x." before the area code, which as I understand is supposed to be a wildcard... and that didn't work either.   I think these were both just cases of the device being in a flaky state and requiring a manual reboot before the new setting would truly kick in (even though the local web GUI showed the new setting had been pulled down from obiexpert)

In general it seems 3.2.2 has a few flaky/intermittent bugs, which makes it tough to troubleshoot.

Abestock

I noticed that issue using my cellphone a while back. Depending on the carrier, calls would come in as +1(+10 digits), 1(+10 digits) or just a 10 digit number as per the NANP. I use the AA feature, so in my case I added +1800...., 1800.... and 800 .... to cover all variations. Works perfectly.