Emerging pattern for dropped calls, maybe... 4

[573dawn]

Hi All, me again. It is looking like the drops are slowly getting better, and I am crediting routing. BUT, yesterday and today, so far there have been a couple of drops that look suspiciously similar.

Both calls arrived at one of our "non-trouble" sites and were transferred to the "trouble" site.

Both calls were dropped more than once, and circumstance #1 still applied.

Both calls were sent to HGs at the trouble site, NOT individual extensions.

Both calls appear to have been unanswered by the HGs at least once, and sent back to the originating site.

I see a pattern here, the first pattern I have seen. I will be happy to post the Monitor screens if that will help, but I don't see anything there that tells me much more than what I've outlined. I may need to change my Monitor settings, but I don't know what to add, so any suggestions would be most appreciated.

Thanks, Dawn

P.S. I have heard that it IS better, and I'm not sure whether to credit the upgrade or the route changes, and I can't really base a judgement on a day and a half anyway.

 

[573dawn]

Then again, maybe not...I just had a call telling me that 3 were dropped in rapid succession, but they weren't transfers. What is weird is that they don't appear to have come in across the PRI or beemn transferred from other locations. Direct dial into the trouble site is SUPPOSED TO be on POTS, but is still going through the DS unit, WTH?

 

[573dawn]

I can link one drop definitively to:

I80735652mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...
80735653mS CMLOGGING: CALL:2007/07/2709:41,00:01:29,006,2178266591,I,537,537,BOYERJOHN,,,0,,""n/a,0
80735654mS CD: CALL: 10.171.1 State=2 Cut=1 Music=1.0 Aend="Line 10" (0.0) Bend="" [Toya Phillips(510)] (1.31) CalledNum=510 (ServiceWrtrGr21) CallingNum=2178266591 (BOYER JOHN ) Internal=0 Time=96853 AState=2
80735654mS CD: CALL: 10.171.1 Deleted
80735657mS CMLineTx: v=10
CMReleaseComp
Line: type=IPLine 10 Call: lid=10 id=171 in=1
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
80735660mS CMExtnTx: v=510, p1=0
CMReleaseComp
Line: type=DigitalExtn 3 Call: lid=0 id=2730 in=0
Cause=2, No route to specific transit network/(5ESS)Calling party off hold
Timed: 27/07/07 09:42
80735662mS PRN: EXTN: Toya Phillips received CMFacility msg for deleting ep 0.2730.0 -1 Toya Phillips.-1
80735668mS CMMap: a=0.0 b=0.0 pcp[318]b0r1 RTPH0
80735668mS CMMap: a=3.1 b=0.0 H0
can link at least on drop to the following:

 

[573dawn]

I've had a radical idea: What if I drop the IP trunk to my trouble site altogether and force my other three sites to transfer to the POTS lines at the trouble site?

 

[tlpeter]

You can try it
if the calls keep dropping you know for sure it is on that site
then you are sure it is not a network issue
try it for a few days

but be very sure that there is no route to that site
also not thrue another site



ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[573dawn]

tlpeter, each DS unit has a static IP route to each other unit, so I would need to remove the statics to the trouble site in each DS as well?

Example: remote site HWY to trouble site 21 DS has a route of:

192.168.3.180 (trouble site) 255.255.255.0 10.10.1.1 (HWY site router)

So I would need to remove each static route on each DS as well as the IP trunk (just want to be perfectly clear)

In addition, I can't take the T1 to the trouble site down altogether as they need it for our main software application. I don't know what you know about cicso, but they are all static routed as well.

 

[kwing112000]

I know you have had alot of posts on here with all of the isssues you are having. I am sure this was mentioned before but have you checked the direct media path on your IP Lines. Maybe if it is on try to turn it off and see if the issue gets better. If you have already tried then ignore this.

 

[573dawn]

Kwing112000, already been done, thanks though

 

[kwing112000]

I figured that. Sorry..

 

[573dawn]

Nothing to be sorry aboutm I'll take all the help I can get!

On the phone with ATT...Seeing Media Exceptions today, no transports available, they're saying it's the IPO software. Just cleared the counters on my routers, the Media exceptions/no transports can be directly correlated to drops today...

 

[tlpeter]

if i understand right then you have a main site with ip routes to the remote sites

but the remote sites also have iproutes to each other ???
if yes then remove all those

the main ipoffice should have iproutes to the remote locations and the each remote location should only have 1 iproute to the main site


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[ProviderReborn]

Sorry to be really "Anal" here.
I like tlpeters advice here.
Can you take 5 minutes to clearly put your IP Routes up here for Main site/Site A/Site B

And also list up your IP Lines Incoming and outgoing for each system too.

Thanks

 

[Gibsonic]

i casting my lot that the config on the "trouble" site is somewhat corrupted and should be wiped clean and started from scratch.

 

[573dawn]

Ok Guys, here you go:
Main site DS 192.168.0.180
1mm (non-trouble) DS 192.168.2.180 / Cisco 192.168.2.1
Hwy (non-trouble) DS 10.10.1.180 / Cisco 10.10.1.1
21mm (TROUBLE) DS 192.168.3.180 / Cisco 192.168.3.199

Cisco from Main to 1mm & Hwy 192.168.0.200
Cisco from Main to 21mm 192.168.0.199

Main Site IP Routes:
10.10.1.180 255.255.255.0 192.168.0.200
192.168.2.180 255.255.255.0 192.168.0.200
192.168.3.180 255.255.255.0 192.168.0.199
IP Lines:
10 - to 21MM 192.168.3.180
11 - to Hwy 10.10.1.180
12 - to 1MM 192.168.2.180

1MM Site IP Routes:
10.10.1.180 255.255.255.0 192.168.2.1
192.168.0.180 255.255.255.0 192.168.2.1
192.168.3.180 255.255.255.0 192.168.2.1
IP Lines:
12 - To 192.168.0.180

HWY IP Routes:
192.168.0.180 255.255.255.0 10.10.1.1
192.168.2.180 255.255.255.0 10.10.1.1
192.168.3.180 255.255.255.0 10.10.1.1
IP Lines:
11 - to 192.168.0.180

21MM IP Routes:
10.10.1.180 255.255.255.0 192.168.3.199
192.168.2.180 255.255.255.0 192.168.3.199
192.168.0.180 255.255.255.0 192.168.3.199
IP Lines:
10 - to 192.168.0.180

 

[573dawn]

I should mention here that the original config, the meshed one, had all 3 IP lines on all 4 DS units, this was what was causing my "incompatible" errors that plagued us for the first month and a half, kurthansen caught that one.

 

[ProviderReborn]

Your still IP meshed by the looks of your routes.

Your main site wants all.
1MM wants 192.168.0.180 255.255.255.0 192.168.2.1
HWY wants 192.168.0.180 255.255.255.0 10.10.1.1
21MM wants 192.168.0.180 255.255.255.0 192.168.3.199

The line routes look ok.

Any one else want to comment on that before its tried.

 

[573dawn]

TheProvider, so the remote sites' IP routes should only point to the main DS?

I know my BP set up alot og things incorrectly, but one thing they really stressed was that all DS units should be able to talk to all other DS units, hence the multiple routes.

If they are wrong, which I would very much believe, are you telling me that each DS has to talk to the MAIN DS, and it it the MAIN DS job to then route the transfers to the correct sites? I just want to be very very clear in case I wreck the whole thing

 

[ProviderReborn]

Await some clarification on this. But our own in house multisite is set up this way and also I would set up any sites I was tasked to do this way.

One quick Q I have for you. Do you have VM if so is it centralised?? off your main site???

 

[573dawn]

Yes, and Yes, and I will definitely wait for clarification!

 

[ProviderReborn]

And to be sure none of the remote sites have their own independant VM's.