CUCME hunting

[allenelson]

I need some help here on the express system with hunting. I need to be able to do parallel hunts without converting to SIP. Also, i cannot use the same extension on every phone due to complications of the system.

I need this feature in order for BLF to display properly.

7961's, 4 BLF speed dials on each phone, 2 CO lines to ring on each phone. When a user goes off hook, the BLF displays their status. When an incoming call from the PSTN arrives and is answered, the BLF does not work due to a different extension picking up the call. All phones have primary extensions on buttons 1 and 2, with an overlay of extension 350 (my fake parallel hunt group).

So the voice port would plar opx 350, which would ring every phone. If the voice port were to ring a hunt group, and all of the members were a part of the hunt group, the BLF would display properly due to their own extensions ringing.

Basically what am after is, can the system do the hunting via TCL script or something else. If it cannot, how complex would it be to run SIP/SCCP phones side by side. And a better question, is that possible? Thanks in advance. I appreciate any input on this matter.

[paolo bevilacqua · Accepted solution]

Yes, you can use a TCL/IVR service I wrote for "blast calling":

http://pbevila.fastmail.fm/public/bcast.tcl

Note: most applications can be achieved with shared DNs also, but due to the intricacies of that I understand the need for a such a service.

Hope this helps, please rate post if it does!

[allenelson]

I can't thank you enough. You've just turned my weekend around for me. :) Thanks again.

[paolo bevilacqua]

Please try it first, it's still experimental :)

[hfang]

FYI:

The Cisco Communication Manager Express version 4.3 will support hunt group call-blast on SCCP phones. (will be available with 12.5(2nd)BU Special Q1CY08)

[paolo bevilacqua]

Wooahh ... I have waited too long to write the script then.

Well at least it will have some six months of usefulness :)

[allenelson]

I am going to test it first thing tomorrow morning and will post the outcome. Hopefully all goes well.

[allenelson]

The script works great. I haven't hammered it yet so i'm not really sure if it is buggy or not. I did notice transfers were lagging a little behind, but that could have been due to the system needing a reload. Caller ID is displayed a little funky. I'll post the setup and the output below:

This is using forwards in order to force a day/night mode key.

application

service blast350 flash:bcast.tcl

param destinations 310,324,328,332,334

!

voice-port 0/1/0

connection plar opx 399

!

voice-port 0/1/1

connection plar opx 399

!

voice-port 0/1/2

connection plar opx 399

!

voice-port 0/1/3

connection plar opx 399

!

voice-port 0/2/0

connection plar opx 399

!

voice-port 0/2/1

connection plar opx 399

!

dial-peer voice 9 voip

service blast350

destination-pattern 350

session target ipv4:192.168.100.254

incoming called-number 350

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

ephone-dn 100 dual-line

number 399

label Attendant

call-forward all 350

When an incoming call comes in, it rings 399 which forwards to 350 to the hunt group. All of the phones ring on the extensions and light up the BLF keys. I tested it without the initial forwarding, and the caller id is still showing up the same:

Internal Call:

Forward (First Last) (Extension) For 350 by Unknown Number

Pots Line:

Forward (350) For 350 by Unknown Number

I am aware of the fact that clid might not be turned on for the POTS line, but its the forwarded by from that i was pinpointing.

All in all i'm not that worried about it. The system works the way we planned so it's something i can live with. If you would like to take a look at it though, i would greatly appreciate it, as i will be using this hunt script until 4.3 is stable at least. ;)

Thanks again!

[paolo bevilacqua]

You are welcome. Showing caller-id it's "delicate" in TCL/IVR . I'm not sure I can do better that the current result right now, as time permit will try a config with CFA like your, and see what comes out.

Please remember to rate useful posts rating the scrollbox below!

[allenelson]

No worries. I wouldn't want to waste any of your time with it. As far as I am concerned, the system is doing something it wasn't designed to do yet, so the customer will have to accept that. ;)

[allenelson]

anyway you might be able to throw in a final destination ?

[paolo bevilacqua]

I will put that on the wishlist :)

[allenelson]

well if there is a wish list... :)

the call completes and rings the group for about 3 rings. after that, it seems like 1 leg gets disconnected but not the initiator. so the phones stop ringing but the caller still hears their phone ringing.

also if for any reason a phone that is a part of a destination is not registered, the calls do not complete. the caller hears the phone ringing however it doesn't actually ring the hunt group.

thanks!

[paolo bevilacqua]

Issue 1 is like a bug, have to check. Are you calling from isdn or what ?

Issue 2 will require some trickery to ensure that ephones are registered and removed from destination if not.

[allenelson]

I was initiating the call from an IP phone with a voip dial peer. I want to say I also tested it from a POTS line but am not 100% sure. I can hook one up and test from that tomorrow if you'd like.

I tried to get around the call forward by adding the script to a hunt group but failed. It was supposed to look something like this:

ephone-hunt 1 sequential

list 350 (blast script)

timeout 30

final 6000 (VM)

It seemed the dial-peers were up and functional but would go directly to voicemail. I didn't save the debug information so I forget exactly why.