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.