Problem with long distance with T1

[MissAvaya]

I have a customer with two systems: Legend R7 (site A) and Magix R1.0 (site B). They are side to side in the same room. They are connected with 2 100DCD card in UDP. It work perfectly.
I installed a new PRI for outside calls in the Legend cabinet and it work good also.
My problem is: when I dialed a long distance call with site B, it's doen't work.
The way they normally dial LD is press 9 then 1 and then dial the 10 digit # they are trying to call. They would hear a tone that would prompt them to enter a 4-digit code and then it would allow the call to go out.
From site A, it's working perfectly. They are able to do LD.
From site B, they are able to place local call but when I dialed longue distance, I hear the tone but when I try to enter the 4-digit code, the DTMF that I sent doesn't break the tone. With the CO with did some test and we can hear the tone like toc, toc, toc... They explain to me that, at this point the system should send the DTMF but because it's a PRI it should be sent diffently. Before the modification (installing PRI) it was working properly on regular lines. Maybe someone could help me on this? (by the way, sorry for my French accent )

 

[dagwoodsystems]

Given that you are being prompted with the Calling Code tones, it sounds like your Magix programming is correct. But it may be helpful to look at a thing or two...just in case.

Print out the Magix ARS tables. I would expect to see Table 25 (Default Toll) show the pool to be the Legend/Magix connecting PRI pool. The Absorb field should be "00", the Other Digits field be "9" and FRL at "3".

You're description of the "toc, toc, toc" makes me think that the outpulsing of the digits are rotary, not DTMF. But that only makes sense if we're talking about analog lines. Are there any analog circuits on the Legend side, or is both local and long distance handled by the new PRI? If so, we may need to adjust the Outmode Signalling for those trunks, which is done using the menu: LineTrunks -> TT/LS Disc -> Outmode -> Touch-Tone -> (dial trunk number) -> Enter

Finally, is there a way to temporarily remove the Call Accounting codes? Let's remove our first barrier, and see if a long-distance telephone call "goes through" without these codes. The results of this test will tell us where the problem may lay.

Ne faites pas des excuses pour l'accent français! Vous recevrez beaucoup d'aide parce que vous êtes une femelle avec un accent français!

 

[MissAvaya]

Thanks Dagwoodsystems for heling me.
I ask last friday the CO to remove the barrier code to let the users making long distance call. They are able to do it with no barrier code.

>>> There is the ARS for site B:

ARS IS: ACTIVE ACCESS CODE: 9
A TABLE 25: Default Toll Output Table
A Pool Absorb Other Digits FRL Call type Start Pattern
A 1)70-- 00 9------------------- 3 BOTH --:-- A
A 2)890- 00 -------------------- 3 BOTH --:-- A
A 3)---- -- -------------------- - ----- --:-- A
A 4)---- -- -------------------- - ----- --:-- A
A 5)---- -- -------------------- - ----- --:-- A
A 6)---- -- -------------------- - ----- --:-- A

A Pool Absorb Other Digits FRL Call type Start Pattern
A 1)70-- 00 -------------------- 3 BOTH --:-- B
A 2)890- 00 -------------------- 3 BOTH --:-- B
A 3)---- -- -------------------- - ----- --:-- B
A 4)---- -- -------------------- - ----- --:-- B
A 5)---- -- -------------------- - ----- --:-- B
A 6)---- -- -------------------- - ----- --:-- B
A AUTOMATIC ROUTE SELECTION

A TABLE 26: Default Local Output Table
A Pool Absorb Other Digits FRL Call type Start Pattern
A 1)70-- 00 9------------------- 2 BOTH --:-- A
A 2)890- 00 -------------------- 2 BOTH --:-- A
A 3)---- -- -------------------- - ----- --:-- A
A 4)---- -- -------------------- - ----- --:-- A
A 5)---- -- -------------------- - ----- --:-- A
A 6)---- -- -------------------- - ----- --:-- A

A Pool Absorb Other Digits FRL Call type Start Pattern
A 1)70-- 00 -------------------- 2 BOTH --:-- B
A 2)890- 00 -------------------- 2 BOTH --:-- B
A 3)---- -- -------------------- - ----- --:-- B
A 4)---- -- -------------------- - ----- --:-- B
A 5)---- -- -------------------- - ----- --:-- B
A 6)---- -- -------------------- - ----- --:-- B
A AUTOMATIC ROUTE SELECTION


>>>>> But I thing my problem is on the PRI-tie between this two sites.
PRI report of site A:

A PRI INFORMATION
A Slot 15 Switch: Legend-PBX
A Slot 17 Switch: DMS-100

A System: By line
A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 1 17 5143331234 CallbyCall By Dial Plan

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

A Line PhoneNumber NumberToSend
A 857 5143331234 5143331234
A 858 5143331234 5143331234
A 859 5143331234 5143331234
A 860 5143331234 5143331234
A 861 5143331234 5143331234
A 862 5143331234 5143331234
A 863 5143331234 5143331234
A 864 5143331234 5143331234
A 865 5143331234 5143331234
A 866 5143331234 5143331234
A 867 5143331234 5143331234
A 868 5143331234 5143331234
A 869 5143331234 5143331234
A 870 5143331234 5143331234
A 871 5143331234 5143331234
A 872 5143331234 5143331234
A 873 5143331234 5143331234
A 874 5143331234 5143331234
A 875 5143331234 5143331234
A 876 5143331234 5143331234
A 877 5143331234 5143331234
A 878 5143331234 5143331234
A 879 5143331234 5143331234

A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 80 15 ElecTandNtwk Route Directly to UDP

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

A Line PhoneNumber NumberToSend
A 833
A 834
A 835
A 836
A 837
A 838
A 839
A 840
A 841
A 842
A 843
A 844
A 845
A 846
A 847
A 848
A 849
A 850
A 851
A 852
A 853
A 854
A 855

A Network Selection Table

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

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: 0 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 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
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:
A DeleteDigits: 0 0 0 0 0

A Dial Plan Routing Table

A Entry Number: 0 1 2 3
A NtwkServ: 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: 4 5 6 7
A NtwkServ:
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:
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:
A Expected Digits: 0 0 0 0
A Pattern to Match:
A Digits to Delete: 0 0 0 0
A Digits to Add:

>>>>> PRI report of site B:

A PRI INFORMATION
A Slot 4 Switch: MERLIN-Ntwk

A System: By line

A BchnlGrp #: Slot: TestTelNum: NtwkServ: Incoming Routing:
A 80 4 ElecTandNtwk Route Directly to UDP

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 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 824
A 825
A 826
A 827

A Network Selection Table

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

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 OP OP OP/P OP none none none
A Type of Number: I I I N N N N N
A Digits to Delete: 0 0 0 0 0 0 0 0

A Call-By-Call Service Table

A Entry Number: 0 1 2 3 4
A Call Type: BOTH BOTH BOTH BOTH BOTH
A NtwkServ:
A PRI INFORMATION


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:
A DeleteDigits: 0 0 0 0 0

A Dial Plan Routing Table

A Entry Number: 0 1 2 3
A NtwkServ:
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: 4 5 6 7
A NtwkServ:
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:
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:
A Expected Digits: 0 0 0 0
A Pattern to Match:
A Digits to Delete: 0 0 0 0
A Digits to Add:

>>>>> I presume that I have a mistake somewhere in the PRI programmation but... Only long distance call made by site B and passing on the PRI-tie are not working and also, only when have barrier code from the CO because otherwisw it's working. Do you have others suggestions?

 

[HarrisD1200]

It sounds like possibly an answer supervision problem. IE, the Tie lines are not allowing the code dialed by the B location to reach the LD carrier. Fairly easy to test with the LD carrier. Or, possibly, the phones in B are not creating DTMF correctly for the LD barrier codes.

 

[dagwoodsystems]

Once the call completes, neither the Legend or Magix "have anything to say" about what further digits are outpulsed by the station. So I don't see the digits being supressed.

However, I think there's value in exploring what the LD carrier hears when these digits are outpulsed. It would be interesting to see how she has her Switch Identifiers set (shown in Print > Trunk Group > General). The audio in a networked link can get weird if these are set incorrectly.

A stronger possibility might be that the network timing parameters are screwy. Site A should have the LD carrier's T1 as the Primary with the clock source set to Loop, and Site B should have the tandem T1 port shown as the Primary with the clock source set to Local. That way, the Magix derives it timing from the Legend which, in turn gets it from the carrier.

Since everything works EXCEPT for the call accounting codes, I'm thinking that the audio is somehow getting skewed along the way.

 

[HarrisD1200]

Should be fairly easy to test for skewed digits, dial into an AA and dial a specific extension. If you get what is expected, then most likely it's not skewed digits. If not, then it most likely is.

 

[dagwoodsystems]

Very smart and straightforward. I thought about that while I was in the shower this morning, but you posted first and definately deserve all the credit.

Did you understand the thinking here, MissAvaya?

HarrisD1200 wants you to call an Automated Attendant from the Magix side. If you can successfully navigate your way through it, then DTMF is being outpulsed correctly (and it's the carrier that has a problem).

If the Automated Attendant you call does not repond as you expect, then please try one or two of my suggestions. My preference would be for you to look at the Syncronization parameters first.

 

[MissAvaya]

I already try to dial into an outside voice mail from side B passing throught the PRI-tie and going out from the PRI and it's working perfectly. So, it's look like the DTMF works correctly. But the CO guys they told me that when I reached the CO tone, their database open and receive the code and try to match that code to let the longue distance done. With analog lines it's correct because the analog sent DTMF but with digital, It's not receive in the same way because the D-Channel (or the B-channel) sent the information differently. They told me about Progress message and about the Speach Path like into Nortel products??? But I don't know what I have to ajust to sent the code in "data"??? Is it because my Call-by-Call service in PRI-tie it's not writen No service or Any service?

Call-By-Call Service Table

A Entry Number: 0 1 2 3 4
A Call Type: BOTH BOTH BOTH BOTH BOTH
A NtwkServ:
A PRI INFORMATION


Thank you to help me... it's very appreciated

 

[dagwoodsystems]

There is nothing wrong with your Call-By-Call Service Table, so please don't give it another thought.

The D-Channel is responsible for telling the carrier when and what B-Channel that the voice call is being set up on, and whether it is a National or International call. It is also reponsible for sending the various progress conditions of the call (ringing, answer/off-hook, release, etc).

When an outbound call hits the ISDN switch (apparently a Nortel), the system sends back an ISDN progress message on the D-Channel, but does not fully connect the path until their touch tone detectors "hear" a valid code. By default, the audio path is cut-through in the backward direction (toward our PBX), but not in the forward direction, until the terminating gateway receives a connect message. Therefore, there is no voice path to transmit DTMF tones or speech towards the terminating switch. Believe it or not, this is a common problem when VoIP circuits meet traditional telco TDM circuits at the NNI. Anyway, I suspect that this PRI is being provided by some kind of CLEC, who needs to study this problem on THEIR end a bit further.

Aside from my egghead understanding and explanation of the problem, what further proof does the carrier need? The Automated Attendant test that HarrisD1200 suggested worked fine, thus proving that you are outpulsing DTMF on the voice channel correctly. Also, calls seem to complete without incident when the calling code restrictions (and thus the calling code gatekeeper) are removed. The fact that calling codes are OK when dialing from the Legend and NOT from the Magix is immaterial. To me, it simply means that "their version" of AT&T Custom signalling is incomplete, or that their gatekeeper software has a problem (and if it's a Cisco, then I know EXACTLY what the problem is).

In simplest words: you have proven your point, and the problem belongs to the carrier.

Il est évident que vous soyez une femme futée, et vous devez insister sur le fait que le problème n'est pas à vous. Le fournisseur du service doit réparer ce problème complexe. Bonne chance!

 

[phonesrus]

Find out what the protocol setting in the LT_DEF is in the carriers Nortel DMS-100/250. It should be U-459, anything else will not work properly, and may be the cause of your problems.

 

[MissAvaya]

dagwoodsystems what are you thinking about that? With all our discussion I realize something. I thing the solution is there:

A Slot # 0: CKE5 CPU
Serial Number Not Available
A Slot # 1: 412 LS-TDL
A Serial Number 01DR01004973
A Slot # 2: 016 MLX-U
A Serial Number Not Available
A Slot # 3: 016 MLX-U
A Serial Number Not Available
A Slot # 4: 100D/CSU/DSU-U
A Serial Number 01DR01385313
A Slot # 5: 008 MLX-U
A Serial Number Not Available
A Slot # 6: 016 MLX-U
A Serial Number Not Available
A Slot # 7: Not Used
A Serial Number Not Available
A Slot # 8: Not Used
A Serial Number Not Available
A Slot # 9: Not Used
A Serial Number Not Available

What all those cards have in commun? No one have touch tone receivers! So I think I will install a 016TRR card to have 4 touch tone receivers and I will perform a test... I think (or I hope) it's going to work.

Qu'en penses-tu? Et surtout un gros merci pour ton aide.

I will let you know the result.

 

[dagwoodsystems]

You are welcome. What do I think about it? I think that the addition of touchtone receivers will NOT solve the problem. I understand why you think the way that you do, but I believe it's misguided. The inability to correctly decipher the digits rests squarely on the shoulders of the carrier, not on your Legend.

Comprenez-vous? L'incapacité de déchiffrer les chiffres est le défaut du fournisseur de service, parce que l'appel téléphonique échoue APRÈS QU'IL ait sorti l' Legend. Vous avez prouvé ceci deux fois avec les essais suggérés!

However, I have given additional thought to the outbound Call-By-Call Service table as being a trouble source. There COULD some alteration of the D-Channel data by passing through the Legend, but I will have to experiment a bit before I can say for sure. Some modification of this data is done in order to preserve the Calling Name, Extension Number and such when making inside calls. I will have to study this a little more...

If you live in lovely Southern California, I would be happy to assist on-site. Otherwise, please post your results here and we will continue to work towards an answer.

 

[MissAvaya]

Thanks dagwoodsystems. You were right. I still have the problem with a 016TTR installed in the cabinet.

So... I live in lovely Quebec that why my French accent . But it's sure if you can continue to help me it's going to be very appreciate.

I spoke to the CO and they are not able to modify something otherwise other customer will have other kind of problems. And somewhere I have difficulty to said the problem it's from their side because only when the call past by the PRI-tie (not passing by the CO facilities) we have the problem to dial the code.
site A -> long distance number -> PRI (outisde lines) -> tone from the CO -> barrier code -> OK
site B -> long distance number -> PRI-TIE -> PRI (outisde lines) -> tone from the CO -> barrier code -> not-OK
The PRI (outside lines) are the same. The only difference that I can see is PRI-tie.
I saw that the DS1 board from side B is not the same as site A because is offer me CSU activate or desactivate and the DSU activate or desactivate. Is it possible to effect something?
Ou as-tu appris a parler (ou écrire) si bien le Français?
Thanks again to help me.

 

[dagwoodsystems]

Change your Call-By-Call Service table on the MAGIX to look like this:

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


You can do this by choosing CBC SERVICE (under PRI options) > PATTERNS. At the "ENTER LIST (0-9) AND ENTRY (0-9):" prompt, type 00 (zero zero) and Enter. Then:

ENTRY 0, ENTER PATTERN: 0 (then F9 to choose Next)
ENTRY 1, ENTER PATTERN: 1 (then Next again)
ENTRY 2, ENTER PATTERN: 2
ENTRY 3, ENTER PATTERN: 3
:
:
ENTRY 9, ENTER PATTERN: 9 (then press F10 to choose Enter)

Now choose NETWORK SERVICE. At the "ENTER LIST NUMBER (0-9):" prompt, type 0 (zero) and Enter. Now choose MISC (F4) > NO SERVICE (F2) > ENTER > EXIT > EXIT.

Please write back and let me know what the results are.

 

[MissAvaya]

Dagwoodsystems, be sure that I will let you know the result. I look forward to try that.

Plusieurs Merci encore une fois pour votre aide.

 

[MissAvaya]

I did the modification and it still not working. I try different things like modify the DMS-100 for DMS-250,... but no difference. Do you have more suggestions?

 

[dagwoodsystems]

Let's try one last thing. Add the digits of a valid account code in the "Other Digits" field of the ARS table.

When a call leaves the Magix, it will go over a specific trunk and then outpulse whatever is in the "Other Digits" field. You may have to add pauses in order to get this to work, and I don't know if that's even possible.

But even if you can get the extra digits to outpulse at the appropriate time, it still may not work. I'm not sure if it makes any difference whether the end user or the switch sends the code.

I'd love to know what the results are, provided that you are willing to try this last thing.

 

[dagwoodsystems]

Also, a very bright collegue has suggested that you set Tie Line and Non Tie Line Remote Access to UNRESTRICTED in both PBXs.

I'm not entirely sure what the logic is behind this change, but this individual has an awful lot of years as a Avaya Tier III support.

It looks like Quebec is enjoying -1°C weather right now. Nothing like an Easter with light snow flurries (I always say)! Your fingers are probably frozen and you can't type right now, but please write back when you can.

Venez visiter la Californie pour les vacances de Pâques. Quel temps fait-il? La température était 24°C dans ma ville aujourd'hui!

 

[MissAvaya]

I have to ask the CO to activate the peek each time that I would like to do a test and they are not able to remove taht peek before 24 hrs later. Each time I activate that peek, I create the problem and there is something like 30 persons which are not able to do longue distance call so I ask the CO to activate that peek Friday at 5:00pm and I perform the test on Saturday and I ask to desactivate the peek on Monday morning (more than 24 hours later).
So I will test your new suggestions tomorrow (on Saturday) and I will let you know.
Also, ici au Québec nous avons reçu un joli manteau tout blanc durant la journée d'hier. Nous avons toujours un peu de neige autour des jours de Pâques, normalement c'est la dernière neige avant novembre prochain donc on l'apprécie beaucoup si on peut dire Parcontre je suis un peu gênée de vous dire qu'ici la température était en moyenne de 0°C.
A bientôt Dagwoodsystems and I will let you know the result.

 

[dagwoodsystems]

Oh where, oh where is Miss Avaya these days? This problem was given a lot of love and time, so I'm hoping that it's been resolved. Kindly post back.