News:

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

Main Menu

Problem forwarding busy calls from {ph1} to ph2 Obi202

Started by PlummerBob, March 20, 2013, 03:58:23 PM

Previous topic - Next topic

PlummerBob

Obi202. I have call waiting disabled on ph1, and have SP1 setup to forward to ph2 on busy. I can't seem to get ph2 to ring under these circumstances. I had this exact setup working for 2 months, and then it suddenly stopped working, or maybe I just noticed it.  But I am sure at one point it was working. I have X_InboundCallRoute set as "{ph1}" and CallForwardOnBusyNumber set as "ph2". CallForwardOnBusyEnable is enabled. CallWaitingEnable is disabled/unchecked. I have also tried disabling CallWaitingCallerIDEnable.  

What this setup was doing, was make it so if ph1 was in use, all incoming calls would just forward and ring to ph2.

Any help troubleshooting would be appreciated.

Thank you.

PlummerBob

I have a suspicion that this could be related to the firmware version I have 3.0.1 (Build: 3741), because in the past I had this forwarding setup and there were no issues.

Does anyone have copies or links to other versions of firmware that I could try out?


QBZappy

Ron,

He mentions that he is already using that version (Build: 3741). He would like a previous version. Do you keep copies?

Quote from: PlummerBob on March 21, 2013, 01:55:14 PM
I have a suspicion that this could be related to the firmware version I have 3.0.1 (Build: 3741), because in the past I had this forwarding setup and there were no issues.

Does anyone have copies or links to other versions of firmware that I could try out?
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.


PlummerBob

Well it doesn't seem to be working with 3722 either. Any suggestions on troubleshooting?

Shale

Try setting your call route to
ph1,ph2

I think ph may be a synonym for ph1.

Now when the call comes in, both lines ring. The first to pick it up gets it. Now check the behavior if one line is busy. It would ring the other line and usually do call waiting on the busy 1.

But if you have turned off call waiting, you might get something close to what you are looking for.


PlummerBob

Quote from: Shale on March 22, 2013, 04:22:11 PM
Try setting your call route to
ph1,ph2

I think ph may be a synonym for ph1.

Now when the call comes in, both lines ring. The first to pick it up gets it. Now check the behavior if one line is busy. It would ring the other line and usually do call waiting on the busy 1.

But if you have turned off call waiting, you might get something close to what you are looking for.



Setting the inbound route to ph1,ph2 does still ring both lines.  I have also confirmed while setting the inbound to ph1 and enabling call waiting that my service provider sending and the obi is receiving the call waiting signal.  I used to have the obi setup in the manner you suggested in the past but I switched it so ph1 would forwardonbusy to ph2 because my phones would rack up a lot of missed call messages even when they were answered.  What I just don't understand is why the callforwardonbusy just suddenly stopped working.

PlummerBob

#8
I think I may have found the reason the calls do not forward to ph2 or any phone number for that matter upon further testing.  Call waiting doesn't seem to get disabled even when the check box is unticked.  I've also tried this with 3 service providers.  So it seems without ph1 giving the busy signal, it never gets kicked over to ph2.  Ideas?  Resetting to factory to see if the settings will stick, will update soon.

Edit:
Call waiting can be disabled, but the obi still doesn't forward to ph1, ph2 or another number.

Strange note:
While setting inboundroute to {ph,ph2} with call waiting disabled on both ports, the 1st ring will still sound a call waiting tone.

mife

Forwarding to "ph2" did not work for me either (went to my provider voicemail), but when I tried "ph2(#)" it worked. I suppose that the CallForwardBusyNumber syntax requires some destination number...