On Tue, Jun 22, 2010 at 4:31 PM, Ryan Wagoner <[email protected]> wrote: > On Tue, Jun 22, 2010 at 6:26 PM, James Lamanna <[email protected]> wrote: >> On Tue, Jun 22, 2010 at 12:06 PM, Stefan Schmidt <[email protected]> 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:[email protected]>' >>>> >>>> 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 >> >> -- > > I had the same result when using $OPTIONS on a SPA941 phone with > firmware 5.1.8. I am running Asterisk 1.6.2.9 that has the keep-alive > support, however I still see Asterisk sending a 489 Bad Event. I just > reopened the issue and provided the necessary debug log at > https://issues.asterisk.org/bug_view_page.php?bug_id=17379
Ryan, This is most likely because the packet never makes it to handle_request_notify. I haven't looked at the code for 1.6.2.9 yet, but in 1.4.32 without my patch, the NOTIFY request would never make it out of find_call() and return early with a 489 Bad Event response. Were you getting any response at 1.6.2.9 with the OPTIONS message? -- James -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
