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 SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Merlin Legend R7 UDP extension 1100-1199 dialing using PRI

Status
Not open for further replies.

schaller

IS-IT--Management
Oct 28, 2010
19
0
0
US
We've been using 4-digit station extensions and T1's to network 3 Merlin Legends successfully for more than 11 years. We're currently transitioning from these T1's [Legend-Ntwk] to AT&T's IPFlex BVoIP [5ESS]. The problem I'm having is with the adjustments to the Uniform Dial Plan (UDP) to route non-local extension calls through PRI channels (specifically for extensions in the range:1100-1199).
If I program an appropriate route, absorbing and adding the necessary digits to make a switch-to-switch call on the PRI (or even across the POTS lines), the switch generates a warble tone, an MLX display phone indicates the programmed line selection for the pool, but the 100D lights stay off and AT&T reports that no digits are coming from the switch to their Cisco 2811.
If I try to absorb NO digits and pad the number of digits in the UDP route, then I can successfully present the programmed digits to AT&T's router, but the Legend's dialed digits (e.g., 1120) are prepended to the dial string they see presented from the switch. Obviously, the switch and router are trying to act on these extensions (1100-1199) as long distance calling attempts. I've tried clearing the Special Services patterns in PRI programming to prevent a possible conflict and playing with the ARS tables, but without any success. All other extension patterns in the UDP are working (1200-1499) and as I indicated it's been working in a Legend-Network for 11 years. Thanks to anyone who can help, but what am I missing?
 
Merlinman,

Yes. We had been using a PTP T1. Now we're trying to replace that circuit with the PRI from AT&T (IPFlex).
 
Whatever method telco is using, it has to provide a "point-to-point" equivalent of the DS1 hand off on the end connecting to the Legend, or it won't work. As far as the FLEX is concerned, I am not aware of a PTP offering on FLEX. WHY go that way, when straight DS1 is simpler and MORE reliable and robust and less hardware to break!

If the UDP works on the existing PTP with the 1100-1199 range of DID numbers it should work on the new PTP, otherwise that is a telco problem! How are the PTP DS1s configured, as CAS or PRI?

....JIM....
 
SYQUEST (Jim) - Thanks for the post...
The intent in moving from our existing T1s (PTP - DS1 Clear Channel interfaced to AdTran TSU equipment on each end of each T1 to split Voice and Data assigned B-Channels - NON-PRI) is to reduce our service costs, and take advantage of VoIP features w/o having to replace our existing telephone equipment. The new service (for IPFlex) is ISDN PRI. This means that 4 digit extension calls that previously crossed from switch to switch through the private T1 network, now must be "dialed" to a Virtual DID number and examined from the source switch in the Non-local Dial Plan and at the destination switch in the PRI Dial Plan routing table. This all seems to be working as expected except for the extension calls to 11xx numbers.
 
Does AT&T want to see a * or # in FRONT of the four digits you're sending? I ask this because other providers distinguish "normal" network calls from those that use "station to station dialing", i.e. a code that gets translated to a DID number for the other end.

If for example that a * needs to preface the remote side extension (simulate an internal call by translating the star code to the remote user's DID), you'll need to put a "11" in the Other Digits field in the pattern defined to route the call AND let the carrier know that you will be sending the "rotary equivalent" of star.

Why? Because despite being able to stick a "*" in the Other Digits field for a Non-Local UDP, the switch won't actually outpulse it.

Tim Alberstein
 
Tim, Thanks for the post...

I'm afraid I haven't clearly defined the problem I'm having, so I'll attempt to post some of the configuration w/examples of the results.

Under the old PTP T1, the Non-Local Dial Plan looked like this:
Code:
A         Range   Ptn Dgt
A    1) 1100-1299 01  04 

A    Pattern  1:

A    Pool   Absorb  Other Digits          FRL  Call type
A    1)894-     00  --------------------    0    BOTH
This worked without any problems between the two (2) switches.

I have changed the programming to work with the new ISDN PRI and the Telephone Numbers provided by AT&T to support inbound Dial Plan routing on the receiving switch. For Example, I have a station on switch 1 at extension number 1158. I have been given a telephone number of 840-1158 by AT&T. I created the following Dial Plan to support calling this extension from the remote switch:
Code:
A         Range   Ptn Dgt
A    2) 1158-1158 02  04

A    Pattern  2:

A    Pool   Absorb  Other Digits          FRL  Call type
A    1)890-     00  840-----------------    3    BOTH

If I dial extension 1158, I see the 100D card go active for a second. The MLX display phone indicates that a PRI line (channel) has been selected. But the activity light on the 100D card goes out and I get the warble tone from the Legend. Yet, I have a range of extensions in the 1400-1499 range which are station ports on the same remote switch as my 1158. The programming on the switch is identical to pattern 2 illustrated above. These calls work flawlessly.

I have tried using pool 70 (POTS lines) to make the connection to station 1158, but instead of dialing xxx-840-1158, the call is made to xxx-948-1158 (948 is the exchange for ALL of my lines in pool 70).

All indications point to the issue being a problem with dialing 11xx on the Legend switch. Is there some programming buried in the Legend that I don't know about?
 
I believe that there is a problem with UDP and a range starting with "11", and that networked Magixs automatically compensate for it, but sending UDP over the PSTN does not. Here's my story:

Customer with 2 sites, Point to Point, networked Magixs, everything works perfect. 3 digit extension numbers, Site A is 100-199, Site B is 200-299.

CLEC puts in Circuits in both sites, to split into Data, and 4 channels of E&M T1. Adds 100 DID's per site, sending last 3 digits on incoming. Set it up for 4-Digit dialing from site to site. Site A (Ext. 100-199) has DID's ending in 6100-6199, and Site B (Ext. 200-299) has DID's ending in 4200-4299.

So, we set up UDP to use the pool with the T1 channels; dialing from A to B it adds the 4, sending 4XXX, from B to A it adds the 6, sending 6XXX.

Dialing from A to B works fine. Dialing from B to A, have a problem with Extensions 110-119. Routing the calls trough a Loop Start line instead of the T1 allowed me to use a Digit Grabber to see what was sent, and I found that it was putting the Other Digit on the END of the string instead of the front.

In other words, you dial 110, instead of sending 6110, it sends 1106. For 111, instead of 6111, you get 1116. 112=1126, 113=1136, etc.

The CLEC was able to put a custom translation in their switch to compensate for it
 
TouchToneTommy, thanks. I thought I was going NUTS.

Unfortunately, instead of a range of 10 numbers, I'm dealing with the potential for 100 numbers and dialing problems from 2 remote switches. The CLEC hasn't suggested that there's anything they can do from their end (yet).

Does anybody know if this can be resolved on the Legend?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top