[cisco-voip] CUBAC - Forced Delivery and Shared Lines

Bennie Grant Bennie.Grant at mettoni.com
Thu Mar 3 11:41:13 EST 2011


Sounds like what you are trying to do is not supported…you cannot login operators into a shared line – and will cause the issues that you are seeing…

You don’t want the call to ring directly to the handset (as in, by passing the queues), as this causes issues when multiple calls arrive, plus you lose the reporting on the queue information

If you want all the operators to ring at the same time, then turn off Forced Delivery, and make sure all operators are sharing the same queue. Then, when a call comes in to the queue, all of the PC's will ring at the same time. While it isn't the "phone" ringing – it is the same experience, all PC's will ring at the same time, and whichever operator gets there first will answer the call

Alternatively, you can use forced delivery if you need the phone to ring. However – as you are seeing – forced delivery works on a "longest waiting" basis, so it will ring each phone in turn if the call is not answered, as opposed to ringing all of them at the same time..

In your example, if 1,000 is the main DN where the calls come in, then this should be translated to the CTI Route Point to let the CUBAC Server take care of it – you should not be routing this directly to the handset(s) as this is bypassing the system, as I say. If you're doing that, you're essentially not using CUBAC – you're just send a DID call to a shared line

Unfortunately, shared lines (same DN, same partition) is not supported in CTI, which means that each operator needs to have a unique extension.

Hope that helps

Bennie Grant
VP - Operations
Arc Solutions (International) Inc
Part of the Mettoni group | www.mettoni.com

From: Brian Schultz <bms314 at gmail.com<mailto:bms314 at gmail.com>>
Date: Thu, 3 Mar 2011 15:50:10 +0000
To: Cisco-voip <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: [cisco-voip] CUBAC - Forced Delivery and Shared Lines

We are running CUBAC 8.5 with two operator licenses and CUCM 8.5.  Our main number is a shared line across several phones so it can be answered in several different areas.  If I login to CUBAC using the main number DN (1000 for example), then forced delivery will successfully still ring all of the phones as well as allow the CUBAC operator to answer the call.  This however poses two issues:

1)  If the CUBAC operator answers a call and a second call comes in, forced delivery no longer pushes the call to all of the phones sharing DN 1000.  I can change the RNA timeout on the CTI ports to something low like 5 seconds and forward to 1000, but that is inefficient.  Not sure why forced delivery doesn't work with a second call.

2)  The second receptionist is unable to login to CUBAC using the same 1000 DN because it is already in use.  If they login with their personal extension, then inbound calls to the main number CFNA to that personal voicemail and forced delivery to the shared line is broken again.

I tried to overcome this by creating a broadcast hunt group instead of a shared line.  Unfortunately, the CUBAC operator can't login with the hunt pilot number because it is considered an invalid extension.  This also breaks my attempt at forced delivery to ring all of the phones simultaneously when the CUBAC operator is logged in because the extension is unique on all phones within the hunt group.

Can anyone think of another way to make this work?  My goal is to have all 6 phones ring simultaneously for calls to the main number and have up to two operators be able to login and handle calls through CUBAC.  Of course, this worked well with the old built-in Cisco AC.  :-)

Thanks,
Brian

*************************************************************************
Please consider the environment before printing this e-mail
*************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.  http://www.mettoni.com

Mettoni Ltd
Registered in England and Wales: 4485956
Ashfords House, Grenadier Road, Exeter, EX1 3LH
*************************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110303/1f0c1a70/attachment.html>


More information about the cisco-voip mailing list