Intermittent CallFwdNoAnswer and no Caller ID syslog with UnconditionalFwd!
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:
Quote from: GWCS on March 10, 2012, 05:52:20 pm
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page