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]

Gotta head home, have to get a ride from a co-worker, hubby tied up. Will check back as soon as I get there, I have remote access, naturally

Be back very soon!

And THANK YOU ALL, you guys are the best!

Dawn

 

[573dawn]

Ok, home now, is there a consensus?

 

[intrigrant]

It is a H.245 problem
I80735652mS ERR: EXCEPTION ON MEDIA CONNECTION --- Error from protocol entity! MSDSE --- local timer expired ...
This is a H.245 protocol error.
MSDSE = Master Slave Determination Signalling Entity
If timer T106 expires then the MSDSE user is informed with the REJECT.indication primitive and a
MasterSlaveDeterminationRelease message is sent to the peer MSDSE.

For humans: The two systems create a connection, one of them is a master and the other is a slave.
The slave has to reply on the keep-alive packets which are send by the master gatekeeper in order to check if the connection is still alive.
The Gatekeeper uses a timer for this : T.106
If the master gatekeeper do not receive a acknowledgement from the slave within the expiry of T.106 the master will terminate the media stream, what we call a broken call.

Make sure you have selected H.450 on both IP Trunks, enable Faststart.
Run Monitor on both sites and select only the first four options of the interface and error on the system tab.
Check that if the slave sends ACK messages that the master receive them.
I once had a issue with this using Cisco switches/routers/PIX firewall.
For some reason the cisco systems sometimes blocked the ACK messages, the Cisco gurus solved it, i do not know what they did.

 

[573dawn]

intrigrant, thank you. But I have a question, my BP had me disable faststart on all IP lines and said there was a bulletin from Avaya telling him to do this in relation to VM, do you know anything about that?

Also, what is your opinion of the routes?

 

[573dawn]

intrigrant, ok, both ends were H450, and I re-enabled faststart. Is there anything else I can do for the timer? Would the routing potentially be causing this too?

 

[intrigrant]

Sorry, the faststart must be disabled and also disable the direct media path option.
I don't have enough time right now to take a close look on the IP routes.

 

[573dawn]

intrigrant, I thank you for any of your time. I will disable the faststart and the direct media path is already disabled. Thanks again

 

[intrigrant]

One quick quetion more : if the remote sites call each other do they also experience dropping calls?

 

[573dawn]

intrigrant, in general, no. There have been a few, one I experienced myself. BUT, and this is a big but, the trouble site recieves far more of the calls than any other site.

In addition, we have both the main site and the Hwy (non-trouble) site receiving calls to the main number, by far the majority of the drops are calls transferred from the Hwy site to the 21mm (trouble) site.

 

[573dawn]

incidentally, when we bought the 21mm (trouble) site last year, they had all of 4 POTS lines, which were busy all the time. We had no idea the actual call volume that place gets until we did this. It's pretty huge, we max out the PRI regularly on weekends.

 

[intrigrant]

Concentrate on the IP Link between them, there you will find the problem. Maybe there is a problem in a switch or in the router, check the equipment for packet loss and delays as the keepalive system use conectionless UDP packets.
It could very well be something stupid as the speed settings of the switch port were the IP Office is connected to, make it fixed to 100Mb full duplex for a 406V2,412 or a 500, and 100Mb halfduplex for a 406V1 or 403. On a heavy load on a switch port with auto negotiation you can have this kind of problems. Maybe you may have to program DiffServ QoS on the switches too.

 

[573dawn]

intrigrant, very interesting thing here. If you ping a DS from my pc, there are no timeouts, but if you trace, you will get 3 timeouts before hitting the DS, for a total of 6 hops to the remote DS.

BUT, if you trace from the main site router to the remote DS, it doesn't find it.

BUT, if you trace from the remote router, it's one hop.

this has been the case all along.

 

[573dawn]

oh, and speaking of the switch port, it is an auto-negotiate and runs at 100Mb, should it be something else? How do I tell which IP406 I have?

 

[tlpeter]

This is how a 406v2 looks like

and this is a 406v1

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!

 

[tlpeter]

No pictures aloowed here

And indeed you stil have a mesh

the main site is alright

at the location 1MM delete the routes to 21MM and HWY
at hte location 21MM delte the routes to 1MM and HWY
at the location HWY delete the routes to 1MM and 21MM

also the VMPro server must be at 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!

 

[intrigrant]

A mesh config is possible, as long as the lines with the "Speech network" option are setup as a star config.


http://marketingtools.avaya.com/knowledgebase/ipoffice40en/mergedProjects/productdescription/images/ip406_v2_front_annotated.gif

and this is a 406v1

[img]http://marketingtools.avaya.com/knowledgebase/ipoffice21en/mergedProjects/productdescription/images/control_unit_406_annotated.gif

 

[mattKnight]

How are your cisco routers programmed? - it is still entirely possible that the Cisco's are programmed for a Mesh configuration rather than a star...

Maybe we are making things more complex than they need to be on the IP routing side...

I.e.

current @ Main Site
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

Suggested @ Main Site
0.0.0.0 / 0.0.0.0  / 192.168.0.200
192.168.3.0 / 255.255.255.0 / 192.168.0.199

current @ 1MM Site
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

suggested @ 1MM Site
0.0.0.0 / 0.0.0.0 / 192.168.2.1

Current @ HWY Site
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

suggested @ HWY Site
0.0.0.0 / 0.0.0.0 / 10.10.1.1

Current @ 21MM Site
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

Suggested @ 21MM Site
0.0.0.0 / 0.0.0.0 / 192.168.3.199

basically, push all non local IP traffic to the Cisco routers. The only exception to this is at the main site where traffic to 192.168.3.x subnet uses a different router.

At the very least, I think the routes need to be made into subnet routes rather tha specific IPs

that is using main as an expample

current @ Main Site
10.10.1.[b]0[/b] / 255.255.255.0 / 192.168.0.200
not
10.10.1.[COLOR=red]180[/color] / 255.255.255.0 / 192.168.0.200

192.168.2.[b]0[/b] / 255.255.255.0 / 192.168.0.200
not
192.168.2.[COLOR=red]180[/color] / 255.255.255.0 / 192.168.0.200

192.168.3.[b]0[/b] / 255.255.255.0 / 192.168.0.199
not
192.168.3.[COLOR=red]180[/color] / 255.255.255.0 / 192.168.0.199

I hope this helps!

Comments please folks!

Take Care

Matt
If at first you don't succeed, skydiving is not for you.

 

[573dawn]

Good Morning fellow posters, ok, I'm going to post these as I go, sorry that it will be multiples, but it's less confusing for me.

Changed the Main routes to:
10.10.1.0 255.255.255.0 192.168.0.200
192.168.2.0 255.255.255.0 192.168.0.200
192.168.3.0 255.255.255.0 192.168.0.199

Changed the 1mm routes to:
0.0.0.0 0.0.0.0 192.168.2.1
removed other routes

Changed the Hwy routes to:
0.0.0.0 0.0.0.0 10.10.1.1
removed other routes

Changed the 21mm routes to:
0.0.0.0 0.0.0.0 192.168.3.199
removed other routes

Then I had each location transfer me to another location, all worked just fine...

And now for the routers, be back shortly

 

[573dawn]

Ok, here are the routers, I posted this on a Cisco thread as well (the first portion is already on this thread, but left here for convenience).

We have 4 locations, 3 are non-trouble sites for the phones, one is a nightmare:
Main (non-trouble)
1mm (non-trouble)
Hwy (non-trouble)
21mm (TROUBLE)

Here are the basic setting for each:
Main router #1 goes to 1mm & Hwy
fa0 192.168.0.200/24
se0 to Hwy 192.168.254.1/30
se1 to 1mm 192.168.254.5/30
IP ROUTES
IP classless
IP route 10.0.0.0 255.0.0.0 se0
IP route 192.168.0.0 255.255.255.0 se0
IP route 192.168.2.0 255.255.255.0 se1
IP route 192.168.3.0 255.255.255.0 192.168.0.199
no IP http server

Main router #2 goes to 21mm
fa0 192.168.0.199/24
se0 to 21mm 192.168.254.10/30
IP ROUTES
IP classless
IP route 192.168.3.0 255.255.255.0 se0
IP route 192.168.3.0 255.255.255.0 192.168.254.9
no IP http server

Router at the 1mm:
fa0 192.168.2.1/24
se0 192.168.254.6/30
IP ROUTES
IP classless
IP default gateway 192.168.254.5
IP route 0.0.0.0 0.0.0.0 se0
no IP http server

Router at Hwy:
fa0 10.10.1.1/8
se0 192.168.254.2/30
IP ROUTES
IP classless
IP route 0.0.0.0 0.0.0.0 192.168.254.1
no IP http server

Router at the 21MM:
fa0 192.168.3.199/24
se0 192.168.254.9/30
IP ROUTES
IP classless
IP route 0.0.0.0 0.0.0.0 se0
no IP http server

thoughts?

 

[intrigrant]

I have been reading this whole thread again and one thing i noticed :
Line 10 on the main site is connected to Line 10 in 21MM.
Line 11 on the main site is connected to Line 11 in Hwy
Line 12 on the main site is connected to line 12 in 1mm

In SCN it is mandatory that all line group numbers have a unique number. This is for the route-optimalization.
My advide is to change Line ID in 21MM to 20, in Hwy to 30 and in 1mm to 40.
Keep the Line ID starting with 1 for site 1, line IDs starting with 2 for site 2 and i guess you'll know what to to with the other sites.
Check the shortcodes with the "old" LineID and change them also.
This may not solve this problem but it makes the system more stable and accurate.