There are different interpretations to the term glare, so in regards to my question, I'm referring to the scenario where two calls attempt to access the same 2-way PRI trunk channel simotaniously from oppisite directions.

An in-service 2-way PRI trunk between our 5ESS and a local G3R has no alarms, symtoms, or issues whatsoever with calls procesing to and from either direction. This has been confirmed by myself here at the 5E and by the local Definity G3R tech. However the local Definity tech is receiving glare errors when his PBX performs a daily scheduled diagnostics. In the 5ESS, I've updated the glare control for the trunk group in 48 hour increments from 'all' to 'none' and then back to 'all', to see if this had any impact on the errors he's receiving. He's still receiving the errors, and he and I agree that all calls are still processing fine to and from both directions. I was simply going to suggest to him to refer this symptom to Avaya, but I wanted to see if I could get some input from any of those here whom may have experienced similar symptoms with Definitys. Could there be an issue with his G3R diagnostics program?

Thank you all in advance for any help or input that I can pass on to him.

Don't know about the diagnostics, but has he verified that both switches aren't hunting the same direction? What type trunk conditioning? I would think a PRI would be wink wink and you shouldn't have glare problems at least I'd think it'd be pretty rare, unless both switches are hunting high low or low high. Most the time I saw glare was when this was the case.

Thanks Bill. That's what I was thought at first, but we've each confirmed that we're set up opposite in hunting the B channels. Here's what I'm contemplating: We're both currently set for loop start, and I heard somewhere that changing from loop start to ground start may help eliminate any glare conditions, even though I honestly feel that glare isn't even occurring. Every test from my end passes fine, no errors or alrarms at all, the calls are also processing fine, and he and I try to help each other whenever we can. I can't think of anything else to suggest. I'll see if I can have him email me the exact error message he is receiving to post here, to see if it strikes any bells. At least the calls are processing fine while we work this. I'm just trying to avoid 'MBSWWYPBX', but he may just have to escalate this up to Avaya. :shrug:

I think you hit it, ground start was developed for preventing glare. I just ASSUMED, there I go again, they'd be wink.

My training taught that PBX's ALWAYS have ground start trunks to avoid 'call- collision' or 'glare'. I should clarify this to say trunks in 2-way trunk groups. Unpublished number outbound only trunk groups could be Loop start, but not recommended. Individual lines could be loop start. And I was taught that trunks were ground start and lines were loop start. More recently, the expressions 'trunk group' and 'hunt group' seem to have started to be used interchangeably, probably do to lack of training. Ditto 'trunk' and 'line'.

All that said, I've been talking about copper and T1. Can PRI be configured ground start in the 5ESS? In the Definity? If not, then wink start is a much better choice that loop start. I'll bet the Definity tech won't be too enthusiastic about changing start type! I know I wouldn't be too enthusiastic about changing a Mitel. Although, I would do it because of the errors and my training. I'd also want to find out what IDIOT put in the trunks L/S, although murder is against the law. John C.

And while I'm writing this book, Bill jumps in and steals my thunder! Oh well, I'm going to leave it as is, maybe the 'whippersnappers' will learn something, or not.

I'm not too excited about the idea either. If collisions were occurring, I'd be receiving glare messages at the ROP, which I've even checked the overnight logs, when his PBX's scheduled diags are running. The calls are flying fine from both directions and neither he or I have received a single report of calls not completing. I guess if we were both receiving constant glare messages, versus just from his side, and only after the scheduled diags, I'd be more comfortable changing it. This also only started occuring from his side recently, and we've changed nothing at this side from as far back as I can remember. I'll have to research how long this has been setup for loop start. Maybe he's recently pushed down a software update or something. I'll discuss this with him Monday. I'm gonna go try to steal a jon boat somewhere and hope it doesn't start raining later! Thanks again John and Bill for sharing your valuable time to help me give a helpful, local tech a hand with this. Y'all have a great weekend!

I was thinking the same as Bill, that both switches were hunting in the same direction. If you could post his trunk setup (disp trunk X, disp ds1 01AXXXX, and disp sign X) and errors that he is getting, I could compare to some of my PRI's that work fine.

I would think that the PRI sends all signaling over the D channel, as to which channel is incoming, and, at that point, which channels are available for outgoing use.

brokeda,
Yes, the signaling and messaging is handled by the D, but for 2-way PRIs, the available B channel 'hunting' for outgoing call paths must occur in opposite order from each end of the PRI. One end must hunt available members in ascending order (lowest member/channel first, then upwards thru the channels), the other in decending order (high-to-low). This protects the 2-way call traffic from trying to access the same channels simotaniously. When these collisions do occur, one side of the PRI is assigned 'All Control' regarding call treatment for the call being placed from it's side of the PRI, and the other side sets for 'None control'. To avoid conflicts, the 'none control' side's calls yield the glared channels to the calls coming from the opposite 'All control' direction. There's also an odd/even glare control that applies to SS7 trunks.

Thanks for offering to compare, vw! We're set for ascending, and the G3R is set for decending. He just called me from his cellphone, letting me know that he'll be away from work this week, but he'll try to have another tech contact me. Check this: When I asked specifics of the error message, he said he couldn't remember the exact wording, but his documentation 'told him it was glare'. I'm starting to ponder if the errors he's receiving actually pertain to PRI 'SETUP' glare, which can occur when two originators attempt to send setup messages simultaneously, which is a separate glare condition than that with hunting available PRI members. The setup glare is resolved thru Q.921, and the CO side would need to use NTWK side layer 2 procedures, and the PBX would use USER side procedures. I'll keep you updated and post what I can receive regarding his exact error message/setup when and if the other tech contacts me. It will be alot easier when we can see exactly what he's receiving on his reports. I've been in G3R environments before installing DSX patch panels and other equipment, but I have no knowledge of Definity administration and reports. Thank you again vw and brokeda!

Any chance that the background tests are causing these glare errors? That would explain both why there are no problems during "normal" operation, yet errors during the diags. Could both observations be correct?

And yes, I strongly vote for wink/wink signalling.

Thanks dagwoodsystems. I'm still waiting to receive the exact wording of the glare error message being provided from his PBX. Once he provides this to me, we can hopefully cross-reference the message to identify the exact problem. I'm afraid to start guessing at this point, because I'm not very familiar with Definitys. I think the other tech whom was supposed to contact me has decided to hold off until the primary tech I normally work with returns next week.