Ring after hangup
Stewart:
It appears that the remote OBi (at the Sensaphone location) is set to send calls that arrive on its Line port to your Obi, via OBiTalk. What does the remote device have for Line Port -> InboundCallRoute? If you are configuring it via the OBiTalk portal and it looks ok there, check by accessing the device directly -- it might have lost sync with the server.
MurrayB:
OK Stewart - Now we are on to it. I learn more about this marvelous device every day through reading the forum. Somethings my own interpretation is not reality.
The Obi at the remote location is current set to unconditionally forward all calls via *72 over ObiTalk to my current location. I thought wrongly that because the Sensaphone is ahead of (parallel to) the Obi Line Port and the Obi is set to default (4 sec?) answer the Obi would ignore the single ring. When I call back about 10 seconds later the Sensaphone would answer on the first ring and I have no activity from the Obi as evidenced in the call log.
The reason it does not happen in the reverse direction when I am back at the other location checking the Sensaphone here is because there is no forwarding.
Is my analysis correct and is there any adjustment I can make?
Thanks!
Stewart:
Your analysis is correct. Most POTS lines do not provide any indication that a not-yet-answered call has been abandoned by the caller, other than cessation of ringing. A standard US ring is two seconds on and four seconds off, i.e. rings occur every six seconds. So, at four seconds after the start of ringing, the OBi has no way of telling that the caller hung up.
If the POTS line has caller ID service, you could configure the OBi to not forward calls that originate from your other location. For example, in lieu of *72, set Line Port -> InboundCallRoute to
{12123456789:ph},{ph,pp1(ob234567890)}
where 12123456789 is your GV number (in the format that shows in Call History) and 234567890 is your OBi number. Then, your calls would ring only the Phone port, while calls from others would ring at both locations.
If you don't have POTS caller ID, IMO your only options are to either delay the forwarding to e.g. 10 seconds, or live with the problem. Perhaps RonR will chime in with a better solution.
MurrayB:
This is real food for thought. If I did set the Inbound call route as you describe could I still use *72 on a casual basis as I go back and forth? The situation only exists in one direction. The call forwarding is only from my house in Pennsylvania to my house at the Jersey Shore (nowhere near Snooki) at this time. Sort of like going between Bangkok & Pataya at least that was the thing in the old days.
Thanks a whole heap Stewart now that I understand what is happening it is not a debilitating situation. I agree that I am also interested in RonR's point of view.
RonR:
Quote from: MurrayB on March 03, 2012, 08:02:18 pm
If I did set the Inbound call route as you describe could I still use *72 on a casual basis as I go back and forth?
The answer to your question should be yes, but unfortunately, Obihai intentionally implemented code that disables all InboundCallRoute processing when *72 (Call Forward All) and *78 (Do Not Disturb) are used.
Navigation
[0] Message Index
[#] Next page
[*] Previous page