MAGIX PRI Incoming Problem

[dholmes45431]

Have a Legend R7 on a PRI with rock steady performance for years, about half of the system is comprised of Magix modules in clam shells, including the the processor as a result of office growth.

Moving to a new building and using the opportunity to upgrade to Magix carriers, 100 DCD, 016, more MLX-16 etc. Have setup a Magix carrier with a seprate new processor, 100DCD and MLX-16 to initially configure the new system. Testing involves just moving the incoming PRI from the Legend/external-CSU to directly to the Magix 100DCD.

Have used the print out from the orginial system to program the new system exactly, even matched both printouts. Magix of course has the internal CSU activated.

Outgoing local and long distance calls works as expected. Incoming to the office number (via cell phone), gets a fast busy and "network busy" message on my cell phone. Return the PRI to the Legend and the old system (which still supports the office works perfectly). Sounds like a dial plan table problem in the new system, but everything (all the PRI settings including the dial plan table, extensions, etc.) are exactly as in the Legend. Is there something unique to the Magix that I'm missing??

BTW, have also done a Frigid start and used the FAQ checklist to program with no change to incoming calls status on the new system...

Thanks!

 

[merlinman]

I would ask that you post both PRI Print Outs, even though you are certain there are no differences.

No, there is nothing unique to the Magix on this scenario that I know of.

My first guess would be that it is something in your DIAL PLAN ROUTING.

 

[phonesrus]

When you say "Incoming to the office(via cell phone)" fails on Magix, but not on Legend. I am making an assumption that since you say new building, you have a new pipe from the carrier to the new facility, correct? Same or different CO switches? Could be a carrier issue too, since you receive a "network busy" on the cell phone.
As MM suggested, revisit or post your PRI info for comparison.
Ask the carrier to check both trunk groups and compare if possible, also were the numbers ported if a CO change??

 

[dholmes45431]

phonesrus...I literally have both new and old(operational) systems side by side, just moving the operational PRI between systems to checkout the new Magix configuration BEFORE moving it to the new building...therefore the problem is isolated to the new Magix configuration

MM...I agree symptoms appear to be a incoming routing problem. Attached are the two PRI printouts, the Operational Legend first then the new Magix. In both printouts, the phonenumber and number to send columns have the same numbers listed, but have been masked for security purposes

Thanks

_________________________________________________________
Legend PRI (Operational)

Slot 5 Switch: DMS-100

System: By line

BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
1 5 CallbyCall By Dial Plan

Channel ID: 1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 16 17 18 19 20
21 22 23

Line PhoneNumber NumberToSend
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831

Network Selection Table

Entry Number: 0 1 2 3
Pattern to Match:

Special Service Table

Entry Number: 0 1 2 3 4 5 6 7
Pattern to Match: 011 010 01 00 0 1
Operator: none none none none none none none none
Type of Number: I I I N N N N N
Digits to Delete: 3 0 0 0 0 0 0 0

Call-By-Call Service Table

Entry Number: 0 1 2 3 4
Pattern 0: 0
Pattern 1: 1
PRI INFORMATION


Pattern 2: 2
Pattern 3: 3
Pattern 4: 4
Pattern 5: 5
Pattern 6: 6
Pattern 7: 7
Pattern 8: 8
Pattern 9: 9
Call Type: BOTH BOTH BOTH BOTH BOTH
NtwkServ: No Service
DeleteDigits: 0 0 0 0 0

Entry Number: 5 6 7 8 9
Call Type: BOTH BOTH BOTH BOTH BOTH
NtwkServ:
DeleteDigits: 0 0 0 0 0

Dial Plan Routing Table

Entry Number: 0 1 2 3
NtwkServ: Any service Any service No Service No Service
Expected Digits: 0 0 0 0
Pattern to Match: 9106499 9106
Digits to Delete: 7 4 0 0
Digits to Add: 666

Entry Number: 4 5 6 7
NtwkServ: No Service No Service No Service No Service
Expected Digits: 0 0 0 0
Pattern to Match:
Digits to Delete: 0 0 0 0
Digits to Add:

Entry Number: 8 9 10 11
NtwkServ: No Service No Service No Service No Service
Expected Digits: 0 0 0 0
Pattern to Match:
Digits to Delete: 0 0 0 0
Digits to Add:

Entry Number: 12 13 14 15
NtwkServ: No Service No Service No Service No Service
Expected Digits: 0 0 0 0
Pattern to Match:
Digits to Delete: 0 0 0 0
Digits to Add:
_______________________________________________

Magix PRI

A PRI INFORMATION



A Slot 1 Switch: DMS-100

A System: By line

A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 1 1 CallbyCall By Dial Plan

A Channel ID: 23 22 21 20 19 18 17 16 15 14
A 13 12 11 10 9 8 7 6 5 4
A 3 2 1

A Line PhoneNumber NumberToSend
A 801
A 802
A 803
A 804
A 805
A 806
A 807
A 808
A 809
A 810
A 811
A 812
A 813
A 814
A 815
A 816
A 817
A 818
A 819
A 820
A 821
A 822
A 823

A Network Selection Table

A Entry Number: 0 1 2 3
A Pattern to Match:

A Special Service Table

A Entry Number: 0 1 2 3 4 5 6 7
A Pattern to Match: 011 010 01 00 0 1
A Operator: none none none none none none none none
A Type of Number: I I I N N N N N
A Digits to Delete: 3 0 0 0 0 0 0 0

A Call-By-Call Service Table

A Entry Number: 0 1 2 3 4
A Pattern 0: 0
A Pattern 1: 1
A PRI INFORMATION


A Pattern 2: 2
A Pattern 3: 3
A Pattern 4: 4
A Pattern 5: 5
A Pattern 6: 6
A Pattern 7: 7
A Pattern 8: 8
A Pattern 9: 9
A Call Type: BOTH BOTH BOTH BOTH BOTH
A NtwkServ: No Service No Service No Service No Service No Service
A DeleteDigits: 0 0 0 0 0

A Entry Number: 5 6 7 8 9
A Call Type: BOTH BOTH BOTH BOTH BOTH
A NtwkServ: No Service No Service No Service No Service No Service
A DeleteDigits: 0 0 0 0 0

A Dial Plan Routing Table

A Entry Number: 0 1 2 3
A NtwkServ: Any service Any service No Service No Service
A Expected Digits: 7 0 0 0
A Pattern to Match: 9106499 9106
A Digits to Delete: 7 4 0 0
A Digits to Add: 666 0

A Entry Number: 4 5 6 7
A NtwkServ: No Service No Service No Service No Service
A Expected Digits: 0 0 0 0
A Pattern to Match:
A Digits to Delete: 0 0 0 0
A Digits to Add:

A Entry Number: 8 9 10 11
A NtwkServ: No Service No Service No Service No Service
A Expected Digits: 0 0 0 0
A Pattern to Match:
A Digits to Delete: 0 0 0 0
A Digits to Add:

A Entry Number: 12 13 14 15
A NtwkServ: No Service No Service No Service No Service
A Expected Digits: 0 0 0 0
A Pattern to Match:
A Digits to Delete: 0 0 0 0
A Digits to Add:

 

[dizzyphil]

D,

Your Channel ID's are reversed in the Magix programming. Reprogram them to start with 1 instead of 23. It may be causing a 'Glare'.

Dizzy

 

[dholmes45431]

Dizzy..yes I thought of this before and had tried it last week, just finished doing it again to reprogram channel IDs from 1 to 23, and retried, still not inbound, outbound works fine??? Caller ID says Network Busy and fast busy tone. Thanks for the idea

 

[ken1713]

Dial plan routing table pattern 0 should have expected digits 7.

 

[phonesrus]

Leave your "B" group as you have it on the Magix, carriers generally ascend 1> therefore you should decend 23< to prevent "glare".
The only outstanding thing that I see is under the call-by-call service table you have calltype: (set to) "both" but NtwkServ: (set to) "none", this should be set to "any" which will allow 56 and 64k calls. The Legends sometimes had a bit of tolerance in this area, but the Magix series do not. Cellphone calls can be a bit wierd at times, but set the pattern "0" to any and see what happens. Your "dial plan routing" is ok as I see it, the issue appears to be the "cbc", and I would also leave the expected digits under the "dpr" table 0 to "7" if 7 digits is what you are receiving.

 

[merlinman]

As far as "GLARE", my theory has always been that since the 2 End Points (The Legend/Magix and the CO) NEGOTIATE which channell to use, GLARE shouldn't be an issue.

But that's not helping/hurting this issue......

 

[phonesrus]

MM,
True on the negotating, but I have always found that there is less "D" channel congestion with the low road/high road approach. If you have one door with people trying to enter and exit at the same time you stand a much higher chance of collisions than with one door to enter and another door to exit. you ought to watch the messaging fly with a very busy 94B+1D NFAS circuit.

 

[merlinman]

phonesrus - Interesting.

Now another thougt on the original problem.

When you get this FAST BUSY, does your amber light come on in the DS1 Module?

Also, are Extension numbers in the right range on the new switch?

 

[dholmes45431]

MM,

No amber light on incoming

Yes, in the test setup I have a few extension numbers with phones that are in the correct range as verified by internal call between them. Internal calls will light the amber LED

 

[memphisribs]

In dial plan routing change all entries for service to any. Entry 0 should be default, use entries 1-15 for insert and delete. Your current entry #1 is looking for 4 digits,(expected digits should = 4) these should match the last 4 not the first 4 digits from the CO. Also you would need digits to add if you delete 4. It appears your not sure how many digits the CO is sending. Your current entry #0 is looking for 7 digits from the CO, make sure extension 666 is a valid extension in the switch. Once you are sure of the number of digits from the CO you can correct your entries. Suggested entry would be:
Entry number = 0
NtwkServ = Any Service
Expected digits = 4 ( if CO is sending 4 )
Pattern to match = 6 ( if last 4 starts with 6xxx)
Digit to delete = 0(to route to did extensions in 6xxx range)
Digits to add =0
Entry number = 1
NtwkServ = Any Service
Expected Digit = 4 ( if CO is sending 4 )
Pattern to match = 6499 (if this is last 4 of listed number)
Digits to delete = 4
Digits to Add = 666 ( if this is valid extention number)



40 years in the business and counting.

 

[dholmes45431]

Ok, back to basics

CO sending 7 digits, Legend (first print out) working in this configuration for years.

All CO digits sent are of this format: 91064XX

Internal extensions are in the 400's (except for remote access ext 666)

Extension 400, 666, 401, 402, 403, etc are valid with handsets in the Magix test configuration

Deleted all the table configurations, except table 0 for each of the test cases below

Dialing from a cell phone to local 9106400, NONE of the following routing table 0 configurations work (fast busy)...is this a bad 100DCD???

Note: with the PRI disconnected, incoming cell phone call hears a busy signal indicating that the Magix is responsible for the fast busy)

Test Cases each tested individually as table 0...

Entry number = 0
NtwkServ = Any Service
Expected digits = 0
Pattern to match = 9106
Digit to delete = 4
Digits to add =0

Entry number = 0
NtwkServ = Any Service
Expected digits = 7
Pattern to match = 9106
Digit to delete = 4
Digits to add =0

Entry number = 0
NtwkServ = Any Service
Expected digits = 0
Pattern to match = 9106400
Digit to delete = 7
Digits to add =400

Entry number = 0
NtwkServ = Any Service
Expected digits = 7
Pattern to match = 9106400
Digit to delete = 7
Digits to add =400

Entry number = 0
NtwkServ = Any Service
Expected digits = 0
Pattern to match = 9106400
Digit to delete = 7
Digits to add =405

Entry number = 0
NtwkServ = Any Service
Expected digits = 7
Pattern to match = 9106400
Digit to delete = 7
Digits to add =405

 

[dholmes45431]

The plot thickens...

Tried calling another Magix extension by dialing out through the ARS (dial 9+full 7 digits DID of another extension on the system)
Got the typical telco 3-tone error signal then the automated message that reads the number back and states that the number is not in service

Works as expected with operational Legend system

...any ideas??

 

[phonesrus]

Your Magix switch is failing the "D" channel setup message with a reject message. Recheck and compare your PRI setup and configuration and it might be a good idea to open a ticket with your carrier and request a technican to run a "D" channel trace on inbound and outbound calls with you to see if you can isolate a cause code related to the failed calls. If you can call out and back in to your switch and it fails, that leads me to believe it is a protocol issue on the Magix.

 

[TravelingTom]

Are you just moving the pri from the legend to the magix? Are you eliminating the external csu when you plug it into the magix and activating the internal csu? Sometimes it is the basic connections that can give us problems.

 

[MYKELB]

From the beginning I also wondered about the csu question?
If that's ok I think ypu should follow phonesrus' advice and have the carrier place a trap on the circuit to let you know what's up.

 

[SYQUEST]

What about disabling the CSU in the 100DCD?

Next, try using the 100D Module from the Legend and put it in the Magix or try the reverse in the Legend and see what happens.

Is this a GOOD case for using the MONITOR feature???

....JIM....

 

[phonesrus]

Actually you can use 2 CSU's in series with no ill effects. CSU's are basically clock and framing recovery devices, with the ability (in some cases) to add gain or apply padding (loss)to the T-1 signal. I have used them to increase the available loop length post smart-jack in large campus (read long loop) applications. I had one application on a Legend with an IDF at 1400 cable feet with a -24db signal. I placed a CSU with 3db of gain on the incoming signal and output at 0db and was able to travel an additional 800 C/F to the equipment CSU, arriving at -14db for a total loop of 2200 C/F on a PRI.

I am really leaning to a Setup/protocol mismatch on the Magix.

I had a C-beyond Cut Friday on a Definity G-3, I told them 5ESS + AT&T Custom, we got the "D" up, but could not bring up the "B's". They weren't listening to me, they messed with it for about 2 1/2 hours telling me it was on my side. Finally, they got a higher level of support on their side (read-someone that had an idea of what they were doing) and got the "B's" up. I asked what they did. They said " We applied a special protocol that we use on Legend/Magix systems"??? I said "Custom" they replied "yes", I said "I told you that 3 hours ago"!!