Not All PRIs Connect to Telcos…

Occasionally in voice world you end up configuring PRI connections to devices other than telco gateways. Sometimes these are PRIs between PBXs, fax servers, or other third-party vendor voice gateways for applications. These are typically connections internal to the organization versus a PRI to the outside world. Many times these require you to think just a little bit differently than your standard PRI turn-ups to get to that fabulous MULTIPLE_FRAME_ESTABLISHED goodness.

I’ll offer you a few things to look out for should you find yourself in this type of situation.  Keep in mind that no voice installation is ever *standard* so your mileage may vary.

1. T1 crossover cable. It’s a thing.  Often times the vendor bringing in their voice gateway will tell you things like “it’s just an RJ45 hand-off” or “just provide us a straight-through cable” but don’t believe the lies. More often than not in cases where you are going from your voice gateway to a vendor’s voice gateway, you will need a T1 crossover cable to achieve blinky green light success. You can order these via your favorite cable vendor or Google it to see the pin out and make one yourself, should you be that kind of handy.

2. ISDN switch-type. When you setup a PRI with a telco, they tell you what switch type and line encoding you will use, not much room for creativity.  With these back to back non-telco PRIs, I have found that vendors often have no idea what switch type you should be using and just start naming some that sound believable.  As with any PRI, you need to find an ISDN switch type that both sides can support and this could take some guessing if the vendor doesn’t know. For what it’s worth, I have had a lot of success with primary-5ess, but terrible luck with primary-ni. Of course the switch types and line coding must match between the devices.

3. “Reverse” dial-peers. Typically dial-peers follow a general standard of sending 4 or 5 digits to the CUCM and sending local, long distance, and international patterns out the serial interface of the PRI.  When passing calls between gateways in an internal situation, you need to think about what is going to be coming across to your voice gateway from this new PRI connection.  Many times it’s devices that will be trying to make outbound calls. That means they will be sending calls to your gateway and then your gateway will need to pass them to CUCM to send them out.*  You will also need to communicate to your third-party application configuration team (which may be you) the correct pre-pending for the vendor to use in order to match your dial-peers. For example, will the devices be dialing with a 9 or without?  Here’s an example of a dial-peer that would handle a local call by sending it to CUCM for further processing. Note, in the example I am requiring the vendor to pre-pend**:

dial-peer voice 10 voip
destination-pattern 9[2-9]………
modem passthrough nse codec g711ulaw
session target ipv4:10.10.10.10
dtmf-relay h245-alphanumeric
no vad
voice-class codec 100
voice-class h323 1

4. ISDN, someone needs to be in charge. This where the fairly obscure isdn protocol-emulate network command comes in.  The default in IOS, which you don’t see (because it’s the default), is isdn protocol-emulate user.  You may need to change this to get the PRI to a MULTIPLE_FRAME_ESTABLISHED state. To do so you add the emulate network command under the serial interface like so***:

interface Serial1/0/0:23
no ip address
no ip directed-broadcast
isdn switch-type primary-5ess
isdn protocol-emulate network
isdn incoming-voice modem
no cdp enable

Fortunately troubleshooting these types of connections are about as straight forward as other ISDN PRIs and debug isdn q931 is your best friend. Also, debug voip dialpeer all comes in super handy.

Published 4/30/2014

*this assumes the new vendor PRI and your current telco PRI are not terminating on the same box.  If they are you may need to enable h323 to h323 connections as well as deal with any clocking issues from having basically two providers housed in the same box.  There are specific caveats on making this type of scenario work, refer to Cisco’s documentation for your gateway.

**keep in mind that POTS dial peers consume, that is strip, explicitly matched digits and voip dial peers do not. So if, for example, you are sending a four digit extension across to the vendor’s gateway via a POTS dial peer with a destination pattern of 5000, you should add a forward-digits all to the dial peer to compensate for this behavior.

***bonus information on the isdn protocol-emulate network command