Ring after hangup

[MurrayB]

I have two Obi 110 in two locations this happens at only one location. When I call the other location through the Obi via GV to access a remote monitoring device (Sensaphone) I allow one ring hang up and call ten seconds later to access the device similar to a TAD. The Sensaphone is ahead of the Obi. After the first call my phone rings after I hang up. I have to answer and hang up then make the second call. This does not happen in the reverse direction. Any ideas?

[jimates]

Do you have the number you are calling from in the Trusted Caller list of the other Obi. If so the other Obi is initiating the ring back feature.

[MurrayB]

I have no trusted callers, I will check that at the other location to be sure,  and the answer of both Obi is set to default time. When I take the ringing phone (Panasonic Cordless) off hook I have dial tone.

[Stewart]

Check the Call History on the originating OBi for the unwanted return call.  If (as I suspect) it's not present, the OBi is likely seeing a hookflash when you hang up (and is calling you back to return to the original call).  Try changing Phone Port -> HookFlashTimeMin from 70 to 150.  If no luck, troubleshoot by testing with a different phone, preferably a dumb line-powered corded set.

If there is a return call in the history, check for anything other than ph in the InboundCallRoute for the Line port of the Sensaphone OBi.  If no luck, troubleshoot by calling into the Sensaphone with its OBi temporarily disconnected. 

[MurrayB]

Hi Stewart thanks for the reply. This is my call history for that call sequence:

Call 2   03/03/2012    08:29:56   
Terminal ID   PHONE1   GoogleVoice2
Peer Name      
Peer Number   **2xxxxxxxxxxx   1xxxxxxxxxx
Direction   Outbound   Outbound
08:29:56   New Call   
08:30:01      Call Connected
08:30:28   End Call   
Call 3   03/03/2012    08:29:37   
Terminal ID   OBiTALK1   PHONE1
Peer Name      
Peer Number   yyyyyyyyyyy   
Direction   Inbound   Inbound
08:29:37   Ringing   
08:29:39   End Call   
Call 4   03/03/2012    08:29:28   
Terminal ID   PHONE1   GoogleVoice2
Peer Name      
Peer Number   **2xxxxxxxxxxx   1xxxxxxxxxx
Direction   Outbound   Outbound
08:29:28   New Call   
08:29:34   End Call

Does this help?

[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]

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.

[Stewart]

If the usual case is that only one location is occupied at a time, then setting it up so that both POTS lines ring in both homes should work fairly well; you would not have to change anything when going from one to the other.

A distinctive ring could identify which line was ringing, so you would not answer the remote line, when you knew someone was there to pick it up.

[MurrayB]

More food for thought. Only one house is occupied at a time. I can live with it but having both ring is very intriguing. What would the rule set up be?

Thanks RonR for joining in.   

[Stewart]

The example I gave earlier:
{12123456789:ph},{ph,pp1(ob234567890)}
says to send calls from 12123456789 to only the local Phone port, but to "fork" all other incoming calls to both the Phone port and OBiTalk number 234567890.  When a call is forked, all destinations ring simultaneously and the first to answer gets the call.

See page 121 of Admin Guide.

[MurrayB]

Thanks! I need to think over how I want to handle things.

[RonR]

The example I gave earlier:
{12123456789:ph},{ph,pp1(ob234567890)}
says to send calls from 12123456789 to only the local Phone port, but to "fork" all other incoming calls to both the Phone port and OBiTalk number 234567890.  When a call is forked, all destinations ring simultaneously and the first to answer gets the call.

See page 121 of Admin Guide.

Those rules (and all other rules), if used on the SP1, SP2, or LINE Port trunks will be ignored if *72 or *78 are in effect.

[MurrayB]

Thanks again for both of your inputs.

Having no caller ID on either pots line, I plan on dropping the expensive Verizon package, which would probably not be relevant for this condition which is most desirable.  How would I set up each Obi so that all incoming calls at either location 215xxxxxxx or 609xxxxxxx ring both locations? I assume that they would be transported via the Obitalk network.

[Stewart]

Set LINE Port -> InboundCallRoute to e.g.
{ph,pp1(ob234567890)}

In each OBi, use the OBiTalk number of the other.  With other settings at default, incoming calls on either device's Line port will ring the attached phones of both devices.

[MurrayB]

Thank you Stewart. Hopefully, I will be able to implement this.

[MurrayB]

Works great in one direction sometime next week I will reconfigure the other Obi.

Thanks!