December 09, 2018, 06:21:19 pm *
Welcome, Guest. Please login or register.
News:
 
   Forum Home   Search Login Register OBiTALK  
Pages: [1]
  Print  
Author Topic: WARNING: The new SIP GV CallerID has changed  (Read 6082 times)
azrobert
Hero Member & Beta Tester
*****
Posts: 3653


« 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 might stop working with the new firmware.
« Last Edit: May 08, 2018, 07:57:05 am by azrobert » Logged
Taoman
Hero Member
*****
Posts: 1153


« Reply #1 on: May 07, 2018, 11:16:09 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.
Logged
LTN1
Hero Member
*****
Posts: 515


« Reply #2 on: May 08, 2018, 05:54:09 am »

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....
Logged
aberson
Newbie
*
Posts: 8


« Reply #3 on: October 04, 2018, 08:41:23 am »

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.
Logged
Abestock
Newbie
*
Posts: 11


« Reply #4 on: October 04, 2018, 12:12:59 pm »

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.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC