According to Cisco documentation the cause code breaks down as follows:

The first two digits (82) mean that the message is coming from the local telco switch. The last two digits (AC) means: The remote equipment cannot provide the channel that the user requests, due to an unknown reason. This problem is usually temporary.

From the cisco document at: http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

From the debug you posted it looks like the calling number is 507316 and the called number was 008. The number 008 is not really a number that the PSTN would be able to route so I'm not sure why someone would have dialed that number. Is the debug from an outbound call or an inbound call?

On your Dial-peers:

dial-peer voice 9 pots

description ** Outgoing **

destination-pattern 9T

port 0/3/0:15

dial-peer voice 900 pots

description ** Incoming **

incoming called-number .

direct-inward-dial

port 0/3/0:15

Add the following:

dial-peer voice 9 pots

description ** Outgoing **

destination-pattern 9T

progress_ind setup enable 3
progress_ind alert enable 8
progress_ind connect enable 8
progress_ind disconnect enable 8

port 0/3/0:15

dial-peer voice 900 pots

description ** Incoming **

incoming called-number .

direct-inward-dial
translation-profile incoming PSTN-INCOMING

progress_ind setup enable 3
progress_ind alert enable 8
progress_ind connect enable 8
progress_ind disconnect enable 8

port 0/3/0:15

voice translation-rule 1
rule 1 /\(.+\)/ /9\1/ type unknown unknown
rule 2 /\(.+\)/ /9\1/ type national national
rule 3 /\(.+\)/ /90\1/ type international international
!

voice translation-profile PSTN-INCOMING
translate calling 1

Hope this help?

Many Thanks,

Nico

Hi

You are getting an error Cause i = 0x82AC - Requested circuit/channel not available?, this implies Circuit Channel DS0 is

not available for the Call to get matured thru POTS

Check the Channel Status, channels should be "Idle" to make new calls. and If the Channel is "out of service" or "blocked"

then the call will not mature. this command will help you to identify the status.

ROUTER-I#show isdn servic

PRI Channel Statistics:

ISDN Se6/0:15 SC, Channel [1-31]

  Configured Isdn Interface (dsl) 0

   Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart 5=Maint_Pend)

    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    State   :  2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

   Service State (0=Inservice 1=Maint 2=Outofservice 8=MaintPend 9=OOSPend)

    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    State   :  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

   Channel blocked? (0=No 1=Yes)

    Channel :  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

               0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Also check for E1 Status, using the following command. E1 status should be up.

ROUTER-I#show controllers e1 6/0

E1 6/0 is up.

  Applique type is Channelized E1 - balanced

  Description:

  No alarms detected.

  alarm-trigger is not set

  Version info of slot 6:  HW: 1032, PLD Rev: 7

  Framer Version: 0x9

Manufacture Cookie Info:

EEPROM Type 0x0001, EEPROM Version 0x01, Board ID 0x03,

Board Hardware Version 4.8, Item Number 73-3996-05,

Board Revision A1, Serial Number JAE13062GGI,

PLD/ISP Version ,  Manufacture Date 4-Feb-2009.

  Framing is NO-CRC4, Line Code is HDB3, Clock Source is Line.

  Data in current interval (672 seconds elapsed):

     0 Line Code Violations, 0 Path Code Violations

     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins

     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Either E1 or Channel status should be the cause for the failure. 

Also configure the Dial-peer with the Port Number Alone, as below

dial-peer voice 9 pots

description ** Outgoing **

destination-pattern 9T

port 0/3/0

dial-peer voice 900 pots

description ** Incoming **

incoming called-number .

direct-inward-dial

port 0/3/0

Kindly rate if this helps. Thankz

I finally tracked the SRST/ISDN issue down. The only issue I could find was:

        Cause i = 0x82AC - Requested circuit/channel not available

There was a backup VPN with BGP routing the Voice Subnet over the VPN allowing for heart beats to pass, so the phones did not fall into proper SRST.

I created a access list on VPN Tunnel interfaces blocking the Voice VLAN, then the Phones registered with the SRST Voice Gateway.

Inbound and outbound calls then worked.

Thank you for your time.

Nico