I talked to an AT&T level 3 tech a few days ago, and I understand from him what happened at the second attempt to turn up the VoIP part of IP Flex. The turn up tech asked us whether the voice and data were coming to and from the same IP address. We said yes. She programmed the router. Outgoing voice started to work, but incoming voice, which had been working, stopped. More importantly, the data traffic stopped working. The reason for this is that the turn up tech programmed the router to send all of traffic, whether voice or data, coming from x.x.202.194 to the SIP server. Thus, getting outgoing voice working broke outgoing data.
As I reported in the previous post, we are currently operating with a workaround that I came up with: assign the firewall WAN address to x.x.202.195. That breaks the voice traffic. If I have to make the choice, I’d rather have data than voice.
Here’s the problem with fixing it. The AT&T level three tech said that the standard configuration is to have the voice on one IP address and the data on another, and to do it any differently will require “special programming.” I’m not sure what that means. It sounded a little like, when you’re negotiating with someone from Japan, and they say, “That would be very difficult.” The level three tech was not authorized to do whatever “special programming” it would take to fix things, and he was not eager to find someone who could. Based on the one step forward two steps back progress that characterized the VoIP turn-up thus far, I’m not eager to take AT&T even further outside of their comfort zone.
I’m not sure why the turn up tech asked us whether voice or data shared an IP address, since, with standard programming, they can’t share an IP address according to the level 3 tech.
What to do? Here are the options that I see.
Solution 1) The level 3 tech suggested that we put the PBX on the WAN side of the firewall. The problem with that is the PBX only has one Ethernet port. Thus putting the PBX on the WAN side of the firewall means we have to put all the phones on the WAN side of the firewall. That would mean setting up a VLAN for the phones, and that all the phones would have to have an address in the x.x.202.19x subnet, and, since those are public addresses, there aren’t enough IP addresses in that subnet. It also means that all the phones would be unprotected from malicious traffic.
Solution 2) Get another router. Assign x.1x.202.194 to the WAN side of the new router. Leave the current firewall on x.1x.202.195. Program the PBX to use the new router for all voice traffic. Connect both routers to the internal subnet, giving them different LAN-side IP addresses. Possibly have a new subnet just for the phones and the PBX and the LAN side of the new router – I think that’s cleaner.
Solution 3) Connect another Ethernet cable to the WAN side of the Sonicwall. Leave the current WAN port at x.x.202.195. Assign the new WAN port 12.199.202.194. Figure out how to program the Sonicwall to send all the voice traffic to 12.199.202.194 and the data traffic to x.x.202.195. It’s not clear to me how to do this, and I am not looking forward to debugging it.
Solution 4) Leave everything the way it is. The firewall uses x.1x.202.195. Data works. IP voice is broken. We continue to use the analog trunks we have.
I told the level 3 tech to close the trouble ticket, as there’s no easy solution on the AT&T end. I favor Solution 4, or Solution 2 if the new router is cheap enough. I’ve invested a lot of my time and, when I get the bill from the PBX installers, I’m sure I will have invested a lot of my money in trying to get the VoIP working, and I’ve got nothing to show for it. I think it may be time to stop throwing good money after bad. I wish one of the turn up techs had told us that the way we needed to do VoIP was unworkable, but that’s water under the bridge now.
Leave a Reply