Rejecting unknown sip connection from 127.0.0.1

Had an interesting issue come up today. We’ve got a sangoma PBX 40 with 10 or so S500’s installed at a customer and today out of nowhere they started getting a message saying “The number you have dialed is not in service” from asterisk. So, the calls were making it there. (They are on SIP.) And this is after the system has been installed and working great for a little over a year I think. So, I got to digging a little bit into asterisk log as a call came in and here is what I got at the point of the message being played.

   -- Executing [202@from-sip-external:1] NoOp("SIP/173.94.9.159-0000095f", "Received incoming SIP connection from unknown peer to 202") in new stack
  == Extension Changed 205[ext-local] new state Ringing for Notify User 204
  == Extension Changed 205[ext-local] new state Ringing for Notify User 200
  == Extension Changed 205[ext-local] new state Ringing for Notify User 207
  == Extension Changed 206[ext-local] new state Ringing for Notify User 205
  == Extension Changed 206[ext-local] new state Ringing for Notify User 203
  == Extension Changed 206[ext-local] new state Ringing for Notify User 204
  == Extension Changed 206[ext-local] new state Ringing for Notify User 200
  == Extension Changed 206[ext-local] new state Ringing for Notify User 207
  == Extension Changed 207[ext-local] new state Ringing for Notify User 205
  == Extension Changed 207[ext-local] new state Ringing for Notify User 206
  == Extension Changed 207[ext-local] new state Ringing for Notify User 203
  == Extension Changed 207[ext-local] new state Ringing for Notify User 200
  == Extension Changed 207[ext-local] new state Ringing for Notify User 204
  == Extension Changed 207[ext-local] new state Ringing for Notify User 207
    -- Executing [202@from-sip-external:2] Set("SIP/173.94.9.159-0000095f", "DID=202") in new stack
    -- Executing [202@from-sip-external:3] Goto("SIP/173.94.9.159-0000095f", "s,1") in new stack
    -- Goto (from-sip-external,s,1)
    -- Executing [s@from-sip-external:1] GotoIf("SIP/173.94.9.159-0000095f", "1?setlanguage:checkanon") in new stack
    -- Goto (from-sip-external,s,2)
    -- Executing [s@from-sip-external:2] Set("SIP/173.94.9.159-0000095f", "CHANNEL(language)=en") in new stack
    -- Executing [s@from-sip-external:3] GotoIf("SIP/173.94.9.159-0000095f", "1?noanonymous") in new stack
    -- Goto (from-sip-external,s,5)
    -- Executing [s@from-sip-external:5] Set("SIP/173.94.9.159-0000095f", "TIMEOUT(absolute)=15") in new stack
    -- Channel will hangup at 2019-12-04 10:29:21.958 EST.
    -- Executing [s@from-sip-external:6] Set("SIP/173.94.9.159-0000095f", "receveip=recvip") in new stack
    -- Executing [s@from-sip-external:7] Log("SIP/173.94.9.159-0000095f", "WARNING,"Rejecting unknown SIP connection from 127.0.0.1"") in new stack
[2019-12-04 10:29:06] WARNING[11460][C-000002e8]: Ext. s:7 @ from-sip-external: "Rejecting unknown SIP connection from 127.0.0.1"

So, just for kicks, I rebooted the phone that ext 202 was registered to and as soon as it was reachable, calls flowed as normal. WEIRD. I haven’t seen this particular issue before so really I’m just posting to maybe get a little understanding as to what may have happened. I’ve got the asterisk log from the whole call sequence if that’ll help.

A few things in this log are puzzling:

  1. The loopback (127.0.0.1) rejected the call, which could be an indication of a firewall or networking issues
  2. Executing [s@from-sip-external:5] Set("SIP/173.94.9.159-0000095f", "TIMEOUT(absolute)=15") in new stack seems to indicate that it could not connect to 173.94.9.159 within 15 seconds

Either way, without seeing this in real time to test, it’s kind of hard to say what is going on here, but my guess is it is an issue with the firewall or network.

I thought that was pretty weird too that the loopback was the one rejecting the call.

Here’s everything from the beginning if you’re feeling giddy (If any of it actually tells you something.)

A reboot of the phone “fixed” it. Interested to see if it happens again that’s for sure.

https://pastebin.com/SQhGZguP

If there isn’t really much to pull from it without actually seeing it happen again, it’s all good. Just thought the issue was really weird. Thanks @mbrooks for the response!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.