I can't find anything wrong, unless there is something else in the system stopping it.

application

service csqueue flash:app-b-acd-2.1.2.2.tcl

param aa-hunt1 1200

param queue-manager-debugs 1

param number-of-hunt-grps 1

param queue-len 15

!

service load csaa

!

service csaa flash:app-b-acd-aa-2.1.2.2.tcl

param handoff-string csaa

paramspace english index 1

param max-time-vm-retry 2

paramspace english language en

param aa-pilot 1299

param drop-through-prompt _bacd_welcome.au

param second-greeting-time 60

param welcome-prompt _bacd_welcome.au

paramspace english location flash:

param call-retry-timer 15

param voice-mail 1800

param max-time-call-retry 700

param service-name csqueue

paramspace english prefix en

param number-of-hunt-grps 1

param drop-through-option 1

!

dial-peer voice 2299 voip

description **Cust Svc Call Queue**

service csaa

destination-pattern 1299

session target ipv4:10.1.10.1

incoming called-number 1299

dtmf-relay h245-alphanumeric

codec g711ulaw

ephone-hunt 10 peer

pilot 1200

list 1201, 1202

final 1801

timeout 12, 12

statistics collect

auto logout 1

description ** Cust Svc Hunt Group**

Only other thing I can think of is the session target IP address.

Is this the correct IP?

The IP to send this to is the interface service-enginge

service-module ip default-gateway

I would assume the IP is fine, my other voip dialpeers work fine.

service module config:

interface Integrated-Service-Engine0/0

description cue is initialized with default IMAP group

ip unnumbered Loopback0

ip nat inside

ip virtual-reassembly

service-module ip address 10.1.10.1 255.255.255.252

service-module ip default-gateway 10.1.10.2

I've also taken out the 'session protocol sipv2' and cleaned up the DTMF settings to match other's configs

I have had the same issue. Try this

sho call app voi sum

Check to see if the script has loaded or is still in the state of "loading...". My shows that it is in the loading state. As shown below:

SERVICES (standalone applications):

name type description

queuename (BLANK SPACE) builtin:app_b_acd_script.tcl Loading...

.....

aaname (BLANK SPACE) builtin:app_b_acd_script.tcl Loading...

.....

Also try this

debug voice app script

Don't for get to turn on "term mon" if you are on vty. Look for the following message:

000214: Jul 3 19:10:55.942: %CALL_CONTROL-6-APP_NOT_FOUND: Application aa in dial-peer XXXX not found. Handing callid 74 to the alternate app .

where XXXX is your dial-peer number.

As I can see this is because the script has not loaded. So TCL sends it to alternate app which you can see by typing

sho call app ses

The call must still be connected and you will see:

Session ID XX

App: Default

Type: Service

Url: builtin:Session_Service.C

Where XX is a number.

Does anyone know why a script would not load?

Is it the IOS version? Current IOS is:

c2800nm-advipservicesk9-mz.124-15.T1.bin

With this many bytes of memory 509952K/14336K

Can't believe it would be memory.

I have tried this with both flash b-acd and builtin as well with the same results.

Based on this it seems that you are sending it to CUE (10.1.10.1) it should be point to your loopback interface (10.1.10.2?)

dial-peer voice 2299 voip

description **Cust Svc Call Queue**

service csaa

destination-pattern 1299

session target ipv4:10.1.10.1

incoming called-number 1299

dtmf-relay h245-alphanumeric

codec g711ulaw

interface Integrated-Service-Engine0/0

description cue is initialized with default IMAP group

ip unnumbered Loopback0

ip nat inside

ip virtual-reassembly

service-module ip address 10.1.10.1 255.255.255.252

service-module ip default-gateway 10.1.10.2

Thanks engage and rimon, your suggestions have solved my issue. I was using the IP of the CUE system instead of the CME system. I set the IP to 10.1.1.1, which is the IP of CME on the UC520, and it worked like a charm. I assume the 10.1.10.2 address would work too, but Cisco TAC had me use 10.1.1.1