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

 

[kurthansen]

You will want voice networking turned on for the sigle IP trunks at each remote site or you won't have centralized voicemail or calling between sites.

Short codes are certain strings of numbers that end users dial to do special things. example is *17 is voicemail collect (call voicemail). I created short codes for redundancy on a non voice networking IPO network. I setup the trunks and then created a short code that said if anyone dialed 4xx it would go out that trunk group to get to the 4xx extension range.

Don't worry about the numbers of the lines/Trunks those are used for different things like my short code example. The reason they set the voice channels to 4 could be a few different things. Normally you set those to how many VCM(voice compression modules) channels you have. Other times it is to limit calls across the network if you don't have much bandwidth.

 

[jslewis]

There are incremental backup files in the folder:
\program files\avaya\ipoffice\manager

Does each site have their own external trunk lines, or are outgoing calls from remote sites routed back to main site to utilize a central T1?

 

[573dawn]

Good morning fellow posters! I found out as soon as I got to work this morning that he voice networking HAD to be checked on the remote sites or nothing worked.

I originally started to add all the lines back in because all remote sites were incompatible, but kurthansen was so sure of himself re the lines that I decided just to see what would happen if I added back on the voice networking, and voila! All the phones started working again.

We are now configured with only one IP trunk at each remote location, pointing back to the main site, all IP trunks at the main, and voice networking enabled. I have made sure each site can call every other site. I am looking forward to the test of time to see if my "incompatibles" have gone for good.

aarnot, thanks for that valuable info too, I was not aware of it. All the vendors who posted are making my vendor look bad

Kurthansen, thanks for your followup and assistance, I don't know where I'd be without the helpful people I always meet on the forums. (mental ward, probably)

jslewis, I hope this has helped you resolve your issues too. I will check back on the thread a bit later to update.

Now all I have to do is figure out the echo we occasionally get, but I'll save that for another thread <g>.

 

[573dawn]

jslewis, I have the PRI coming into my main site, and 3 full T1s going from the main to each of my 3 remote sites. I am actually not sure how the outbound calls are handled though.

I was led to believe that if I was watching IP Status at the main site, that I could see all active calls at all sites, but yesterday I noticed that there were calls showing on the active calls for my 2nd largest site that DID NOT show on my active call status for my main site.

My assumption would be that the outbound calls made from a remote site would route back to the main site and out, but I am not sure of this.

 

[jslewis]

I would check all sites to make sure users can make outbound calls, this morning.

 

[573dawn]

jslewis, yes, everyone can make outbound calls, the only thing I've heard this morning was someone getting a busy signal when calling a hunt group. Otherwise, all has been fine.

Thanks!

 

[jslewis]

You might have a little problem with remote hunt groups, unless you have advanced networking license on all sites. But if not, there is a work around.

 

[573dawn]

One other thing I would like to ask the thread, while we were trying to troubleshoot all of this, we went from the 8k compression to the 64k compression, and almost immediately started getting incompatibles. This was true for both ALAW & ULAW compression.

While removing the extra trunks, I noticed that the trunk from 2 of 3 remote sites was set up for aut-select on compression, but the 3rd site was set to 8k. I changed that to auto-select while making the other changes. The main site is set to 8K.

So the questions is, now that we've removed the incorrect trunks from the remote sites, does anyone think that putting back the 64K compression will get me back into "incompatible" mode? And if not, should I use ALAW or ULAW? I think my echo may be realted to it and would like to give it a try, but I wanted your opinions first.

Thanks, Dawn

 

[573dawn]

jslewis, I am not sure what we have for licensing, I will see if I can find out (is there a way to tell without asking my vendor?)

Thanks, Dawn

 

[573dawn]

jslewis, call me an idioit We have Advanced SCM Networking licenses on all sites (and I didn't have to ask the vendor, just look, duh).

Thanks, Dawn

 

[jslewis]

In system manager it is one the left about 6 up from the the bottom. The license should read advanced small comm ...
The site I am getting the incompat error is using ulaw 64, this was the only setting we could get the fax to work with. Auto select does not work for faxes on my site.
Maybe the 64k could be the cause of my incompat error.

 

[573dawn]

jslewis, funny you should mention that. We have had no end of trouble trying to fax out, and some receiving. I have been having my uses use the few remaining POTS lines to do their faxing, but overall this is unacceptable as we bought a fax server and another DID block to give everyone a personal fax line.

I am certain that the 8k compression is probably causing some of the fax issues, but I want to see how my changes for the incompatible issue go before making another change to the system.

We are a marina on a busy weekender lake, and I am thinking that I will let the weekend go by before making any other changes as our weekend phone loads are very high, but weekdays aren't. You might try changing the compression and see how the incompatibles go after that. I know that when we turned the 64K on it was almost immediate that we started to get the incompatibles, and they retreated somewhat after going back to 8k, but the problem was still there, just not as often.

 

[573dawn]

jslewis, just wondering, but if only 1 of 3 sites is using 64K, maybe making all sites 64K would get rid of the incompatible and still allow faxing, if you have the bandwidth. Then again it might not, just a thought.

 

[jslewis]

573dawn, where are you located? It feels like my time zone, which is Arizona.

 

[Escorthosis]

There was recently another thread about faxing over IPlines.
G711 Compression on the IP-Line (both sides)was required to get faxing working.
Ulaw for America, A-law for the rest of the world.
See Helpfile in Manager in system-tab and look for locale.

 

[jslewis]

All three nodes on site are using 64k, otherwise I do not think it would function at all. I was thinking of maybe adding fax only voip lines that would not have scn enabled. Then change the main voice voip lines to 8k, if this would solve the incompat problem. Although there should be a new 4.0 version coming out soon, that might clear up these issues.

 

[573dawn]

jslewis, I am located at the Lake of the Ozarks, in Missouri, central time. So you're in Arizona? Hope the weather there is nice So you are using ULAW 64K on all 3 nodes? How are your building connected? I am assuming it's NOT T1?

I am planning on switching all my sites to the 64k compression next week, pending the weekend results on the incompatible. Although it was unpredictable, it was pretty much everyday, several times a day. If I can go the next 4 days without an incompat, I will change the compression.

Escorthosis, thanks for the info, I was not aware that ULAW was for the US and ALAW for everywhere else, thank you very much.

 

[jslewis]

My buildings are connected with fiber.

 

[573dawn]

jslewis, I can't imagine fiber being an issue either. Here at my min site we have 3 buldings, and our service bldg & ship store are both connected to the sales office with fiber, but neither of them have DS units in them and the phone traffic isn't flowing over that fiber but the existing copper that was already in the ground. Still, fiber is stable and should be pretty error free.

 

[jslewis]

573dawn, I was wondering if it was a network issue. Until I saw your post with the identical problem, but using different media. I also was thinking about recommending that the user go to ptp Ts, glad I did not. Pretty sure now that it is software based (4.0). Or maybe related to the compression ratio used. I have quite a few sites that are both scn and not scn using voip but with older versions of ipo that work fine. I usually do not mess with faxing accross voip, and use the 8k codec.