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

[Joshua Colp]

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.

> 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.

> 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.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org