There is an admin guide (linked in my notes) that helps to understand what the OBi can do, but it does not walk you through it. You must study it, learn, and then devise your own solution. And there are forum and blog posts that offer some help. I studied these, discovered how the OBi can be used, and then put together the most elegant dial plan I could. My notes capture what I learned and how I applied this, but they are not a tutorial (there is also a linked dial plan tutorial but I never read it... it came out too late). If you are clever, you can study my dial plan, understand it, and copy/adopt it for your needs. Most of the heavy lifting behind it has been done already.
You can also use Anveo as failover for GV.
For example, your PHONE1 Port Primary Line would be Trunk Group 1:
TG1 Trunk Group1 = sp4,sp1,pp1,bt1
TG1 (Mtg1) = ((Msp4)|(Msp1)|(Mpp1)|(Mbt1))
Where sp1 is Anveo, sp4 is GV, pp1 is OBiTALK, and bt1 is Bluetooth cell phone. All calls go out GV, except 911 and OBiTALK. 911 goes out Anveo. OBiTALK goes out OBiTALK. If GV is down, calls will failover to Anveo. If Anveo is down, 911 will failover to Bluetooth. I prefer to relegate GV to sp4; you can keep it on sp1.
It all starts with knowing/defining your outbound dialing requirements and mapping the respective digit map for each trunk (Msp1), (Msp4), (Mpp1), and (Mbt1). The rest can be configured easily enough, given a working example.
The shortcut approach tends to misplace dial plan elements in the 'wrong' digit map or call route and/or cram everything into the PHONE Port digit map(s) which otherwise do not need to be changed once configured for 'their' outbound dialing requirements.
OE