Slip Errors on 3845 Voice Gateway

[robmas0871]

Hi,

i have some slip errors that i think can compromise fax transmission. This can be caused by clocking configuration but i want to ask the correct clocking configuratin for a multi VWIC Gateway.

I have a 3845 Router with 3 VWIC2-2MFT-T1/E1 cards (6 controllers) :

- 2 controllers connected to PSTN E1

- 3 controllers connected via QSIG to Nortel

I did this configuration:

- 1 E1 controller connected to PSTN PRI (clock external) and i supply the command "clock source line primary" manually on the router.

- 1 E1 controller connected to PSTN PRI (clock internal)

- 1 QSIG controller connected to Nortel (clock internal)

- 1 QSIG controller connected to Nortel (clock internal)

- 1 QSIG controller connected to Nortel (clock internal)

I did this configuration thinking that first controller acquires clock from Telco line and all others take correct clocking from first controller (so they have internal clock). Slips errors continue appearing.

Is my idea correct ? I must do another command on gateway ?

Thank you.

[Michael Whaley]

I had a similar issue a few years back on some Q.Sig circuits to an Avaya PBX and I had forgot to add the "network-clock-participate" and "network-clock-select" commands. Use these commands for your external clock sources (usually carrier provided circuits). After this is setup you can use the "show network-clocks" command to verify.

On your Q.Sig controllers check to see what the clock is set to on your Nortel PBX side. If the Nortel PBX is providing clock on that side, then use "clock source line" on the controller. If the Nortel PBX is set for line clock then set your clock to "clock source internal" on the controller.

Hopefully this helps. Let us know how you come out.

[robmas0871]

Hi,

thank you for reply: what about 2nd PRI controller ? It must have Internal clock too ?

[Michael Whaley]

You can set the priority order for the external clock under the "network-clock-select" command. For example, here is my config for my external clocks:

router#sh run | i clock

network-clock-participate slot 1
network-clock-participate wic 0
network-clock-participate wic 1
network-clock-participate wic 2
network-clock-participate wic 3
network-clock-select 1 T1 0/0/1
network-clock-select 2 T1 0/2/0
network-clock-select 3 T1 0/2/1
network-clock-select 4 T1 0/3/0
network-clock-select 5 T1 0/3/1

router#sh network-clocks
  Network Clock Configuration
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type

     1          T1 0/0/1        GOOD            T1
     2          T1 0/2/0        GOOD            T1
     3          T1 0/2/1        GOOD            T1
     4          T1 0/3/0        GOOD            T1
     5          T1 0/3/1        GOOD            T1
    11          Backplane       GOOD            PLL

  Current Primary Clock Source
  ---------------------------
  Priority      Clock Source    Clock State     Clock Type

     1          T1 0/0/1        GOOD            T1

In this example, I have 5 network clocks configured coming from the PSTN PRIs and the current primary clock source is on T1 0/0/1.

Does this help?

[Steven Holl]

You need to configure the PBX's to receive clock for this scenario.  Because the DSPs are on a clock, and the provider has to send you clock, you need to transmit this clock to the PBX circuits otherwise you get slips when the PBX circuit hands frames to the DSP.

network-clock-participate wic 0

network-clock-participate wic 1

network-clock-participate wic 2

network-clock-participate wic 3

network-clock-select 1 T1

network-clock-select 2 T1

controller t1

clock source line

controller t1

clock source line

controller t1

clock source internal

controller t1

clock source internal

controller t1

clock source internal

Then, make sure the PBX side is set to receive clock from the gateway.

[robmas0871]

Hi,

thanks to all of you. Fax quality now is fine and there are no more slip errors. This was very important for my organization that receives many faxes from customers: with your help we avoid a roolback migration to Nortel!!!!