Intermittent CallFwdNoAnswer and no Caller ID syslog with UnconditionalFwd!

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

[Stewart]

Instead of call forwarding (clear all those settings), set X_InboundCallRoute for SP1 to
{ph,sp2(yourcellphone)}
and X_InboundCallRoute for SP2 to
{ph,sp1(yourcellphone)}
That way, forwarding will start immediately, but all calls will still ring the Phone port and give you the desired syslog entry.

However, please explain your overall goal.  Are you texting the caller ID just to get around GV's inability to spoof it, or are you depending on sending a fixed caller ID, e.g. because you have unlimited minutes to/from specific numbers?  Are the two OBi GV numbers "special", e.g. ported in, or could they be anything?  Also, what it the estimated usage for each forwarding link?  I'm asking, because there are some alternate and non-free solutions that would eliminate both the 25-second GV deadline, and the inability to pass caller ID.

[GWCS]

The GV numbers are not "special", insofar as they were not previously owned numbers that were ported to GV.

My goal is to circumvent the restriction that GV imposes wherein only on GV number is allowed to forward to a given "regular phone" (cell, landline, etc.), with the nice by-product of a totally free VOIP line at my home, which is something I have done without ever since I had my little divorce from Miss Vonage.  I am texting the caller ID of the caller so that I can have that little tidbit of information because there is no way to have it spoofed or conveyed any other way that I know of.

Now I have my original GV number that is somewhat permanently linked to my cell, and the Obi affords me the advent of funneling two more numbers to the cell, albeit with some of the issues previously mentioned in this and other threads.

I am going to play around with the configuration settings you suggested, but I wonder if modifying the X_inboundcallroute will disallow me from dialing into the Obi call attendant from my cell?

[Stewart]

I am going to play around with the configuration settings you suggested, but I wonder if modifying the X_inboundcallroute will disallow me from dialing into the Obi call attendant from my cell?

It shouldn't, the value for SP1 should end up being something like:
{yourcellphone:aa},{ph,sp2(yourcellphone)}

However, as you have described the system so far, the AA is IMO not useful.  If you will be calling in on GV and calling back out on GV, you will get better quality, lower latency and better reliability by just using GV (at the GV main menu, press 2 to make an outgoing call).  The usual use of AA is to provide access to a service other than the one used to call in, e.g. landline, inexpensive international provider, other OBi.  If you have such, please explain.

If you just want a number that both forwards to your cell and rings your home phone, passing caller ID correctly and giving you plenty of time to answer the cell, there are many options.

One is Anveo.  You can get a Value DID for $0.99/mo. (40 min. free incoming per day) or a Personal Unlimited DID for $1.99/mo.  Calls that you answer at home on your OBi are free; calls forwarded to your cell are $0.01/min.  If desired, you could add 911 service for $0.80/mo.  Excellent quality, reliability and support.

At the other end of the spectrum is VoxOx. Free, though you can't pick your number.  Like GV, quality and reliability are good but not the best, support is almost non-existent.

There are also do-it-yourself solutions, where the call comes in to your OBi on a free or paid DID, and gets forwarded to your cell via a different provider that allows spoofing the caller ID, typically $0.005 to $0.01/min.

[GWCS]

Stewart, first of all, thank you for your time. I read another thread wherein someone was not entirely receptive to your help and asked you if you worked for Obi, as if to imply that your input was less-than-qualified without Obi's official credentials. I recognize that you're simply an enthusiast of the product, and a helpful one to boot.

I absolutely concur with you about AA not being the right choice for me. I have used GV's "press 2" selection to make outgoing calls through my GV number before, and as such, I have removed my cell phone from my Obi's "trusted callers", and obviously I had to modify the corresponding contact information on my android phone, specifically what DTMFs to produce after the call connected. Also, GV allows one to make a particular group go straight to its voicemail, so by making my cell phone the only entry in that group, I do not have to wait for the 4-5 ringbacks to access the GV voicemail. One nice thing about android is the ability to do a one-time edit of a given contact prior to making a call. So, I maintain a GV contact in my phone which is this: MYGVNUMBERp_*PINCODEp_*2# (where the lower case 'p' is a pause - pity that android pauses still adhere the the antiquated, unofficial 2-second standard, because most of the time a 100-500ms pause is all that is really required, but I am digressing). Now, any time I wish to return a call that has come through my GV number via my Obi, I can view the special caller ID text message that my syslog server sends me at the beginning of the incoming call, and pull up my GV "template" contact, insert the caller's number into the contact information in the penultimate position, leaving the #-key as the final element and hit 'OK'. Once the outgoing call has been generated from my phone, I can now save that long string (my base GV contact + the destination phone number) as a new contact, in and of itself. It actually works quite well.

Because of the undesirable latency of the Obi forwarding that I have been alluding to and lamenting, I did try your suggestion out. I prefer to access my Obi directly through my LAN via a browser instead of Obitalk. At first, it did not work, and it kept reverting to the simple "ph", but then it dawned on me that the Obitalk configuration must have been overriding my settings, so I found myself doing it that way, and voila'. I grant you it is certainly faster than my old forward-after-1-ring method, which generally resulted in my cell phone actually ringing on the fourth (occasionally third) ringback,but it is far from instantaneous. My cell rings pretty consistently on the second ringback that the caller hears, and sometimes on the third. So, is it better? Certainly. Is it truly instantaneous forwarding? Unfortunately, no. The good news is that the precious caller ID syslog code is generated. Tell me something, your enthusiasm for Obi notwithstanding, do you think it is a bona fide bug that the caller ID is not generated when one sets the UnconditionalCallForwarding? I ask this because the caller ID information is present, because if one goes back and reviews the call history in the Obi, sure enough it's there, so why is it not generated among the numerous syslog codes during this type of forwarding?

Anyway, I thank you quite appreciatively for the time you've taken with me on this matter.

[Stewart]

For making outbound GV calls from your mobile, if you can use the GV account associated with the mobile (as opposed to one of the "funneling" accounts), you can set up GV to go directly to the VM prompt without requiring a PIN, which would save one two-second pause, plus the time to send the PIN.  Of course, if you are using a funneling account in order to send that specific caller ID, then this would not be applicable.

If you want to update your OBi directly from its web interface, you must first prevent OBiTalk from overwriting your changes, by setting from the web interface:

System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled

Save changes, reboot, then make other changes as desired.

On a recent firmware update, Obihai removed some debugging information that was previously available via syslog.  I don't know whether they had an ulterior motive, or were simply trying to eliminate some verbosity that they felt was redundant.  However, the behavior of what remains ([SLIC] CID to deliver:) is not IMO buggy -- if the call doesn't ring the Phone port, that message should indeed not appear.  Why is that an issue for you?  I would assume that simultaneously forwarding and ringing the Phone port would be desired anyway; if you happen to be at home, you could answer on the OBi, getting better quality and saving cell minutes, etc.

Although I can't come up with the 13 seconds you have observed (I can see maybe 10), instant forwarding to a mobile is not possible, because the call setup time is inherently slow (limited by GSM or CDMA protocol), and you have two GV call setups in the path as well.  Try calling your mobile from a landline or another VoIP provider and see how long it takes for the mobile to actually start ringing (the mobile carriers usually play a fake ringback to the caller, before setup is complete).  There are several reasons why setup time to a mobile varies from one call to the next.  Among other things, to improve battery life, the radio receiver is off most of the time.  The phone "wakes up" every second or two, at a precise time previously negotiated with the base station, "listens" a few milliseconds for a page, and goes back to sleep if there is none.  So, an incoming call must wait for the next paging "slot" before it can signal the mobile.

[GWCS]

I agree that your configuration is better (much better) with no call forwarding settings in place and the X_InboundCallRoute set as instructed, and I don't foresee ever changing that. I have not been at home for a couple of days and changed the settings remotely, so I have not actually seen if I can answer the call on the Obi, but I will take it on faith that it works until I get home to see for myself.

I do, however, still see the inconsistency of the CallerID syslog generation as a bit of a bug, but I suppose that is a matter of opinion. Don't get me wrong. I really like my Obi, and am considering buying a couple more of them, including one for my mom so that she has a "home phone" in addition to her cell.

The idea that a future firmware upgrade might eliminate the CallerID syslog generation altogether, in the interest of "trimming the fat" of electronic verbage, is an unsettling thought. I do have the default of Auto Firmware Update under Auto Provisioning as "disabled", so I presume I won't just get saddled with a deficient firmware upgrade without my consent. I see that it is easy to save my configuration, but is there a way to save my current firmware on a computer's hard drive in the event that I do a firmware upgrade in the future, only to discover that I wish to revert to the current version?