Summary:	ASTERISK-01440: passwords can't be used with SIP behind NAT as SIP clients have trouble registering with secret and auth defined
Reporter:	chrisorme (chrisorme)	Labels:
Date Opened:	2004-04-20 12:10:58	Date Closed:	2011-06-07 14:10:10
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) authpatch.txt
Description:	If passwords are defined SIP clients (particularly ATA186 but also snom) have difficulties registering with * and fall to a not registered state quite frequently, (sometimes quickly recovering 30secs later, often not) at which time incoming calls then cannot be delivered.  Clients are behind NAT. * gives the client 401 Unauthorized when it fails to register. ****** ADDITIONAL INFORMATION ****** Very similar problem to one I reported some time before however latency was much higher in that case. Typical console output is : 'sip:devata186@212.18.255.13' failed for '213.137.20.127' Apr 20 16:27:26 NOTICE[81926]: chan_sip.c:5698 handle_request: Registration from 'sip:devata186@212.18.255.13' failed for '213.137.20.127' Apr 20 16:29:40 NOTICE[81926]: chan_sip.c:5960 sip_poke_noanswer: Peer 'devata1862' is now UNREACHABLE! Apr 20 16:29:41 NOTICE[81926]: chan_sip.c:5960 sip_poke_noanswer: Peer 'devata186' is now UNREACHABLE! Apr 20 16:30:04 NOTICE[81926]: chan_sip.c:4988 handle_response: Peer 'devata1862' is now REACHABLE! Apr 20 16:30:05 NOTICE[81926]: chan_sip.c:4988 handle_response: Peer 'devata186' is now REACHABLE!    -- Registered SIP 'devata186' at 213.137.20.127 port 35254 expires 240    -- Registered SIP 'devata1862' at 213.137.20.127 port 35254 expires 240
Comments:	By: Brian West (bkw918) 2004-04-20 12:24:15 THAT is far from correct and ok.. if you take the qualify= line out it will not do that. bkw By: Olle Johansson (oej) 2004-04-20 12:34:04 This patch is major error. Chris - this is only with ATA, right? The ATA behavies oddly. Retransmits messages with same Call ID and the same Cseq even though Asterisk replied and closed the transaction. By: chrisorme (chrisorme) 2004-04-20 13:06:07 I know the diff is horrible but it's the only way I could see to test if the issue was password related without reconfiguring the remote clients. If this is the ATA devata1863 devata1864 (two ports of one box) that behaves oddly then that is behind a different router than devata186 and devata1862 and on a different network and therefore it be the linksys routers fault or even a config issue in the cisco. With devata1863 devata1864 it is possible to make calls but not receive.  I don't think the Via 192. IPs in the debug help!  I'm tempted to blame the router in the case of 1863 1864 or revisit the config.   My main concerns are with devata186 /1862 and if that is behaving oddly despite a sensible router. By: chrisorme (chrisorme) 2004-04-20 13:15:15 snom dropped to 'NR' (failed to register) or was refused around 18:12 for about 3-4 minutes So registration problem may not just be limited to ATA By: Olle Johansson (oej) 2004-04-20 14:32:36 Seems like packets from Asterisk doesn't reach the device. Chris, you need to add a network analyzer on both sides of the NAT to see what happens. By: chrisorme (chrisorme) 2004-04-20 17:38:19 the .0.6 one?  Ok. just close this as 'not a bug' to save my embarrasment for being at the top of the bug list if it's not a bug and I'll turn off qualify (hoping that having nat=yes in sip.conf will keep the hole open), lengthen the registration intervals of the devices to 3600 and read lots of debug and the RFC and hopefully avoid having to learn all about SER.  I think mileage with ATAs such the Sipura and ATA186 might vary quite a lot depending on the router in front of them - maybe even phones too. By: Olle Johansson (oej) 2004-04-21 02:29:40 You either need asterisk or the device to send regular packets to keep the hole open. Nat=yes doesn't do anything to keep holes open, qualify= does. You might want to check the qualification timing if the NAT devices closes. Also, use Xten to check the type of NAT, if it is at all possible to do anything. Sipuras and Xten can be configured to send packets to keep the NAT relation open. I think newer ATAs can do that as well. By: Olle Johansson (oej) 2004-04-21 02:30:17 Installation-specific problems (NAT devices)