Debugging PRI

Integrating 3rd party device in Gateway scenario

There may be times when you will have to integrate a 3rd party device with a Com.X unit via it's PRI port. This may happen in a gateway scenario:

e.g.

(3rd party PBX) --> PRI --> (Com.X Gateway) --> SIP --> (Telco)

Note that PRI P-2 (Telkom interface) will be playing the role of TE and that PRI P-1 (Alcatel interface) will be playing

the role of NT.

Note that a Cat5 cable from PRI P-1 to the Alcatel will need to cross over:

Tx pins (NT 4,5) will need to be mapped to Rx pins (NT 1,2)

You can verify that the cabling is correct by looping back the cable from PRI P-1 to PRI P-2, then using an outbound

route to dial out through P-1 to P-2 (you can route everything to music on hold in your inbound routes to catch incoming).

If you reach music on hold you will know that the cable works correctly.

Validate that your SIP trunk is working correctly, independently of the gateway.
Validate that your PRI trunk is working correctly, independently of the gateway.
Connect up the SIP and PRI trunks to the Com.X gateway
Create separate 'test' outbound routes to test each trunk separately.

(Note that the match patterns above will need to be set back to '.' once both outbound routes are confirmed as working)

Using a local extension say extension '2000' dial out to a cell phone through the SIP trunk and Telco: e.g. dial 2+<cell phone number>
Using extension 2000 dial out to the PBX: e.g. dial the orignal DID of the PBX.
Now that both routes have been verified as working, route them to each other using flexpaths. See 'Ports' in "Setup Routing" section below.
From the legacy PBX dial normally to your cell phone through the gateway and to the SIP trunk
From your cell phone dial the inbound DID that was originally assigned to the legacy PBX.
Done.

Confirm that layer 1 is working correctly. Layer 1 is responsible for HDB3 encoding and signal strength.
- Check Dahdi span status (Monitoring->Telephony->Dahdi Span Status)

Check Dahdi statistics (Monitoring->Telephony->Dahdi Span Status). The most important diagnostic information here are
the Clock source slips, skips and and frame errors.

If you have command-line access. e.g. (if your comma iTA device has IP address 192.168.103.2)
> comma-console 192.168.103.2
> t1e1 status

Due to the large number of frame errors above there may be noise induced on the cable connecting the two devices. A high 'cabledb' reading may also indicate
a faulty cable that needs to be replaced.

Asterisk CLI: Conduct a test call while watching the Asterisk CLI trace. You will be able to glean important diagnostic information on how your call is being routed.
1. > asterisk -vvvvvr
2. Then conduct the call.

In the call flow above we have identified that the PRI route is failing because of a "hangup request, cause 27", resulting in circuit-busy. This indicates a problem with layer 1
of the PRI connection.
Get the span number of the PRI port you want to monitor:
> asterisk -rx "pri show spans"
In the cli type command:
> pri set debug intense span 2
PRI Span: 2 < Message Type: DISCONNECT (69)
PRI Span: 2 < [08 02 80 9b]
PRI Span: 2 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
PRI Span: 2 < Ext: 1 Cause: Destination out of order (27), class = Normal Event (1) ]
PRI Span: 2 -- Got ACK for N(S)=27 to (but not including) N(S)=27

Google Sites

Report abuse