How to block the call id per call using *67
RonR:
Quote from: Obitalk on March 24, 2011, 05:48:47 pm
1. If you want to block ALL callers, you can set
your SP1/2 (where your GV account is configured) InboundCallRoute= (blank)
What would be the behavior of the Obi Unit ? I assume that it won't ring the phone connected to the Obi Unit. What would the party who dialled the SP1 line hear ?
The behavior of the OBi unit and what the party who called hears would appear to be unchanged.
Leaving SP1 -> X_InboundCallRoute (where my GV account is configured) blank is identical to having it set to ph on my OBi.
EDIT : Looks like obi-support2 actually meant : InboundCallRoute= ()
Obitalk:
Thanks for the input RonR and Obi Support 2
Just out of curiosity, since I have two Obi's connected to the same Broadvoice phone number wonder what would be the impact of setting the inbound call route to () on the remote obi. I hope the Obi in USA would ring and the remore Obi wouldn't ring. At least I will have to experiment with it to find out. Anyone have any thoughts ?
Thanks
obi-support2:
It is correct that a blank in InboundCallRoute implies {ph}. To block all callers you must specify explicitly an empty route, such as this: {}.
() works as it implies {()} or {}. Thanks for noting this.
Regarding two devices registering to the same number w/ Broadvoice, it all depends on whether Broadvoice can simultaneously fork the call to both devices. BV will not take into consideration that one of the OBi is rejecting the call and therefore sends the call to another OBi (in other words, hunting for an answer from one of the registered devices). You might want to check with BV to see if you can turn on simultaneous call forking.
Obitalk:
I'm happy to state I have implemented the {()} on the inbound call route on the remote Obi.
Now only the Obi in the US rings. (Before implementing this, both the US based Obi and Remote Obi rang simultaneously.)
Now the remote Obi is only used to make outgoing calls and I have a GV number for incoming calls.
Obitalk:
Thanks RonR, QBZappy and obi-support2 for your contributions and help in resolving this issue.
Navigation
[0] Message Index
[#] Next page
[*] Previous page