I couldn't find any info on this searching the forum.
Is there a way to do rollover lines with the obi110? In other words, if you have 4 POTS lines connected to a multiline phone, and you wanted to port those 4 lines to 4 obi110 units (google voice?), can you make it so that if someone calls your main phone number, it bumps to your next number, and then your next number, and then your next number (or in other words, bumps to your next obi, then the next, then the next).
Or perhaps there is a different way to deal with entirely.
You can use the CallForwardOn Busy/NoAnswer feature of the OBi on each unit. You might even think of forking the call over the OBi's for simultaneous ringing if this call strategy works for you.
Thanks,
OK, so I don't think I would have it forward a busy over to all three of the other lines because that would be ugly to just see all those lights go off at once.
But, a forward on busy to the next obi in the series is a no brainer.
Next question, if you do a forward on busy, and then the next line is also busy, can that obi forward to the next? In other words, can it forward a forward?
gobluelou,
Good one, never been asked before I think.
I can not test it here, however if the call is passed to OBi#2 the CallForwardOn Busy/NoAnswer feature of the OBi should cycle through to the next OBi in series until it is picked up or goes to GV VM on the last OBi.
It would be a simple test for someone with several OBis.
Cool, thanks.
So, the $100 question is do I buy two more units to test it out!
gobluelou,
You might get lucky. There are a few good Samaritans on this board who may give you your answer if you wait a while, or the OBi people might chime in with a confirmation since it is basically a pre sales question.
Quote from: gobluelou on September 12, 2011, 06:15:19 PM
if you do a forward on busy, and then the next line is also busy, can that obi forward to the next? In other words, can it forward a forward?
The OBi doesn't really 'forward' calls. It makes a totally new outgoing call and bridges the old incoming call to the new outgoing call. Both individual calls remain in effect, 'spliced' together. Consequently, there should be no problem chaining a call on and on.
An afterthought,
I'm not certain what CID you will end up with on the calls being forwarded. OBi v 1.3 new feature spoofs CID on a forked call if it is passed over the OBi to another OBi or OBiAPP. I'm not certain if it also passes CID on forwarded calls. I can not test this for you.
The change in v1.3 was for bridged calls, not just forked calls:
- Allow Caller-id spoofing for calls bridged via OBiTALK service.
Consequently, CallerID is passed on forwarded calls via the OBiTALK service.
Keep in mind that each OBi is limited to 4 simultaneous bridges.
It will also be necessary to disable Call Waiting on the PHONE Port and OBiTALK service MaxSessions will have to be increased past 2 (at least in OBi #2).
Now, having clarified some of the OBi's features and limitations, I think this whole idea hasn't been thought through:
If four OBi's each have different PSTN telephone numbers from Google Voice, the first (main) number can only handle a maximum of 2 sessions. After two calls to the main number, callers to that number will get a busy. The only way the other three Google Voice numbers will be used is if someone explicitly calls them. Only the first two OBi's will get used for calls from the main number.
If you use a VoIP provider on the first OBi that supports four sessions on the DID associated with it, then the second, third, and fourth caller can be passed off to subsequent OBi's as each OBi's PHONE Port becomes busy. In this case, you ony have one main number and no additional numbers to deal with. All calls come into the first OBi only.
It's also an easy task to route outgoing calls from the other three OBi's through the first OBi that has the VoIP provider configured on it.
Quote from: RonR on September 12, 2011, 07:34:25 PM
If four OBi's each have different PSTN telephone numbers from Google Voice, the first (main) number can only handle a maximum of 2 sessions. After two calls to the main number, callers to that number will get a busy. The only way the other three Google Voice numbers will be used is if someone explicitly calls them. Only the first two OBi's will get used for calls from the main number.
This scenario is possible if you get more than two calls at the same time. The third simultaneous call will get the busy or GV VM. The timing of the calls is important. With call waiting disabled on the OBi#1, the second call should be call forwarded (rolled over) to the next OBi, freeing up the second voice channel on GV. In a home office/small business setup it might be very unlikely to get that many calls at the same time. Worst case the missed call will go to VM. It probably is a workable solution considering the minimal costs of using GV and likelihood of receiving that many simultaneous calls.
Quote from: QBZappy on September 12, 2011, 08:34:07 PM
With call waiting disabled on the OBi#1, the second call should be call forwarded (rolled over) to the next OBi, freeing up the second voice channel on GV.
It doesn't work that way. Here's what happens:
Call number 1 goes to the PHONE Port of OBi #1.
Call number 2 gets
bridged via the OBiTALK service to OBi #2 and its PHONE Port. This does NOT free up the second voice channel on Google Voice.
At that point things look like this:
GV call #1 -> OBi #1 SP1 -> bridge to OBi #1 Phone Port
GV call #2 -> OBi #1 SP1 -> bridge to OBi #1 OBiTALK service -> OBi #2 OBiTALK service -> bridge to OBi #2 Phone Port
Only when a call is terminated does that Google Voice session get freed up. Bridging it to somewhere else doesn't change anything.
I'm reading this rather interesting thread and I'm confused. If the OP Port his 4 POTS Line to GV, wouldn't the call end up in Voicemail after 25 secs [approximately 5 rings (each ring is equivalent to 5 seconds)]? In other words, if the call is transfer on no answer after 3 rings from OBi-1 to OBi-2, OBi-2 would only have 5-10 secs to answer, before the call ends up in VM. Is my thinking correct?
Maybe the OP might consider using a Asterisk system such as PBX In A Flash (PIAF), which has the free GV calling feature and somehow has managed to disable the GV Voicemail (unless explicitly enabled). He can take advantage of the call hunt (and other features) feature of Asterisk 1.8.X. You can setup PIAF on very inexpensive hardware.
EDIT: Why is it that Asterisk can disable GV Voicemail and the OBi cannot accomplish the same?
While QBZappy mentioned Call Forward on No Answer, it really has no place in the discussion (lines roll over on busy conditions, not no answer condiitions). Also, as I explained over the last several posts, you can't accomplsih more than a two-line scenario with rollover from line 1 to line 2 using Google Voice. Assuming you're using Call Forward on Busy to accoplish this, the second call being transferred to the second OBi should occur pretty quickly.
The question about PIAF being able to disable Google Voice voicemail has been raised before, but no answer has ever been given why the OBi isn't also able to do so.
Quote from: RonR on September 13, 2011, 09:31:28 AM
While QBZappy mentioned Call Forward on No Answer, it really has no place in the discussion (lines roll over on busy conditions, not no answer condiitions). Also, as I explained over the last several posts, you can't accomplsih more than a two-line scenario with rollover from line 1 to line 2 using Google Voice. Assuming you're using Call Forward on Busy to accoplish this, the second call being transferred to the second OBi should occur pretty quickly.
Hi Ron,
Call Forward on Busy/No Answer is a feature and might be relevant for some users. In the context of "rollover", I see what you mean that the call is bridged to another OBi when user on OBi#1 is talking. If we see it as a feature it becomes "rollover"+"call hunting". Use scenario: No one in the room to answer OBi#1 Call Forward to OBi#2. If I'm in another room and hear OBi phone ringing, I will not need run over to the OBi#1 to answer if I know that OBi#2 right next to me will ring in a moment. We could of course CF to a remote number. This is another useful way to use the OBi. We can combine both features as it creates redundancy in the call handling strategy.
QBZappy,
You've strayed from the OP's request to have one telephone number be able to accept up to four incoming calls on a multi-line telephone. If all four calls are coming into a 4-line telephone, or multiple 4-line telephones as would probably be the case in a typical office environment, it doesn't make sense to have the calls roll over on no answer.
I don't believe the OP's request can be satisfied practically using Google Voice, but it's an absolutely trivial task to accomplish using a VoIP provider that supports four channels on a single number. The end result should be very difficult to tell apart from a telephone company provided installation (and a whole lot less expensive, up front and recurring).
Assuming:
Four OBi's with OBiTALK numbers of 200000001, 200000002, 200000003, and 200000004 respectively.
OBi #1 configured with a VoIP provider on SP1 capable of 4 simultaneous inbound/outbound sessions.
OBi #1 -> Line 1
================
Voice Services -> SP1 Service -> MaxSessions : 4
Voice Services -> SP1 Service -> CallForwardOnBusyEnable : (checked)
Voice Services -> SP1 Service -> CallForwardOnBusyNumber : PP(ob200000002)
Voice Services -> OBiTALK Service -> InboundCallRoute : {(200000002|200000003|200000004)>(Msp1):sp1},{ph}
Voice Services -> OBiTALK Service -> MaxSessions : 4
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
OBi #2 -> Line 2
================
Voice Services -> OBiTALK Service -> MaxSessions : 4
Voice Services -> OBiTALK Service -> CallForwardOnBusyEnable : (checked)
Voice Services -> OBiRALK Service -> CallForwardOnBusyNumber : PP(ob200000003)
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
Physical Interfaces -> PHONE Port -> DigitMap:
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|<2*>(Mpli))
User Settings -> Speed Dials -> 2 : PP(ob200000001)
OBi #3 -> Line 3
================
Voice Services -> OBiTALK Service -> MaxSessions : 4
Voice Services -> OBiTALK Service -> CallForwardOnBusyEnable : (checked)
Voice Services -> OBiRALK Service -> CallForwardOnBusyNumber : PP(ob200000004)
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
Physical Interfaces -> PHONE Port -> DigitMap:
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|<2*>(Mpli))
User Settings -> Speed Dials -> 2 : PP(ob200000001)
OBi #4 -> Line 4
================
Voice Services -> OBiTALK Service -> MaxSessions : 4
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
Physical Interfaces -> PHONE Port -> DigitMap:
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|<2*>(Mpli))
User Settings -> Speed Dials -> 2 : PP(ob200000001)
Here is an abbreviated setup if you'd like to do a proof-of-concept test using two OBi's and a Google Voice account:
OBi #1 -> Line 1
================
Voice Services -> SP1 Service -> CallForwardOnBusyEnable : (checked)
Voice Services -> SP1 Service -> CallForwardOnBusyNumber : PP(ob200000002)
Voice Services -> OBiTALK Service -> InboundCallRoute : {200000002>(Msp1):sp1},{ph}
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
OBi #2 -> Line 2
================
Physical Interfaces -> PHONE Port -> CallWaitingEnable : (unchecked)
Physical Interfaces -> PHONE Port -> DigitMap:
([1-9]x?*(Mpli)|[1-9]|[1-9][0-9]|911|**0|***|#|**1(Msp1)|**2(Msp2)|**8(Mli)|**9(Mpp)|<2*>(Mpli))
User Settings -> Speed Dials -> 2 : PP(ob200000001)
I imagine you are correct. I just put one of these obi's in my home and got all excited about "what else". It started a nice little run on the forum with a bunch of interesting info which I have enjoyed reading.
After studying the posts, it would appear that GV would work for a two line "rollover" setup since it only supports 2 simultaneous channels.
Would a service such as this, http://www.didforsale.com/home.php which supports 20 channels per did (had to goolge that to figure out it means direct inward dialing number, previously known to me as "a phone number")?
So if you used RonR's detailed flow chart with the above servcie, could you link 4 obi's and have a 4 line phone system (I mean regular old 4 analog line phones) having each of the 4 lines getting calls rolled over to and also being able to place outgoing calls?
Great thread.
I am new to Obi, just ordered mine today.
I too, have 4 business lines to manage. I am not in a hurry to ditch my primary landline though. What do users think of keeping one landline, using call busy forwarding feature on that line to forward to a GV number, and in turn have Obi manage two additional lines? I'd be giving up one line if i read the posts here correctly but I could live with that.
TIA.
I have tried to set up 2 Obi devices in a rollover configuration detailed in previous posts. The rollover to the second device works other than when someone calls and device 1 is busy, I get the Auto Attendant asking me whether I want to continue with the call or gives me other options. I have unchecked the auto attendant option but it still seems to be routing to the auto attendant. Can anybody help?
Quote from: Louie1043 on March 05, 2012, 07:31:16 PM
I have tried to set up 2 Obi devices in a rollover configuration detailed in previous posts. The rollover to the second device works other than when someone calls and device 1 is busy, I get the Auto Attendant asking me whether I want to continue with the call or gives me other options. I have unchecked the auto attendant option but it still seems to be routing to the auto attendant. Can anybody help?
If you configure the OBi's exactly as shown in Reply #15 above, there can be no Auto Attendant answering. For the Auto Attendant to answer, there must be {.....:aa} type rules, and there are none in the configuration illustrated in Reply #15 above.
I suspect the problem is you used the OBiTALK Web Portal and have the OBi(s) listed in the Circle-of-Trust.
Log into the OBi's directly at the IP address returned by dialing ***1 and verify that each OBi is configured as illustrated above.
I did exactly as the post showed in #15 for the 2 Line Google voice setup and I have double and triple checked settings but every time I still get the Obi Attendant. Are there any other Routing settings that could be causing this like in the ObiTalk section or something like that? P.s. I configured everything through the actual IP addresses of the units.
Thanks,
Ryan
Log into the OBi directly (not via the OBiTalk portal) and confirm that OBiTALK Service -> InboundCallRoute is set to ph , which is the default.
If it's not, and you were configuring the OBi directly, just check the Default box, Save and reboot.
If you were configuring on the OBiTalk portal, make sure that OBi #1 is not listed as a Trusted Caller or in Circle-of-Trust. Possibly, your device is failing to sync with the portal.
Quote from: Stewart on March 06, 2012, 09:27:04 AM
Log into the OBi directly (not via the OBiTalk portal) and confirm that OBiTALK Service -> InboundCallRoute is set to ph , which is the default.
If it's not, and you were configuring the OBi directly, just check the Default box, Save and reboot.
If you were configuring on the OBiTalk portal, make sure that OBi #1 is not listed as a Trusted Caller or in Circle-of-Trust. Possibly, your device is failing to sync with the portal.
Thanks guys, it was the inbound call route that kept defaulting to something other than ph even after saving. So the rollover now works on Obi #2. My next question, is there a way to use Obi #2 to route outbound calls through Obi #1. Right now you have to call out from obi #1. When you try to place a call Through obi #2 it just calls obi #1. May not be possible but I think it would be.
Check that on OBi #1:
Voice Services -> OBiTALK Service -> InboundCallRoute : {200000002>(Msp1):sp1},{ph}
where 200000002 is the OBiTalk number of OBi #2.
If no luck, check the Call History of OBi #1 to confirm that the Peer Number logged matches the OBi #2's number.
Quote from: Louie1043 on March 06, 2012, 10:01:22 AM
My next question, is there a way to use Obi #2 to route outbound calls through Obi #1. Right now you have to call out from obi #1. When you try to place a call Through obi #2 it just calls obi #1. May not be possible but I think it would be.
The configuration described in Reply #15 above handles placing calls from OBi #2 though OBi #1.
Have you set:
System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled
in both OBi's to prevent the OBiTALK Web Portal from overwriting the changes you're making directly?
Quote from: gobluelou on September 12, 2011, 03:09:41 PM
Or perhaps there is a different way to deal with entirely.
You might do better implementing this functionality at the VoIP provider, rather than trying to do everything with the Obi.
Voip.ms is reported to be implementing "call hunting" soon.
But are you sure that is what you want? Is it multiple incoming channels (with same phone number) each of which will ring a pool of four phones, where the first to answer gets the call?
If so a possible set up (using voip.ms as an example) would be:
Single incoming DID (supports multiple calls) -> Ring Group -> 4 Obis (or 2 SPA2102s) with each phone/extension registered to a different sub account.
* An incoming call will go to the first phone that picks up.
* Phones not in use for incoming calls can make outgoing calls.
* Calls between the extensions are possible
* If having 4 DID numbers (as opposed to being able to make/receive four simultaneous calls) is important, then all four DIDs could all be routed to the same Ring Group.
This isn't rollover/hunting (all phones ring simultaneously, rather than in sequence) but is a practical set up for a small office. (You can also fake a rollover with timeouts).
The Cisco/Linksys/Sipura SPA2102 supports two lines - I think I read somewhere that the next Obi might support more than one line - so might work out a little cheaper.
You might also want to check the VoIP Tech Chat forum for advice.
http://www.dslreports.com/forum/voip