Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Legend w/PRI 3

Status
Not open for further replies.

thephonelady

Vendor
Feb 27, 2004
479
US
I have a customer with an r7.14 Legend.They have a PRI setup for Switch type-Legend-Ntwk and NetworkServ-ElectandNtwk
The provider is Verizon & all calls come in through a Definity and routed via UDP to 2 Legends. The problem is this- When the cust tries to install 2 016Mlx boards, he shuts down the system, installs the boards ,powers up, does a board renumber and everything comes up but the PRI.
There are no errors in the system & the CSU shows the ckt as being up but they can not make or receive any calls that would normally go across the PRI. The cust says that he has to call Verizon and they do "something" to the ckt & it comes bk up but in the meantime he has taken out the 016's thinking they are causing a prob. I tend to doubt this since the PRI went down on it's own the other day & the cust had to call Verizon & it took a few hours for it to come up. Any ideas??? It sounds to me like the D channel is not syncing up correctly after the power down & up.
Thanks in advance!!
 
I suspect the 100-D module.

I would be willing to bet the DS1 card is a 517M15.

That has a known problem when used with any type of 016 module.

If you were to do MAINTENANCE, SYSTEM, INVENTORY the card in question would probably show:

Hardware 0A, Firmware 91

That would indicate the BAD BOY 517M15.
 
Merlinman-
You were right about the hardware & firmware.
They do have the "BAD BOY" board
What kind of issues have you seen with this one & 016 MLX modules?
 
Merlinman-
They have an 016TRR in the system now. Would that cause a problem or is it just with the 016MLX modules??
 
It is my understanding, any 016 WHATEVER will do this.

The problem I had with the system I tried to turn up was that when we first fired it up, or when we did a reset, it would work just great for a minute or 2 or maybe even longer.

But then it all came to a screaching halt!

My Avaya Tier-3 contacts clued me in that the MIX of the "M" board and the 016 was the problem.

Bell Labs answer was, "DON'T DO THAT"!

So my answer is, get a later or newer board and you will be OK!

 
I'm having the same problem at a customer site. I tried upgrading the system from Magix R1 to R4 thinking maybe they fixed the problem in the newer release.... No luck. Anyone know of any other options, or is a complete hardware replacement with a newer board the only option?
 
Actually I think I may have a slightly different problem. I didn't realize that this post was talking about a legend. I have a magix with a DS1 board 617N15A.
HW Vintage - 0A
FW Vintage - 91
App Vintage - 23
Does anyone know if this board has any known issues in a system with 016's? The PRI works fine sometimes, but several times a day they get heavy static in the middle of a call then drop. verified that the D channel was not in my pool. Checked all connections back to the Smart Jack. Tried using an external CSU and using the boards integrated one. Thanks in advance for any help.
 
Merlinman-
When you had this problem did you have any type of errors in the system? My customer has an existing 016TRR and seems to not have any probs until he tries to install the 016MLX's
 
Just a thought, but could someone have programmed a "phantom" module in one of the slots?

franke
 
-jfilary -

Oa 91 is a BAD BOY, that is the Hardware, Firmware for a 517M15 100 D card that DOES NOT MIX with any 016 mods.

If you have a "M" card in a Magix, I'd bet the MAGIX is PLASTIC, not Metal.

-thephonelady-

"did you have any type of errors" - Didn't check errors, but when I did a TRACE in MONITOR, I only got about 1/2 of what I should have seen in the way of set up messages and stuff.

I don't recall all the details, but, BOTTOM LINE, IT DIDN'T WORK FOR BEANS !

-franke-

NO, that is not what is happening here.

If you have enough Lab Equipment, you can make it fail EVERY TIME!
 
Thanks Merlinman,
One more question for you then. I have an INA board laying around. I was thinking about throwing that in instead. When I do so will I have to remove all my PRI programming, then swap the boards, board renumber, then reprogram the INA for PRI? I'm thinking I will, but was kind of hoping I might get lucky.
 
I think the INA will look like any other DS1 to the system.

You may be able to get away with swapping it out and doing a board renumber, or you may not need to do a board renumber.

I usually recommend it though.

I really think you will not have to fiddle with the programming.
 
I have 2 Legend w PRI systems. I traced a disconnect problem on one of them to callerid strings longer than 15 characters causing the dchannel to drop and reset all the bchannels - disconnecting any calls in progress. I'll find out what vintage the T board is. Anyway you may want to test various length strings to see if your system's behaviour is related...

John
 
...a little trivia. This is the board where >15 character caller ID name strings are causing resets.

100d-U 517M15
Hardware Vintage: 0A
Firmware Vintage: 91
Application Vintage: 18

...timming incoming strings (I'm using asterisk which gives you a lot of latitude) makes the board workable. There is still a bit of unusual behaviour (extra messages) - but the span works.
 
...well, I'll assume you are unfamiliar with asterisk. It is an open source pbx that runs on linux (bsd, or osX). That can deployed with modest hardware costs.

As such, it offers a great deal of flexibility where it can integrate with traditional telephony & be a voip gateway, do attendant & voicemail and in this case allow you to manipulate cid data. Im using it at a school district with several buildings (non-contiguous properties) to integrate a variety of gear, Toshiba 424, system 75, several merlins and sip phones. Almost all of our internal calls are carried voip on our wan. This scheme is also allowing us to consolidate our out-of-district calling through a couple of telco PRIs. We have gotten rid of a whole bunch of OPXs and centrex trunks, (we are across exchanges and had to use 7 digit dialing) 2 of which get used for each internal call so this is saving us a lot and also given us a 4 digit dial plan. The cost has been a lot of work.

Soon I will write up a merlin to asterisk how-to.

Anyway, If I send a call into this merlin with the text part of the caller id as "Monroe - Woodbury Central School District" the dchannel would drop and all the bchannels are reset - any calls in progress are dropped. Trimming this string to "Monroe - Woodbu" solves this problem. I don't know if this card has had longer than 10 digits of cid number passed to it so don't know if there are similar restrictions. The other legend (that also is set up as a PRI) doesn't have this problem.

The trimming is done in the asterisk extensions.conf dialplan configuration file. It is in the form of
exten => _64XX,1,SetCIDName(${CALLERIDNAME:0:15})
This little problem set me back months since this was my first legend set up and I eventually gave up on PRI and made it a regular T.

The one remaining hurdle is illuminating the MWI over the PRI (I'm routing unanswered calls back out the PRI and asterisk is doing voicemail). I think I could hack it with MWI notification calls as asterisk -> Merlin -> fxs -> fxo. Here the fxs -> fxo would be a merlin 2500 extension run back into an analog trunk port on same merlin. So asterisk would dial that extension then pass it the mwi code & ext_#_to_illuminate - but it seems there should be a better way.

John
 
WOW, Yes, I know not of which the ASTERISK is.

Rots o' Ruck...

Sounds like you are way ahead of the old MerlinMan on this setup...........

However, I would wonder, would it simplify things to have the external addresses set up as a NUMBER combo rather than an ALPHA Combo?

Perhaps the end users need the ALPHA, but if they didn't it may make the things work better together.
 
Well, I can control the text portion of cid easy enough within my system - but external callers are able to send in larger strings (we have national PRIs from our local telco - I think these support 64 characters). It is my suspicion that this may be responsible for many people's troubles with the 517m15s. On the other hand, when I was getting my ass kicked by this for the first month I tried to get my system up I learned a lot about the various parameters... of the merlin (and pri on *).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top