Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

New thread for bigblock454's drop issue, updated info & summary

Status
Not open for further replies.
Sep 12, 2007
143
US
Hi All, I seem to have too many threads for my drop issue, so I thought I'd start this new, up to date thread.

Setup: 4 locations, 1 hub (3mm), 3 spokes (1mm, Hwy, 21mm)
All connected by B8ZS/ESF PTP Full T1s on 1721 Cisco routers running QoS. Switches are Avaya P133GT2s with port prioritization on voice and router ports.

Problem: If a call comes into the Hwy spoke and is transferred directly to another spoke, the call will drop 100% of the time. If the call is transferred to the 3mm hub FIRST, and THEN transferred to another spoke, the call will stay connected.

Our bandwidth is underutilized most of the time, we have virtually no congestion, packet loss, jitter etc. I have never been able to find anything that indicates the problem.

The error that accompanies a drop is consistent (call information removed):

176379090mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...[call information]…
176379091mS CD: CALL: 40.64.1 Deleted
176379095mS CMLineTx: v=40
CMReleaseComp
Line: type=IPLine 40 Call: lid=40 id=64 in=1
Cause=2, No route to specific transit network/(5ESS)Calling party off hold

In all the time we have tried to troubleshoot this, we have focused on the destination and believed it was random and unpredictable. In fact it is nether random nor unpredictable. The calls ALWAYS originate at the Hwy, and ALWAYS drop if directly transferred to another spoke. The calls ALWAYS stay connected if sent to the hub FIRST. I am beginning to wonder if we have a bad DS or corrupt config at the Hwy location.

 
On the HWY site what do you have for IP lines? Is it just 1 to the hub? what about IP routes? what do you have there?

Kevin Wing
ACA- Implement IP Office
Carousel Industries
 
If you are running the same switches at the locations you can always take backups, swap two IPOs, apply the proper configs and see if the problem follows the switch. Its drawing straws but might be worth a try. You never know.

Chris
ACA- Implement IP Office
 
By directly transferring what do you mean here?

Is it a DDI pointing to a remote extension. Could you explain how the transfer is working.

ACA - IP Office Implement
ACA - IP Telephony
CCENT - Cisco ICND1
CCNA - Working towards.
 
She has a main site (hub) and 3 spokes. If she transfers from HWY directly to another spoke it drops the call. However if she transfers from HWY to the Hub then to the spoke it works fine. the other spokes work fine.

BigBlock did I remember right?

Chris
ACA- Implement IP Office
 
oh HWY is one of the spoke systems. forgot that little BIG detail :).

Chris
ACA- Implement IP Office
 
Ok,

What happens, does the remote phone ring and drop on pickup?
Please can you explain the scenario of what happens at each side of the transfer please.

ACA - IP Office Implement
ACA - IP Telephony
CCENT - Cisco ICND1
CCNA - Working towards.
 
Also a trace on each end would be very handy.
You should be able to rig this now you know the scenario in which the call is dropped.

ACA - IP Office Implement
ACA - IP Telephony
CCENT - Cisco ICND1
CCNA - Working towards.
 
To be honest i do not remember.

Another thread discussing the issue is here thread940-1457999



Chris
ACA- Implement IP Office
 
Hi guys, and you all have great memories :) Anyway, the calls connect when transferred from Hwy, and they stay connected anywhere from 30 seconds to 2 minutes, the majority stay connected for about 1:30. They are being sent to both individual DIDs and HGs, that part doesn't matter, they all drop.

Example: I call the main number for the Hwy and they answer (doesn't matter who answers or from what phone). I ask for a DID at the 21mm or the 1mm, and am sent to that DID. The called party answers and we chat for what is almost always 1:27-1:35 and the call drops. On my cellphone I hear two beeps then silence. On a landline, it is just silence.

I would like to do the trace thing, I just have so little idea of what I'm doing that although I can follow the instructions provided in IPO Tech Tip 195 (hat tip to AZJeepGirl) up to a point, I feel like a first grader trying to read a college thesis. I'm not even sure I'm doing it right. I guess that should be my next step though, so should I set one up at the Hwy and the other at the 21 or the 1 spokes? I don't know that having it set up at the Main does me any good.
 
By trace we are looking for an IPO monitor trace. I would run monitor at the HWY site and the destination site of the transfer for the entire call so we can see what both sites see. Also does HWY have a PRI? If so this sounds like it could be the problem that Kurthansen posted the CQ for in thread940-1457999 .

A CQ is a trouble tracking ticket avaya uses. Usually if they acknowledge a problem they will create a CQ then make a private build to fix the problem or release it in the next GA. Those look like they were fixed in a private build but 4.1 will most likely have the fix as well.

What version software are you running?

Chris
ACA- Implement IP Office
 
Oh, and about the IP lines, there is only one from each spoke to the hub, they are uniquely numbered, and each spoke DS unit has 2 routes, which are:

0.0.0.0 0.0.0.0 [local cisco fastethernet address as gateway]
and
192.168.99.0 255.255.255.0 0.0.0.0
which is apparently the remote access address, though no one remotely accesses them.
 
on the routes that have all the 0.0.0.0 do they have LAN 1 as the destination?

Kevin Wing
ACA- Implement IP Office
Carousel Industries
 
kwing, all spokes have LAN1 as destination with the 2 routes described. The hub has the following routes, also with LAN1 as destination (the gateway addresses are the fast ethernet ports on the 1721s a the hub that go to each spoke):

10.10.1.1 255.255.255.0 192.168.0.200
192.168.2.0 255.255.255.0 192.168.0.175
192.168.3.0 255.255.255.0 192.168.0.199

 
That first one looks wrong. I think that should be 10.10.1.0? is that how it is in the system or just a typeO. That is saying when you want 10.10.1.1 go to 192.168.0.200 but not anything else. do you also have a default 0.0.0.0 route on the main? if the network is set up properly then the default gateway should know the routes to each site as well. it is a little fall back if one of your other routes is not right.

Kevin Wing
ACA- Implement IP Office
Carousel Industries
 
kwing, you were right it's a typo, it is:
10.10.1.0 255.255.255.0 192.168.0.200

I don't have a default route on the main, just the ones I showed you. If I wanted to add one, what would it be?

Each hub router (one for each spoke) has IP routes such as (this is the hub router to the Hwy router):
ip route 10.0.0.0 255.0.0.0 Serial0
ip route 192.168.2.0 255.255.255.0 192.168.0.175
ip route 192.168.3.0 255.255.255.0 192.168.0.199

Each spoke router has only a default route, here is the Hwy IP route:
0.0.0.0 0.0.0.0 se0

I can't ping from one spoke router to another though, just from spoke to hub.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top