After five or six months of trying, the AT&T IPFlex system is now working with my NEC PBX. In this post, I’d like to review what went wrong, how we made things work, and what should have happened in a perfect world to make the installation quick and easy. I’m hoping that other people with upcoming IPFlex installations can learn from my experiences and have an easier time of it.
The initial configuration was a Sonicwall router running NAT with a WAN port to AT&T’s Cisco router, and a LAN port on the Sonicwall connected to the local non-routable IP network, and the PBX and the phones on that network along with all the computers and such.
The data worked great from day one, so I’m not going to talk about it here.
When AT&T first attempted to turn up the VoIP part of IPFlex, we could receive incoming calls, but couldn’t make outgoing ones. Looking at the SIP packets flowing across the firewall using the Sonicwall Dashboard, I could see the PBX issuing an “Invite” packet to the AT&T SIP server, the SIP server coming back with a “Trying” packet, and immediately following that with a “Forbidden” packet. The PBX issues an “Ack” packet, and we were done.
The LAN side of the Sonicwall had the IP address range 10.10.24.0/24. The AT&T tech was saying that she couldn’t ping the PBX at 10.10.24.2. That’s unsurprising, since that address is non-routable on public IP networks, but she thought it was an indication that the firewall is improperly configured.
I struggled with the configuration on and off for two months, and couldn’t get it working.
Lesson 0: the AT&T IPFlex techs don’t get their end right every time, and that leaves you with a broken system, no way to tell what’s wrong, and no way to fix it.
Finally we scheduled another turn up attempt. That produced some interesting results. Outbound calls were suddenly working. However, incoming calls, which had worked, were broken. And even worse, all non-voice Internet traffic stopped dead.
I replaced the Sonicwall with a laptop programmed to have the same IP address as the Sonicwall, and found that it couldn’t access the Internet. That meant that our problem wasn’t the firewall. I changed the IP address of the laptop and it could get to the Internet just fine. As a workaround, I changed the Sonicwall’s WAN-side IP address to a different one, and dat started working agin.
All that meant that AT&T, in getting voice to kind of work, had blocked data to the IP address of the firewall. I went through a series of AT&T techs until I got to a level 3 tech who said that was the way that they normally configured IPFlex, and if I wanted both voice and data, they’d have to go to different IP addresses.
Lesson 1: IPFlex voice and data have to go to different IP addresses. Both the PBX installer and AT&T should have told me that.
I came up with a proposal to my PBX installer: install another firewall with the WAN-side IP address that AT&T wanted to use for voice, and leave the Sonicwall at a non-voice WAN-side IP address, then attach both firewalls to the same LAN, and give then different gateway addresses. Tell the PBX about the voice-connected firewall, and tell everything else about the data-connected firewall.
We did all that. We got SIP packets in both directions. We got RPT (voice) packets from the firewall to the other end of the call. But we got no RTP packets from the outside to the firewall.
Three out of four isn’t bad when you’re batting or shooting three-pointers, but it stinks when you’re trying to make phone calls. I set up a computer running Wireshark to look at all the traffic from AT&T’s Cisco router and saw that the incoming RTP packets were MIA.
I set up a service ticket, and went through the long painful process of the techs trying to fix it before I finally got to a level 3 tech. He said that the reason we weren’t seeing the incoming RTP packets was that the PBX in its SIP packets was saying that its address was 10.10.24.3, which is non-routable.
I relayed that to the PBX installing company, and, after a while, they suggested that I should reprogram the PBX to think we’re using NAPT, and to tell it that the address of the NAPT router voice router’s WAN-side address We’re not using NAPT, but we are using port forwarding for the RTP packets, so I guess that’s close enough, and the PBX now puts the voice firewall’s WAN-side IP address as its IP address in the SIP packets it sends out.
Problem solved.
Lesson 2: If your firewall doesn’t do the remapping of the IP addresses in the outgoing SIP packets so that the firewall address appears as the sender (the Sonicwall can do this, but the voice firewall that we’re using can’t), you should program your PBX to do that. The PBX installer should have told me that. The first AT&T tech to get the service call should have told me that.
Leave a Reply