OBi1032 Three Related Lines Won't Ring Simultaneously

[Charlemagne]

My OBi1032 is auto provisioned and assigned as follows:

Line Key 1 (SP1)  Google Voice
Line Key 2 (SP2)  Callcentric
Line Key 3 (SP3)  Vestalink

Inbound calls to my GV number are configured to ring on SP1 (and through forwarding) SP2 and SP3, but lately inbound calls may ring for an instant on all three line keys, then on only one line (SP2), with the other two lines being disabled from for answering a call by depressing the corresponding line key.

I use the GV web interface to place most outbound calls, typically designating SP2 to complete the call.

A factory reset and tweaks have been tried, but so far nothing has restored all three lines to ring simultaneously when my GV number is dialed.

Any suggestions?

Thanks very much.

[formerlyubergoober]

I'd be curious to know if there is something about SP2 that is providing a response to Google that is causing Google to choose just SP2.

When a SIP call is forked to multiple endpoints, the first responding endpoing is assigned the call and the other SIP dialogs are torn down.

Is Callcentric doing something that makes Google think that Callcentric has accepted the call even though you haven't picked up?

[Lavarock7]

Not an expert here but there are two ways that calls are forwarded. Knowing this may help in specific situations.

Note than when a call is forwarded, the phone doing the forward will usually ring once, telling you that the call was forwarded.

A Conditional call forward seems to be what Google Voice does, ringing a remote phone but allowing the call to be retained by Google so their own VoiceMail can take over if the call is not answered in a certain period of time.

This Conditional procedure is often used in an office when to get a call and want to forward it to another person. You dial their number and stay on the line to see if the person is there, then end the call forward attempt and try a different number.

An UNCONDITIONAL forward is when you force the call t othe remote number and give up your control. Thus the remote phone may be answered by a person, go to voicemail or worse just ring and ring, depending upon the remote phone capability.

Some Voip providers like Voip.MS and CallCentric have what they call a RING GROUP. A call sent to a ring group will ring all phones in the group until one of them answers or a timeout happens which may send the mto voicemail.

Some providers have a FOLLOW ME service which calls phones in a certain order, maybe 3 rings and if no answer call a second nuber, etc.

On an Obi setup I created, a user sometimes presses the phone button to forward calls uncondionally, using their cellphone as the recipient. The problem with that is when they are away from the physical phone doing the forwarding, they can't undo that until they get home. Also, if the call goes to their cellphone and they don't answer the call, the caller gets a voicemail prompt configured on the cellphone. If the yreturn tha call from their cellphone then the caller gets a message from a telpehone number they did call and may not recognize.

[Charlemagne]

It's good of both of you to have responded with well-reasoned thinking.  After additional troubleshooting and research the cause of the issue was discovered.  I then asked the Forum Moderator to remove my question because it turned out not to be ObiTalk or GV related.  No response was received from the Moderator, and the requested deletion did not occur.  So, I'll share my remedy for anyone who may be similarly situated.

I found that that Callcentric's Call Treatment was forwarding to extensions which (correctly) corresponded to SP2 and (and in error) corresponded to SP5.  Under these conditions inbound calls momentarily illuminated the primary set of three line keys, but when the Call Treatment in turn forwarded to the SP5 assigned extension (on the second set of line keys), the fourth and sixth line naturally keys did not flash or activate.  This switchover occurred so immediately and seemlessly that it created a false appearance that the first set of keys were still being displayed, when they had actually toggled and been replaced by second set.  What was visible then was a single ringing line (SP5), with the other two lines inactive and non-responsive to answering the inbound call.

This incorrect forwarding was not how the Call Treatement was previously configured, but the offending extension somehow became corrupted in the process of complying with updated password parameters for several Callcentric extensions.

Hope this explanation may be helpful to someone, and apologies for not analyzing the fault correctly before posting.