PRI Dial Plan Routing Problem

[phonesaz]

I have a PRI, Magix R3V4, sending 3 digits. The client's fax # ends in 6093. I build a pattern 6, see below. It still isn't working. I am 99% positive the CO is sending 3 digits, because I have been able to renumber other extensions (that didn't have zeros in them) to ring when their DID number is called. I have listed the programming below; any suggestions? I am on site and trying to get this fixed because they can't receive faxes - not very happy right now.

2 other things - could the fact that I have 2 PRI's have anything to do with it? They are programmed identically - except one is B Channel 1 and one is 2. The only other thing I noticed is that on entry 0 in the call by call table is says to delete 3 digits - since I have made so many changes trying to get this fax to work I don't know if that is a typo error on my part, or if I need to change it to 0. (they can't make LD calls right now, but they don't know if it is their problem or mine.)

HELP!! I really need to get out of here and promised I would fix this.

Here is the PRI printout:

----- Site: Direct. Captured: 03/01/08 -----
PRI INFORMATION



Slot 2 Switch: 5ESS

Slot 8 Switch: 5ESS

System: By line

BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
1 2 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
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827

BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
2 8 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
837
838
839
840
841
842
843
844
PRI INFORMATION


845
846
847
848
849
850
851
852
853
854
855
856
857
858
859

Network Selection Table

Entry Number: 0 1 2 3
Pattern to Match: 101**** 10***

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
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 Any service Any service
PRI INFORMATION


Expected Digits: 3 3 3 3
Pattern to Match:
Digits to Delete: 0 0 0 0
Digits to Add:

Entry Number: 4 5 6 7
NtwkServ: Any service Any service Any service Any service
Expected Digits: 3 3 3 3
Pattern to Match: 093
Digits to Delete: 0 0 3 0
Digits to Add: 193

Entry Number: 8 9 10 11
NtwkServ: Any service Any service
Expected Digits: 3 0 0 0
Pattern to Match:
Digits to Delete: 0 0 0 0
Digits to Add:

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



----------------------------------- ANNOTATION -----------------------------------

 

[tdaugirdas]

I would ask the Telco to send 4-digits - then modify your entry for Pattern 6 (6093) to fit accordingly. The leading zero may be the issue - but I'm not sure. I always request at least 4 digits. As for your entry of 3 - that is for international calls - so you are deleting the initial "011" in the dialing seqience. Different Telco's have different requirements for how they want you to dial International, long distance and local calls - so ask them what they are expecting you to dial for each call - and whether they want any of the leading digits deleted (like the 011 for international - or the leading 1 for national long distance - then make the appropriate changes.

Tom Daugirdas,
President
STCG, Inc.
stcg.com

 

[photon33]

In special service table 5 change type of number to international from national maybe it will fix LD.

In dial plan routing Entry 6 change digits to delete to 1 and digits to add to 1. Verify that dialing 193 does indeed ring your fax.

If it doesn't end up ringing where it should, it should be atleast ringing on your operator or unassigned DID extension,.

Is the call even making it to your switch?





------------------------------------------
Wash, rinse, repeat.

 

[photon33]

*correction*
In special service table 6 change type of number to international from national maybe it will fix LD.





------------------------------------------
Wash, rinse, repeat.

 

[phonesaz]

Yes - it hits the switch. And I was wondering if the 0 could be the problem, but I thought that was the whole point of mapping patterns? And 193 does, in fact, ring. And..what would be the difference between dropping 3/adding 3 and dropping 1 adding one? PLEASE keep you suggestions coming - I had to leave to go to a wedding shower on the condition that I am back there tomorrow at 7 - yeah for weekends

 

[phonesrus]

In routing by dial plan, the switch looks at the DNIS digits received and if a match is found routes the call accordingly. With a leading "0" a match is immediate, and may route without resolving the rest of the digits. It is possible that a "1" digit drop and insert "might" overcome this.
The carrier should also be able to use its facilities to do a digit modification table prior to outpulsing, that would fix your issue.

 

[photon33]

In dial plan routing entries 1 thru 5 are not being used so maybe delete entry 6 altogether and reprogram it to entry 1. Leave entry 0 as it is.

Where does 6093 ring and what information appears in the display?





------------------------------------------
Wash, rinse, repeat.

 

[phonesaz]

It rings at the main console and I haven't paid attention to what it says.

 

[phonesaz]

Update - I tried both the moving to pattern 1 and drop/delete 1 digit instead of 3. Neither made a difference. With regard to what happens at the recpt display when a fax (or any unmapped DID #) is called. Instead of the usual unknown DID message, you simply get a tiny little dark square (Maybe 1/16 of an inch small) in the upper left-hand corner of the display. Weird.

 

[phonesrus]

So, on this switch, if you call an unassigned DID # without a leading "0"(3 digit) you receive the dark square and if you call another unassigned DID # WITH the leading "0" do you get the same dark square??
I suspect you still have a protocol issue that is messing up the Progress messaging on the "D" channel.

Make sure that they have the "L1 Flag" set to Yes.
Confirm with them that they are indeed using "U-459" in the Lt-Def. Close only counts in Horseshoes and Hand grenades.

Otherwise have the carrier do a "D" channel trace, or drag out a protocol analyzer, if they have or know how to use one. This will tell what is happening on the call setup and progress messaging, and should indicate where the issue is.

 

[dagwoodsystems]

I have a customer with a similar setup (zero is the leading digit sent). I dialed in and printed a PRI INFO report so that I could compare it to what you posted. As far as I can tell, the only thing that's really missing is a "0" in the "Expected Digits" field for the entry in question.


Other points that you brought up:

In my experience, entry order DOES matter. For example, an entry whose match pattern is "777" needs to appear before the entry whose pattern is simply "7". Since you don't have a mixed length dialplan (with the same first digit), the table order isn't critical. Simply said, it is immaterial whether these translations are writ down in entry #6 or entry #1.

You can support two PRI circuits on a Magix...no problem. To accomplish this, the B-Channel group number for each circuit must be unique. So this business about "one is B Channel 1 and one is 2" isn't an issue. I would expect that 23 B-channels for the first circuit to be assigned to Group 1, and the second circuit's B-channels to be assigned to Group 2.

Lastly, the way your switch handles (or doesn't properly handle) outbound 011 calls is unrelated to the way the Digit Translation Table manipulates inbound calls. Any issues with International calls can be addressed later in this thread. In the meantime, please try sticking in a zero in the Expected Digits field as suggested above.

Tim Alberstein

http://www.dagwoodsystems.com

 

[merlinman]

Entry Order:

I really think the system looks at ALL ENTRIES before making a decision.

I think I recall trying to "MESS IT UP" by shuffling the order, only to find that it worked just fine.

 

[xjswx]

I had a similar issue with 2 faxes in a Magix that started with the leading digit as "0". I Tried the pattern, didn't work. So being the impaitient person I am, I told the "CO" to change the digits to matching unused extension numbers, renumbered the extensions to what the CO was sending, and the numbers dialed through just fine.

Example: fax numbers 057 and 058 - Renumber extensions to 740 and 741 - Instead of CO sending digits 057 and 058 for phone numbers (XXX) XXX-0057 and 0058, replace those digits with 740 = 057 and 741 = 058.

Anyways... that was the quick fix as it was 10:00 pm and the customer wanted to go home.

But it is my experience that the Magix does not like the leading digit to be "0". But I have also seen the patterns work just fine before.

 

[photon33]

As far as entry order goes, there are 5 unused entries before a used one. This IMHO is not the right way of doing it, this is the needle in the haystack way of doing it..

I have never had problems routing leading zero's using DPR, either. So I figured cleaning up the entries was a shot.

I do believe you can corrupt the DPR table rather easily as well (or so Tier 3 said back in the day). So your next step is to backup, factory reset the system, and reprogram the PRI and that one entry to test the corruption theory. Or have the provider drop the 1 in place of the 0 for you as posted earlier.





------------------------------------------
Wash, rinse, repeat.

 

[phonesaz]

I never could make the zero work - since it was only one number, I finally just had the CLEC forward it to an unused DID number - took the coward's way out I guess..

 

[photon33]

Sounds like you took the smart tech's way out if you ask me.

No reason to waste any more time with it, it works and it only cost 1 DID.





------------------------------------------
Wash, rinse, repeat.

 

[xjswx]

Yeah. There was no sense in "Reprogramming" the switch. Whoever did the initail programming was mostlikely new to Magix. It's just kind of a strange programming. So I left it like it is and it is working just fine now.

Thanks everyone for your help.

 

[merlinman]

My 2 cents:

I have had A vendor do a "PATCH" to their switch software, it was XO, as I recall.

But mostly, the Legend/Magix really doesn't like the leading ZERO.

I had to get a vendor (Whose name starts with Q) to send 4 digits instead of 3 to eliminate the leading ZERO.

http://home.comcast.net/~merlinman