Setting X_InboundCallRoute to block direct calls to forwarding number on Obi200
Taoman:
Think about what you're doing here. On the one hand you're trying to block calls made directly to your VoIP provider's DID (presumably Callcentric). But you also want calls made to your GV number (that forwards to that same Callcentric number) to ring through. ???
Ask yourself this question. What number is Google Voice using to forward incoming calls to your Callcentric DID? It's the one you're blocking so why would you expect incoming GV calls to ring through?
There are different methods to try and accomplish your goal. You could make a block list of individual numbers on your OBi itself (see link in post above). Personally, I would do it with Callcentric's phone book, groups, and call treatments.
Keep in mind that Google Voice "ignores" (you're welcome, Steve) early media. This means that "most" of the Callcentric call treatments won't work for incoming GV calls. However, they will all work for incoming calls directly to your Callcentric DID number.
SteveInWA:
Quote from: drgeoff on October 08, 2015, 09:23:37 am
Perhaps I misunderstand but how are you expecting your OBi to differentiate between a call coming in to SP3 directly from a caller and one coming in to SP3 as a forward from GV?
Google Voice users can control the caller ID that is sent to forwarding phones. You can decide to either have GV send the calling party's CID (the phone number of the person who called your GV number), or you can have GV send its own number (your GV number) as the CID.
This is useful for people who want to know, for example, if someone calling their forwarding cell phone number is calling them directly on the cell phone, or forwarding from GV.
You can toggle this setting here: https://www.google.com/voice#callsettings
So, you'd set GV to send the calling party's CID, and, on the OBi, block the SIP ITSP's CID.
The only "monkey wrench" might be an obscure issue whereby calls forwarded over SIP contain two numbers: the CID of the original calling party, and the CID of the number that is forwarding the original party's call (this is in the "SIP diversion header" field). I don't know if OBi devices see this information, which could cause all calls to be discarded, but a simple test should determine if it does or doesn't matter.
drgeoff:
Quote from: SteveInWA on October 08, 2015, 09:40:54 am
So, you'd set GV to send the calling party's CID, and block the SIP ITSP's CID.
From your explanation I expected you to say "Set GV to send your GV number as CID and set the OBI's X_InboundCallRoute to reject everything else."
But then the CNAM ability is gone which was the whole point of forwarding to SP3 in the first place.
So, if GC sends the calling party's CID, back to my question of how does the OBi distinguish?
SteveInWA:
Quote from: drgeoff on October 08, 2015, 09:47:29 am
Quote from: SteveInWA on October 08, 2015, 09:40:54 am
So, you'd set GV to send the calling party's CID, and block the SIP ITSP's CID.
From your explanation I expected you to say "Set GV to send your GV number as CID and set the OBI's X_InboundCallRoute to reject everything else."
Well, that would work, too, but then all inbound calls would have the same (GV number's) CID, which is pretty useless from a "who is calling me?" perspective. :P
Taoman:
Quote from: SteveInWA on October 08, 2015, 09:40:54 am
So, you'd set GV to send the calling party's CID, and, on the OBi, block the SIP ITSP's CID.
How would you block the ITSP's CID on the OBi? ??? Wouldn't the calling party's CID be coming through and not the ITSP's CID?
Navigation
[0] Message Index
[#] Next page
[*] Previous page