News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Forwarding Setup

Started by pitcritter, August 31, 2013, 02:22:24 PM

Previous topic - Next topic

pitcritter

I live in Canada, but spend a lot of time at my property in the US.  I currently have two Obi devices setup and working fine.  On each of them, I have a Canadian number through Freephoneline.ca as my primary line and a GV number as my secondary.  My goal, is to make incoming calls as easy as possible for the caller.  I'd like callers in Canada to call one CDN number and callers in the US to call one US number and be able to get me at either location.

Currently, I have my FPL account on my CDN device set to ring both FPL accounts.  This is working perfectly.

Now, I'd like it if someone calls the GV number associated with my US Obi, that both my US and CDN Obis would ring. This is proving difficult, since GV won't allow simultaneous ring of a CDN number.

It's a little convoluted.  If I've made anything more complicated than it needs to be, then please ask for clarification.  I'd really like to get this straightened out.

Thanks, PC. 

QBZappy

Hi,

Look up "Call Forking" on the forums or admin guide. The OBi can ring both the local unit and any other number using this "Forking" strategy.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

pitcritter

Thanks Zappy.  I think I'm on the right path now.  Can you tell me if this makes sense?  Currently, here's the InboundCallRoute on one of my devices.  It uses two trusted numbers (my work numbers, changed obviously) to go straight to AA so i can call LD from work through my OBI. This works flawlessly.

{(x.9051111111|x.9052222222):aa},{ph}

The way I understand it, it should be changed to look like this:

{(x.9051111111|x.9052222222):aa},{ph},{sp1(9053333333)}

The alternative would be to ring the Obi number of the other device, but I couldn't figure out how to do that.  Would it be something like the following?

{(x.9051111111|x.9052222222):aa},{ph},{**9(555555555)}

The **9 looks wrong, but I'm not sure what's right.



pitcritter

OK, read BEFORE you post I guess.

How about this:

{(x.9051111111|x.9052222222):aa},{ph},{PP(555555555)}

Now am I close?


QBZappy

Quote from: pitcritter on September 01, 2013, 06:32:44 AM

{(x.9051111111|x.9052222222):aa},{ph},{PP(555555555)}

{(x.9051111111|x.9052222222):aa},{ph},{PP(ob555555555)}
This should do it

Quote from: pitcritter on August 31, 2013, 02:22:24 PM
Now, I'd like it if someone calls the GV number associated with my US Obi, that both my US and CDN Obis would ring. This is proving difficult, since GV won't allow simultaneous ring of a CDN number.

I understand this to mean using the native GV portal config. I believe GV allows for 2 voice channels. You should also be able to fork the call over the GV as well using above mentioned method using the OBiTALK network.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

pitcritter

Thanks again Zappy.  I'm off for the next couple of days, so it's time to play.  I'll report back results.

Is there any advantage to forking to the OBI number as opposed to a VOIP provider like FPL or GV?

The way I see it, if I only setup forking on SP1 and SP2 incoming calls and not on PP1 on both devices and fork to the OBI#, that would avoid ping-ponging back and forth.

I don't use the OBI# for anything else.

QBZappy

Actually the most direct route between the two OBis is to use a sip uri address as the forking number. It avoids any 3rd party disruptions. Any of these methods will work and give you the same result. Just pick one and see how it goes.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

pitcritter

OK, now you're just showing off!!  ;D

I have no idea how to use a "SIP uri address".  I'm not looking to be spoonfed, but how about a nudge in the right direction?

pitcritter

I tried

{(x.9051111111|x.9052222222):aa},{ph},{PP(ob555555555)}

The call didn't get forwarded to the other Obi device

Would this work?

{(x.9051111111|x.9052222222):aa},{PP(ob555555555),ph}

QBZappy

Sorry for the above. Here is a more detailed way to do it with explanations for what you want, directly from obihai and RonR:

Quote from: obi-support2 on March 21, 2011, 10:34:40 AM
The Call forward destination number fields only allow 1 number at present.

The Inbound Call route parameters, on the other hand, would allow you to fork the call the multiple numbers, simultaneously. The limit 4.

Some examples with SP1 InboundCallRoute:

{ph,SP1(12345678),SP2(11112234),SP2(44445555)}, OR

{(33931111|3399xxxx):ph,PP(ob200123456),SP2(11112234),SP2(44445555)}


This is assuming you can support at least 2 calls per SP service. Whichever number answers first will "win" and the other calls will be canceled by the OBi automatically.

---------
Note: If you include LI(some-number) in the route, however, LI will "win" most of the time since there is no easy way to tell if the call on the analog PSTN line is answered; so the device simply assumes the call is connected once it finishes dialing out the number on the PSTN line (hence it wins).

In 1.2 (currently in beta) we offer a new feature to detect if outbound call on PSTN line is connected based on tones and signal detected on the LINE. But this may require some tweaking for your local phone company. By default that feature is not enabled.


Quote from: RonR on October 30, 2011, 06:11:37 PM
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.


As for an explanation on sip uri, you can refer to these posts:
sip uri using GTALK (note not direct as it uses GTALK)
http://www.obitalk.com/forum/index.php?topic=3573.0

General discussion on using sip uri (Direct if pointing to the ip of the OBi)
http://www.dslreports.com/forum/r26327633-Obi110-SIP-URI-s-SIP2SIP-
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

pitcritter

Zappy, you are a true public service.  Thanks for all the info you've presented here.  More testing is in order, but I'm sure with this material available to me I can now figure it out.

If you're anywhere in the Niagara region, I'd love to buy you a coffee.  You've certainly earned it.

pitcritter

#11
I think I've finally figured it out.  I was missing one step that was in the above detailed directions.

I am located at the location of one Obi device.  I applied the setup noted above and then asked someone to call the number associated with SP1 on my other Obi device to see if it would ring where I am.  They kept reporting that it was going straight to "Voice Mail".  

I had a thought.  I asked if it was my voice on the greeting, or a "Computer Voice".  The caller reported that it was a Computer Voice.  This meant that it was not my FPL voice mail, but ObiAttendant that was answering.

I looked at the "ObiTalk Service Settings: InboundCallRoute" and found {(290333333|200222222)>(xx.):SP1},{(290333333|200222222):aa},{ph}

I changed it to: ph

And all is well.

It seems that ObiTalk automatically adds the other devices on your account as Trusted Callers and routes them to AA.  In this case, my other Obi device and my SoftPhone got this preferred treatment.

I've confirmed that it works in one direction.  I can only assume that it's OK at the other end now.

I'll test over the next few days or so.

Thanks again to everyone who helped me to figure this out.