T1 to PRI 1

[Shermanchicken]

I have never done this befor but the customer has a Magix V.6 CKE processor in a Legend clamshell. The card for the current dss T1 is a 100D card. They are using a Paradyne CSU/DSU with the T1 to interface with the system. The new
service provider has brought in a PRI to be cutover to the Magix. I have tried to the programming changes for this using

a Doc ID: SOLN112384 Merlin Legend,Magix : Initial PRI configuration

I started from scratch building the PRI on the system and couldn't get it to work. Is there simpler format or document that can help me achieve this. The new service provider has also given me a test number to try before I get the numbers ported over. Thank you.

 

[TouchToneTommy]

At the top of this very forum, there is a link for FAQs. Click there, and look for "Legend/Magix Initial PRI Setup", which will lay it out for you, step by step.

Before you make ANY changes, back the system up to the PC card, so you can restore if it goes south (been there, done that)

If the new provider is using an IAD, you can bypass the CSU/DSU

Remember that the Magix is very limited on the protocols that it can accept, and the provider must match you.

 

[Shermanchicken]

Thanks for the response. I got what I needed and will move forward. Thanks.

 

[Merlin101]

If you went from T1 to PRI without deprogramming the T1 ( setting all channels to "unassigned") it can cause some problems even if the protocols are correct. One thing that can correct the situation is to change the switch type to Merlin Network, then back to whatever you are using for the connection. This will break down the b-channel group and clean it up. All you have to do then is rebuild the d-channel group from scratch and it may work for you...


One test for protocol... if you don't have a major that says "PRI D-CHANNEL INOPERATIVE", or "D-CHANNEL AUDIT TIMEOUT", your D-Channel is probably up, and you probably have a protocol issue.

Something else to check. Look under General trunk info, and DID, and make sure invalid destination isn't set to return busy. That will make sure the switch isn't rejecting the call because of incorrect DNS digits.