PRI Gateway on RLS 6.0

[khaman]

I have installed a PRI Gateway on a RLS 6.0 system and cannot get the d-channels to establish. This is what the customer is using it for. They have an Avaya system installed and when a user from the Nortel systems calls in over the H323 trunks, then sent over to the Avaya system via SIP trunks there is no DTMF. So we are putting the PRI Gateway in place to route H323 calls over this before sending them out the SIP trunks to the Avaya sytem. One of the sales reps said we could put the PRI Gateway in place, break the 8 T1s into two groups, one outgoing and one incoming.

I have built the Loops, d-channels, rdb and trunk members. When I bring up the 2 d-channels, hoping they will sink together, they never do. I don't get any wierd error mesages when bringing up the loops its just that the d-channels won't establish. The face plate on the PRI Gateway is all green, wish that meant its working. My Loops are MSBY and the d-channels are in RLS.

Is it possible to use the PRI Gateway in this fashion? I know that a T1 cable is pins 1 to 4 and 2 to 5, does this need to be different if I am direct connecting one d-channel to the other? Of the 8 T1s in the gateway it is cabled out; 1 to 5, 2 to 6 (this is where the d-channels are), 3 to 7 and 4 to 8.

 

[chris13]

sorry for not remembering the menus, but you need to check:

Protocols need to match: Q.931/ETSI ,DSS1/EuroISDN, Q.SIG or DPNSS ?

Using a direct connection, one side needs to be configured for network-mode, the other side for user-mode (CO vs. PBX). This configuration option defines which side is supposed to initiate certain events and how the other side is supposed to react. Necessary to bring up the D-Channels for propper signalling.

Indicators for clocking problems like frame-slips/-drops?
ISDN/PRIs run synchronously (as opposed to the VoIP world). Most often a PBX/Gateway system tries to derieve the cklocking for all the synchronous processing (clock master) from a designated PRI port. Usually the master clocking should be provided by a port which is connected to a 'real' CO.

 

[khaman]

I have d-channel 15 programmed as the NET side and d-channel 17 programmed as the USR side. Everything else as far as the d-channel and the trunk members is programmed the same. When I bring up the loops with the d-channels, it looks like the d-channels cannot see the other d-channel and stay in the RLS state. I am wondering if I need maybe a dumb switch to connect my d-channels to, thinking that maybe a regular T1 cable connected back to back on Slots 2 and 6 isn't correct.