Intermittent CallFwdNoAnswer and no Caller ID syslog with UnconditionalFwd!

(1/3) > >>

GWCS:
I sincerely hope that someone that is very knowledgeable about the Obi peruses this post and can conjure up some answers for me. I am finding myself a little desperate here.....

My setup is as follows: I have TWO GV numbers associated with my Obi box (SP1 and SP2). Please keep in mind that neither of the GV numbers associated with my Obi are set to forward to any "normal" phone via Google's server, so I cannot achieve the "Simul-Ring" syndrome that so many enjoy (to borrow a Vonagism).  Instead, they are only set to forward to Google chat. Reason being, I have yet another GV number already linked directly to my cell phone as far as Google is concerned, and since they don't allow one to funnel more than one GV number to the same destination phone, I was hoping my Obi could serve to work around that limitation.

If I set my Obi to execute a call_forward_no_answer of its associated GV number to my cell phone, even if set to do so after only one incoming ring, my cell phone does not start to ring until about the fourth ring that the originating caller hears. If that isn't bad enough, even if I answer my cell the instant it first rings, more often than not, the caller does NOT connect with me, and they are diverted to the GV voice mail. By that, I mean to say that the call connects about 40% and winds up at voicemail 60% of the time.

If I set it to unconditionally forward, which I presume should be an almost instantaneous forwarding, it takes about two rings before my cell phone rings, and most of the time I can successfully field the call on the cell, but occasionally same thing happens and the caller still winds up at GV voice mail. Granted, this is a much rarer occurrence than when employing the call_forward_no_answer, but it unfortunately happens nevertheless. This is more like 70% success vs. 30% failure.

Am I the only one going through this? Does anyone know precisely why this is happening to me? It's an untenable situation and I desperately require some semblance of rectification.

Now, I went ahead an synchronized my laptop's clock with the same time server the Obi employs, namely pool.ntp.org. I generated calls to my Obi for testing purposes, and the first ring the Obi generates to the attached phone on an incoming call directly coincides with the precise time it occurred, according the Obi call history, however, a 13 or 16 second delay always comes after that before my cell phone rings. Why is this delay happening? I have checked the syslog and there is always a similar delay among the avalanche of syslog entries that occur in very quick succession. The delay is always here:

2012-03-09 23:31:09 kernel.debug 192.168.1.110   RTP:Start->4a7d7f7f:19305(80);0;0;0:0:0;1(57)\n
2012-03-09 23:31:22 kernel.debug 192.168.1.110   GTALK:sess callsess_17 state changed from 2 to 5\n  Notice the 13 second delay between the entries



Furthermore, the [SLIC] CID to deliver: does not get thrown to the syslog server during busy or unconditional call forwarding and is only occurring during Call_Forward_No_Answer.

Does anyone out there know what is going on here?

jimates:
google voice receives the call
google has to wait for the caller id (which is delivered after the first ring) before it knows what to do with the call
google forwards the call to the Obi
Obi receives the call
Obi has to wait for the caller id (which is delivered after the first ring) before it knows what to do with the call
Obi delivers the call to the phone port and or the forwarded number. It is quite possible that by the time the phone port on the Obi rings once, it is actually the 3rd ring of the phone.

likely by the time the Obi forwards the call it has already rang 3 times at google. google voicemail picks up after 25 seconds which is usually 4 rings, 5 max.

So the problem is just that there is not enough time for the call to route before google voicemail picks it up. And generally the caller might hear one ring before it ever rings at google. This is why so many people hang up before forwarded calls are answered, even calls not routed through google.

My multi handset corless even does it. The base rings first and then the extension phones all ring on the second ring. Add that to your equation and it is really messed up.

jimates:
You can have 2 google voice numbers forward to the same cell phone as long as you classify it as home or work instead of mobile. of course you will not be able to receive sms through google to the phone unless it is classified as a mobile phone.

GWCS:
First of all, I don't know when the last time you arranged two GV numbers to forward to the same number using the "I will classify it as a 'home phone' in one GV's settings and on the other it will be a 'mobile phone' classification" trick to circumvent Google's safeguard, but it seems those days are over as I just tried to do that very thing, and I got the thin, pink popup which said something along the lines of "this number is already in use as a cell on another GV account".  I paraphrased a bit, but you get the idea. That little loophole has been closed, unfortunately.

I believe I have discovered the cure to the issue, although the intermittency of its necessity still remains a mystery. It all has to do with that stupid "press 1 to answer" crap that GV still forces on its users. No, turning the call screening off does NOT fix the issue, so please - let's not have anyone say that. If I press the 1-key immediately upon receiving the call, I can field the call pretty much every time. Of course, this is hideously inconvenient, especially when driving.

Your accounting of the forwarding/hand-off procedure does not accurately reflect my experience at all. My Obi rings the same instant the caller hears his first ringback, and even though I have it set to forward after one ring, my Obi rings a second time before the caller hears his second ringback. Unfortunately, this is where the delay commences. My Obi stops ringing abruptly and nothing happens during the caller's third ringback and during the delay between the third and fourth. Then, around the time the fourth ringback occurs, my cell phone will ring, but only a portion of the time. Sometimes, it simply won't ring at all, and after the fifth ringback, GV voicemail gets the call. Now, if my cell does ring, I must answer the call immediately and, more often than not, quickly press the 1-key to complete the answering process.

On the other hand, if I set to unconditionally forward, my cell phone rings almost 100% of the time and occasionally as soon as the caller's second ringback, although more often during the caller's third ringback. Granted, I still need to answer the call quickly, and most of the time go through the annoying procedure of pressing the 1-key to complete the answering process. The major downside of this is that Obi's firmware does not produce the [SLIC] Caller ID syslog code during this type of forwarding and only does so on the no_answer_call_forward. I hope someone at Obi sees this and fixes that, because I created a way to send a text to my cell phone with that precious originating caller's ID, but I now fear it was all for nothing if I am relegated to only using the unconditional forwarding.

I wonder if Google will ever eradicate that annoying attribute once and for all. The GV forums are littered with folks complaining about its ramifications in other areas (aside from Obi). It just sucks.

GWCS:
Well, I tried yet another configuration with some moderately pleasing results....

Since I have two GV numbers associated with my Obi as (SP1 and SP2), I decided to crosshatch them. In the SP1 profile, I have it set to forward after one ring but the forwarding number is SP2(MYCELLPHONE), and conversely, in the SP2 profile, I have it also set for forward after one ring but I utilize SP1(MYCELLPHONE). Of course, if someone calls my line 1, my cell phone sees line 2's caller ID, and vice versa, but the really cool part of this is that that idiotic "press 1 to answer" garbage is totally circumvented. Also, the crosshatching of the SP1/SP2 now allows for a second incoming call (call-waiting) to forward to my cell phone, where it previously always went to GV voicemail. Lastly, by using both GV numbers, I seem to have much greater success in the call actually reaching my cell phone.

That said, it is not just nice, but a bona fide necessity to have two GV numbers if one desires to forward calls exclusively via the Obi.

Navigation

[0] Message Index

[#] Next page