[asterisk-users] Workaround for bug in Linksys Firmware 6.1.3(a) (or greater)

[James Lamanna]

On Tue, Jun 22, 2010 at 12:06 PM, Stefan Schmidt <sst at sil.at> wrote:
> James Lamanna schrieb:
>> If you've used Linksys phones against recent Asterisk 1.4.x you may
>> have noticed
>> that they may drop registration for a quick bit and then go back to being ok
>> if your phone is behind NAT.
>> If you turn Asterisk's sip debug information on, you'll probably find
>> errors like these in your logs:
>>
>> NOTICE[30179] chan_sip.c: Correct auth, but based on stale nonce
>> received from '"999911" <sip:999911 at 208.90.186.10>'
>>
>> I believe I have determined that this is caused by a bug in the
>> Linksys firmware that is related to the NAT Keep-Alive packets.
>> Because recent Asterisk 1.4.x's do not establish a SIP dialog for
>> NOTIFY requests, the "489 Bad Event"
>> replies were going back to the wrong address if your phone was behind NAT.
>> This lack of reply would cause the next REGISTER message to use the
>> same nonce as the previous REGISTER,
>> resulting in the "stale nonce" errors and temporarily dropping
>> registration. I've also seen the lack of response to
>> the NAT keep-alive cause the phone to stop being able to register
>> completely as well.
>>
>> Below I've posted a patch that responds with a 200 OK to these
>> keep-alive requests, and I believe
>> also solves the temporary loss of registration problem, though more
>> testing in different environments
>> for those who experience this problem would be greatly appreciated.
>>
>> The patch is against 1.4.32.
>>
>> -- James
>>
> Hello,
>
> you also just could set the NAT KEEP ALIVE MESSAGE on Ext 1 from $NOTIFY
> to $OPTIONS and make this extension in your default context:
> exten => s,1,hangup
>
> and you also would get a 200 ok for the keep alive package.
>
> IMHO a stale nonce would only occur when a user tries to register faster
> than 3600s cause of the register timeout used in asterisk. Maybe you
> should also try to set a higher register timeout on your phones. but i
> dont have an 1.4 system running, only around 2k of linksys phones on a
> 1.2.40 and 300 on 1.6.1.18 and i dont see this problem there.

I'm not sure how this works.
The OPTIONS message fails chan_sip.c:parse_request() so the OPTIONS
message never gets processed.
The options message I receive from a Linksys942 6.1.3(a) looks like this:

<--- SIP read from xxx.xxx.xxx.xxx:8037 --->
OPTIONS
<------------->

-- James