I have a customer who has an VOIP PBX connected to a Level 3 fiber connection. He has offices all across the country using different ISPs. Two of those offices use AT&T, both in different states. One is T1, the other is DSL. For the past week, every day around noon EST, both AT&T sites have one-way voice issues where they cannot hear the other side. This lasts the rest of the day. The next morning, things work fine again until noon. The phone logs show they are not receiving the RTP stream. All the other non-AT&T sites work fine. I had them try connecting their phones to other systems on other ISPs (one on Comcast, one on Level 3 and one on Megapath) with no success. I had them plug a phone directly into the T1 router with a public IP, bypassing the NAT/firewall, with no success. I've changed the SIP and RTP ports to non-standard ports without success.
I'm coordinating with them to set up a packet capture on the far end while I do a packet capture on the PBX , but I was hoping to find out if others have encountered one-way voice issues with AT&T recently, and if so, how you were able to resolve the problem.
Just to recap:
– 2 different offices in 2 different states on AT&T simultaneously experience one-way voice issues every day starting around noon. All of their other non-AT&T office work fine.
– The 2 offices that are affected have different switches and routers.
– Trying different PBXes on different ISPs did not fix the issue.
– Configuring a phone with a public IP and bypassing the LAN and NAT does not fix the issue.
– Using non-standard SIP & RTP ports did not fix the issue.
– I tried as many variations of all the above I could think of with no change.
I've been doing this for 8 years and never saw anything quite like this.
Best Answer
One-way audio with SIP/RTP calls is caused by one of the pair of RTP streams not being established. This is either a routing (i.e. NAT) problem, or a firewall problem. By default, SIP usually causes RTP streams to be established over UDP with destination ports on either side between either 10000-20000, or 16384-32768. Both sides must be able to make an otherwise unsolicited outbound connection to the other side (i.e. a NEW connection as respects conntrack). Stateful firewalls designed to prevent inbound connections are a common cause of this when NAT is not the problem.
It could certainly be the case that the ISP is mangling packets and obstructing the connection, but it's very unlikely if you have a business connection of any type. Keep in mind that it's the firewalls on both sides.