Google Voice CallForwardUnconditional
RonR:
I think you've found a bona fide bug.
I have GV on SP1/ITSPA and I just put my Sipgate account on SP2/ITSPB.
With no forwarding, calls to my Sipgate number ring the OBi phone, as expected.
Enabling CallForwardUnconditional via SP1 (using either SP1(...) or **1...), the forwarding fails.
I tried the same forwarding from OBiTALK to SP1 and was better able to see the problem. It appears the outgoing call is actually being placed through SP1, but GV responds "You don't have sufficient credit to place this call." This would seem to indicate the OBi is not sending the correct number when the new call is placed through GV.
RonR:
Quote from: dialtone on March 16, 2011, 02:55:46 pm
Is this SP1(8005551234) syntax correct, as it applies to Google Voice on SP1 ?
I think GV would prefer a leading '1', but if I recall correctly, it's also happy without it. I was testing with a leading '1'.
I think the general rule in the OBi is that numbers in TK format [SP1(18005551212)] are sent to the port directly with no alteration, whereas in PHONE Port format [**118005551212] they're run through the normal DigitMap's and OutboundCallRoute's. At least that's the way it's stated for Speed Dials.
dialtone:
Ron, Thanks for these details.
From all our findings mentioned above, I knew the following would not work but I was curious so ...
I tried SP1(1234567890) and SP1(11234567890) because 123-456-7890 is the associated Google Voice number.
That would normally take you to your Google Voice menu ... To check for new messages, To place a call, etc.
No luck. Busy tone.
Quote from: RonR on March 16, 2011, 03:10:23 pm
I tried the same forwarding from OBiTALK to SP1 and was better able to see the problem. It appears the outgoing call is actually being placed through SP1, but GV responds "You don't have sufficient credit to place this call." This would seem to indicate the OBi is not sending the correct number when the new call is placed through GV.
Since it is not clear which or how many of these digits are being sent to GV ...
Is there any way to introduce a Delay in this syntax?
To slow down the number dialing, instead of just shooting it out.
Just like the "w" in D(wwww ...) in the Asterisk Dial() command.
That way a delay could be introduced before and/or during the number like so:
SP1(www1234567890)
or
SP1(www1w2w3w4w5w6w7w8w9w0)
etc.
RonR:
Quote from: dialtone on March 16, 2011, 04:39:07 pm
Since it is not clear which or how many of these digits are being sent to GV ...
Is there any way to introduce a Delay in this syntax?
To slow down the number dialing, instead of just shooting it out.
The digit's aren't 'pulsed' out to GV as you dial them. Once the OBi collects and processes what's supposed to go to GV, a packet of information is sent across the Internet containing all the necessary pieces at the same time. It's not 'dribbled' out in real time. Consequently, you'd need to 'packet sniff' what's being sent and analyze what is seen. This is a much better project for Obihai as I'm sure they already have this capability in place and they'll know what should be there instead of what is actually there.
RonR:
dialtone,
A correction to my earlier post. There is not a problem with OBiTALK -> GV forwarding. I had to have someone help me test that path and I just discovered he was forgetting to dial **9 in front of my OBiTALK number. It was his GV that was reporting "You don't have sufficient credit to place this call", not mine. I just ran the tests again to be sure and here's how forwarding stands:
Working:
OBiTALK -> GV
LINE -> GV
GV -> GV
Failing:
SIP -> GV
Navigation
[0] Message Index
[#] Next page
[*] Previous page