Dealing with Phone system providers...How do you guys handle this?

drnick5

Active Member
Reaction score
122
Hey Folks,

We've run into this situation a few times over the years, and I'm sure we'll deal with this more and more. Phone system installers. Mainly, installing VOIP systems to replace aging POTS phone systems of yesteryear. I've now dealt with 3 different companies, installing systems at 3 different clients. And every single one of them I've run into seem to have no clue about networking.

In this latest example, a client of ours had their 15 year old phone system die. So they called the company to install a new one. At 4:45pm we get a call from them asking us to "open a port" on the firewall (they use a Sonicwall). when I asked more specific questions such as UDP or TCP? timeout settings? Source and destination IP? QOS? etc. I was told "Just open the port".......

In this case, it turned into emails between us, the client and the phone system provider, basically the phone guys saying we don't know what were doing and can't open a simple port. Us saying we need more information that they can't seem to provide. The guy even threatened to remove the sonicwall and replace it with his own router. (Seriously?!). We responded that removing this will cause a multitude of other problems. We've dealt with plenty of VOIP systems (we've been running on VOIP internally for 7 years now). and it needs to be planned correctly and set up properly. What I can already see happening (as its happened with other clients) is this system will get set up, but have problems with call quality, dropped calls, etc. Then the blame will then be pushed to us since we control the network.

I don't want to put my client in the middle of a pissing contest between the phone guys and us, but i'm also not willing to take any of the blame when this system doesn't work because it wasn't planned out, or installed correctly. We are contracted for support, but we don't cover the phone system. so when the phone guys are trying to pass this off as "just type in the port and click open". It's not as simple as it sounds. I can already see a slew of support requests once this gets set up.

Sorry for the wall of text, just curious as to how you handle these types of situations. We are contracted to provide unlimited support, but in my opinion, this doesn't fall under support, but rather a project/deployment, that we need to assist with, so this would be billable, which i'm sure my client won't be happy about.
 
I wouldn't put up with this crap from the phone company either... Well said. They regularly screw stuff up for us, and then it is a LOT of work to ever get it fixed because usually they need to go through an entire circuit-order to get something fixed (like an IP address).

Heck, one of my sites has a little Ciena box to do the hand-off of a WAN circuit, and they are giving it to us via Copper, BUT I have fiber between that and the MDF wiring closet.

I asked AT&T to put in a Transceiver... Nope - that would require a new circuit request. Why someone cannot simply change how they hand-off a circuit, I will never know.

Anyway, I completely relate. The best irony is you cannot simply open a port without knowing if it is a TCP or a UDP port... There is no such thing as an IP Port... Ports operate at the Session Layer of the OSI model NOT the Network layer! Internet protocol itself has no ports!

Now for me, personally, I have gotten away from ports to prevent spoofing or mascaraing; instead, I specify the actual protocol Application, and the firewall inspects it all the way to Layer-7. If someone tries running RDP throughTCP Port 443 or something, it is NOT going to go through unless I allow the application RDP...

For example, here is a rule that allows ping/icmp, and Microsoft's kerberos and RPC. It's probably for a Domain Controller or something, I did not actually look at the Policy Rule other than to show what I mean.



upload_2015-7-31_15-54-29.png



If they are asking, they probably want you to open tcp/5060 and udp/5060. Here is the application info in an advanced Application-Layer Firewall

upload_2015-7-31_16-16-22.png
 
I had a location with a problem with phantom calls. Previous tech opened 5060, and it worked for a while, but once the open port was found, they were pounded with people trying to register their phones with their server. Call the trunk provider, and get the IPs to whitelist. We also had to open 10000-20000 udp and another port for the HUD, but I forgot which one. We only had to open HUD port because we had remote phones. 5060 was for registration.
 
I would just tell the idiots asking for the port to be open that you need to know the full details. Perhaps send them a simple template such as port number : protocol etc where they fill it in. Make it clear that until the details are given nothing will be actioned, and if they don't know, they'll need to look into their own product and find out.

Clowns.
 
From the looks of things, you need to open both UDP 5060 and TCP 5060; hence, two (2) ports.
 
Back
Top