Upate: There’s a bit of confusion around what needs to happen to take advantage of this latest fix.
- 1. NO changes need to be made to SIP accounts or the SIP account a particular ATA/Phone is using,
- 2. A change does need to be made to the registration contact being used for a provider IF it’s used for Google Voice callbacks AND the contact username is NOT the same as the web login username.
As people quickly discovered the new redundant sipsorcery deployment did not play happily with matching callbacks on Google Voice calls. The reason is that Google Voice calls from sipsorcery are not a SIP call at all but instead are initated with a HTTP request to Google Voice which generates a callback to a 3rd party SIP provider such as Gizmo (via SIP) or SIPGate (via PSTN) which if the provider is configured correctly forwards the call back to sipsorcery. If that all goes smoothly the sipsorcery server will receive the call and attempt to match it up to the SIP call that initiated the whole thing. Messy, yes; complicated, yes; one big hack, yes; since Google Voice don’t currently provide a public SIP gateway this mechanism is the only way to use Google Voice with sipsorcery, not that that’s a major goal of the project but it seemed like an interesting challenge at the time.
Anyway the introduction of a dual server deployment at sipsorcery meant that the forwarded call from the 3rd party SIP provider could now arrive at either server. That’s not an issue for pure SIP calls and the sipsorcery application servers are smart enough to know which proxy to use when forwarding to registered SIP accounts. However it is an issue when waiting for the Google Voice callback since the originating SIP call exists on a single specific server and if the forwarded callback does not arrive at the same server they won’t be matched up and more than likely the forwarded call will get rejected or cause a different phone to ring.
I have now put in a workaround (hack to a hack to a hack sort of thing) that will allow the callbacks to be correctly matched up. The caveat is that the forwarded call from the 3rd party SIP provider MUST be to the username of the owning account that is it can’t be to any old sipsorcery SIP account it MUST be a SIP account that has the same name as the username that’s used to login to the web site.
The new mechanism relies on telling the sipsorcery SIP proxies, that sit in front of the application servers, that the next call for a specific username should be directed to a specific application server. The reason the SIP account must be the exact same as the owning username is that the SIP proxies don’t have time to go looking things up in the database, they are designed to get the SIP packets to and from the other SIP servers as quickly as possible and introducing database checks would slow them down dramatically.
So the mechanism isn’t perfect but then again the original sipsorcery Google Voice call approach is not a beacon of purity either. Hopefully it should be enough to get people by.
sipsorcery.wordpress.com 
19 comments
Comments feed for this article
January 20, 2010 at 21:12
Sri Sri
I understand and complexity of getting Google Voice to work properly but I trust we are adding more mortar to cover the problem rather than fixing the root cause. You might disagree with me but for the past few weeks I realized using Gizmo (the first solution you came up with) is more reliable than the using DID providers like SIPGate.
I’d encourage improving the code that works with Gizmo. Yes Gizmo had problems earlier but looks like it is much better today. When I initiate a call from Google’s web interface and forward the call to Gizmo->Sipsorcery (local installation, code changed a bit, but not to affect any core Sipsorcery functionality) not a single call fails (admit I use this solution hardly for 1 to 2 calls a day). However I do not see such success when I use
Sipsorcery->Google->Gizmo->Sipsorcery
Sipsorcery->Google->SIPGate->Sipsorcery
Google(web)->SIPGate->Sipsorcery.
January 21, 2010 at 15:57
Benjamin
No wonder why I wasn’t able to place calls on my ATA, because it was under a sub sip account.. So I Deleted the sub account, created a new sipgate account with the same userid and pass, and copied my dialplan over to it and added my Gizmo account to it, and it works! Didn’t have to change my ATA setup at all. (Which would of been annoying)
January 25, 2010 at 02:29
Deg
“So I Deleted the sub account, created a new sipgate account with the same userid and pass, and copied my dialplan over to it and added my Gizmo account to it”
You need to elaborate here. This makes no sense. Out line steps and reasons for this. Why use both gizmo and sipgate? Why delete something to create anew? Sipgate dial plans dont work with gizmo.
January 25, 2010 at 03:49
Jose
Aside from the problem that I cannot make calls Google Voice Web -> SIPGate -> SipSorcery, my setup works very well and I am pleased. However, I would like to resolve the issue indicated above because I have all my contacts in Google Voice and when i am at my desk it is easier to originate an ATA call from Google Voice Web. I am very confused as to what needs to be done with my SIPGate or SIPSorcery setups. Would you please provide step-by-step instructions? I would hate to wreck an otherwise working installation with my blind attempts to fix one issue.
January 25, 2010 at 04:38
sipsorcery
I’ve updated the Google Voice Call App tutorial to include all changes, https://sipsorcery.wordpress.com/2009/08/13/google-voice-app-tutorial/.
January 25, 2010 at 06:46
Mike Telis
Question: is your new mechanism compatible with suffix matching? Is it okay to use prefix.myusername@sipsorcery.com instead of myusername@sipsorcery.com?
January 25, 2010 at 08:31
sipsorcery
Yes if you know what you are doing you can use a prefix on your username and incoming calls will still match up for Google Voice callbacks. I’m not going to encourage that approach for most people though as it’s additional complication and it’s already hard enough.
January 25, 2010 at 08:47
Mike Telis
Okay, then the prefix is not the cause of my problems. I’m desperately trying to restore GV dialout after your deployment of backup sipsorcery server. The problems are either no callback at all or callback not matched with outbound call (so callback is processed as an incoming call). My callback DIDs are from IPKall, IPCOMMS and Gizmo, all configured to forward calls to myusername@sipsorcery.com (Sipsorcery does not register to receive calls from DIDs). Match pattern is ‘.*’, so it shouldn’t be the cause.
Any ideas? I’m more than willing to PM my SS account credentials to you if it can help with the investigation.
Generally, what one should do if his callback DID does not allow registration to receive incoming calls and forwarding is the only way (this is the case with IPKall)?
January 25, 2010 at 09:48
sipsorcery
I’m not sure what the issue could be but as I do keep pointing out the whole Gogole Voice callback mechanism used at sipsorcery is fragile. It’s a higher priority for me to have a proper redundant SIP platform. If you’re desperate you could try tieing everything to one server by registering your ATA using one the sipsorcery server IP addresses and using the same IP address to forward the DIDs with.
January 25, 2010 at 12:03
Mike Telis
Registering to sip1.sipsorcery.com and forwarding everything to myname@sip1.sipsorcery.com works just as expected, thank you! However, I have quite a number of DIDs and switching to sip2 when sip1 is down would be a pain. Is there a way to create some DynDNS-style name I could use instead? Say, sip.sipsorcery.com with TTL 60 seconds pointing to the server who’s alive at the moment…
January 25, 2010 at 12:42
sipsorcery
Or can you have your cake and eat it too :).
The DNS provider I use for sipsorcery doesn’t support anything like that and I’m not confident it’s the right answer. Before I do anything else either in the code or configuration wise I’d like to get a better understanding of what’s happening. I spent a frustrating morning banging my head against the wall trying to work out why my callbacks were getting missed. The two causes I found were:
1. I had a softphone registered to sip2 and it had asked the proxy on sip1 to forward all incoming calls for me to app server2. I was testing calls from my IP phone registered to sip1 and the callback kept getting missed because it arrived at the sip1 proxy. Once the forward request on proxy 1 expired the problem resolved itself. The wider issue is if an ATA load balances its calls across both servers there’s a chance for conflict,
2. I haven’t gotten to the bottom of it but sipgate seem to be doing something funny when forwarding calls to a domain with SRV records. It’s possible they forward calls to ALL the servers with SRV records, possibly with a delay between each forward. That causes issues for matching callbacks. On some sipgate calls I was getting a callback match AND an incoming call.
I’ll continue to keep an eye on things to try and understand what’s going on but I don’t want to dedicate hours to it each day so it could take some time to determine what’s happening. Of course observations and hypothesis from others are welcome, the forums being the best place for any such.
January 25, 2010 at 13:36
Mike Telis
I have a feeling that the whole idea of combining backup server with load balancing wasn’t that great. If one of the servers is down the other is supposed to handle all the load, anyway. Therefore, it should have enough horsepower to do that. If so, why don’t you stick to mere switchover (to backup server) rather than keep applying a hack onto a hack? 🙂
January 25, 2010 at 22:02
sipsorcery
Your’e making a wrong assumption that supporting the GoogleVoice callbacks is the most important thing. Like the Betamax hacks before it the whole GoogleVoiceCall thing is solely to help a few users out because it was possible at the time. Google Voice could change things overnight and I’m not interested in building up elaborate mechanisms for it. If the hack to a hack gets too painful I’ll take the whole thing out and get back to SIP only integrations which is my area of interest.
In regards to utilising both the sipsorcery servers for fault tolerance AND load balancing it amkes perfect sense to me. Firstly because it relies a standard (RFC3263) employed by most of the SIP ecosystem, and I don’t want to have to start fighting against ATA’s and phones. Secondly the load on a single server was only months away from topping out it’s EC2 instance, once it did that I’d need to scale up to a bigger EC2 instance, which doubles the cost, and with your approach I’d also need to scale up the standby server so I’d quadruple my costs!
January 25, 2010 at 22:41
Mike Telis
If it was only GoogleVoiceCall callbacks issue, I would agree (with a sigh, because I really like the thing and use it a lot). However, it also affects incoming calls in general. In particular, callbacks initiated from GV website intermittently failed and those callbacks are in fact regular incoming calls. Jose also complained about the same problem (see above). So, I’d consider GoogleVoiceCall as an indicator where the problem is most acute rather than something extraordinary that can be easily dismissed.
Anyway, I’m not going to insist, don’t have enough knowledge and expertise in this field.
P.S. Aside from GoogleVoice, what would you recommend to do with IPKall DID? I mean, if DID can only forward calls to some SIP URI, what should I do to forward it to my main SIP account? What if I want to forward it to a secondary SIP account (SIP account name != login name)?
January 25, 2010 at 23:00
sipsorcery
I test GoogleVoice calls with Gizmo and SIPGate and in general they work with the same level of reliability as before the redundancy upgrade, I’d estimate about a 90% success rate.
I wouldn’t disagree that there are now some additional quirks when receiving calls from 3rd party providers. I mentioned previously I’ve seen some oddities with inoming calls from SIPGate where they seem to fork calls to all SRV records. I suspect there will be others as well. My previous point was if the cause of the failures/quirks can be understood it would be possible to consider doing something about it.
As previously mentioned you can go back to the exact same set up you had previously by using the IP address of one of the servers in your ATA and SIP Provider registration contacts. That will tie all your calls and registrations to a single server. If you want redundancy and the supposed quirks it involves with callback then you use sipsorcery.com everywhere. If you want both I don’t have the answer.
January 26, 2010 at 06:16
Mike Telis
I can’t tell about Sipgate because I don’t have one but in my experiments a Gizmo DID forwarded to myusername@sipsorcery.com gave about the same failure rate as IPKall. Your results are way better and I think it’s because you registered into Gizmo to receive incoming calls.
I already switched to srv1 and it works like a charm, thank you! What I’m concerned about is switching over to srv2 should it be necessary. Isn’t it possible to add a DynDNS name like sipsorcery.thruhere.net and switch it to whatever server is alive and less loaded? I remember seeing source code for DynDNS update clients, both in C and in Perl…
January 26, 2010 at 06:39
sipsorcery
You’re missing the point I’ve already implemented redundancy, including at the DNS level, in a manner that’s desinged for SIP. You’re barking up the wrong tree here rather than trying to get me to implement even more hacks and workarounds why not get onto GoogleVoice and hassle them about opening up their SIP gateway.
January 26, 2010 at 01:01
Jose
Thanks very much for your prompt response to the issue of Google callbacks to ATA. I made all the changes you suggested and the service now works well. I can use GV web to make calls into my ATA phone.
January 26, 2010 at 10:01
Mike Telis
Of course, SIP gateway to GV would come handy (and in fact, there was a gateway but GV closed it half a year or so ago). Anyway, let’s forget about GV for a moment.
Is there a way to receive (with confidence) incoming calls from IPKall DID ? What if I register my ATA to a subaccout (SIP account name != SS login name)?
So far, it only works if I bypass new mechanisms and use either sip1 or sip2 everywhere.