Forward one Obihai (both inbound and outbound) to another.

[Jean-Charles]

I currently own two Obihais and I was wondering if there was anyway I could have one work as a repeater of sorts. I would like Obihai-1 to ring and make calls as usual, but I would also like it to forward all inbound calls to Obihai-2. Additionally, I would like Obihai-2 to forward all outbound calls through Obihai-1. So, essentially, the second Obihai is an extension of the first.

Can anyone help me with this? I've only ever used the web interface an relied on the obhai defaults.

[RonR]

If you're wanting each OBi to simultaneously ring its own phone plus the phone connected to the other OBi, make the following changes as applicable.

For SP1 Service:

Voice Services -> SP1 Service -> X_InboundCallRoute : {ph,pp(ob200123456)}

For SP2 Service:

Voice Services -> SP2 Service -> X_InboundCallRoute : {ph,pp(ob200123456)}

For OBiTALK Service:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456:ph},{ph,pp(ob200123456)}

For LINE Port:

Physical Interfaces -> LINE Port -> InboundCallRoute : {ph,pp(ob200123456)}

where 200123456 is the OBiTALK number of the other OBi.

[bukzin]

Thanks for the answer.

Anyway you could re-state this in a simple form for us newbies?



Thanks!

[RonR]

If you want calls coming into the SP1 Service to simultaneously ring both OBi's, set:

Voice Services -> SP1 Service -> X_InboundCallRoute : {ph,pp(ob200123456)}


If you want calls coming into the SP2 Service to simultaneously ring both OBi's, set:

Voice Services -> SP2 Service -> X_InboundCallRoute : {ph,pp(ob200123456)}


If you want calls coming into the OBiTALK Service to simultaneously ring both OBi's, set:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456:ph},{ph,pp(ob200123456)}


If you want calls coming into the LINE Port to simultaneously ring both OBi's, set:

Physical Interfaces -> LINE Port -> InboundCallRoute : {ph,pp(ob200123456)}


where 200123456 is the OBiTALK number of the other OBi.

[jimates]

I don't guess it would matter but, with both Obi's set to fork the calls to each other, wouldn't that create a loop on the Obitalk Services.

[RonR]

I don't guess it would matter but, with both Obi's set to fork the calls to each other, wouldn't that create a loop on the Obitalk Services.

It definitely matters and would be a serious problem, but it won't occur:

Voice Services -> OBiTALK Service -> InboundCallRoute : {200123456:ph},{ph,pp(ob200123456)}

Calls from the other OBi only go to the PHONE Port and don't fork.

[Jean-Charles]

I've been playing around with this idea for a bit now and I've now got 2 additional questions:

1) I can get the call forwarding correctly using essentially this method, however when OBi1 calls OBi2 over the ObiTALK network, regardless of the peer number I set, OBi2 treats the call from OBi1 as though I'm not spoofing at all. In other words, this scenario:
OBi1 has an OBiTALK # of 111 111 111
OBi2 has a # of 222 222 222
OBi1 SP1 has an inbound call route of {ph,pp(333333333>ob222222222)}
OBi2 OBiTALK has an inbound call route of {111111111:aa},{333333333:ph}
If I were to call into OBi1's SP1, OBi2's call log would show 333333333 but would go to AA (the rule for 111111111, not the rule for 333333333).

Why is that?

2) I can't seem to get the $1 variable to work. For example, if I use the following inbound call route:
{ph,pp($1>ob111111111)}, the call log on that OBi will show a call from "$1" instead of the caller's number. Why?

Thanks!

[bukzin]

I guess my request for a simple answer is too tricky.


Maybe this device is beyond us non- techies.

[bukzin]

OK,

Found some info which does address a few of my questions.


May be of interest to others.



http://michigantelephone.wordpress.com/2011/01/22/review-of-the-obihai-obi110-voip-device-part-1-use-your-phone-with-google-voice-for-free-incoming-and-outgoing-calls/

[whee]

I've been playing around with this idea for a bit now and I've now got 2 additional questions:

1) I can get the call forwarding correctly using essentially this method, however when OBi1 calls OBi2 over the ObiTALK network, regardless of the peer number I set, OBi2 treats the call from OBi1 as though I'm not spoofing at all. In other words, this scenario:
OBi1 has an OBiTALK # of 111 111 111
OBi2 has a # of 222 222 222
OBi1 SP1 has an inbound call route of {ph,pp(333333333>ob222222222)}
OBi2 OBiTALK has an inbound call route of {111111111:aa},{333333333:ph}
If I were to call into OBi1's SP1, OBi2's call log would show 333333333 but would go to AA (the rule for 111111111, not the rule for 333333333).

Why is that?

2) I can't seem to get the $1 variable to work. For example, if I use the following inbound call route:
{ph,pp($1>ob111111111)}, the call log on that OBi will show a call from "$1" instead of the caller's number. Why?

Thanks!

Did you find a solution to this problem? I'm experiencing the same thing. I'd like to be able to directly call an OBi110 through OBiTALK and get the AA, but also be able to forward incoming calls on the LINE port to the other OBi110 and ring the phone. I figured spoofing the CID would work, but I see $1 as the peer number and the OBi110 seems to act as if I hadn't spoofed the CID when it evaluates the InboundCallRoute (i.e., the AA picks up). Seems broken.

[Stewart]

I'd like to be able to directly call an OBi110 through OBiTALK and get the AA, but also be able to forward incoming calls on the LINE port to the other OBi110 and ring the phone.

It does seem to be broken, but there is probably a solution by using SIP, rather than OBiTALK, for one of the paths.  What services do you presently have on each of the OBi devices?

[RonR]

It's not broken, it's designed badly.  From the v1.3.0 release notes:

- Allow Caller-id spoofing for calls bridged via OBiTALK service. But use the obi number for circle-of-trust authentication.

[whee]

I'd like to be able to directly call an OBi110 through OBiTALK and get the AA, but also be able to forward incoming calls on the LINE port to the other OBi110 and ring the phone.

It does seem to be broken, but there is probably a solution by using SIP, rather than OBiTALK, for one of the paths.  What services do you presently have on each of the OBi devices?

Each OBi has Callcentric on SP1 (different accounts) and Flowroute on SP2 (same account, only used for outbound). I don't believe Callcentric will let me spoof CID, but Flowroute does. I could probably get a similar (and free) end result with a Flowroute -> Callcentric SIP address call between the two.

It's just a cleaner model (mentally and configuration-wise ) if the forwarding/bridging part were a separate service, like OBiTALK. Hopefully it gets ironed out.

[RonR]

I'd like to be able to directly call an OBi110 through OBiTALK and get the AA, but also be able to forward incoming calls on the LINE port to the other OBi110 and ring the phone.

Since you have SIP configured on each OBi, these easiest solution is to route the OBiTALK Service to the Auto Attendant in the normal way and forward your LINE Port calls to the other OBi's PHONE Port via SIP:

Physical Interfaces -> LINE Port -> InboundCallRoute : vg1

Voice Services -> Gateways and Trunk Groups - Voice Gateway1
AccessNumber : SP1(hostname or ipaddress of other OBi)

You will need to forward ports 5060 - 5061 in the router serving the 'other OBi' if the first OBi is on a different LAN.

[Stewart]

If the direct path suggested by RonR won't work, e.g. because of router or DNS constraints, you could set it up so an incoming call on the LINE port dials the other OBi's CC 1777 number, via the local CC account, which should ring the PHONE port on the other OBi.  When you call the other OBi via OBiTALK, it would recognize your caller ID and route to the AA.

However, I assume that you want to access the AA, so you can make calls from the remote OBi's LINE port (which doesn't offer any other services that you don't already have on the local OBi).  If that is your goal, you can set it up so that you can dial through directly, avoiding the AA and the need for two-stage dialing.  It should even be possible to configure the digit map so that calls to certain destinations would use the remote OBi's LINE port automatically.

[whee]

Since you have SIP configured on each OBi, these easiest solution is to route the OBiTALK Service to the Auto Attendant in the normal way and forward your LINE Port calls to the other OBi's PHONE Port via SIP:

Nice. This does ring the other phone (and call waiting even works), but it doesn't transfer the caller ID from the original caller. This might be a limitation of using a SP trunk if I'm reading the documentation correctly

[Stewart]

This does ring the other phone (and call waiting even works), but it doesn't transfer the caller ID from the original caller. This might be a limitation of using a SP trunk if I'm reading the documentation correctly

OBi will not spoof caller ID on a VGx.  I've heard that this is for marketing reasons; if so, it won't be fixed.

If you don't need spoofing for Flowroute, you could move it to a VGx and use SP2 for calling the other OBi.  Otherwise, would Flowroute allow for a free call to the other OBi (e.g. SIP URI or iNum)?  If not, you might move Callcentric to a VGx, getting incoming via SIP URI direct to the OBi.  

[whee]

For reference, I ended up using OBiTALK for just forwarding the calls, with no access to the AA. Then, I set up the Callcentric->Callcentric route for AA access. This way I retain caller ID and still can get to the AA.

(The alternative of forwarding using the Callcentric accounts has a funny caveat; if account #2 is on a call and the first OBi forwards its LINE call to it, the caller gets sent to account #2's voicemail and the first phone doesn't get a chance to ring.)

[Stewart]

Assuming that you don't actually want to access the AA, but are just using that as a way to get to the remote device's LINE port, perhaps this thread by RonR will work for you: http://www.obitalk.com/forum/index.php?topic=1103.0

In my case, a remote OBi is registered as a sub-PBX to a free PBXes account.  Calls from our IP phones to designated (in PBXes) destinations go out the OBi's LINE port, with no need for two-stage dialing.  Incoming calls are forked (by PBXes) to multiple IP phones; you can answer from any and they all show the caller ID.