atcomsystems.ca/forum Forums TDM Business Telephone Systems Avaya - Lucent Telephones & Systems 400x series IPO: AMI vs B8ZS in VoIP environment

Another helpfull tidbit is give us a run down of the systems in question. Model/version/etc.

If this is the case, how many IP trunks are configured the different sites? How many systems are connected? Is this an scn? And, as IPOfficeguy asked, what releases are we talking?

ipofficeguy, I think I am probably the same Dawn if you are referring to the tek-tips forum, I still have posts there too <g>. Ok, here we go...

Yes, all calls come in to the hub on a PRI and are then routed over IP lines to the destination indicated by the called number, including all spokes. When a call comes in for the Hwy spoke, it rings there, but I am assuming that it comes into the PRI at the hub before heading to the Hwy. Then if the call is for aother spoke, is would be sent to that spoke directly. After approx 1:30 the call will drop.

There are 3 IP trunks configured at the hub (numbered 10,11,12), one IP line at each spoke (numbered 20,30,40). It is an SCN, we are using IP406 Office, IP400 Digital stations, and at all but one very small site IP400 Phone units. The versions are:
Hwy: 4.0(14) & 6.0(14)
1mm: 4.0(14) & 6.0(14)
21mm: 4.0(10) & 6.0(14)
3mm (hub): 4.0(14) & 6.0(14)

I think that the 21mm is out of date because over the weekend we had a component fail and it had to be replaced yesteday (they lost all phone service there). The BP didn't mention needing to upgrade it, but I am going to assume that I will need to do that.

Hey, it looks like there is updated software for all units, admin 4.1(12)? Do I need the user 4.1(17) release and the VM Pro 4.1(40) release too?

Also, do I need to do the maint releases from December 07 first? And is there a way for me to be notified when these releases come out?

In those IP trunks that are configured (one trunk for each remote system) how many channels are there for each of them?

Also, what type of connection is the IP trunk using? Free internet? Point to point T1?

mongo5150, I have them configured as 4, 6, & 6. Originally they were configured for 4, 8, & 8, but we only have a total of 16 VCMs at the hub, and if I understand correctly, the total of the spokes can't exceed the total at the hub. Please clarify if I am incorrect.

They are connected by the PTP T1s, I have no internet traffic at all crossing them, internal data and voice data only, with class-based QoS on the routers to give the voice traffic 50% dedicated bandwidth. Before implemeting the QoS, if I flooded a T1 with data and placed a call to that location, it was obvious in the horrid quality of the call. Since implementing QoS that is no longer a problem.

Just to make sure I understand this. The PRI where all calls come in is at the main (HWY) site?

Then if the call is meant for the spoke site, it routes there as per the incoming call route...

Where the problem is, is after the spoke answers or whatever, when the call gets rerouted back to the main site, that is when the problem occurs?

Do these site all have their own voicemail, or is this centralized?

Was there a network assessment done? IF so, were the QOS settings made afterwards?

Simple answers first..
If you are going to upgrade to 4.1.++ then yes you would also need to upgrade the user and VMpro release. You don't need the maint release from Dec, and there isn't an easy way to be notified of new releases other than to check the site every 3-4 months. (updates are scheduled to be released quarterly....but that isn't always the case)
You can have more channels and/or ip lines configured than what you physically have in the system, just as you generally have more phones than lines, but you would only be able to utilized the amount of channels you actually have.

You might get lucky and resolve the issue you are having by upgrading to at least the latest maint. release.

The only other obvious thing I can think of at the moment would possibly be "direct media path" being checked when it shouldn't.

It really is a strange setup with an even stranger problem. I haven't noticed a bug listed with this type of problem but since I haven't encountered this setup myself yet, I haven't been looking for it either but will check the caveat list for something similar.

Have your business partner check into these...


CQ39306

Call between remote site drops after 90 seconds on ISDN line

4.0.10

MT_RELEASE_2Q08_4.1


3-Available

6.0.102804


CQ58088

External calls into PRI forwarded to remote SCN site drops after 90 seconds.

4.0.7

MT_RELEASE_2Q08_4.1


4-Proven

4.0.75060

mongo5150, no, the main site is NOT the HWY, HWY is a spoke. Only calls that originate at the HWY (I am assuming that they really originate at the HUb on the PRI but go directly to HWY via forward not incoming call route), and are transferred to another spoke will drop. If the call comes into HWY and is transferred to HUB before being transferred to a spoke, the call will stay connected. Voice mail is centralized. And NO, the BP did NOT do a NA, though it is a requirement. I had absolutely zero experience in phone systems when this was installed, we relied on the BP to tell us what we needed. He didn't. We have been trying to get him to do one ever since. He won't. I have acquired the knowledge I have of Avaya because of places like this where people with much more knowledge than I are willing to share their expertise. My background is in PCs and LAN/WANs with non-voice data, or I'd really be lost.

ipofficeguy, LOL! You already know my BP is, well, shall we say less than helpful? At this point, the BP and I only speak when forced to do so. I was in fact pointed to the docs you mentioned over at tek-tips, and indeed I plan to upgrade and hope to get lucky :)Thanks for the advice on what I need and what I don't. None of my units have "direct media path" enabled, we took that out sometime last summer. It was only when I stopped paying attention to the BP that I got THIS far. The BP never looked at where the call came from, only where it went, as it turns out, where it started is key, or we wouldn't have the workaround (that I discovered all by myself <g>).