We have 13 Obi boxes on a dedicated DSL line all running Google Voice. When a call comes in, the receptionist does a transfer using the Obi transfer code combo and, if the call goes to voicemail instead of being picked up live, the call ends exactly 20 seconds into the voicemail, mid-sentence.
Is there some setting I can change not he Obi boxes to fix this?
Thanks!
Please explain your system flow in more detail. Original call comes in on what (GV number in question, another GV number, POTS, SIP, etc.)? Receptionist answers how, e.g. analog PBX connected to Phone ports of all the OBis, GV forwards the call, OBi forwards the call, etc? Receptionist does what (e.g. sends hookswitch to the OBi and dials *98 from the PBX)? OBi sends outbound leg on what (same GV account, another GV account, another service)? Transferred call sent to what (same GV account, another GV account)? If call does not go to voicemail and is picked up live, what is the path (picked up on another GV forwarding phone, picked up on the OBi)?
Is OBi firmware current? Can you test one unit on your "normal" Internet connection? If you transfer to a different voicemail service, e.g. a cellphone, does that work correctly?
1. Automated attendant provided by Toktumi answers. Caller dials "0" and Toktumi forwards call to GV DID.
2. Call rings into operator extension (A GV DID), answered by receptionist on Obi box #1
3. Call is manually transferred using Obi Speed Dial code by receptionist to another GV DID that rings on Obi box #2 on the same LAN
4. call is not answered and GV voicemail picks up. Exactly 20 seconds into leaving message, voicemail disconnects, although caller is not aware of disconnect (no click or dial tone comes up).
All firmware is current. If call is answered instead of going to voicemail, then line does not disconnect. The DSL used for data is identical in service to the DSL dedicated to voice calls and we get the same result when Obis are placed on the data connection. When call is transferred to an outside line (such as a cell voicemail), the call does not cut off and the whole message is recorded.
Wow. Let's try to simplify this. If you bypass Toktumi, by calling the operator extension directly from a landline or mobile, does the transfer still fail? If the receptionist simply picks up OBi #1's Phone port and dials the speed dial code for OBi #2 (and lets that call go to voicemail), does that fail?
On the transferred call, is the outbound leg using the same GV account as the operator extension? If not, please explain.
Post a screenshot or transcription of the OBi #1's Call History for a failing call (mask phone numbers or other personal info, but leave all times and technical details intact).
Though unrelated to your current problem, it appears that this transfer scheme does not pass the original caller's ID. Is that correct? If so, and you'd like to fix it (the solution would likely not be free), the new scheme would likely not have your present issue.
Your last insight about testing whether just dialing the Obi #2 from the Obi #1 using the speed dial extension reveals that the voicemail cutoff STILL happens after 15-20 seconds - no transferred call even involved!
So does this indicate the speed dial feature is broken? Or that we're using it incorrectly?
You are correct about the caller ID not being passed through - is it supposed to be?
(I tried attaching the redacted call history as a screenshot but the forum says the ftp is "full" right now, even though it's a very tiny file)
I should point out that the designated destination of the speed dial is the Google Voice DID, not the Obi number, because that's the only way to reach the Google Voicemail if the call is not picked up.
I did a test, calling with Gmail from one GV account to another. No OBi or other VoIP hardware was involved. The voicemail cut off after 20 seconds, exactly as you found. Calling from another service into GV did not have this problem. So, it appears that this is a GV bug (or perhaps an intentional restriction, though I don't understand why they would do that).
IMO you have three options (other than living with the problem):
1. Somehow get Google to fix it. I don't believe that's likely to happen quickly.
2. Use a (paid) service other than GV for the outbound leg of the transfer from the receptionist.
3. Use a free or paid voicemail service other than GV at the user end.
You might also select a service other than GV for the link from Toktumi to the receptionist. Depending on your choices, you could pass caller ID, handle more concurrent calls, and/or get lower latency and better voice quality. Note that your present system can only handle one transferred call (if sending on the from-Toktumi account) or two (if sending on SP2).
What is your anticipated monthly minutes usage over this path? How many concurrent transferred calls do you need? How important is GV voicemail? (If e.g. transcription to SMS is essential, anything else is likely to be costly.) Budget?
Our usage is fairly light. The reason we switched to this system was that email has overtaken voice conversation in our business over the last five years, and we have very few calls in or out. (Maybe 200 minutes a month for all 13 people).
This may be a question better addressed in its own thread but: What is the most recommended VoIP service for outgoing calls in the Obi community for light domestic usage? We'd like to keep the GV for incoming calls and voicemails, but for the incoming operator and for everyone's outgoing, I'd like to find a paid service like you suggest.
By the way, thanks for all your help on this, Stewart. Brilliant sleuthing on your part to figure out this issue.
So I tried voice.ms for outgoing calls to see if this would fix the issue. Oddly, calls that are transferred using the Obi *98 protocol hang up as soon as the voicemail (or the line itself) gets picked up. Worse than Google Voice.
Anyone recommend a VoIP provider that won't do this?
I noted the 20 sec voicemail issue with GV to GV calls about a month or two ago. I also would lose the caller id of the original caller with that setup. The way I fixed my setup was by sending all voicemails to my asterisk server, which would answer the calls, translate the calls into text (using the same software used by GV), convert the wav to mp3, and send the translation and mp3 as an email to the designated email. Acts just like GV but with caller id included, longer greeting message capability, and longer voicemail message. It works great so far. The only issues that I am now dealing with are mainly with GV's service or with obi's connection to GV (can't tell). Recently, my calls seems to be cutting off randomly :( .
Not sure how you system is setup but if you have one main GV number that your customers call to, then get a couple free callcentric dids and have your main gv number redirects calls to the new callcentric dids. Then, if you want them to leave a message, they can be transferred to your voicemail-only gv did. Roundabout way but it should overcome the 20 sec limitation.