Any SIP/VOIP/IPECS server experts on here?

Associate
Joined
26 Oct 2002
Posts
1,728
Location
Surrey
Hi guys.

I run a successful IT company with that specializes in the Legal Sector and while I am not a telephony person at all, I am finding myself drawn ever closer to having to deal with this side of things, which sucks to be honest.

I have one particular client that uses a full remote desktop/satellite office model, with getting close to 100 solo remote workers alone (not counting remote offices/workers there) and they are experiencing ever-increasing issues with dropped calls mid-conversation, one way conversations, inability to get external lines etc. The last one is being put down to not enough SIP channels by the phone company and they are putting in an expansion card next week.

The system is an LG IPECS. No site to site vpn or static internet IP address needed for the phones, just certain ports forwarded through a router at the IPECS end through to the controller.

The comms line is what is known as a 2Mbit SDSL Annex M connection with failover line and is controlled by a Cisco 1841 running in bridged mode. No data manipulation is being carried out by the Cisco that I am aware of, packets are being passed straight through to a Draytek Vigor 2950 Router (SIP DISABLED) which in turn feeds only the IPECS.

Traffic is well within limits, peaking at around 0.7Mbit in/out during the day and is confirmed by both the Draytek and Cisco logging. The client is at the end of their tether and have begged me to get involved as the phone company seem to be helpless in regard to the NAT/SIP/IP side of this problem. Pretty well everything I read states that wherever possible, the SIP side of a phone server should be outside a firewall, on a public internet IP address and I totally understand that as NAT routers are known to cause all sorts of issues for SIP-related traffic.

The problem I currently have is that the IPECS only has 1 LAN port and LG insist that it has to sit behind a firewall as it has no inbuilt firewall/defences against attack. I know for a fact that an additional card/interface can be added but as for whether or not the IPECS can be programmed to gateway SIP traffic out on that only outside the firewall, while maintaining normal internal LAN traffic, is out of my field of knowledge.

As the client was desperate to be seen as doing something for the workers, they roped me in to looking at all of this, dropping a large data centre project that I am supposed to be installing this weekend, and I spent most of yesterday at their offices. The only realistic thing I could try was putting a totally different router in, in place of the trusted Vigor 2950 (which worked perfectly with the previous Avaya phone system by the way, albeit VPN-based). I dug out an old Linksys RV082 and set all the routing up to emulate the Vigor. Early days yet but I do believe that if anything, the problem is worse.

The pain is that the phone people seem incapable of giving me information regarding live system monitoring, won’t allow me access to the unit to just do it myself and I have just had enough of it basically. As far as I am concerned even if the IPECS doesn't have built in firewall, we may have to go old school with it and just use stupidly long/complex passwords to protect system access/SIP channel access and slap it on the internet, if a secondary interface allows it.

As far as I am concerned, LG should have a list of approved routers/configs purely based on this apparent inability to work outside a firewall but the phone company tell me that this isn't the case.

I have already asked the company that manages the line/Cisco whether or not they would be prepared to alter the Cisco from a bridge to a router, put in all the relevant firewall rules and let that act as the firewall for the IPECS, purely so I can take the Draytek out of the picture and wash my bloody hands of it all, not that the client will let me get away that easily........

My questions are:

Does anyone on here know the IPECS systems?

If so, do they really have no ability to router via WAN/LAN setup with a secondary interface card?

I am right in saying that putting SIP servers behind firewalls should be avoided whenever possible?


That is about it I think, sorry for the waffle....


Nick.
 
Last edited:
I'll start by saying I don't know the IPECS system.*
I don't know if they can have two separate interfaces set up, but it boggles my mind that it wouldn't...

Move the VOIP box on to the public range, but still behind a firewall.
Have a second interface (Or VLAN) connecting to the internal network.

VOIP and NAT do not make happy bedfellows.
Unless you have someone who is trained in Cisco voice and knows their protocols inside out, don't even attempt it. Getting NAT traverse to act consistently with VOIP is a task in itself, completely ignoring any conflicts within the config.
It's possible, but it's much easier to avoid the problem.

*I am not an expert
 
Although I don't deal with many phone systems the only thing I'd comment on is that we set up our clients servers behind the firewalls. There's no reason to bridge WAN to LAN and bypass that security, even if it is a SIP device (and again to protect the device itself). We have them working behind ASAs and Checkpoints - probably a Sonicwall and Watchguard somewhere although I don't know for sure.

- GP
 
2Mbit as in 2 meg broadband?

100 workers... 2Mbits.... am i reading this right?

I would conclude your 0.7mbit peak is not correct.. ?
 
GhostlyPea- Are they on separate networks internally though? Specifically, not behind NAT.
I agree the device needs protecting, as well as the phones. VOIP systems are an easy vector of attack, especially older models.

NAT Traversal does vary between phone systems. The ones that support ICE / STUN are great - having far fewer problems with NAT (most of the time, none at all), but not many of them do yet.
 
Thanks so far guys. The IPECS system runs a mixture of classic ISDN30 I think and SIP for additional channels. The IPECS system only has 1 RJ45 LAN interface as standard.

Edscdk, you read corectly, the usage is never above 0.7Mbit in/out, this is confirmed by both the deraytek logs and Cacti logging via the Cisco. Not all the workers are on the phone at the same time don't forget and I think they are on quite a conservative codec ;)

If it helps, here is the basic plan of how the networking is at the office where the IPECS server is:

25 workers all on 192.168.17 range
Worker computers gateway out via a router on 192.168.17.1 that has it's own internet line, totally seperate to the 2Mbit line
IPECS system is on 192.168.17.10, gateways via what is currently the Linksys on 192.168.17.254
The Linksys WAN1 is connected in to the only LAN interface on the Cisco 1841 that controls the 2Mbit line and is on a public internet IP address "217.xxx.xxx.xxx".

If it helps/interests, the following firewall rules inbound are enabled, as requested by the phone company:

UDP 5060 -> 192.168.17.10
TCP 5060 -> 192.168.17.10
UDP 5588 -> 192.168.17.10
UDP 6000-6047 -> 192.168.17.10
UDP 6254 -> 192.168.17.10
UDP 7000-7015 -> 192.168.17.10
UDP 7100-7115 -> 192.168.17.10
UDP 7300-7315 -> 192.168.17.10
UDP 8000-8047 -> 192.168.17.10
UDP 9000-9047 -> 192.168.17.10

With the Linksys at least, I am having to leave the Stateful Packet Inspection part of the firewall enabled as it flat out refused to route the ports inbound without it.
 
@ Yamahahahahaha - Yeah behind NAT (static 1-2-1 in MOST cases, although some are Port Forwarded). Most of the problems we have had are with handsets registering behind other routers, but a few tweaks have sorted this easily.

Note though that I'm a network engineer not a phone specialist, I only deal with the infrastructure so I cant give many specifics, just that it works

- GP
 
With this current system, we don't touch any of the remote worker routers or make inbound rules to their handsets. The phone company program the handsets for DHCP too which wouldn;t help me trying to play around with various worker's router rules. These are all various ISP-provided ones from the likes of TalkTalk (shudder), BT, Virgin, Sky etc etc.
 
@ Yamahahahahaha - Yeah behind NAT (static 1-2-1 in MOST cases, although some are Port Forwarded). Most of the problems we have had are with handsets registering behind other routers, but a few tweaks have sorted this easily.
I think it must be dynamic NAT it doesn't like. Even when we set up static NAT for those ranges (and port forwarding) it still didn't play nicely.
I hope Mr Twoinches doesn't mind our digression :D

I've had a quick Google and it could be that the IPECs model you are using is only the 8 SIP version? There is a 24 SIP version. I have no idea where your ISDN30's channels would fit into that combination...
 
Last edited:
I believe that the current version is the 8 SIP version (I know, shocking for a site that size but that is between the phone provider and the client....) but a 24 SIP expansion card has been ordered I believe for next week that will take it to 24.
 
Last edited:
I think it must be dynamic NAT it doesn't like. Even when we set up static NAT for those ranges (and port forwarding) it still didn't play nicely.
I hope Mr Twoinches doesn't mind our digression :D

I've had a quick Google and it could be that the IPECs model you are using is only the 8 SIP version? There is a 24 SIP version. I have no idea where your ISDN30's channels would fit into that combination...

Yeah mostly it's the NAT service we disable for SIP outbound and that generally sorts it...

Digression or not, tough!

- GP
 
NAT doesn't work with SIP because it sometimes puts the source IP in the higher layer protocol headers which NAT doesn't translate resulting in mismatches even with static 1:1 translations. Some systems have options for devices being NAT that allows for this issue and some firewall have options you enable to cope with this. They're not open standard and only as good as the vendor implementation, which varies.
Avoid NAT if possible, don't be afraid to stick things on public addresses as most decent firewalls support layer2 zones and/or virtual wires which makes them invisible to layer 3 up but they are still there and offer the usual rules and IPS features.
 
With this current system, we don't touch any of the remote worker routers or make inbound rules to their handsets. The phone company program the handsets for DHCP too which wouldn;t help me trying to play around with various worker's router rules. These are all various ISP-provided ones from the likes of TalkTalk (shudder), BT, Virgin, Sky etc etc.

This is a headache all by itself, we have started to sell the IPECS systems at work, also had a lot of fun and games with the Draytek PBX and remote handsets.

Site to site VPN's help a lot with remote workers, if you connect the phone system directly to the Cisco lan port and set the gateway to the cisco, does that make any difference?
 
I strongly suspect the answer here is buy a better firewall unfortunately. To be honest, if it's affecting your relationship with the client then I'd get rid of it as a problem, make it the phone people's problem, you can spend weeks troubleshooting these sorts of issues when it's set up perfectly with top end hardware, what you've got isn't that.
 
This is a headache all by itself, we have started to sell the IPECS systems at work, also had a lot of fun and games with the Draytek PBX and remote handsets.

Site to site VPN's help a lot with remote workers, if you connect the phone system directly to the Cisco lan port and set the gateway to the cisco, does that make any difference?

^ VPN is the only completely reliable method I've found to connect remote handsets. Especially if there is more than one.
 
Thanks guys. This is the key issue, the phone company don't really seem to know their own equipment all that well. Originally the client had an Avaya system which we had to use site to site VPN's with in order for the ip handsets to connect. The big issue with this was having to force each remote worker that joined the company to not only make us provide them with a router capable of establishing site to site VPN but also wherever possible, to have a static IP.

The rate at which remote workers join up now has upped to 2-3 a week on average. We are not, never have been, and don't pretend to be the phone guys for our client but they turn to us for answers when their own phone companies can't get their act together.

Solicitors are great at pleading poverty so you cannot always get them to spend thousands on a router, especially when what they have was running all the site to site VPN tunnels perfectly for the previous phone system.

The new company supplying the IPECS came along and after telling them what the infrastructure was, they just said "that will be fine, just forward these ports at the IPECS end and job done".

Please don't think that I haven't been doing my job properly. As already stated, NOT a phone engineer. I cannot get a LG support person to speak to me directly, taking the phone company out of the equation and when they forwarded on my request for recommended/supported routers, configuration notes and the query about a secondary interface to deal with WAN side, all I got back was:

"There is no secondary network interface for the IPECS. The systems are generally installed behind NAT with no problems, indeed we have many hundreds of these systems installed and working in this way."

Wow, really really helpful not.

When asking about the tell-tale signs of NAT/SIP problems of one way conversations, calls ending midway etc I got this back:

"The Voiceflex traffic is SIP based, but the remote extension traffic is not SIP based. An ALG is not required as the system will handle the routing through NAT, for this reason an ALG must not be active on the router."

SIP ALG has been disabled on the router since day 1.

They're not open standard and only as good as the vendor implementation, which varies. Avoid NAT if possible.

It is my opinion that the phone company/LG should be dealing with making sure that the router there that is dedicated to their system, is compatible and they can manage it. All they did was walk in, say everything would work and here we are. I managed every other expact of the client's IT and that all works exactly as it should, I am not a phone guy.

Based on this router lottery etc, I am very close to recommending that the client gets a SIP/VOIP specialist to come in who knows all about the router lottery etc etc and can give us something that will make the phone system work as it should for the client.

Thanks again chaps, I really appreciate your input on this!
 
Last edited:
if you connect the phone system directly to the Cisco lan port and set the gateway to the cisco, does that make any difference?

Thais is exactly one of the things that I want to try and have checked with the company that manage the line/Cisco and they are prepared to alter it from a bridge to a router and forward through the necessary ports to the IPECS but this would still be a NAT style configuration though, only taking any router that we provide/manage out of the equation.

I am more than happy to try and have it as an option this but the line company want to charge to try this so down to the client.
 
If they're saying it should work, you've done everything they've told you to and it doesn't; then it's a fault. If it's a fault then THEY need to fix it. I'm guessing you have some sort of support agreement in place?
Have you paid the invoices for the install and or maintenance contract yet? If not, don't. And make a point of telling them you won't until this issue is resolved.
I've had 3rd party contractors sit on problems for months in the past (usually after they gave us **** advice), the only way we actually got things done was we refused to pay them a penny until they did their job properly.
 
Thanks guys

I think I have enough information to run with and I appreciate you guys pretty well confirming my thoughts on the NAT side of this technology being a key problem.

What I will say is that is anybody knows of any specialist independant VOIP/IP Telephony consultants, specializing in this potential NAT minefield side of things outside of the phone system, and could forward their details to me to keep as an option for the client, my mail is in Trust and I would be extremely grateful.

Not interested in the client being sold a new phone system, purely interested in taking that routing side out of the equation for all concerned thanks :)
 
Last edited:
Back
Top Bottom