Three months have past since I came up with this workaround to get Internet access over my ATT IP Flex fiber circuit. I had been limping along with Solution 4) from that post – reassign the IP address of the firewall and use analog trunks. The company that installed the PBX said that they’d be willing to try 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.
The company that installed the PBX showed up with a Ubiquiti EdgeRouter that they’d used with success with IPFlex. We assigned it the WAN address of x.1x.202.194, and the LAN address of 10.10.24.253. We reprogrammed the PBX to point to it instead of the Firewall, set up port forwarding for SIP and RTP protocols to flow to the PBX, and tried to make an incoming call. We got ringing and ringback, and when we went off hook on the internal phone, we got voice coming from the PBX to the outside caller, but no voice in the other direction. We made an outgoing call. Yes to ringing and ringback. Yes to outgoing voice, and still no to incoming voice.
I hooked up a computer between the EdgeRouter and the ATT router, and repeated both types of call. I could see the SIP packets from both ends indicating normal call setup. I could see the RTP packets flowing outwards. But there were no incoming RTP packets. This can’t be a problem with the EdgeRouter, since we’re looking on the WAN side of it.
I called ATT service, and they assigned me a ticket number.
The next day, I got a voicemail from ATT saying that, when they tried to make a call to the PBX, the got a SIP 486 packet back. A 486 packet means “Callee is busy”, and it would have to be sent by the PBX, as far as I know. That’s strange. I tried it, and got the same behavior as before: the call went through, but I only got voice packets in one direction.
I called ATT back, and was told that there’d be a two minute hold for a tech. After 35 minutes on hold, I hung up so that I could go do something more pressing.
Done with that, I was back on the horn to ATT. Back on hold. This is probably a good time to mention that the music on hold on the VoIP support line repeats every fifteen or twenty seconds. It’s a little bit like “It’s a Small World” at Disneyland, only not near as catchy. After an hour and forty five minutes, I got a Tier 2 tech on the line. After another hour and a half of troubleshooting, we had made exactly no progress. The tech said he could see both sets of RTP packets in the ATT-managed Cisco router on my site. He said he’d refer me to a Tier 3 tech.
The next morning, I got a call from the Tier 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. That’s it. The whole call took a minute or two.
Unexplained is what the Tier 2 tech was looking at when he said he could see both sets of RTP packets.
The Sonicwall firewalls have provision for translating addresses in SIP packets so that you can make the VoIP server think that the address of the PBX is the WAN address of the firewall, but it looks like the EdgeRouter can’t do that. At teh suggestion of the PBX installers, I reprogrammed the PBX to think we’re using NAPT, and to tell it that the address of the NAPT router is x.1x.202.194. 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 x.1x.202.194 as its address in the SIP packets it sends out.
Problem solved.
I only have a sample space of two, last February and now, but it’s amazing the difference between the ATT Tier 2 and Tier 3 techs.
Leave a Reply