Author Topic: SIP unable to connect; "Other Party" shows unfamiliar IP addr. (solved)  (Read 655 times)

n6ldj

  • Newbie
  • *
  • Posts: 14
    • View Profile
This is for information only.

I had a completely reliable connection that would consistently auto-connect following outages, etc. for about four months.  Used public routable IPs on both ends, no firewalls.  Not one connection problem (other than a ISP outage) in 4 months, and we maintain a 24/7 nailed-up connection.**

I dropped the connection for about one hour to rearrange some DC wiring and could not reconnect.  Sip error, and a UDP error.  Rebooted in various sequences many times.   But nothing had changed.  I then noticed that the Radio RRC showed an ip address of 172.83.45.42 (actual) in the "Other Party" field.  That is not one of mine, as it should be from the Control RRC when connected.  I have a managed switch at the site so I disabled the switch port supporting the Radio RRC overnight, then was able to re-connect in the morning. 

I found a message here indicating that this condition might be Carrier Grade NAT (CGN), but the radio end is supplied by a small ISP so that is unlikely.

I then sniffed the traffic coming into the Radio RRC and noted that the IP above was coming in with a destination UDP port that matched the default SIP port, every few seconds.  My guess is that these were possibly SIP connection attempts, but they did not know the password as it never showed connected.  It remains unclear why I could not connect between their attempts as there was not a flood of these.  Maybe the RRC locks out/delays repeated attempts, and the access attempt was regular enough to prevent me from connecting.

I just changed all of the default ports on the devices, including the Web server port, which might resolve this issue for a while.  This is becoming mroe important over the last few years.     

** Unrelated, we had the radio end running through a firewall and nat'ed before this current arrangement.  This arrangement was extremely unreliable from a auto-reconnect perspective.  Maybe I had the ports setup wrong, but sniffing showed that that the Control RRC's auto-reconnection attempts would often use the default destination port numbers to reach the Radio RRC, instead of the ones I set for for it.  As a result, it would get stopped by the firewall and not re-connect.  We had two Radio RRCs on the same site router so one had to use non-default ports.  I believe this problem remains in V2.95.  FYI.