Summary: | ASTERISK-14202: [patch] [SIP realtime] "sip reload" makes UNREACHABLE users behind NAT | ||
Reporter: | Iñaki Baz Castillo (ibc) | Labels: | |
Date Opened: | 2009-05-26 08:17:41 | Date Closed: | 2011-01-06 15:02:10.000-0600 |
Priority: | Blocker | Regression? | Yes |
Status: | Closed/Complete | Components: | Channels/chan_sip/Registration |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) sip.patch | |
Description: | When a SIP dynamic realtime user is registered behind NAT (with "nat=yes"), a "sip reload" command makes Asterisk "forgetting" the public location of the peer, and instead uses the private address of Contact header to reach it. Of course it fails and causes the user to be UNREACHABLE. ****** STEPS TO REPRODUCE ****** - Asterisk with public IP. - SIP users/friends in dynamic realtime (sip_buddies table). - Peer behind NAT: - Router public IP: 99.99.99.99 - Peer private IP: 10.10.10.10 - The peer has "nat=yes" and "qualify=yes". - Peer is registered in Asterisk and Asterisk sends OPTIONS to public IP (99.99.99.99) to mantain the keepalive (as usual). - The correct info (about public IP) is stored in MySQL "sip_buddies" table and astdb. - Now I do "sip reload". - After it Asterisk performs "Dial(SIP/PEER)" and the INVITE is sent to the peer private address (10.10.10.10), the same for the keepalive OPTIONS sent from Asterisk. - Of course this causes the peer to be set as UNREACHABLE until it registers again. ****** ADDITIONAL INFORMATION ****** SIP realtime section in sip.conf: rtcachefriends=yes rtsavesysname=yes rtupdate=yes | ||
Comments: | By: Iñaki Baz Castillo (ibc) 2009-05-26 08:22:46 Also confirmed in version 1.4.24-rsp. By: Leif Madsen (lmadsen) 2009-05-26 08:27:11 In which version does this work on? I'm trying to track down to determine if this is really a regression, and if so, where the regression happened. By: Iñaki Baz Castillo (ibc) 2009-05-26 08:28:21 I'm testing some older versions right now to check if it has worked fine before the current version. I'll comment it here soon. By: Iñaki Baz Castillo (ibc) 2009-05-26 08:34:19 This is a regression! It doesn't happen, at least, on 1.4.19.1. I will check other versions after it. By: Iñaki Baz Castillo (ibc) 2009-05-26 08:43:54 It also fails on 1.4.22.2. By: Iñaki Baz Castillo (ibc) 2009-05-26 09:03:40 If doesn't occur in 1.4.20.1. By: Leif Madsen (lmadsen) 2009-05-26 09:03:54 OK, can you try to narrow down to which version first shows this new behaviour? That way we can focus between just the working and non-working version. Thanks! By: Leif Madsen (lmadsen) 2009-05-26 09:04:42 If you even went so far to investigate the ChangeLogs and try the various revisions on SVN to try and track down where the change actually occurred, I wouldn't be offended :) By: Iñaki Baz Castillo (ibc) 2009-05-26 09:06:23 Yes, I'm testing now 1.4.21. For now we already know the following: VERSION BUG 1.4.25 YES 1.4.24 YES 1.4.22.2 YES 1.4.20.1 NO 1.4.19.1 NO By: Iñaki Baz Castillo (ibc) 2009-05-26 09:15:24 VERSION BUG 1.4.25 YES 1.4.24 YES 1.4.22.2 YES 1.4.21.2 NO 1.4.20.1 NO 1.4.19.1 NO By: Iñaki Baz Castillo (ibc) 2009-05-26 09:24:49 VERSION BUG 1.4.25 YES 1.4.24 YES 1.4.22.2 YES 1.4.22.1 YES 1.4.21.2 NO 1.4.20.1 NO 1.4.19.1 NO By: Jon Bonilla (manwe) 2009-05-26 09:25:11 The bug only occurs if rtupdate is enabled. By: Iñaki Baz Castillo (ibc) 2009-05-26 09:29:47 > The bug only occurs if rtupdate is enabled. Not true. Tested in 1.4.22.1 and 1.4.25 with "rtupdate=no" and the bug also occurs. Before each test I'm doing, I stop Asterisk, delete astdb and clear the register information fields in sip_buddies table. By: Iñaki Baz Castillo (ibc) 2009-05-26 09:40:51 VERSION BUG 1.4.25 YES 1.4.24 YES 1.4.22.2 YES 1.4.22.1 YES 1.4.22 YES 1.4.21.2 NO 1.4.20.1 NO 1.4.19.1 NO So it's clear that the bug occurs between 1.4.21.2 and 1.4.22. By: Jon Bonilla (manwe) 2009-05-26 11:19:07 It seems tha deleting the line "__set_address_from_contact(fullcontact, &peer->addr);" fixes the regression. Line 17685 of chan_sip in 1.4.25 As pointed out by Julian J Menendez seems that regression came in rev 138258 By: Eliel Sardanons (eliel) 2009-05-27 14:33:41 Could someone try this patch, i think this could fix the issue, but didn't test it. By: Jon Bonilla (manwe) 2009-05-28 04:08:08 I have tryed versions 1.4.24 and 1.4.25 with and without the patch. I haven been able to reproduce the bug when rtupdate was unset. When set, the bug appeared 100% of the times. After aplying the patch the bug did not appear in any case. It worked for me. By: Digium Subversion (svnbot) 2009-05-28 10:21:33 Repository: asterisk Revision: 197562 U branches/1.4/channels/chan_sip.c ------------------------------------------------------------------------ r197562 | eliel | 2009-05-28 10:21:33 -0500 (Thu, 28 May 2009) | 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue ASTERISK-14202) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=197562 By: Digium Subversion (svnbot) 2009-05-28 11:01:49 Repository: asterisk Revision: 197621 _U trunk/ U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r197621 | eliel | 2009-05-28 11:01:49 -0500 (Thu, 28 May 2009) | 19 lines Merged revisions 197562 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue ASTERISK-14202) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=197621 By: Digium Subversion (svnbot) 2009-05-28 11:15:20 Repository: asterisk Revision: 197625 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c ------------------------------------------------------------------------ r197625 | eliel | 2009-05-28 11:15:19 -0500 (Thu, 28 May 2009) | 26 lines Merged revisions 197621 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines Merged revisions 197562 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue ASTERISK-14202) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=197625 By: Digium Subversion (svnbot) 2009-05-28 13:26:51 Repository: asterisk Revision: 197696 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r197696 | eliel | 2009-05-28 13:26:51 -0500 (Thu, 28 May 2009) | 26 lines Merged revisions 197621 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines Merged revisions 197562 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue ASTERISK-14202) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=197696 By: Digium Subversion (svnbot) 2009-05-28 14:00:22 Repository: asterisk Revision: 197704 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r197704 | eliel | 2009-05-28 14:00:22 -0500 (Thu, 28 May 2009) | 26 lines Merged revisions 197621 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines Merged revisions 197562 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines Use the address we already know when reloading a peer with nat=yes. If we already have an address for a peer, and we are reloading the sip configuration, try to use that address to contact the peer, instead of getting it from the Contact. (closes issue ASTERISK-14202) Reported by: ibc Patches: sip.patch uploaded by eliel (license 64) Tested by: manwe ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=197704 |