I have no problem with this setup. Most certainly something's wrong with CID passed by IPKall. If I was in your shoes, I would try initiating a call manually (from the Google Voice web site) and checked what you get for a caller ID in the console. The rest is simple, just enter the number you get as the last parameter of sys.GoogleVoiceCall.When using the above setup I get a 486 Response "Busy Here" in the console and have to hangup then pickup to complete the call.
Any ideas as to why?
Google Voice Call Arbitrary Provider for Callback
Last edited by MikeTelis on Fri Sep 04, 2009 3:00 am, edited 1 time in total.
OK, that worked. Strange as incoming show/pass the correct CID but the CID on the call back does not show my 360 XXX XXXX IPKall # but a 253 XXX XXXX.MikeTelis wrote:I have no problem with this setup. Most certainly something's wrong with CID passed by IPKall. If I was in your shoes, I would tried initiating a call manually (from the Google Voice web site) and checked what you get for a caller ID in the console. The rest is simple, just enter the number you get as the last parameter of sys.GoogleVoiceCall.When using the above setup I get a 486 Response "Busy Here" in the console and have to hangup then pickup to complete the call.
Any ideas as to why?
Thanks for your help.
IPKall has always been tricky on CID. It works for you today but may stop working tomorrow if Google Voice change the carrier they use to terminate the callback.OK, that worked. Strange as incoming show/pass the correct CID but the CID on the call back does not show my 360 XXX XXXX IPKall # but a 253 XXX XXXX.
I would suggest that Aaron allow to use a regular expression (pattern) as the last parameter of sys.GoogleVoiceCall. In this case you could set it to /253\d{7,7}/ or even /*/ and bind any incoming call from 253 area or simply any incoming call that occurs within 15 seconds of GV dialout attempt. The probability of wrong binding is very low for most users and I'd rather submit to that.
I just received an IPKall number and I'm trying to use it for Toll-free only (not via GV) since Sipgate works but takes at least 10 s on average per connection. With IPKall I get connected in 3 s but get a recording saying I'm not allowed to dial out unless it is toll free but I am dialing a tollfree.
Here is my dialplan code for sipgate that is working with 10 second connect:
This is replaced with sys.Dial("IPKall") where I get a recording claiming I'm not dialing Toll free. Is it confused because of the (1)??
My Sip Traces for non-working IPKall went to:
DialPlan=> ForkCall commencing call leg to sip:18004664411@voiper.ipkall.com.
DialPlan=> Switching to sip:18004664411@voiper.ipkall.com:5060 via udp:127.0.0.1:5066.
For working sipgate, it's:
DialPlan=> ForkCall commencing call leg to sip:18004664411@sipgate.com.
DialPlan=> Switching to sip:18004664411@sipgate.com:5060 via udp:127.0.0.1:5066.
So any ideas why IPKall thinks I'm not dialing toll free??
TIA,
Synchron
Here is my dialplan code for sipgate that is working with 10 second connect:
Code: Select all
when /^(\+?1)?(8(00|55|66|77|88)[2-9]\d{6})/ then sys.Dial("sipgate")
My Sip Traces for non-working IPKall went to:
DialPlan=> ForkCall commencing call leg to sip:18004664411@voiper.ipkall.com.
DialPlan=> Switching to sip:18004664411@voiper.ipkall.com:5060 via udp:127.0.0.1:5066.
For working sipgate, it's:
DialPlan=> ForkCall commencing call leg to sip:18004664411@sipgate.com.
DialPlan=> Switching to sip:18004664411@sipgate.com:5060 via udp:127.0.0.1:5066.
So any ideas why IPKall thinks I'm not dialing toll free??
TIA,
Synchron
I like that suggestion. Any reasons not to use a regular expression?MikeTelis wrote: I would suggest that Aaron allow to use a regular expression (pattern) as the last parameter of sys.GoogleVoiceCall. In this case you could set it to /253\d{7,7}/ or even /*/ and bind any incoming call from 253 area or simply any incoming call that occurs within 15 seconds of GV dialout attempt. The probability of wrong binding is very low for most users and I'd rather submit to that.
synchron,
I had been using SIPBroker/Voxalot for toll-free calls until I figured out that all US toll-free numbers are listed in ENUM database
Here is a snippet of the code:
The whole of the code is here:
Flexible table-controlled dialplan
and here:
Flexible table-controlled dialplan, optimized for US, GV
Voxalot (Gizmo) dialing rules are still there but in fact they are just for backup purposes, normally dialing occurs by ENUM URI.
I had been using SIPBroker/Voxalot for toll-free calls until I figured out that all US toll-free numbers are listed in ENUM database
Here is a snippet of the code:
Code: Select all
if enumuri = sys.ENUMLookup("+#{@num}.e164.org") # Check if NAPTR exists for the number
sys.Log("ENUM entry found: '#{enumuri}'") # If yes, call that URI
result = sys.Dial(enumuri).ToString() # if call failed, call via regular VSP.
# If this is not what you want, add "return"
sys.Log("Call to #{enumuri} #{result}, will call again via regular VoIP provider")
end
Flexible table-controlled dialplan
and here:
Flexible table-controlled dialplan, optimized for US, GV
Voxalot (Gizmo) dialing rules are still there but in fact they are just for backup purposes, normally dialing occurs by ENUM URI.
The bogus 253 area code for my 360 IPKall number is not consistent. Last week my correct IPKall CID was displayed for a short while.MikeTelis wrote:I would suggest that Aaron allow to use a regular expression (pattern) as the last parameter of sys.GoogleVoiceCall. In this case you could set it to /253\d{7,7}/ or even /*/ and bind any incoming call from 253 area or simply any incoming call that occurs within 15 seconds of GV dialout attempt. The probability of wrong binding is very low for most users and I'd rather submit to that.
After reviewing their forums, I guess I was wrong and you can't use IPKall for outbound. Still, I think getting that recording is a little strange.Grampa wrote:synchron, isn't IPKall inbound only? It forwards to a SIP or IAX address, but you can't register your device to it. What am I missing?
Thanx for your suggestion
Synchron
Thanx. I'll give it a try. It would be ironic if the e164.org lookup is super quick and it only takes 3 seconds or so for the call to go through this way.MikeTelis wrote:synchron,
I had been using SIPBroker/Voxalot for toll-free calls until I figured out that all US toll-free numbers are listed in ENUM database
Here is a snippet of the code:
Code: Select all
if enumuri = sys.ENUMLookup("+#{@num}.e164.org") # Check if NAPTR exists for the number sys.Log("ENUM entry found: '#{enumuri}'") # If yes, call that URI result = sys.Dial(enumuri).ToString() # if call failed, call via regular VSP. # If this is not what you want, add "return" sys.Log("Call to #{enumuri} #{result}, will call again via regular VoIP provider") end
Synchron