Time-out and match params for GoogleVoice

New features you'd like see on SIP Sorcery
Post Reply
MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Time-out and match params for GoogleVoice

Post by MikeTelis » Tue Sep 29, 2009 7:52 pm

Dear Aaron,

Is it possible to make callback time-out of sys.GoogleVoiceCall flexible instead of hardcoded 10 seconds? You could add this parameter in the end of argument list.

Yet another request: it would be nice to change "match" parameter's type from string to pattern. Experimenting with IPKall, I noticed that sometimes callback comes with a wrong CID (some local number instead of my GV number). I could put them both in the pattern (/^(GVNUM|LOCALNUM)$/).

Mike

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: Time-out and match params for GoogleVoice

Post by Aaron » Wed Sep 30, 2009 12:09 am

MikeTelis wrote:Is it possible to make callback time-out of sys.GoogleVoiceCall flexible instead of hardcoded 10 seconds? You could add this parameter in the end of argument list.
I could do that easily enough. Is the 10s proving to be an issue? My callbacks generally come in at 3 or 4 seconds and I would have thought if it's taking over 10 there's a good chance it's never going to arrive.
MikeTelis wrote:Yet another request: it would be nice to change "match" parameter's type from string to pattern. Experimenting with IPKall, I noticed that sometimes callback comes with a wrong CID (some local number instead of my GV number). I could put them both in the pattern (/^(GVNUM|LOCALNUM)$/).
I did see this one last time you mentioned it as well. The problem is it's too dangerous to use a regular expression match as what's happening is that every incoming call to sipsorcery is being checked to see whether it's a callback and if so is being patched to the waiting user. Using a regular expression would just be asking for trouble. A pattern of .* would mean the next incoming call for any user would be matched. Even blocking out obvious ones like that would still leave a lot of latitude for erroneous matches.

The callback match doesn't necessarily have to be done only on the number. If you can find another piece of information in the IPKall incoming SIP request that would allow it to be definitively matched to a user that would be a better solution.

Regards,

Aaron

MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Post by MikeTelis » Wed Sep 30, 2009 3:38 am

what's happening is that every incoming call to sipsorcery is being checked to see whether it's a callback and if so is being patched to the waiting user.
What?! This approach would work if every Sipsorcery user supplied their GV number as the "match" parameter of GoogleVoiceCall. However, there is a ton of "misbehaving IPKall numbers". "Misbehaving" means that they all report the same CID when called back by GV. For example, all such IPKalls in 206 area code report (206) 204-0232 as caller's number.

Waiting for a callback from this number is not as bad as /*/ in match pattern, but pretty close :( And I was among those many who used this number as "match"...

I think you need to check only calls to SIP accounts whose owner is the user who initiated GoogleVoiceCall. For example, JoeBloggs has 2 SIP accounts, jb1@sipsorcery.com and jb2@sipsorcery.com. You should check only incoming calls to these 2 accounts and then apply pattern provided by Joe in his GoogleVoiceCall match param.

Update: using a chance to ask this question. Is there any particular reason you prohibit adding "sipaccount@sipsorcery.com" entries to SIP providers list? I thought it would be the easiest way of converting GoogleVoiceCall into SIP proxy (so I could use it with sys.Dial and sys.Callback) but it was before I figured that 'sipsorcery.com' domain can't serve as SIP provider...

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Wed Sep 30, 2009 11:47 am

MikeTelis wrote:Update: using a chance to ask this question. Is there any particular reason you prohibit adding "sipaccount@sipsorcery.com" entries to SIP providers list? I thought it would be the easiest way of converting GoogleVoiceCall into SIP proxy (so I could use it with sys.Dial and sys.Callback) but it was before I figured that 'sipsorcery.com' domain can't serve as SIP provider...
Because heaps of people end up creating a provider for sipsorcery.com and registering it which results in extra work for both the registrar and registration agent servers for absolutely no purpose.

I understand what you are trying to do with the GoogleVoiceCall proxy but that's also not the ideal approach and enabling sipsorcery.com providers for that purpose does not outweigh the previous point. The correct approach for the GoogleVoiceCall limitation is to enhance the functionality within the dialplan application and that means C#.

Regards,

Aaron

MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Post by MikeTelis » Wed Sep 30, 2009 12:23 pm

Because heaps of people end up creating a provider for sipsorcery.com and registering it which results in extra work for both the registrar and registration agent servers for absolutely no purpose.
Prohibiting "Register" checkbox for sipsorcery.com is one thing and prohibiting using this domain name as SIP provider's domain is the other. You could have opted for less radical measure... :)
I understand what you are trying to do with the GoogleVoiceCall proxy but that's also not the ideal approach and enabling sipsorcery.com providers for that purpose does not outweigh the previous point. The correct approach for the GoogleVoiceCall limitation is to enhance the functionality within the dialplan application and that means C#.
Yea, C#... I'm reading the book but it will take long time before I'm able to convert GoogleVoiceCall into a proxy (if ever!).

I absolutely agree with you, creating a SIP account dedicated to GoogleVoiceCall is certainly not the best solution, but it could serve as a temporary workaround. And yet, it would make me feel much safer (you need to know login name/password to use it as a proxy).

Well, we're getting away from the subject of this topic. So, what do you think about checking SIP account names first, before you verify caller ID against the "match" parameter? It would solve a lot of problems (now I understand why sometimes GoogleVoiceCall connected me to a wrong number) :)

Besides, it would allow /*/ patterns, nothing really bad is going to happen if you match next incoming call to SIP account that belongs to one particular user.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Wed Sep 30, 2009 1:34 pm

That's a fair enough request and is an improvement. I've gone ahead and implemented it now and hopefully there are no unanticipated side effects.

The GoogleVoiceCalls now match the username of the incoming call against the originating dialplan owner. In addition a regex can be used in place of the fromUserToMatch. A number in the field will still work since it's a valid regular expression. Example:

when /^501$/ then sys.GoogleVoiceCall("username@gmail.com", "password", "123456", "2132701859", "^89122")

There could still be side effects if you use a broad regular expression. For example if you use .* it will match the next incoming call to your account irrespective of whether it's the callback from GoogleVoice or not. At least now it can only ever be the next call to your account rather than any account.

Regards,

Aaron

MikeTelis
Posts: 1582
Joined: Wed Jul 30, 2008 6:48 am

Post by MikeTelis » Wed Sep 30, 2009 2:28 pm

That's a fair enough request and is an improvement. I've gone ahead and implemented it now and hopefully there are no unanticipated side effects.
Aaron, you're the man! Thank you!

I have tested this new feature and it works just as I expected.

What do you think about adding callback time-out parameter? Now that you are only monitoring incoming calls for one particular user, extending callback time-out to, say, 30 seconds wouldn't do much harm.

In my experiments, I observed Gizmo5 callbacks arriving as late as in 26 seconds after GV call was initiated...

Sincerely,

Mike

huibw
Posts: 34
Joined: Sun Sep 07, 2008 12:13 am

Post by huibw » Sat Oct 03, 2009 4:39 pm

Thank you! This IPKall random CID was driving me nuts. The timeout will be welcome as well. I have noticed that on occasion it seems that SipSorcery is slower. When I monitor the progress of a call through the console I see that when I dial a number it takes a couple of seconds (sometimes 10 or more) to show up. If SipSorcery also needs those extra seconds just for recognizing a call coming from Google you quickly go over the 10 seconds, as was happening for me 10 minutes ago (and perhaps still) and then the call goes to never never land.

Post Reply