atcomsystems.ca/forum Forums TDM Business Telephone Systems NEC Telephones & Systems Choppy calls SV9100

Just an idea. Not like NEC isn't a major player just your SIP provider hasn't bothered to get NEC certified. That being said choppy calls means they are establishing so look deeper. AND not to be a debbie downer you are not using ANY sort of MPLS or QOS service so there are no guarantees.

I added 10-58 Set local network area of DT800/DT700, the correct ip range 10.0.0.1 sub 255.0.0.0 yes 16 million range for 10 devices(don't ask) .

Added 84-13-28: Sip Trunk Codec Setup - Audio Capability Priority to G.711_PT

So all codecs are running the same.

Those changes made no difference

Yeah it's something to do with the router/routing I think PFSense had QOS running in its software its called Traffic Shaping. Two pieces to it actually bandwidth throttle and prioritizing types of traffic.

What I did for testing was to get a baseline before any changes. I would run one or two outbound calls to a number that automatically started talking recordings 858-651-5050 if you ever need it for any reason great way to test or go insane whichever better then calling up your wife and making her help you.
Within 10 minutes I would get a choppiness that was really bad, the timing was random would be at minute one or minute 4 or whenever it would be bad for about 30 seconds then clear right back up.

with that at least pinpointed that routing/reshaping of packets or the ISP connection(highly unlikely) is the problem because of VOIP/RDP when packets get out of order because of timing instead of sorting them or resending it will just toss those packets out causing the choppiness. Getting this big of an issue because the router is was either set incorrectly or too many QOS rules being applied. I really need to remove the pfsense out of the picture for a good test.

I disabled all the QOS'ing on pf as best I could but I think it's still imposing something even though I can check monitoring graphs of the QOS and in real time on it and see nothing happening. I believe it either remedied it or made it like 80% better in my testing.

Why 255.0.0.0 for the subnet mask?

Yep, great question have no idea what the person who setup the network was thinking. 16.7 million range. It's been easier to just leave it alone though.

By all means I'm not a IT expert, but my understanding is the subnet mask of 255.255.255.0 speeds up the networking process, 255.0.0.0 slows it down.
Why would it be difficult to change it?

No subnet is just what predetermines your ip range and "Mask" the rest. So no not really. I would have to change firewall switches and PBX I really don't need to mess with the unknown just yet. Just fixing a choppy audio problem. It would be nice to someday so if I do an ip scan or something for whatever reason the tool doesnt have to run through 16.7 million possible used addresses. But switching gear certainly now and days to not scan entire address ranges for packet delivery to slow down anything at worst the sending devices sends to broadcast for a helping hand for delivery. It's just stupid though for managing. 254 range is far beyond enough. only ppl that need 10.0.0.0/8 range are company's handling millions of devices ISP's and datacenters.

Yeah, there is NO reason 192.168.x.x, 172.x.x.x, 10.x.x.x shouldn't be enabled by default. This simply makes the system route internally. If you have ANY IP in the external IP address on the main processor for NAT you must do this or you will have issues. Ya go get cheap router and put it in and see if it goes away.

Hello, tried a cheap router a Netgear something. I set the network for it correctly, turned off SIP ALG and opened the NAT. Also, put the MAC address from other routers WAN port to the Netgear routers WAN port for the static IP it's given. After that connected to the SIP provider just fine and made received calls just fine, but about 15 minutes or so in, the audio would drop this was an outbound call to an 800# this was repeatable I was not talking to a person so I do not know if it was both ways, but the call control was fine the PBX did not drop the call completely just the audio went.

I'm pretty sure I have to port forward/trigger, Netgear's wordage, on the RDP's ports. Just to make sure that's not the cause. Question mark maybe.

You need to wirshark this. Make sure you check and see that UDP flood protect is off. Some routers/switches do not like seeing that traffic. Seems weird if happens after a bit. Wireshark is needed to see what is causing the drop. The router should NOT being doing the NAT control your PBX is doing that. ALL you need are the ports forwarded and get the heck out of the way. Also, check your keep alive timers.

K thank you.