| Summary: | ASTERISK-14127: Routing Extensions between 2 asterisk servers in 2 directions fails with "482 Loop Detected" | ||
| Reporter: | Greg Nutt (timeshell) | Labels: | |
| Date Opened: | 2009-05-14 09:35:22 | Date Closed: | 2009-05-18 08:39:20 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) data ( 1) Debug_from_Initiating_Server.txt | |
| Description: | A* has a user created by asterisk-gui2. B* has a trunkA created to connect to user on A*. Calling rule for trunkA on B* allows exts connected to B* to call exts on A*. Now, I want exts connected to A* to be able to call exts on B*. Scenario 1 Create SIP trunk user on B* with asterisk-gui2. Connect trunk from A* to user on B* and appropriate outgoing rule. Result: calls from one or both sides will get error in CLI reporting "482 Loop Detected" Scenario 2 Create SIP trunk using asterisk-gui2 on A* but leave hostname, username and secret blank. Change registersip to = no. Manually edit extensions.conf and change the global for the new SIP trunk to be something like "trunk_1=SIP/A*Ext" where A*Ext is the trunk extension for B* to connect a trunk to A*. Create outgoing rule on A* to route B* exts to B*. Create incoming rule on B* to accept incoming calls on trunk to A* and set it to route to ${EXTEN}. Result: Calls may or may not work in one direction and the other direction will not work reporting "482 Loop Detected" ****** ADDITIONAL INFORMATION ****** When the loop is detected, it's only on the server where the call is originating from. The only real useful debug information is from the originating server as below. No debug information appears on the destination server. It appears that the call is rejected before getting there. # <--- Transmitting (no NAT) to 0.0.0.0:5060 ---> # SIP/2.0 482 Loop Detected # Via: SIP/2.0/UDP 142.46.193.201:5060;branch=z9hG4bK07866dd3;received=127.0.0.1;rport=5060 # From: "asterisk" <sip:asterisk@142.46.193.201>;tag=as0795686f # To: <sip:67000@206.248.146.138>;tag=as0795686f # Call-ID: 58b77e221e026eac22138ed67e5e959b@142.46.193.201 # CSeq: 102 INVITE # User-Agent: Asterisk PBX # Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY # Supported: replaces, timer # Content-Length: 0 # X-Asterisk-HangupCause: User busy # X-Asterisk-HangupCauseCode: 17 | ||
| Comments: | By: Greg Nutt (timeshell) 2009-05-15 08:49:24 Debug from initiating server attached. Remote server has no debug information. The debug shows all the debug information from the beginning to the end of the call attempt. By: Greg Nutt (timeshell) 2009-05-15 08:51:52 Related Peer in CLI from initiating server: localhost*CLI> sip show peers Name/username Host Dyn Nat ACL Port Status NUTT_LOCAL/7193 206.248.146.138 N 5060 Unmonitored 5281/5281 206.248.146.138 D N 5060 OK (22 ms) By: Greg Nutt (timeshell) 2009-05-15 08:52:31 Related Peer in CLI from remote server: torrent*CLI> sip show peers Name/username Host Dyn Nat ACL Port Status LUSI_LOCAL/5281 142.46.193.202 5060 Unmonitored 7193/7193 142.46.193.202 D N 5060 Unmonitored By: Greg Nutt (timeshell) 2009-05-15 13:57:17 New info about the looping issue. I created a server outside the firewall, so BOTH servers are now sitting right on the internet. I created a one-way link from one server to the other. It worked for a little bit and then started looping after I changed the codecs and reloaded. So, it apparently may not have anything to do with reverse trunking but with one way trunk between 2 asterisk servers configured using the asterisk-gui. By: Mark Michelson (mmichelson) 2009-05-15 15:34:02 The sip debug you attached shows a legitimate loop. The telltale sign is this here: <--- SIP read from UDP://127.0.0.1:5060 ---> INVITE sip:7000@206.248.146.138 SIP/2.0 Right above this, you sent an INVITE out, and then immediately you read an INVITE on the loopback address. This means that you are routing the INVITE to yourself and thus have a loop. This means that you either configured your routes incorrectly, or the Asterisk-GUI has a bug in its configuration setup. Regarding other scenarios, I haven't looked too deeply into it, but I have committed a patch just yesterday to solve issue ASTERISK-11643, which may be related. By: Greg Nutt (timeshell) 2009-05-15 21:29:28 I've discovered part of the problem. I discovered that when I first create a trunk and apply changes through the gui, the trunk works. When I subsequently edit and save, even if I haven't made changes, and then apply changes, it stops working. I further have discovered that the change that occurs in the trunk configuration that is preventing it from working is the "outbound proxy=" setting. The interesting thing is however, the only way I was able to determine this was by removing the setting "outbound proxy=" and unloading chan_sip.so and reloading it. Just doing a usual reload from the CLI didn't work. This is what hampered my previous attempts to troubleshoot as I tried removing the settings one by one before by only reloading rather than unloading the module. So, in short, this may indeed be an issue with how the gui saves subsequent trunk data after the trunks creation. By: Digium Subversion (svnbot) 2009-05-18 08:36:18 Repository: asterisk Revision: 195089 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r195089 | file | 2009-05-18 08:36:18 -0500 (Mon, 18 May 2009) | 5 lines Fix a bug where specifying an empty outboundproxy would cause packets to get sent to ourself. (closes issue ASTERISK-14127) Reported by: timeshell ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=195089 By: Digium Subversion (svnbot) 2009-05-18 08:37:21 Repository: asterisk Revision: 195090 _U branches/1.6.0/ U branches/1.6.0/channels/chan_sip.c ------------------------------------------------------------------------ r195090 | file | 2009-05-18 08:37:21 -0500 (Mon, 18 May 2009) | 12 lines Merged revisions 195089 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r195089 | file | 2009-05-18 10:36:17 -0300 (Mon, 18 May 2009) | 5 lines Fix a bug where specifying an empty outboundproxy would cause packets to get sent to ourself. (closes issue ASTERISK-14127) Reported by: timeshell ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=195090 By: Digium Subversion (svnbot) 2009-05-18 08:38:20 Repository: asterisk Revision: 195091 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r195091 | file | 2009-05-18 08:38:20 -0500 (Mon, 18 May 2009) | 12 lines Merged revisions 195089 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r195089 | file | 2009-05-18 10:36:17 -0300 (Mon, 18 May 2009) | 5 lines Fix a bug where specifying an empty outboundproxy would cause packets to get sent to ourself. (closes issue ASTERISK-14127) Reported by: timeshell ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=195091 By: Digium Subversion (svnbot) 2009-05-18 08:39:18 Repository: asterisk Revision: 195092 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c ------------------------------------------------------------------------ r195092 | file | 2009-05-18 08:39:18 -0500 (Mon, 18 May 2009) | 12 lines Merged revisions 195089 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r195089 | file | 2009-05-18 10:36:17 -0300 (Mon, 18 May 2009) | 5 lines Fix a bug where specifying an empty outboundproxy would cause packets to get sent to ourself. (closes issue ASTERISK-14127) Reported by: timeshell ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=195092 | ||