ip trunk calls drop on g350 1

[Mjoeuser]

Hi,

I have a g350 cm4 connected via IP trunks to an older definity cm2. I'm using a VPN between sites with a Sonicwall on one side and a Linksys on the other. I have generated calls from both sides and they sound great. However, after a few minutes, the call drops. I can set up a constant ping between sites and this always stays clean with low latency.

Can anyone help me with a suggestion or two?
Thanks,
Joe

 

[mattKnight]

>I'm using a VPN between sites with a Sonicwall

Have you turned off the H323 ALG in the sonicwall? This often causes odd issues

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Mjoeuser]

I turned on the h.323 transformation in the sonicwall, and it killed the trunk. I turned it back off and it came back, but the calls still drop after a minute or so.

 

[Mjoeuser]

OK, I am really baffled on this one... I was on site all day today (on the G350 side) trying to figure out why calls are dropping. I noticed I can call the Definity side across the IP trunks many times with no trouble. Then suddenly, I can't call through at all. I would dial an extension and there would be a delay, then a fast busy. This would last a few minutes, and then it would clear and I can dial again with no problem. When I do a trace on the station (during the times I cant get through), I got, "denial event 1220: recovery on timer expiry".

When the calls were going well, I did some speed test on the WAN and still could call the other end with no problem, so I dont think it is a problem with the WAN.

I would leave several calls up all at once to see when they drop. Ironically, they did not all drop at the same time. I would loose one call with two still up. then I might loose another one 5 minutes or so later. There was no pattern that I could find for the drops

Boy, any suggestions on this one?

Thanks.. Joe

 

[AvayaTier3]

list trace station xxxx while making your test calls. If you duplicate a failure, it may reveal something helpful.
See what you have in common on the traces for failed calls. Also compare traces for the good calls.

A great teacher, does not provide answers, but methods to teach others "How and where to find the answers"

bsh

37 years Bell, AT&T, Lucent, Avaya
Tier 3 for 27 years and counting

http://bshtele.com

 

[Mjoeuser]

OK.. Here is a call that works good. This was generated from a station off the G350. I asked the person on the distant end to hang up first. The station is extension 459. I'll post again when I see it fail.


LIST TRACE

time data

12:55:43 active station 459 cid 0x233
12:55:45 dial 773 route:UDP|AAR
12:55:45 term trunk-group 2 cid 0x233
12:55:45 dial 773 route:UDP|AAR
12:55:45 route-pattern 251 preference 1 cid 0x233
12:55:45 seize trunk-group 2 member 8 cid 0x233
12:55:45 Calling Number & Name NO-CPNumber NO-CPName
12:55:45 Setup digits 773
12:55:45 Calling Number & Name 8477483788 Telephone Room
12:55:45 Proceed trunk-group 2 member 8 cid 0x233
12:55:45 Alert trunk-group 2 member 8 cid 0x233
12:55:45 G711MU ssff ps:20 rn:1/1 192.168.5.21:9072 192.168.12.70:5848
12:55:45 xoip: fax:Relay modemff tty:US 192.168.12.70:5848 uid:0x50009
12:55:52 active trunk-group 2 member 8 cid 0x233
VOIP data from: 192.168.12.70:5848
LIST TRACE

time data
12:55:56 Jitter:3 2 4 3 4 5 4 3 3 2: Buff:11 WC:37 Avg:3
12:55:56 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:0 Avg:0
VOIP data from: 192.168.12.70:5848
12:56:06 Jitter:4 4 3 2 2 3 3 3 2 2: Buff:11 WC:49 Avg:3
12:56:06 Pkloss:0 0 0 0 0 1 2 0 0 0: Oofo:0 WC:2 Avg:0
12:56:07 idle trunk-group 2 member 8 cid 0x233

 

[Mjoeuser]

After testing for hours I could not get the delay today. However, I still have calls that continue to drop during a conversation. It's hard to trace because there is no telling which line will drop. I'm wondering if the jitter is to high (above) and may be the cause of calls dropping.

 

[Mjoeuser]

All,

This morning I set up a call on the one analog port on the G350. I have a polycom conference device plugged into this port. I called the polycom from the definity side and did a "li trace sta" on the polycom extension. After about 14 minutes, the call dropped. I looked at the "li trace" and had nothing. It was blank! I called it again to verify it was the correct extension and the "li trace" stared tracing which confirms I was tracing the correct extension. Anyone know what might cause this?
Thanks, ..Joe

An imression of my skull is forming on the wall with this one.

 

[Mjoeuser]

One more thing I did last week... I switched out the router on the g350 side, so I have both ends with a sonicwall TZ210. Yet calls still mysteriously drop.
Thanks..

 

[Mjoeuser]

I built a VPN tunnel from the G350 site, to my office. Using my asa, I again did a "li trace" of a call that I made to the polycom. After about 15 minutes, the call again dropped. I'm not sure if this is a coincedance or not, but I saw the call drop and at the same time I lost my ASA connection. When I got ASA back up, all looked good, (IP trunks were in service, etc..) AHGGG! Any helpers out there?

 

[TelcomAdmin]

I noticed on your posted trace route you are using codec G711. VoIP traffic over a WAN should use G729 or G729A. Something to consider especially if you have low bandwidth.

 

[Mjoeuser]

Hello all.. Its me again. I'm hoping that either someone will know the answer to this, or worst case, I figure it out and this thread will help the next guy. lol

Anyway, I ran a trace on a station again that dropped. Below is this trace. It entails three pages. the first two were whille the call was working. The third was when it dropped. Im not sure what this data means. Thanks.
LIST TRACE

time data

VOIP data from: 192.168.12.70:2206
15:53:38 Jitter:4 4 3 3 5 5 4 4 9 5: Buff:11 WC:73 Avg:3
15:53:38 Pkloss:0 0 0 0 0 0 0 0 1 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:53:48 Jitter:4 6 6 5 8 5 6 11 7 5: Buff:11 WC:79 Avg:4
15:53:48 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:53:58 Jitter:4 9 3 4 5 4 5 5 4 6: Buff:9 WC:79 Avg:4
15:53:58 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:08 Jitter:7 6 5 4 6 3 5 3 4 6: Buff:17 WC:79 Avg:4
15:54:08 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:18 Jitter:7 5 6 3 6 3 4 5 4 6: Buff:18 WC:79 Avg:4
15:54:18 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0

LIST TRACE

time data
VOIP data from: 192.168.12.70:2206
15:54:28 Jitter:5 4 4 3 5 8 5 2 3 5: Buff:14 WC:79 Avg:4
15:54:28 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:38 Jitter:2 5 3 4 4 5 5 5 3 6: Buff:10 WC:79 Avg:4
15:54:38 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:48 Jitter:2 4 4 3 3 3 3 4 2 4: Buff:10 WC:79 Avg:4
15:54:48 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:58 Jitter:4 5 2 4 4 3 4 2 2 4: Buff:19 WC:79 Avg:4
15:54:58 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:55:08 Jitter:4 4 5 5 4 5 4 5 3 4: Buff:12 WC:79 Avg:4
15:55:08 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0

LIST TRACE

time data
VOIP data from: 192.168.12.70:2206
16:02:29 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:9 WC:121 Avg:3
16:02:29 Pkloss:* * * * * * * * * *: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
16:02:39 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:9 WC:121 Avg:3
16:02:39 Pkloss:* * * * * * * * * *: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
16:02:49 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:9 WC:121 Avg:3
16:02:49 Pkloss:* * * * * * * * * *: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
16:02:59 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:9 WC:121 Avg:3
16:02:59 Pkloss:* * * * * * * * * *: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
16:03:09 Jitter:0 0 0 0 0 0 0 0 0 0: Buff:9 WC:121 Avg:3
16:03:09 Pkloss:* * * * * * * * * *: Oofo:0 WC:4 Avg:0

 

[Mjoeuser]

Thanks TC,
Although I believe we have a lot of bandwidth, last night I changed to g.729. Today I had my first test call drop again. ARGG!

I'm at the end of my rope on this one. Can someone let me know if the jitter is too high above, or is this in the normal range.

Thanks.

 

[Mjoeuser]

I figured this out for anyone else that gets this problem. I found that when the signaling group ports are set above 5000 (instead of 1720), the calls stay up. Dont know why it is, but I set both side to 5070. Thanks to all for your help, or just listening..lol

Joe

 

[Mjoeuser]

Hmm. I found out today that calls are still dropping. What I thought was a fix appearantly wasn't. I'm re-submitting this thread with hopes someone might have a fresh Idea.

Thanks in advance,
joe

 

[EPalle]

Hi,

To answer your question "Im not sure what this data means".
A STATUS STATION command will show you everthing that happens during a call from/too that station, but I guess you know that by know

As you will see at the time values, there is always a 10 sec difference. Also note that you have 10 values for jitter and packet loss (each value is a Percentage).
So each 'line' shows you the jitter and packet loss status for the last 10 seconds and this for every second.
Example (will make it more clear):

15:54:28 Jitter:5 4 4 3 5 8 5 2 3 5: Buff:14 WC:79 Avg:4
15:54:28 Pkloss:0 0 0 0 0 0 0 0 0 0: Oofo:0 WC:4 Avg:0
VOIP data from: 192.168.12.70:2206
15:54:38 Jitter:2 5 3 4 4 5 5 5 3 6: Buff:10 WC:79 Avg:4

Here you see that at 15:54:28 you had 5% jitter and no packet loss, at 15:54:29 you had 4% jitter, at 15:54:30 you had 3% jitter etc etc.
Same for packet loss.

At the end: WC = Worst Condition, Avg = Average %Jitter

But you see a '*' for packet loss at the end of the trace.
A star means 100%, so you have 100% packet loss, and therefore the call is dropped (as no packets are transmitted anymore).
That is your problem...... and jitter and packet loss are NETWORK issues.... so stop checking the voice equipment and focus on the network routing/setup.

Jitter and packet loss should be 0 (zero) but the values you have for jitter are not that bad. But maybe they will also be 0 after the network review.

Hope this helps,
Erik

 

[Mjoeuser]

That makes a lot of sense. Thanks for this information. This makes it look like the calls are being dropped by the network, in this case Comcast.

So I went to site and installed an 4612 IP phone directly to the definity, thus bipassing the G350. Im running this 4612 through the same vpn tunnel as the G350. However, the 4612 never drops. Only calls that run from the g350 to the definity drop. Has anyone ever seen this before?

 

[EPalle]

Will have to start with the easy bits: check if the switchport of the G350 is set to 100Mbps Full Duplex.

The Avaya gateways are fixed to this setting, if the switchport is set to something else (especially Auto-Sense) you will have calls that drop.

Regards,
Erik

 

[Joemjauser]

Ok, im looking at it now from the maintanence page/configure interfaces. it says under Ethernet 1: Control Network
"Speed (Current Speed: 100 Megabit full duplex) AUTO SENSE"

It sounds like I have to remove the auto sense, but I dont see where I can change it on this screen? Can someone tell me where this option is set?

THANKS!

 

[EPalle]

Are you looking at the ethernerswitch or the Avaya Gateway.

In case Avaya, are you logged-in into the CLI?
I only know the commands when you are logged-in into the gateway via the CLI.
You will need to select the port and then use the following commands:

set port dublex
set port negotiation disable
set port speed 100

and then save the new config.
It is possible that the link drops when you make these changes, but it should come up again.