penelope

I have one system out of 12 that forwarded off-net calls got an AT&T recording of "your call did not go through..." It would work calling the forwarded extension internally, calling the auto-attendant, and calling reception and getting transfered to the extension but NOT on inbound DID calls over an ISDN. It didn't matter if the extension was forwarded to a local number and went out the COs or to a long-distance number and went out the ISDN.

All the usual suspects were checked out and MANY MANY hours of testing with Avaya and AT&T. I did find that when I created a dummy extension real quick to test with (and so it was bare bones with no coverage path) that it DID work without coverage to vmail. That led to another tangent about it being a problem with answer supervision, etc.

AT&T trace showed that their 4E was receiving two progress messages without ever receiving an answer message. Their error codes meant "message not compatible with call state." I had already brought that up to Avaya that it seemed that once the call was answered, either by AA or the console, and then transfered, it worked.

Avaya finally found a setting that corrected it. They changed the DS1 Interworking Message to ALERTing instead of PROGress.

My only question now is that every other system is set to PROGress. Yeah, why question it if it works? I just don't want it coming back to bite me because it screws up something else!

Penelope

oozenoz

Are all of your systems working out of the same telco switch? Are they all using the same ISDN protocol?

What a Toll or CO switch will accept is dependent on the message set selected (National ISDN is different from Nortel or AT&T custom). Likewise, within National ISDN especially the age of their switch can often limit you on the functionality you can access.

__________________
- calvin

PBXtech.info

 

penelope

No, the systems are all across the US. Avaya believes it is the type of switch on AT&T's side.

The circuit is a little different than any other circuit I have on any system. It was a T1 and we installed an ISDN PRI and ported the DIDs over to it. It is not a local T1, can still do DNIS on it. Just strange how AT&T built it.

oozenoz

I think you may have missed my point.

Think about it this way. Telco is providing E&M signalling on the trunks at one of your locations. How do you program the trunks on your side? But at another site, the telco is providing loop start signalling. How do program those?

The trouble you saw was due to a mismatch between the protocol versions running on the AT&T and local premise switches. They have to match in order to communicate. But it does not mean that all switches are going to speak the exact same language - nor do they have to.

__________________
- calvin

penelope

No, I understand your point. My point was that on AT&Ts side it is a 4E switch and when that was mentioned to Avaya that also gave them an idea of what the problem was.

__________________
Penelope

oozenoz

:D

Now more importantly, was I able to answer your question?

__________________
- calvin

PBXtech.info

 

martinyoung

I would look at that with a grain of salt (big one), it is common for vendors to claim the problem is the other guy's equipment. Just remember, it is all the same family. Avaya is spun off from Lucent which is spun off from AT&T. The network technology is the same as when everyone was one big happy family and Avaya's designs are the same as they were then.

Avaya found a work around that fixed your problem and that is good, but what I see is that in your case you had more competent people working on it at Avaya than at AT&T. Next time it could be the other way around.

__________________
Marty
Retired Avaya DSIC tech

oozenoz

Hear, hear! Unfortunately not only is it common for vendors, but also telcos, customers, engineers, etc. There's just too much fingerpointing in this industry.

I'd rather find the root cause than a scapegoat.

__________________
- calvin

penelope

That's what I think, Avaya found a work around. We could not get anywhere with AT&T except them saying the error code they were getting which meant the message was not compatible with the call state. It got escalated again and again thru Avaya until someone finally "fixed" it. Along the way, almost every Avaya tech I spoke with said it was a problem on AT&T side.

I'm glad it's working but not fully comfortable with them seeming to stumble across what was wrong and what the solution was.

__________________
Penelope

martinyoung

Just for safety's sake I would make a note that this is unique and different. Someday someone at AT&T might be doing some maintenance and notice their option in the CO and say to themselves "Self, this is odd and this option should not be set this way. I will fix it."

That will break it again.

__________________
Marty
Retired Avaya DSIC tech

martinyoung

Start of rant

Unfortunately, that usually doesn't happen until after much finger pointing and time is lost. This goes on until the victim (excuse me, the customer) gets mad and demands a resolution or everybody will be kicked out. When a joint vendor meet is finally arranged the problem suddenly disappears and no one did anything, but the problem is permanently fixed. Until next time.

I have spent most of the last forty years on the industry side of this business, now I work for one customer. I know how the industry works so my tolerance for finger pointing is very low. I have installed hundreds (thousands?) of T1s in my time and I know how they are supposed to work. If it doesn't work I can determine the source of the problem with a pretty fair amount of accuracy. I know enough that the vendor techs can't dazzle me with b*llsh*t. I don't call them until I know positively that it is not my issue.

End of rant

__________________
Marty
Retired Avaya DSIC tech

a237916

It's just a thought, but your problem may be with AT&T's built in Toll Fraud protection. We've had some vaguely similar issues recently with DTMF detection on some local DID numbers that are remote call forwarded to some AT&T 800 numbers, answer supervision is there and the initial portion of the call completes, but the digits are never delivered after the call is connected so any further forwarding or routing is not possible. It's a somewhat different issue, admittedly, but we've been seeing more and more issues stem from AT&T's toll-fraud protection measures, especially when we're using a '1-off' kind of setup. Our issue was resolved by having the DID numbers involved added to the 4E's 'toll fraud exclusion list,' which may be something to try.

Unfortunately, it's not necessarily easy to find an AT&T maintenance technician that's familiar with this list, but if you keep pushing, it's not impossible.

I know the feeling about 'permanent workarounds' being used instead of fixes...that's something that bothers me as well. In my experience it usually means you're just asking for more trouble later on down the road.

__________________
~Teri

oozenoz

Personally, I would not consider what Avaya did as a 'work around' - nor would I call it a 'fix.' I would say they modified the premise switch to conform to what the network was expecting.

When the network switch sends a SETUP message over the PRI, the valid (non-clearing) responses are CALL PROCEEDING, ALERTING, and CONNECT messages. (source: AT&T ISDN Primary Rate Interface Specification, 1995) If none of these are received before the network switch timers expire, the call will be torn down. From this point of view, AT&T was correct in their analysis of the issue because your premise switch was not providing what the network switch was expecting - within the proper timeframe. I have a suspicion that the premise switch was treating the redirection/forwarding as interworking, because PROGRESS is sent when interworking is involved, but not providing the CONNECT message until the far end of the redirect actually answered if it was going to provide answer supervision at all.

I hate to repeat myself, but all network switches are not created equal. The premise and network switches must be talking the same language in order for services to work properly. Blame who you will when they do not.

__________________
- calvin

penelope

Thank you for the responses. I understand what you're saying. I'm just saying that it bothers me that out of 12 systems, every one of them using AT&T circuits, one of them needs to be set up different.

To me that does open the door for things going wrong, as others have said. Someone on AT&T side notices a setting that is "wrong" and fixes it? We have a different problem with the circuit and Avaya says it's because that setting is not what it should be? Whatever.

The circuit that was there previously (and the function did work) could have gone through a different network switch on AT&T side, but I wouldn't know that. Maybe the circuit was built wrong on AT&T side, I don't know that either.

__________________
Penelope

oozenoz

I understand your confusion. But did you not say the other circuit was T1? Apples and oranges.

The difference between what is going on at this location and the others is most likely answer supervision, not the presence or absence of a PROGRESS message. Could something be different on this one set of trunks on the AT&T side? Certainly - mistakes happen when trunks are programmed, because they're done manually. But is it wrong? Only if it's not programmed according to what was ordered.

If you're really interested in getting to the bottom of this, whether it's to find out why this one set of trunks is "different" than the rest (which, by the way, I personally would like to know) or just to satisfy yourself that you're not sitting on a time bomb, contact your account rep and explain that you want to know the following information for each of your PRI ISDN circuits:

Type of Network Switch, including the software release;
Version of ISDN protocol ordered;
Version of ISDN protocol provisioned;
What the T303 timeouts are for each switch (the default is 4 seconds).

__________________
- calvin