The Adtran community holiday season is starting next week! The holiday period will span from December 21, 2024 to January 6, 2025. During this time, responses to feedback form submissions may be delayed. If you are encountering product issues, you can reach out to Adtran support at any time.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable

Bookend PRI across Site to Site

Jump to solution

I have read the document about book ending, but need to look at a configuration example to better understand the steps in delivering a PRI across ethernet from site A to site B. Can anyone provide a sample config?

PRItoMainPBX-->916e-->NV1544-->Fiber-->NV1335-->916e-->PRIto2ndPBX

Thanks,

Blake

0 Kudos
1 Solution

Accepted Solutions
jayh
Honored Contributor
Honored Contributor

Re: Bookend PRI across Site to Site

Jump to solution

If the PBXs have a proprietary signaling method unique to the vendor that isn't either ISDN PRI or CAS robbed-bit then you're unlikely to be able to accomplish this with TA900 hardware.  You'll need some form of pseudowire TDM-over-Ethernet.  Adtran has this in their TA5000 chassis but that is several orders of magnitude overkill for this project.  If there's a spare SFP in the switches, RADUSA makes a nifty device that will do it.  I'm not sure of the rules here for referencing other vendors' hardware but Google is your friend.  Keep in mind that the pseudowire will consume about 2 Mbps of the link 24/7 regardless of whether there is traffic on it.  If there's limited bandwidth this could be an issue.

View solution in original post

0 Kudos
4 Replies
jayh
Honored Contributor
Honored Contributor

Re: Bookend PRI across Site to Site

Jump to solution

Exact configuration depends on your scenario, but this is very easily done.  Variables include whether either or both 916e units will also be routing calls to the PSTN via a SIP provider, or if this is a strict tie-trunk scenario.  If also routing to PSTN, do that first and then build the tie-trunk.

First figure out your dial plan.  If all of the extensions at each PBX have the same leading digit and length it is a lot easier.  For example Site A has extensions 2000-2999 and site B has extensions 5000-5999, then you would configure as follows:

At site A

  • Create an ISDN trunk facing the PBX
  • Create a trunk group that accepts 2XXX and include the ISDN trunk
  • Create a SIP trunk pointing to the IP address of site B
  • Create a trunk group that accepts 5XXX and include the SIP trunk

Site B is the reciprocal of site A.

Considerations and gotchas:

  • Timing sources - if either PBX is also connected to a PRI from a carrier you'll want to have the PBX clock from that carrier and then have the TA912 clock from the PBX.
  • PBX programming - PBXs treat PRIs as trunks and you probably want seamless dialing as if extensions.  On the PBX create a trunk facing the Adtran with a trunk access code of the leading digit of the other side ("5" at site A).  Set the PBX to not return a dial tone after the trunk code and also to not strip it.  This is a bit unconventional, for example a typical PBX uses a trunk code of "9", strips the 9, and returns a second dial tone for a PSTN trunk.  Clueful PBX vendors will understand if you describe it as a tie trunk, less clueful ones will need some hand-holding.
  • If either site will use the other for calls out to the PSTN, then you'll need to pass those through to the other side.  Modify your dial plan to allow the pattern on the trunk in that direction as well as the extensions.  Be careful with 9-1-1 in this scenario.  You can manipulate the ANI for emergency calls and populate the 9-1-1 database with the correct location info.  Alternatively a local POTS line on the Adtran FXO port can be used for 9-1-1 at the remote site.
Anonymous
Not applicable

Re: Bookend PRI across Site to Site

Jump to solution

Thanks for the information. I tried the above but came to the realization that the circuits in the customer's PBX do not act as PRI circuits with D-channels on the connection. The customer has a Nortel PBX with the T1 connection spanning from the main site NT7B74GA-93 card to the remote location  NT7B74GA-93. Since they are not programmed as TDM-PRI slots, the above did not work. Is there a way for the 916e series to transport the T1 across ethernet like a 408e would without the use of the PRI and ISDN trunks?

Nortel Card-->T1-->916e-->NV1544-->fiber-->NV1335-->916e-->916e-->T1-->Nortel Card

If useful, the customer is currently using Transition SSDTF-100 media converters to transport the T1 from site to site. We are having to remove these due to fiber restrictions and to delivery lines on FXS ports for analog service.

Thanks,

Blake 

jayh
Honored Contributor
Honored Contributor

Re: Bookend PRI across Site to Site

Jump to solution

If the PBXs have a proprietary signaling method unique to the vendor that isn't either ISDN PRI or CAS robbed-bit then you're unlikely to be able to accomplish this with TA900 hardware.  You'll need some form of pseudowire TDM-over-Ethernet.  Adtran has this in their TA5000 chassis but that is several orders of magnitude overkill for this project.  If there's a spare SFP in the switches, RADUSA makes a nifty device that will do it.  I'm not sure of the rules here for referencing other vendors' hardware but Google is your friend.  Keep in mind that the pseudowire will consume about 2 Mbps of the link 24/7 regardless of whether there is traffic on it.  If there's limited bandwidth this could be an issue.

0 Kudos
Anonymous
Not applicable

Re: Bookend PRI across Site to Site

Jump to solution

B124jr,

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

David