SIP Problems on 155

My system is not handling SIP data properly from what I can see. Calls coming in from my ISP are ignored. They say it’s my firewall. I’m not so sure. I have IPFIRE send the necessary ports to my Cisco ATA model SPA112.
I am on 155 and aware that the ALG situation changed, however I had disabled ALG whilst on 154, rebooted, and able to access my VOIP from remotely then.
The Cisco is set to handle SIP on TCP port 7000.
These are the rules in IPFIRE:

With the ISP we also tried 5060, hence that rule, and I have the ATA temporarily available to remote administration on port 8081 (which does work).
Using nc from a remote machine, I get a connection refused response;
nc: connect to port 7000 (tcp) failed: Connection refused

Firewall Logs show where the packets are obviously forwarded…but denied connection?

So is it the Cisco ATA at fault?

@onyxnz: Welcome to the community!

If that ATA worked before, I very much doubt it.
My SPA122 is the “larger brother” of your model SPA112.
Please, c.f. the mini-HowTo and the additional background information given in Addendum and Notabene.

If this is set up properly, you should not need any port forwarding rules at all!

  • Is this ATA your one and only SIP device in your network, or do others have to co-exist?
  • Where is it located [Orange | Green | Blue ] ?
  • How is it’s network configured?

We need a bit more details to help you …

EDIT: Forgot to mention:
Upgraded in the way described, 155 works flawlessly like a charm for me!
Many thanks @ms and the whole crew behind IPFire !

1 Like

Thanks for the welcome, Herr Knick! Wie geht’s?

Ok, so the port forwarding I punched in because things stopped working.

The ATA is the one and only SIP on the network.
The network is LAN (GREEN) (including ATA) → IPFire(RED) → outside evil world. (Simple as can be!!)
I do have other port forwards handling the hand off to an internal web server/ mail server, all in the green.
I am a web developer and linux nerd, so not afraid of getting my paws dirty…but unsure about SIP in general, nor what to look for when it stops working.
The Cisco SPA112 has been upgraded to latest firmware (dated 2019), without change in it’s apparent utility.

if port forwarding is unnecessary, then the SIP connection must be green initiated, yes? ie the SPA112 makes a connection to the SIP server at the ISP (too many TLAs!!) ?
And if that is so then any break down in communications is purely because the SPA112 is either stuffed(technical term :stuck_out_tongue: ), or the ISP’s SIP server is?

The SPA112’s connection status shows that it is internet connected, and registered with their server. I can dial out with it, using the crappy little Panasonic cordless phones we have. It’s incoming that fails over to the ISP’s Voicemail system immediately.

Other relevant info:
My SPA112 Voice status:

Is that “Mapped SIP Port” the issue??

The IPFire general Firewall Options:

Vielen dank!

1 Like

Also I have just rebooted IPFire, and note the following log:
The source being the Cisco SPA112, the destination being the ISP’s Voip server.
The interesting things about this are:

  • The packets are dropped by IPFIRE, yet are valid(?)

  • The SPA112 is specifically set in it’s SIP settings, to TCP, port 7000. NOT 5060, which is where the traffic is going.

First quick answer:

ATA = “one and only SIP device”: just stick to the defaults! (kiss)

  • SIP: 5060
  • RTP: 5004 (… 5008) (your SPA122 has two phone lines only, so you never need more)

Will have a deeper look in the evening.
Seems you have already nailed the ATA to fixed IP settings.
Be so kind to add ATA Voice → SIP info, please.

Humble recommendation:
Do yourself the favor of exploiting the benefits of a DMZ (IPFire: “Orange”) for your servers
and the ATA!
From internal (“Green”), you can still access them for your development work without any problems.


Danke schoen!

Sip info:

And I just changed the RTP port Min/max to 5004/5008 as per your suggestion, rebooted…no difference.

Yes, the plan is to get another piece of hardware in order to run a DMZ…currently IPFIRE is running on a headless laptop which has it’s NIC as RED, and a USB-Ethernet as Green. It works, but it can be expanded no further due to limitations of the hardware!

Aber gerne!

SIP TCP Port Min: … 5060
SIP TCP Port Max: … 7800 … <-------- ???

RTP Port Min: … 16384 … <-------- ???
RTP Port Max: … 16482 … <-------- ???

after the screen shot ^^^^^^^^ ???

Be so kind to add ATA Voice → Line_1 info, please.
I’d esp. like to cross-check NAT settings and SIP settings with my configuration.

Yes, after the screenshot. And the SIP TCP port max / RTP ports have not been altered from the factory settings AFAIK. What’s yours?
Voice Line 1:

Not comparable - I’m running more than one SIP device in my DMZ.

Please c.f. recommendations given / explanations linked above.

In your screenshot I am missing the top of the page which includes the NAT settings.

But noting “SIP port:… 7000 …” <-------- from where does this originate?
AFAICR, that might well be out of permitted SIP Port ranges.

Yes, TCP / port 7000 is what the ISP changed it to, from UDP 5060 … and it worked briefly…

Just minutes (from some surviving connection), or “for some consecutive days”?

You have “NAT Keep Alive Enable → yes” which is correct.
On the Voice → Sip page, down to “NAT Support Parameters”,
you find your value for “NAT Keep Alive Intvl”,
and also “Redirect Keep Alive”.

It was going for at least 1 day; we don’t get that many calls to be able to tell you further :smiley:
NAT Keep Alive Intvl = 15
What’s that? Minutes? The help screen is no help there.

Currently = NO

Please, test going back to default SIP / RTP ports and change

  • NAT Keep Alive Intvl: 15 → 5 … [ seconds ]
  • Redirect Keep Alive: no → yes

Done…unfortunately no difference. But thanks for your patience, @manfred_knick !

I suspect that I need to grab a Grandstream ATA instead.

Don’t think so.

  • Re-digest the info links in post #2
  • Reset the SPA112 to Factory settings, Quick setup, …
  • stick to defaults and keep changes as minimal as possible
  • Voice / Line 1/2 :
    NAT Keep Alive Enable: no → yes
  • Voice / SIP :
    NAT Keep Alive Intvl: 15 → 5
    Redirect Keep Alive: no → yes

Sorry for the moment - it’s long past midnight (MEST) over here.

Keine problem. Tuesday is not so bad, once you get into it!

I have no experience with SIP but just going to ask. Is that TCP port something ISP decieds? and if so shouldn’t min and max SIP TCP Port ports both be 7000 in cisco settings?

Something i noticed from first post screenshot, IPFire firewall rules should be matching those ports set in cisco, example if min is 5004 and max 5008, port in firewall rule should be 5004:5008. Not 5004 and 5008 seperatly or you are missing all ports from between them.