Transfer to Hunt-pilot with queuing enabled

[goranpilat]

Hi!

I set the hunt pilot with native call queuing a couple days ago, and only today started receiving complaints about agents not being able to transfer to those hunt pilot numbers. Before enabling call queuing, it was possible to transfer calls to those hunt pilots.

I know this is not usual behaviour, as you are not trying to transfer a phone to the original caller, but rather MOH stream (greeting announcement of the hunt pilot), but is there a way to proceed and complete transfer here?

tnx a lot

Goran

[b.winter]

And what exactly are the issues? What exactly is happening?
"not being able to transfer" is no problem description.

[goranpilat]

So, A and B are IP phones. A calls B. B wants to transfer to hunt pilot with queuing enabled. Transfer isnt completed (B hears greeting announcement but after pressing complete transfer, A never hears this announcement and is kept on initial transfer MOH)

[goranpilat]

seems this is the answer:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuw57732

Conditions: User A want transfer a call to a huntpilot during the Announcement . This hunt pilot have queuing enabled. If all hunt pilot members a busy the user A is landing in the queue. User A presses the transfer button second time, he cannot transfer the call and is holding call into the queue of the hunt pilot during the Announcement.

Workaround: NA

Further Problem Description: That's the limitation in CuCM that the transfer during announcement is not possible. Transfer can be done only after the announcement completion. Limitation for Enhancement Request The limitation from CUCM design will not allow us to address this scenario and raising an enhancement defect will not help here.

[Maren Mahoney]

I wonder if the above can be avoided by using Direct Transfer (DirTrfr) softkey instead of a consultative transfer?

Maren

[goranpilat]

Just a couple of heads-up for anyone planning to use native call queuing, things I encountered as problems and how I solved it:

1)

-you call from the mobile into the queue, and you notice that after initial announcement and 15 - 30 additional seconds of ringing in the hunt list the call gets disconnected (mobile network plays something along:- user you are trying to reach cannot answer your call), although it should be ringing to hunt list members, please check:

"Connect Inbound Call before Playing Queuing Announcement" on the SIP profile used by the incoming SIP trunk

This will send 200OK to the provider at the beginning of the queuing and the rest of the call (playing, hunting, last resort) will be all considered connected, thus not causing provider to initiate timeout waiting the call to connect.

 2)

-the last resort of the call queuing (after no hunt list member answers the call or no member is logged in) was set to be a service on third party IVR/CC behind SIP trunk. After the call was forwarded to this service, it was noticed that DTMF is not working and that there is one-way audio with answering CC agent. Solution was to set the following service parameter:

Duplex Streaming Enabled = TRUE   (default=False)

So... lots of traps on this one... hope it helps 

BR