Avaya 5410/5420 "incompatible" state to remote site 1

[573dawn]

Hi to all. I have a new Avaya phone system giving me all kinds of trouble. The system is an IP400, with an IP 406 Office, and IP 400 digital station boxes at my main location. We have 4 sites overall, connected by PTP full T1s.

On a completely random and totally unpredictable basis, any location might get "incompatible" showing on the phone display when trying to reach another location. It happens most between our 2 largest sites.

We have troubleshot this to death and can't find a solution. The T1s are in no way overloaded (avg usage under 2%), and are not taking any more errors than one might expect to see. Overall latency between any 2 elements on the entire network generally doesn't exceed 28-30ms.

I am monitoring all manageable elements with Solar Winds, and there are no network events that can be correlated with the outages, which can last anywhere from a few seconds to hours. Resetting the voice switches seems to bring the system back, but obviously that is not a solution.

Has anyone heard of this? Our vendor has indicated that there are no cases with Avaya that present this issue. For anyone with a reply, our email server is down right now, and should be up later, but I have ICQ (member#496-338-187)on and will check back often.

Thanks, Dawn

 

[ronromano]

Is SCN enabled or are you dialing each site via outside line? I know your post says PTP T1s but you never know.

What version are the systems?

 

[573dawn]

I am unsure what SCN is, can you tell me? I am very new to voice telephony (I know data ok though). We have a PRI coming into our main site, and calls are transferred to the other sites across our T1s (cisco 1720/21s on each end, no traffic shaping or policy maps, but with such low usage thought probably not necessary?), or we can just pick up and dial an extension to reach a person we want to speak to.
Except when we get the "incompatible" at which point we can't transfer or talk to an extension. What makes it weirder is that sometimes, even though we can't reach them, they can reach us, and are still getting calls to their main number. The old POTS numbers are forwarded to the PRI, so why they can still get calls when we can't reach them from another location is a mystery, although it is not ALWAYS that way. Sometimes they can't be reached period. It is very unpredictable.

The version on the boxes is 4.0(5) and IP Office version 6.0.5.0

Thanks!

 

[jslewis]

I have this happening with a 3 node scn site 4.0.5x. All voip lines are on the same lan. We also lose incoming audio when people call in over the T.

 

[573dawn]

Hi jslewis, and thanks for finally letting me know I am not insane. My vendor is blaming my network, which as far as can be determined is not the issue. I have figured out that to do the things we are doing, we apparently have SCN in place.

We tend to lose some audio too, for instance if we transfer a call to a person who has their 5410 forwarded to their cell phone.

When you say all voip lines are on the same lan, do you mean they are all on the same subnet?

 

[ProviderReborn]

How has your vendor configured your SCN?

Star topology or Meshed. Check your IP Lines on each site.

 

[573dawn]

TheProvider, as far as I can tell with this system it is star. We have 4 lans:
192.168.0.x
192.168.2.x
192.168.3.x
10.10.1.x (I know, but it was set up like that before I worked here)

Each DS unit is addressed as x.x.x.180, and the main location where the PRI comes in is 192.168.0.180.

Each local cisco router is set as the gateway for the local DS units. Therefore, in the main unit of 192.168.0.180, the routes are:
192.168.2.180(switch) 255.255.255.0 192.168.2.1(cisco)
192.168.3.180(switch) 255.255.255.0 192.168.3.199(cisco)
10.10.1.180(switch) 255.255.255.0 10.10.1.1(cisco)
A default route of 0.0.0.0 0.0.0.0 192.168.0.200(cisco to 2 of 3 remote sites, not sure it should be here)
And a route of 192.168.99.0 255.255.255.0 0.0.0.0 is there as a remote management route.
_______________________________________________

Each remote site is set up he following way (using the 192.168.3.x site as an example):
192.168.2.180 255.255.255.0 192.168.3.199
192.168.0.180 255.255.255.0 192.168.3.199
10.10.1.180 255.255.255.0 192.168.3.199
192.168.99.0 255.255.255.0 0.0.0.0

Could the remote management addresses be the problem here? I see in SCN Help that mesh topology is not supported, could the switches be trying to use this route at random times and getting lost? I'm grasping at straws here, thanks in advance! I didn't set up the routes in the voice switches (the vendor seems to think that they should have exclusive rights to configure this until our warranty is up, though I CAN change it).

 

[ProviderReborn]

Did your vendor to a network survey before role out? I can see your av use is under 2% but I say in this game never rule any thing out.

 

[573dawn]

One more thing, a couple of my ciscos have more than one route. They don't necessarily need to, could that be playing havoc with this phone system?

 

[573dawn]

No, the vendor stated that the network was not their responsibility. I just found out a couple days ago that QoS is a REQUIREMENT that Avaya specifies, we've had the sytem for over a month. I have done cisco for huge WAN data only applications, but never for voice, so we did bring in a 3rd party to look over the routes on the ciscos at my request. He made a few changes, but I am wondering if they were the correct changes at this point.

 

[jslewis]

573dawn, my 3 scn nodes are on the same subnet. 3 building within the same business park.
How many voip lines do you have under lines on each ipo?

 

[573dawn]

jslewis, I have 7 lines shown on each remote switch, 4 analog and 3 IP; 8 on my main site, including the PRI.

 

[kurthansen]

That is your problem. You should only show 1 IP trunk at each remote site, the hub site. The hub site should have an IP Trunk for each remote site.

 

[573dawn]

Kurthansen, could you please clarify? I am unsure what you mean by trunk here. Do you mean I should only have one IP line showing under "line" in IP Manager for each site, where right now I have 3 IP lines showing in each IP Manager?

Thanks!

 

[573dawn]

Friends and VERY helpful fellow posters, I am off for the day and as my husband works here too and we rode together today, I need to leave ontime. I will jump on when I get home and be back tomorrow as well.

I think we're very close to solving this and I am begging you all not to let thius thread die!

Thanks again, Dawn, be back soon!

 

[kurthansen]

Correct. You only want one IP line/trunk in the remote IPOs. And you want the IP address pointing to the hub/main IPO. In the hub/main IPO you want an IP line/trunk for each remote IPO.

Well I guess I should clear something else up. I have done this the way you have yours setup also but I don't have 'voice networking' turned on on all of the IP trunks/lines and also have short codes for routing calls correctly incase my MPLS to the hub/main IPO goes down.

If you have all these IP lines/trunks make sure that 'voice networking' isn't turned on on all of them or you will have problems. You will want 'voice networking' turned on to just the ip line/trunk that your hub/main site is located.

 

[573dawn]

Kurthansen, thank you so much. I have to admit I am scared to death to do this given the potential dire consequences.

So. My Main site has lines:
Remote site gc-yacht 192.168.2.180
Remote site gc-hwy 10.10.1.180
Remote site gc-marina 192.168.3.180

BUT Remote site gc-yacht should only have line:
Main site gc-sales 192.168.0.180

AND Remote site gc-hwy should only have line:
Main site gc-sales 192.168.0.180

AND Remote site gc-marina should only have line:
Main site gc-sales 192.168.0.180

as IP trunks? Sorry to be redundant but I have to be SURE.

Thanks again, Dawn

 

[573dawn]

Kurthansen, can you clarify one more thing for me? Short codes: What are they?

If this is too much to ask, I can research it, but a short definition would be beneficial. I will look at this aspect as well.

Thanks, Dawn

 

[573dawn]

Kurthansen et al, I have removed the recommended IP trunks from the remote sites, leaving only the IP trunk lines on each for that location going back to the main site. I have also removed voice networking from the remaining IP trunks at the remote locations.

I have left all of the trunks and voice networking intact at the main site.

I did nothing with short codes; all short code pages were blank, but I would like to know more about them and how they might be used for redundancy.

I did notice that there were some inconsistencies on the removed trunks in the way the vendor set up the line #s, for instance, at one location the line number was designated 12, but at another it was designated 20, and at yet another it was designated 21. I have removed those, so they shouldn't matter, but I thought it was odd.

I also think it is odd that where the # of channels = 20, and the number of outgoing channels = 4, and the number of voice channels = 4, that the data channels = 20. I would have thought that the data channels remaining would = 16.

I guess we'll know more tomorrow, I will update the thread at that time.

Thanks again to all! Dawn

 

[aarenot]

573Dawn,

For each site. In manager, File, saves as, then choose the place to save the CFG. This saves the configuration. Close manager.

To restore this CFG, in manager, File, Offline, Open File, (double click the previously saved file). Then, File, Offline, Send Config.

This is from memory, but should be pretty close. The point is, do not be afraid to make changes, you can always change it back. Note: restoring from the saved file causes the system to reboot.