Transferred Obi calls hang up exactly 20 seconds into leaving a GV voicemail
batchannel:
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!
Stewart:
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?
batchannel:
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.
Stewart:
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.
batchannel:
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)
Navigation
[0] Message Index
[#] Next page