Bacd call queue time lenght.

Unanswered Question
Mar 2nd, 2009

Hi,

Have setup a call queue for a broadcast hunt group, however the calls only sit in queue for 1 calling cycle (30 or so total seconds) to the hunt group before being forwarded to voicemail. We followed the "Configuring a Basic Call Center Application on the UC500" Application note from this site to configure it. We have tried adjusting the values of various timeouts however they do not appear to impact the behaviour.

Can you suggest where we can adjust how long calls site in the queue before being sent to VM??

the call queue config and aa drop through.

!

application
  service queue flash:app-b-acd-2.1.2.2.tcl
  param queue-len 10
  param aa-hunt1 533
  param queue-manager-debugs 1
  param number-of-hunt-grps 1
  !
  service aa1 flash:app-b-acd-aa-2.1.2.2.tcl
  paramspace english index 0
  param aa-pilot 601
  param number-of-hunt-grps 1
  param handoff-string aa1
  paramspace english language en
  param service-name queue
  paramspace english location flash:
  param drop-through-option 1
  param second-greeting-time 60
  param max-time-vm-retry 2
  param max-time-call-retry 180
  param voice-mail 399

!

And the dial-peer

!

dial-peer voice 2601 voip
service aa1
destination-pattern 601
session target ipv4:10.1.1.1
incoming called-number 601
dtmf-relay h245-alphanumeric
codec g711ulaw

!

And the blast group

voice hunt-group 1 parallel
final 399
list 341,351,352,361,363,364,365,371
timeout 200
pilot 533

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
David Harper Tue, 03/03/2009 - 01:37

Nothing obvious leaps out in your application configuration.  However, you should be aware that B-ACD is currently only supported with ephone-hunt groups, not voice hunt-groups.  Try changing the hunt group to use the ephone-hunt syntax and see if that fixes the problem.  Obviously it will not provide blast call functionality, but you may be able to satisfy the customer requirement with one of the other hunt algorithms.

Cheers,

Dave.

geoffh Tue, 03/03/2009 - 15:20

I believe blast style ring is really the functionality they are after, with a queue. What about an shared octo dn? If the bacd queue supports these could they provide the blast style ringing?

David Harper Tue, 03/03/2009 - 15:39

B-ACD is only supported in conjunction with an ephone-hunt group.  However, there is nothing preventing you from creating an ephone-hunt group with a single member that is a shared octo-dn.

Cheers,

Dave.

geoffh Tue, 03/03/2009 - 17:17

Argh, maybe I've been staring at this stuff too long now. But I ran up a lab box to test the suggestion dave made about a normal hunt with a single member (the octo) however this UC won't accept the bacd. *argh*

I created the dial-peer for 601, and built the service queue and service aa1, but when you dial 601 you just get the unknown number error on the phone.

Is there something I'm missing in my config (ie am I having a stupid moment?)... and/or how do I troubleshoot why the bacd isn't picking up OR could it be a problem with the dial peer?

=P

The bits of config that are important:

!

application

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

  param queue-len 10

  param aa-hunt1 501

  param queue-manager-debugs 1

  param number-of-hunt-grps 1

  !

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

  param aa-pilot 601

  paramspace english index 0

  param number-of-hunt-grps 1

  param handoff-string aa1

  paramspace english language en

  param service-name queue

  paramspace english location flash:

  param drop-through-option 1

  param second-greeting-time 60

  param max-time-vm-retry 2

  param max-time-call-retry 180

  param voice-mail 401

  !

!

dial-peer voice 2601 voip

service aa1

destination-pattern 601

session target ipv4:10.1.1.1

incoming called-number 601

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

!

ephone-hunt 1 sequential

pilot 501

list 533

final 401

timeout 0

no-reg pilot

statistics collect

!

!

ephone-dn  47  octo-line

number 533

label 533

description 533 octodn

call-forward busy 401

call-forward noan 401 timeout 10

!



David Harper Tue, 03/03/2009 - 17:34

One really good gotcha for this is that CCA now configures a 'voice source-group' in an effort to improve security.  This restricts incoming voip connections to addresses that match access list #2, which typically will contain only the addresses of any SIP proxies configured plus the address of the VM/AA application (ie 10.1.10.1).  When you set up the dial-peer for B-ACD, you are essentially extending a call out from the UC500 back into the UC500.  As such, you need to make sure you add the address of the UC500 to the access list - specifically the 10.1.1.1 address based on the config you provided.

Cheers,

Dave.

geoffh Tue, 03/03/2009 - 17:58

yep that was it. added 10.1.1.1 into the access list and away it went.

So. I setup the configuration as per above on my lab box to test the behaviour. I have 4 phones, two of them have the octo dn mapped to them (533) as their second button (a 524 and 7961).

The first and second calls to 601 work perfectly, they ring on both phones, and I can pick them up.

The third call however rings the hunt group but does not go into a queue, it just sits there ringing even though both phones second button is in currently call. (I assume this has something to do with the 8 lines on an octo dn) The two phones who have 533 mapped can see the call ringing below their current call. (one nice thing is the phones do have a message saying 1 call in queue hehe). Eventually the call just disconnects after a few minutes.

Is there a ringing timeout that can be set to send them to the queue? And why would the call just be disconnected instead of eventually being sent to voicemail?

601 -> service aa1 -> service queue -> 501 hunt -> 533 member octo dn -> phones 7961/524.

David Harper Tue, 03/03/2009 - 18:02

This *might* be related to the fact that the CP-500 phones currently only support two calls per button, even though they have an octo-dn assigned.  Can you swap the 524 for a 7900 by any chance?

Cheers,

Dave.

geoffh Tue, 03/03/2009 - 18:23

done

533 now has a 7961, 7961 and 7970. (3 members now)

the same thing happens.

1st call ok (521 calls 601, 7961 picks up)

2nd call ok (same 521 calls 601 on 2nd line, [1st on hold], the second 7961 picks up)

3rd call ok (524 calls 601, 7970 picks up)

4th call rings for 180 seconds, then disconnects. (524 on 2nd line, [1st on hold])

5th call rings for 180 seconds, then disconnects (FXS analog phone)

I am using 521's and 524's to initiate calls tho. But I would assume the phone who is calling should not have any effect on the call queue behaviour.

David Harper Tue, 03/03/2009 - 18:48

I am assuming calls 1 thru 3 are still in progress all the while - in other words, there is no idle phone in the hunt group?  In that case, the 180 seconds is the max-time-call-retry timer expiring.  At that point, the call should redirect to ext 401 - voicemail I assume.  Stupid question, but have you confirmed that 401 is actually answering calls at this point?

Assuming 401 is answering calls, we might need to do some debugging, as I can't see anything broken in the config offhand.  Could you try capturing the output of 'debug voice ccapi inout' from the moment the 180s expires?  It'll probably be quite long, so you might want to send it to me directly rather than posting it to the discussion.  Once I've had a look, I'll post an update for the benefit of the rest of the community.

Cheers,

Dave.

geoffh Tue, 03/03/2009 - 19:00

correct. calls 1-3 are in progress.

401 is voicemail correct. And phones can check their voicemail no issues.

--

1st issue is that the call just rings for the entire 180 seconds. It does not get placed into a call queue, ie 'all our operators are busy at the moment, your call is important to us'...

2nd is the disconnect after 180 seconds instead of voicemail.

--

i'll email over debug shortly =)

---- OK to throw a spanner in the works, this time after 180 seconds it went through to voicemail for 501. The last two times I did exactly the same thing it just disconnected. I haven't changed anything in between last time and this.

David Harper Wed, 03/04/2009 - 20:46

After doing some further troubleshooting and testing with Geoff offline, we managed to solve the problem by addressing the following areas:

  • By configuring 'huntstop channel ', where n is the number of phones with the shared line applied, we were able to ensure that callers would go directly to the queue when all phones were on calls on that line.
  • The timeout parameter on the ephone hunt group was set to 180 seconds, which caused the user to never go to the queue, but rather sit ringing on the phone until the call forwarded to VM.
  • We also removed the final parameter from the ephone hunt group since that was kicking in at the same time as the B-ACD final destination, resulting in call drops after the 180 second timer expired.

Cheers,

Dave.

geoffh Wed, 03/04/2009 - 21:59

so last question on this, the current timeout before the call gets sent to voicemail from the queue is 180 seconds. Is there a way to set a parameter so that a person in queue can press a key to be sent to voicemail straight away?

Marcos Hernandez Thu, 03/12/2009 - 12:08

Geoff,

Direct transfer to voicemail or zeroing out of the BACD is not supported by these scripts.

Thanks,

Marcos

geoffh Thu, 03/12/2009 - 16:21

Hi Marcos,

Cheers for that. I had a little offline chat with Dave, and he suggested a workaround to provide similar functionality.

Use a short queue length (eg 1 min) then drop the call into an AA (instead of voicemail's extension) with a press 1 for voicemail, 2 to continue holding message, 1 sends the call to voicemail, or 2 sends the call back to the bacd queue.

Only issue is that the caller will lose their place in the queue, however in smaller environments this is unlikely to cause major issues.

Cheers

Geoff

Marcos Hernandez Thu, 03/12/2009 - 18:30

Extremely useful, just like anything else good ol' Dave always suggests :-)

Just bear in mind that every time you use CUE, you are grabbing a session (max of 6). So if a handful of callers are doing this back and forth and some internal users are checking voicemail, new outside callers might get a busy signal if the front end is the CUE AA.

I typically try to stay away from using CUE for anything other than the short, transactional call handling that it was designed for.

More info on:

https://www.myciscocommunity.com/docs/DOC-2366

Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

phershaw Fri, 03/13/2009 - 02:24

Regarding:

"Direct transfer to voicemail or zeroing out of the BACD is not supported by these scripts."

The CME B-ACD configuration guide now mentions Call Queue Exit and Alternate Destination for Unavailable Hunt Groups options

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/bacd/configuration/guide/40bacd.html#wp1105967

However it does not mention if a particular TCL script is required for these options but it does say that they are available in Cisco Unified CME 7.0(1). The built-in scripts in this CME version are version 2.1.2.3 which I don't think is avalable for download separately ?

I would be grateful if anyone has any information on these new options and if they need a particular script etc.

Thanks,

Phil

Marcos Hernandez Fri, 03/13/2009 - 08:58

Hi Phil,

This is a good observation. The scripts in CME 7.0 are also the 2.1.2.2 scripts, so this param should be available in this version too. The problem is that none of this works when drop through is enabled. If you refer to the original post on this thread, you will notice drop through was needed. Let me elaborate:

There are two TCL scripts involved in the BACD implementation, an AA TCL script and a Queuing script. The callers hit the AA script first as this serves as a front-end IVR. Upon selecting an option, they are transferred to queuing script, that handles well, the queuing. Drop-through allows you to be put in the queue automatically in case you do not need that front-end AA IVR. A good example of a use case is when your main AA is the CUE AA, for instance.

When drop through is enabled, all the other params of the AA script become unnecessary, because you will leave the AA immediately and be transferred to the queue. This includes the queue exit option. If you read what it does, you will notice that it only becomes available if the queue has reached its limit and you get put back on the AA; but with drop-through being there, queue exit can't be there. That's what I meant when I said these scripts don't support what you wanted to do.

From the docs:

"Note When configuring an AA in drop-through mode, set the number of hunt groups in the AA (Step 18) to 1. If an AA is in drop-through-option mode, it cannot have any other options besides one drop-through-option."

Thanks,

Marcos

phershaw Fri, 03/13/2009 - 09:45

Hi Marcos,

Thank you for the excellent explanation.

It's a pity there's no exit option from the queue as a lot of customers use the CUE AA, with B-ACD drop through option and would like to be able to give callers a "leave a message" option from the queue.

Another thing I've noticed with this is that the Editor Express (GUI Script Editor) for CUE by default plays a prompt when a call transfer attempt to an extension is Busy / Invalid / Unsuccesful. But to get the AA to play the prompt you need to change the transfer mode to semi-attended for example, otherwise the caller hears nothing and is disconnected. However, if one of the AA Menu options transfers the call to a B-ACD queue then semi-attended transfer is no good as the AA needs to relinquish the call to the queue, so you would have to either use the CUE Editor to customise the script or create one, which doesn't play prompts for busy extensions, which then means the customer cannot make changes to the script using the GUI.

Unless you know of another option ?

Thanks,

Phil

Marcos Hernandez Mon, 03/16/2009 - 18:45

I was not aware of this situation Phil. I guess your script needs to acommodate for this.

Thanks,

Marcos

peter.konstek Tue, 03/31/2009 - 01:20

Hi Guys.

I recently did a training day with Geoff in perth.. very valuable considering i am configuring a system with this very scenario at the moment. All is working as planned so far except im having difficulty ammending the attached  aa script to auto timeout if there is no button press. In my scenario the all callers are dropped into a AA... one of the AA options is to join a queue which works perfect. I timeout the queue to another AA after 18 seconds which allows the caller to press 0 leave a message (goes to shared mailbox) or wait for a agent.. It is at this point that i cant get the script to work as i want. At the moment the button press to leave a message is ok but i cant get it auto timeout back to the queue (queue is 602).

Can someone point me in the right direction with ammending the attached script? Help would be greatly appreciated.

Actions

This Discussion