Occasional one way audio

[kds1]

3CX 15.5, ATT Sip Trunk, Sonicwall Firewall
System has been up and running for 2 years without a problem. About a month ago, the system will stop receiving RTP packets from ATT. Callers can hear us but we can not hear them. Internal calls work just fine. I have opened a ticket with ATT, however, A quick restart and all is OK. So doesn't really seem like an ATT Problem since it's cleared after a restart and ATT has no registration. Ran a packet capture on two calls back to back and there are no inbound RTP Packets. After reboot, Inbound RTP packets are there.

Also, I have never been able to get the firewall checker to pass on an ATT trunk. I believe their setup does not allow any traffic over 5060 to leave their network which fails the check. Anyway, I have a few setups like this and they all work fine with the failed firewall checker. Just this one that recently started having the intermittent issues.

Any Ideas.

Thanks in advance
Dave

 

[leejor]

...and you have all required ports open (forwarded)?
https://www.3cx.com/docs/ports/

 

[cobaltit]

So Update 6 changed the RTP port range. And as far as getting it to pass the firewall check you would have to put in a request to remove the ACL blocking inbound 5060. By default they do restrict to AT&T IP range.

 

[kds1]

I will double check the ports. Does it progressively move up the ports or are they assigned randomly. I had just assumed they were random assignments but once one call fails, then all of the following calls fail. So it seams as if it works it's way through the ports and presumably restarts when it reaches the end? Just curious. Also, is the port specified in the call setup? I'd like to go back and look at the captures and see if it was a closed port it was specifying.

I'll have to put in another ticket for removing 5060 from the ACL. Never worried much about it because everything always worked flawlessly.

Thanks

 

[cobaltit]

So way back when it used to start at the beginning (9000) and then only go up as needed. Now it seems to increment although i haven't gone through extensive testing. So I'm assuming you are exceeding your existing range and then when you reset it starts back at the bottom.

And yes the ports should be in the SDP. So if you still have old PCAPs of the failed calls I bet they are trying to use ports over higher than 9199/9250/9500 depending on when you last updated the range.

 

[kds1]

It was the ports...Thanks for the heads up on update 6 changing the port range. I went back and dug through some traces and found that it apparently moves up the ports as calls are processed. So the odd thing here was it was not really that random. It started at once per week on the same day. As they got busier, the time span between malfunctions began to close. That was because it was setting the call up on ports greater than 9500 and because they were getting busier, it moved above port 9500 sooner. When I restarted the system, it moved back to 9000 and started moving up again with each call.

Once again, Thanks. I'll get the ACL fixed with AT&T. If I would have handled that in the beginning, A quick run of the firewall checker probably would have identified my problem faster than digging through traces. Lesson Learned.

 

[cobaltit]

No worries, glad it helped. There really should be a hot note field on the updates pages for things like that. It also doesn't help that in an effort to speed up the firewall test they test the start of the range and the end of the range but not the whole range. I understand they want to speed it up but I've seen a few posts of people thinking the RTP range had a gap in it.