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 mylan.com port 7000 (tcp) failed: Connection refused
Firewall Logs show where the packets are obviously forwarded…but denied connection?
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 !
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.
So…
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 ), 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.
Also I have just rebooted IPFire, and note the following log:
The source being the 10.0.2.54 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.
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.
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!
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
NAT Keep Alive Intvl = 15
What’s that? Minutes? The help screen is no help there.
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.
), or the ISP’s SIP server is?
