Pages: 1

Remote sites dropping VoIP Calls

(Read 4663 times)

peve

Member
★★
Offline

Posts: 11

Dec 8^th, 2008 at 7:27pm

Currently running iDirect systems in Northern Canada with our own NOC with a contention ration of 26:1 2M down 512K up bandwidth. Running a private VoIP service that has been tuned to run over satellite.

I am running into random problems across the network where a VoIP call drops the UDP upstream while maintaining the UDP downstream. The remote user can hear the land line but the land line user cannot hear the remote site. This usually occurs 5 minutes into the call but can occur sooner.

I am beating my head against the wall trying to figure this out. QOS, according to iDirect TAC is correct and I cannot force this problem to happen. This is random across the network.

Last night the entire NOC was rebooted and so far things seem stable but not enough time has passed to confirm that this solved the issue.

Looking for input on what we might be missing when trouble shooting this annoying problem

PV

Back to top

IP Logged

Ex Member

Ex Member

Reply #1 - Dec 9^th, 2008 at 1:20am

IDS version?

Group QoS or Legacy QoS?

I am assuming you have application profiles built for VOIP (built specifically to look after RTPs in the dynamic environment). �

1. What does the upstream look like (total BW wise) when the customer experiences the hiccup on the upstream....is there residual BW on the link at the time of interruption? �
a. Is that customer hitting a configured MIR? �
b. Is the IP data rate of the carrier being achieved?

2. Is upstream SAR enabled? �If so, what is the byte count? (if utilizing Group QoS disregard). �Please advise your modulation and coding? �QPSK .793 (long block?)

3. Is there any detectable loss on the link (RF wise)? �TDM loss (I am thinking this is unlikely but thought i would ask)?

4. �Have you ran a full packet ping sized at 1472 from the remote to the NMS or a destination address beyond the earthstation? �Suggest pinging the NMS with 1472 to look for potential packet loss on the link (detectable through full packet pings....a lot of the time it is not detectable with default pings). �Advise you to run a sequence of 100 and report the percentage of loss.

Lots of variables are in play in a naturally jittery environment. �Hopefully you have all the software measures in place to help minimize that.

Back to top

IP Logged

Ex Member Ex Member	Reply #2 - Dec 9^th, 2008 at 11:48am Also, please ensure that you have ALL ports (in the iDirect system) set to auto-negotiate. Especially the Tunnel and Upstream switches. Only exception to that last statement is the EDAS sw port (10 Half). Bottomline: Do not hardcode any of them to 100Full.
Back to top	IP Logged

peve

Member
★★
Offline

Posts: 11

Reply #3 - Dec 9^th, 2008 at 5:55pm

Quote:

IDS version? - 8.0.1.0

Group QoS or Legacy QoS? - Group QOS

I am assuming you have application profiles built for VOIP (built specifically to look after RTPs in the dynamic environment). �

Yes we do

1. What does the upstream look like (total BW wise) when the customer experiences the hiccup on the upstream....is there residual BW on the link at the time of interruption?

Yes and No, these hiccups can occur when the network is quiet and when it's busy, one of the mysteries
�
a. Is that customer hitting a configured MIR? �

Again depends on the time, but have watched calls drop when the users site is realatively quiet

b. Is the IP data rate of the carrier being achieved?

Small argument going on with iDirect over this, but it appears that we are getting the full rate

2. Is upstream SAR enabled? �If so, what is the byte count? (if utilizing Group QoS disregard). �Please advise your modulation and coding? �QPSK .793 (long block?)

QPSK, cannot find a reference to long block

3. Is there any detectable loss on the link (RF wise)? �TDM loss (I am thinking this is unlikely but thought i would ask)?

Nope, TDM losses are minimal

4. �Have you ran a full packet ping sized at 1472 from the remote to the NMS or a destination address beyond the earthstation? �Suggest pinging the NMS with 1472 to look for potential packet loss on the link (detectable through full packet pings....a lot of the time it is not detectable with default pings). �Advise you to run a sequence of 100 and report the percentage of loss.

Will give this a try on the next problem site

Lots of variables are in play in a naturally jittery environment. �Hopefully you have all the software measures in place to help minimize that.

Yes, too many variables in play but trying hard to narrow it down. We have measures in place to deal with jitter etc.

Thanks for replying
PV

Back to top

IP Logged

Ex Member

Ex Member

Reply #4 - Dec 10^th, 2008 at 3:33am

Are you able to see any Upstream QoS stats from the remote? I know there is a custom key available that allows you to enable those SL stats. I dont have knowledge of whether it works or not as I have not tried it. (just thought I would ask if you have used it)

I frequent the Downstream QoS stats, but naturally there is rarely a problem on that speedy TDM downstream carrier.

Do you have a canary (test system) on the air in the same network that you can try to duplicate the interruption with?

Talk to me about your MIR/CIRs. Are you using a CIR to dedicate BW to VOIP?

As you know, there are lots of variables and this is like shooting crows in the dark. Difficult.

How many 512k upstreams are contained in the inroute group? More than one?

Do you ever watch timeslot utilization on those upstreams to ensure you are not running out of slots in that 512k inbound?

M

Back to top

IP Logged

dot Senior Member ★★★ Offline Posts: 118	Reply #5 - Dec 11^th, 2008 at 3:40pm I'd suggest you check that silence suppression is disabled on your VoIP gear. Also if its iDS 7.x make sure that upstream SAR is enables and configured for the correct block size, read the technical reference guide on this.
Back to top	IP Logged

henryrayr

Member
★★
Offline

Posts: 2
NC

Reply #6 - Dec 13^th, 2008 at 6:15pm

Peve, Mike covered everything and more in his reply to you that I would reccommend you check also. I guess it's because he mentored me on iDirect and everything I know when it comes to TDMA networks (lol). However, I am curious if this is happening across the board on all remotes or just one individual remote? I would suggest ramping up some traffic on the problem remote and monitoring the queues realtime on the remote itself from a telnet session. This will give you a realtime visibility on the individual queues themselves to see if they are dropping packets before leaving the modem. See command below to check this out on modem.

1)Telnet to modem LAN IP
2)Type "qos status" at the prompt and hit enter
3)The individual queues will now display, hit the up arrow to display last command and hit enter continously which will refresh data.
4) Monitor for realtime rejected or dropped packets.

Hope this helps as a starting point. I also like to user the probe tab in iMonitor to see dropped or rejected packets leaving hub to remote too.

Vr,
Henry

Back to top

IP Logged

peve Member ★★ Offline Posts: 11	Reply #7 - Dec 17^th, 2008 at 6:51pm Thanks for al the help and ideas. At this point it appears to be an issue with CRTP compression being enabled on the remotes. When this has been disabled the dropped calls have fallen tremendously. We are in contact with the TAC to try and solve this. I will post more as I learn more. PV
Back to top	IP Logged

henryrayr Member ★★ Offline Posts: 2 NC	Reply #8 - Dec 26^th, 2008 at 10:57pm Thanks Peve, that's good info to know. Vr, Henry
Back to top	IP Logged

Pages: 1

Send Topic | Print