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

Third Party server connections to Meridian PBXs

Status
Not open for further replies.

BikeTours

Technical User
Dec 28, 2004
63
CA
Third party server connections:

I work for a third party equipment provider and I have been looking at various Meridian configurations that would provide for the connection of third party equipment [an application server and its associated T1 telephony board] to Meridian PBX's. I am therefore not a Meridian expert.

With the help of useful suggestions from contributors to this website as well as other documentation I have been able to derive a number of solutions. All these solutions use TIE Trunk configurations, and they all pass the called number information required by the application server.

A legacy question I have about these configurations is would an alternative Trunk type other than a TIE connection be equally or more effective? Unfortunately I was not able to find an extensive amount of information on alternative T1 interface types; not much other than that a T1 optioned DID is available.

Question 1:
Other than as a TIE trunk how can T1 DTI/PRI interfaces on the Meridian switch be optioned?

Question 2:
do any of these trunk types offer benefits over a TIE trunk configuration when connecting to a third party server?



 
what does this 3rd party server do ?

T1/PRI is the transmission method ... that is as high as you can go in an open interface - Ofcourse there is Ethernet interface
Tie is anything tying 2 switches together (along this is loose terminology)
Q1. DID?
Q2. why do u need this?
 
If your server is not required to dial out of the M1 then yes you can use DID for the trunk type. Not sure what DID would gain you, but you could do it. Next question is will it be DTI or PRI???

TWM
 
What information does your application need from the PBX when the call is presented?
 
Unfortunately I don't have a detailed Nortel Meridian documentation set nor access to a PBX to trial different configuration settings so I have had to puzzle out how to connect my application server and its T1 telephony board to a Meridian family PBX. I have been able to piece together a solution from available documentation, primarily on-line information. I know have a good understanding of the call routing process in the Meridian PBXs however there is still some legacy questions I have not been able to address.


One has to do with trunk type.

As indicated above I provide a T1 interface to the PBX, and my application requires called number information from the PBX. My connection uses a TIE trunk interface. My understanding is that for a T1 interface you can use DID or TIE connections however, I haven't found enough information on the DID trunk type to determine whether it is a suitable setting. I am looking for further information on this DID trunk type, and whether perhaps it provides a superior connection to that of a TIE trunk.

PRI is ideal because called and calling number are provided in the ISDN message, however we have run into some compatibility issues with PRI.

DID services I associate with T1-robbed bit circuits using E&M signaling. In the typical implementation the PBX provides a wink back to the Central office and then the CO provides the DID number. I am kind of turning the standard connection on its head. I am looking for the PBX to provide DID, called number information, toward my server.

Questions:
I don't know whether a DID trunk in the Meridian world simply looks for DID numbers or whether it can also provide DID numbers?

My application server may need to dial back into the PBX but I don't know whether a DID trunk can support such outgoing calls? [an earlier response suggests it cannot].

If the DID trunk option works does it provide any advantages over a TIE trunk?



The other legacy issue I have is in regards to call routing. The information I have on the BARS/NARS translation tables that are largely used to route a call suggest you have to enter every NPA individually. This sounds tedious to me. I was surprised that the table doesn't allow every PSTN connection and one then just programs the exceptions... any comments?
 
there are scripts in existence that to do the NARS and BARS for you as opposed to sitting there and entering in all that tedious info, but no its not built in to the old ass software the Nortel uses. Nothing is "easy" on a legacy
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top