1608 Diconnecting after 2 minute call

[Shortcode]

I have 10 1608 sets on the far end of a Cisco IPSec VPN Tunnel. The phones are not VPN, they are riding the tunnel to the Main Office.

What happens is this. A call is generated from 1608 set to an external number or to another IP Phone on the network. The call lasts for 2 minutes and then cuts off. The phone then re-registers on its own, it does not appear to reboot. Initially I thought it could be a UDP problem. But the Monitor for H323 Phones has an errorURQ with reason TCP Close. I know this could be the tunnel dropping the TCP keep alive from the set to the IPO.
The only errorURQ I get is during a call. The phones that are Idle on the network have only 1 registration, and no errors. It is consistent and it is annoying.
The system was previously on 4.2.? and we upgraded to 7.0.27. That is when the problem started. The phones initially did not take the upgrade, however once we did get the phones upgraded the problem persisted. No changes were made to the network during the upgrade, or shortly after.

We do not maintain the customer's network, so any advice on guiding the IT Department to the solution of the problem would be very appreciated. If this is a known issue, I am not finding any direct information on my searches.

Thanks!

"When you do things right, people won't be sure you have done anything at all.

 

[tlpeter]

It does not response to the ipoffice keep alive packets.
Do a wireshark trace and see what happens.


BAZINGA!

I'm not insane, my mother had me tested!

 

[Shortcode]

I only wish I could Wireshark. Unfortunately the system and the VMPro are in a Co-Lo, and the far end is in India. Just a slight logistical issue.

I did some more testing, and when I run a ping -t to the phone while the call in is progress, it does not drop until almost 3 minutes. One whole minute more.

When I tracert to the far end IP Phone, the tracert keeps resolving the phone's IP, and never ends. It does it over and over and over until i ctrl c.

What I keep trying to find is what changed in the VoIP operation from 4.2 to 7.0 that would cause this issue to arise.

Grrrrr. >:-<

"When you do things right, people won't be sure you have done anything at all.

 

[kwing112000]

Turn off the H323 and H225 inspect options in the cisco's on both ends.

Kevin Wing
ACSS Small and Medium Enterprise (SME) Communications
ACS- Implement IP Office
ACA- Implement IP Office
Carousel Industries

 

[montyzummer]

mentioned this before but pathping ***.***.***.*** will point out errors and calculate packet loss between hops ,,,may help

APSS (SME)
ACSS (SME)

 

[Shortcode]

Ok, so the pathping came back:

C:\Documents and Settings\Administrator>pathping 192.168.95.93

Tracing route to 192.168.95.93 over a maximum of 30 hops

0 avayavm [192.168.200.151]
1 192.168.95.93

Computing statistics for 25 seconds...

Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 avayavm [192.168.200.151]
49/ 100 = 49% |
1 254ms 49/ 100 = 49% 0/ 100 = 0% 192.168.95.93

Trace complete.
C:\Documents and Settings\Administrator>

But I think the time-outs are killing it,

timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

I have tried to convince the customer to change the UDP time-out, and to turn off the H323 time-out. Or even temporarily disable some of the timers all together just for testing.
H323 and H225 inspection maps are not enabled. It has become apparent they don't want to make changes to IPSec VPN, so there is nothing more I can do. I am sure the problem is not the IPO or the IP Phones.

c'est la vie

If I do come up with a resolution, I will post it.



"When you do things right, people won't be sure you have done anything at all.

 

[montyzummer]

Think youre on thr right track 49%loss on th first hop on the same subnet, take it youre on vlans not that familiar with cicsco but is it not IP helper that needs turning on ...one more thing if they are being so sod, ingdifficult like send out a router drayteck or the like pre config it on a PPTP connection fort Indias external IP plug in a phone and see what happens , a long way round but IM sorry mr english man but my vpn is ok dokey nothing wrong"yeah right " ,

thing is wastes time but proves the point ...oh hang on did the upgrade get done over the vpn ...if yes get IV_IP tel on site in india team view onto a local machine and upgrade the phones again , there you are two suggestions but try the IV_iptel first , if thats not relevent and thephones where done at youre head office separate router at both ends one in india one on wan /lan of IPO and prove youre heart out...good luck

APSS (SME)
ACSS (SME)

 

[Shortcode]

The phones took upgrade via HTTP on the India site. I remotely accessed a machine on site and loaded Abyss web server and had them reprogram the phones to see it upgrade. They wouldn't take the upgrade across the VPN.
The remote site is not using VLANs. There are only 10 phones and one computer on the network. But the near side is VLANs. The near side has about 100 phones on it that are working like champs. Then there are about 12 VPN phones, also rocking and rolling. Just these across the VPN.

"When you do things right, people won't be sure you have done anything at all.

 

[Shortcode]

FYI,
The customer finally looked at both sides of the VPN and found the far-end still had H323 and H225 inspection maps enabled. They disabled them and the calls started working correctly.

Thanks everyone!

"When you do things right, people won't be sure you have done anything at all.

 

[amriddle01]

Yep, issues with IP phones are pretty much by definition always network related, it's proving and finding it that's the hard part