Temporarily cut dropped call still connected CIX670 : B--U CIX40A2 : GCTU2

As reported to me by my users: short drops but call is still there - Happens frequently. 10 plus times a day 2 remote sites.
It sound like muted neither side can hear for a short time 1 to 3 seconds.
USER A: another cut out for a few seconds
USER A: cut out for a second with pt
USER B: cutting out again 2x
USER B: my phone cut out now
my phone just cut off twice back to back like a sec each

Complete drop - only reported once.
USER A: was just on the phone & lost my call completely
USER A: & next to me phone cut out at the same time

Strata unifier Status
Offsite office A: Maximum Delay (ms) 4719 / network delay calls 6
Offsite office B: Maximum Delay (ms) 3766 / network delay calls 2
Main site Maximum Delay (ms) 1204 / network delay calls 1

CIX670 : B--U CIX40A2 : GCTU2
Equipment Version: AR5.20 MT055.00

We have 2 PRI
on avg only 12 lines used at once. not high volume at all.

anyone have any tips to resolve this issue?

Strata unifier Status Maximum delay really bug me.
I can ping those IP from my computer and dont get ping times any where near 4000 MS - is this normal for the Strata unifier Status? i would think they should be down around 1 or 2 ms like my pings
ping - bytes=32 time=1ms TTL=64

Pathping results
0/ 100 = 0% |
1 1ms 0/ 100 = 0% 0/ 100 = 0% 192.168.15.71

added note: the cut/dropped calls only happen at my remote site not at the main site where CIX670 is at, but where I have CIX40A2 : GCTU2 equipment.

My phone support tells me it must be a network problem but i dont see any issues on the network.

is there a diagnostic program i can run on the phone system to see if it is failing? any help would be greatful here.

There isn't any diagnostics utilities in the Toshiba CIX systems. More then likely your only tools are external tools like PING and Wirshark.

I would assume that both PRIs are at the main site, since you can't add a PRI in a CIX40. Also I am assuming that the calls are going through the PRI to site B through a VPN between sites.

Lost audio is typical of IP packet drops. I don't know how many times I have heard an IT guy tell me that the VPN is rock solid, only to find an unstable VPN connection. In the past I have found the source of the problem to be the VPN connection, the ISP, or an IP conflict with the Toshiba equipment.

If you can get the IP address of the MIPU or GIPU card at the remote site I would do a continuous ping to that Toshiba equipment. The Strata Unifier does not handle calls.

David,

Thank you for the fast reply.

There is no VPN involved. It’s Fiber (100Mb) connection via Century Link Meshed fiber network with a path between Site A and Site B.

We are going through a Wireshark log now. Any ideas of what to look out for?

Ping monitoring for 70 minutes has 3863 pings with 19 lost/timeouts ( .49% loss rate)

Is there a way to set voip traffic priority to high from the phone system? Equipment Type: CIX670 : B--U Equipment Type: CIX40A2 with Network Emanger or other tool?

Wireshark has a lot of nice utilities to analyze VoIP traffic. Under Telephony look for RTP and it will analyze the traffic showing packet loss and delay.
Under 1% is not terrible, but I like it as close to as possible. Each packet loss could be a couple seconds of no audio.

Traffic can be prioritized. DiffServ is a pretty common method as long as your carrier supports QOS tagging. You will probably need to talk to Centurylink to see how they would like the voice packets tagged for QOS. Adding QOS could help. DSCP and TOS are supported, along with 802.1P.

Do you have a Toshiba tech you work with? QOS is something that you may want your Toshiba tech to enable for you.

0.49% loss on a one second interval ping usually turns out to be a much higher loss rate on a smaller interval. If you can ping with something that allows a shorter interval, such as a Linux machine, you may reveal a greater loss rate with a 0.1 second interval.

In any case, try to determine if the loss is happening on the CenturyLink connection or if it's happening on a local segment. Cheap switches might choke on higher packet rates generated by lots of IP Phones, possibly mixed with other traffic. Not sure what types of switches you have or which are involved.

we are still having the same issue.
We have reset all the setting to defult
prioritized Traffic enabled QOS tagging
we talked to Centurylink.
we upgraded the firmware and the support guy i am working with says we have done all the steps toshiba would help with and passed it off to an IT problem with the network.
we have 100Mb fiber to remote sites and 300Mb to the main site.
we have Sonicwall routers and HP procurve switches.

we have done wireshark no packet loss or corruption.

any ideas?

No packet loss? You mentioned earlier that you had .49% packet loss. You might note that is 1 packet every 5 seconds on VoIP (G711/G729 send 50 packets per second). Additionally if your packet loss is .49% with ping at its defaults, you will most likely have higher packet loss once you start increasing the size of the pings (Use the -l option). Keep in mind that a G711 packet has a 160 byte payload.

Have you done a packet capture while the issue is occurring? Are you using anything to actively monitor and graph the latency on your network? Does it happen to all the remote users in the same office when it occurs?

mlaing,

Have you done a packet capture while the issue is occurring? yes
actively monitor and graph the latency on your network? not at this time.
Does it happen to all the remote users in the same office when it occurs? good question, it does happen too all users but rarly are they on the phone at the same time. on at least one occasion I know of it only happened to 1 of 3 people on the phone at the same time. the other 2 did not report it.

I am sorry I meant no loss while it was happening when we ran wireshark to catch it.
no resends, no fragmented packets or loss while it was happening.

we used the -l option I am pretty sure 256 byte payload

This is UDP. There are no resends. If the data is lost, it is gone. You wouldn't want to re-transmit a voice packet from 2 seconds ago, hence why they use UDP. Additionally if you are relying on wireshark to just tell you what the packet loss is, it won't. Have you had it analyse the RTP stream? Find the RTP stream, click on a packet from it and click Telephony->RTP->Stream Analysis.

Have you checked the latency across the network when the issue occurs? What you are describing sounds exactly like a network issue (Either high latency or packet loss).

mlaing,

Thank you for the help on this, we are now looking at the Telephony->RTP->Stream Analysis.

is layer 3 siwchtes needed for VOIP

I can't think of an advantage to having a layer 3 switch for voice. You can create VLANs with layer 2 switches. You could use layer 3 switches to route across VLANs, but usually the router handles that.

I don't know if you have the phones on a separate VLAN, but our company likes to separate the phones if possible on larger networks. The Toshiba phones support VLAN tagging.

I am pretty sure the problem is with Sonicwall router Model: NSA 2600 Firmware Version: SonicOS Enhanced 6.1.2.3-20n