News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Sipsorcery for no XMPP calling with Google Voice

Started by giqcass, December 12, 2013, 03:14:40 AM

Previous topic - Next topic

azrobert

#20
Your ITSP DigitMap will match the dialed number with "xx.".
OutboundCallRoute processing goes left to right using the first matching rule, so it doesn't matter if the VG2 rule is first.

Check the OBi call history to see what's happening.
Log into the OBi directly using the Web interface.
Go to Status -> Call History.

You are dialing the number with a "2" prefix?

AntonS

In the Call history it shows the number without the "2", while I do dial with the "2" prefix. The call is made by GoogleVoice1. I had put the VG2 rule not quite at the beginning, so I'll change that and see what happens.

AntonS

I just moved {(Mvg2):vg2} and 2xxxxxxxxxx|2xxxxxxx|2011xx. to the front of  Phone Port OutboundCallRoute and of the Digit Map respectively and now the call does not go out at all. After a long silence with some clicking noises I get the dial tone.

AntonS

I tried this again (maybe the Obitalk network does not update immediately). Now I got an error message and I had the console open at Sipsorcery and saw this:
DialPlan 02:10:15:394 sip1(6116): There was a syntax error in your dial plan on line 21, please check.
DialPlan 02:10:15:394 sip1(6116): Dialplan cleanup for user.
DialPlan 02:10:15:473 sip1(6116): Dial plan execution completed without answering and had an execution error message of Dial plan syntax error.
DialPlan 02:10:15:473 sip1(6116): UAS call failed with a response status of 500 and Dial plan syntax error.

As far as I can see line 21 is the end of the script, so I don't quite understand the error message (the "2" was stripped successfully from the number)

AntonS

I found one error. When I copied your Ruby script, I missed the second "end". I added it and tried again, but now I had another error:
DialPlan 02:17:27:791 sip1(6116): Using dialplan dialplan for Out call to sip:803xxxxxxx@sipsorcery.com.
NewCall 02:17:27:806 sip1(6116): Executing script dial plan for call to 803xxxxxxx.
DialPlan 02:17:27:853 sip1(6116): Phone Number 803xxxxxxx
DialPlan 02:17:27:853 sip1(6116): SDP on GoogleVoiceCall call had public IP not mangled, RTP socket xxx.53.114.116:16802.
DialPlan 02:17:27:853 sip1(6116): UAS call progressing with Ringing.
DialPlan 02:17:27:853 sip1(6116): Logging into google.com for user.
DialPlan 02:17:27:884 sip1(6116): Google Voice pre-login page loaded successfully.
DialPlan 02:17:27:900 sip1(6116): GALX key G0q9gKFG5H0 successfully retrieved.
DialPlan 02:17:28:494 sip1(6116): Google Voice home page loaded successfully.
DialPlan 02:17:28:509 sip1(6116): Could not find _rnr_se key on your Google Voice account page, callback cannot proceed.
DialPlan 02:17:28:509 sip1(6116): Exception on GoogleVoiceCall. Could not find _rnr_se key on your Google Voice account page, callback cannot proceed.
DialPlan 02:17:28:509 sip1(6116): Dialplan cleanup for user.
DialPlan 02:17:28:837 sip1(6116): Dial plan execution completed without answering and with no last failure status.
DialPlan 02:17:28:837 sip1(6116): UAS call failed with a response status of 480.

Here 803xxxxxxx is the number I was trying to dial, but I have no clue what "_rnr_se key on your Google Voice account page" means.

AntonS

It seems that Google is blocking Sipsorcery from accessing my account, as its login originates from an unknown location. I got emails from Google about this referring me to web a page where I could click to say that this was me (or change my password if it wasn't me), but after clicking that it was me,  I still got "Browser sign-in attempt (prevented)" on my next attempt and I can't see on Google's webpages how to get around that. On that same webpage it says:"For your security, we will continue to display these events for 2 weeks." Maybe this means that after 2 weeks it will start working.

AntonS

I found though some Googling that going to the page:
https://accounts.google.com/DisplayUnlockCaptcha
one gets around login issue, but somehow the callback did not happen fast enough and timed out:
ContactRegisterInProgress 03:27:22:926 sip1(1740): Initiating registration for user on sip:callcentric.com.
ContactRegistered 03:27:23:020 sip1(1740): Contact successfully registered for user on sip:callcentric.com, expiry 65s.
DialPlan 03:27:32:957 sip1(17704): Google Voice Call timed out waiting for callback.
DialPlan 03:27:33:004 sip1(17704): Google Voice Call to  was successfully cancelled.


azrobert

#27
The 20 (last parm) is a timeout value. 20 seconds should be more than enough, but you can set it higher.
Make sure the DID type matches how you defined the Forwarding number in GV. It won't work if it doesn't match.

sys.GoogleVoiceCall("GVuserID", "password", "12121234567", "#{dialnum}", ".*", 1, 20)
# GVuserID without @gmail.com
# 12121234567 = Callcentric DID
# Next to last parm = GV forwarding DID type. 1=Home, 2=Mobile, 3=Work

azrobert

I made several changes to my last post because I didn't carefully read your posts.

You have dual registrations to Callcentric. One registration from the OBi and another from SipSorcery. The call from GV should be routed to both.  You can try unregistering Callcentric on the OBi and see if that makes a difference.

AntonS

I am away from my home Obi so I can't test your suggestions. I am at another location where I have another Obi which calls via a speed dial out over Google Voice on  my Home Obi. As an experiment I registered that second Obi with Sipsorcery and tried to dial out to a number prepending the number with **2. As all my outgoing calls are redirected to my first Obi I got the Obi attendant and pressing 1 the call continued, but kept ringing (while an answering machine should have picked it up), so I am not sure that worked. I don't want to mess too much with this second Obi right now (as it is my most reliable phone connection), so I'll wait until I'm back home to try this again.

mrjoe

Just managed to track down the login details for my free account! :)

Going to have some fun with this!

Can you bridge 2 voip accounts using their switches?

azrobert

Quote from: mrjoe on December 29, 2013, 04:54:03 AM
Can you bridge 2 voip accounts using their switches?

Please explain what you want to do.

mrjoe

I want to register a SIP account and have Sipsorcery forward incoming calls via another SIP account.

azrobert

#33
If you want fun you can definitely have it with SipSorcery.

Place following in the inbound section of your dial plan:

Bridge an inbound call to a user at Callcentric:
     sys.Dial("17771234567@in.callcentric.com[fu=#{CID}]")

Bridge an inbound call to an IP address. This can be your OBi.
      sys.Dial("user@someone.dyndns.com:5061[fu=#{CID}]")

The free account only allows 1 provider, but you can route calls to SipSorcery by IP address.
Example: setup IPKall to yourID@sipsorcery.com

When you have multiple providers you normally can't determine which provider is sending the inbound call. There is a trick to determine the provider. Let me know if this is a requirement.

In the outbound section of the dial plan you can send a call to the OBi like this:
sys.Dial("#{dialnum}@you.dyndns.com:5061",30)

Then route the call out a SP:
{YourSipSorceryID>(Msp1):sp1}

This is another OBion replacement.

mrjoe

thank you for that azrobert.  I'm pretty new to this.

shame I can only use 1 sip account, but it is useful to be able to forward an existing "locked" DID to another account.

what account forwards to the SIP address?  Is it the main sipsorcery account or does it go back out via your SIP provider?

azrobert

#35
The only providers I know that can route calls to SipSorcery without registration are IPKall and Callcentric. See giqcass' reply #2 step 4 to setup Callcentric. I'm sure there are others.

This is the info available on an inbound call:
UserID = req.URI.User     
CID = req.Header.From.FromURI.User
CallerName = req.Header.From.FromName

When you bridge the call you set the CallerId and CallerName like this:
sys.Dial("someone@dyndns.com[fu=#{CID},fd=#{CallerName}]")
or
sys.Dial("someone@dyndns.com[fu=#{UserID},fd=#{CallerName}]")
or
sys.Dial("someone@dyndns.com[fu=8005551212,fd=#{CallerName}]")

On an outbound call the UserID of the extension (account) you are registered to is available like this:
UserID="#{req.Header.From.FromURI.User}"

When you do this:
sys.Dial("#{dialnum}@you.dyndns.com:5061",30)

It defaults to the extension UserID. I think you can override this with the "fu" parm, but I never tried it.

Edit:
On an inbound call the UserID is the SipSorcery target ID.
So if your SipSorcery main account is "user" and you have sub-accounts "user2" and "user3", UserID will be one of these depending on how the call was routed to SipSorcery.

deskjockey

I also have an old Sipsorcery account that I once used for GV, using IPComms as my DID. I blamed latency on the Linksys ATA and ended up with 4 Obi devices that improve latency and time to connect the call. But at my age I don't remember much but want to set it up again.

Will having Obi registered with GV conflict with SS registering? IPComms' site shows I can make two concurrent calls, it acting as two lines, if that also is a consideration.

Thanks in advance

drgeoff

Quote from: deskjockey on January 30, 2014, 03:13:52 PM
Will having Obi registered with GV conflict with SS registering?
I think it will not conflict.  SS does not register with GV in the same way that a SIP client registers with a SIP server.  SS only communicates with GV when you place a call.  It emulates the GV method of making a call via your GV web page, inputting the number you wish to call and indicating the callback number.

But why not try it for yourself and report back here with the result?

CLTGreg

This is cool and all but reading their recipe it seems like they are just call forwarding to a phone number that then trickles down through a SIP provider. I'm not sure why I would do that over the free Callcentric NY number (which I wasn't impressed with the quality last night) unless I needed some of the other functionality such as multiple Google Voice #s which is cool.

What isn't cool and what I'm more nervous about is my primary number is linked to an account that links to a lot of other stuff. I'm skittish on giving out my user name and password to a third party that will unlock my entire Google experience.

If I would have planned better I would have set this up different so the account wasn't critical but it is and I'm hard press to give out the authentication.

I'm probably missing something but I don't see the advantage here unless you could use the other features.

deskjockey

drgeoff,

Thanks, I agree but I feared I was missing something and needed encouragement. I still think I better test it on a lightly used number just in case.

I will probably take day if not next week seeing IPComm tech is off weekends because I suspect I will run into a communication problem between IPComms and SS.