[asterisk-dev] Please consider adding new sip peer/Google Voice retry options

[MichiganTelephone]

Joshua Colp wrote:

> MichiganTelephone wrote:
>> I'd like to see the following settings added for SIP configurations
>> for peers and (in particular) in the settings for whatever is used in
>> a Google Voice connection in Asterisk 11, unless there is already
>> some mechanism to handle it (I'm not on 11 yet so don't know):
> 
> Google Voice doesn't use SIP, it uses a Google derived Jingle protocol 
> which is handled by the chan_motif channel driver in Asterisk 11. This 
> channel driver does not have any of the functionality you describe 
> below, for a good reason.

The reason I asked for this capability in SIP also is because some of us use a SIP connection from one system to another, and it is the second system that does the actual interfacing with Google Voice and returns the 503 error.  I am not really familiar with the chan_motif channel driver because I'm not running Asterisk 11.

> 
>> errorretries= (default 0) errorretrydelay= (in ms, suggested default
>> 500) retryonerrorcodes= (comma separated list, suggested default
>> 503)
>> 
>> The idea is that when you are creating a trunk to Google Voice, it is
>> far too often the case that Google rejects the call with a 503 error.
>> But if you immediately retry the call, it will go through on the
>> second attempt.  Rather than force the user to hang up redial, why
>> not simply provide a mechanism that will retry the call one or more
>> times on the same trunk or connection prior to giving up, with an
>> optional short delay between attempts, and the ability to specify
>> that these retries should occur only if particular errors (in
>> particular the dreaded 503 error) are the cause of the rejection.
> 
> Google Voice doesn't reject the call with a 503, it rejects it with a 
> Jingle specific error (probably service-unavailable or something else). 
> This gets mapped into SIP as a 503.

So whatever the Jingle specific error is that gets mapped to a 503 error would be the one used to trigger the retry.  I figured that Google Voice probably doesn't send SIP error codes but I don't know anything about their protocols, so didn't know what kind of error they would send that would equate to the 503.

>> Sane values (for Google Voice) might be something like
>> errorretries=2, errorretrydelay=500, and retryonerrorcodes=503.  If
>> the errorretries value is not set it should default to 0, meaning the
>> call fails without any retries if an error is received, as happens
>> now.
> 
> The Google Voice servers have anti-attack/anti-spam/anti-something built 
> into them. If they sense you are doing something like the above they 
> will block you for a period of time. I know, it's happened to me during 
> the writing of chan_motif. This can even happen if you just place many 
> calls closely together. You need a human factor in there.

My question is, will they block you if you attempt a call, the call fails with the jingle-specific error you mentioned above, and only then do you immediately retry the call?  I can understand them blocking an account if they sense someone attempting mass calling or something like that, but if the call never went through on the first attempt, would they still block a retry half a second later?  It doesn't make sense to me that they would start whatever sort of timer they might use for their anti-attack/anti-spam algorithm on a call that failed to complete in the first place, but then this is Google we are talking about, where half of what they do makes no sense to me (particularly in regard to Google Voice).

Anyway thanks for the reply; I appreciate your insights.

Jack