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

Thu Mar 3 16:03:34 EST 2011

I am not seeing an overflow timer.  Where can I configure this in CUBAC?  I
have an extension configured here, but it only seems to take effect when 0
operators are logged in.

Brian

On Thu, Mar 3, 2011 at 2:41 PM, Bennie Grant <Bennie.Grant at mettoni.com>wrote:

> Regarding shared line support – I couldn’t comment, as that’s a Cisco CTI
> thing. Unfortunately, I know that its a pretty large undertaking, so if I'm
> honest I wouldn’t expect it in the near term
>
> What you say below is essentially correct. As you know, CUBAC is based on
> the same architecture as the Arc Premium products – and this has always been
> the case with both product suites.
>
> There's a couple of different ways to handle this:
>
>    1. If all users are true operators (I.e. They need the directory, etc
>    etc), then give them all CUBAC – as they'll need this to do their job
>    2. If some of the users are "backup" and don't need a full console,
>    then by definition they should be secondary call answerers. In that case,
>    use the overflow timer to send calls over to them after a set period of time
>    (say 30 seconds or something similar). The overflow can be sent to a shared
>    line
>
> Option 2 means that if the operators are available, then they will answer
> the call – as is their primary function. If not, after a certain time, you
> send the cal to the "back office" - which could be a hunt group, shared line
> etc – and that team pick up the call in between their other tasks
>
> Cheers
>
> Bennie Grant
> *VP - Operations
> *Arc Solutions (International) Inc
> Part of the Mettoni group | www.mettoni.com
>
> From: Brian Schultz <bms314 at gmail.com>
> Date: Thu, 3 Mar 2011 19:21:45 +0000
> To: Bennie Grant <bennie.grant at mettoni.com>
> Cc: Cisco-voip <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] CUBAC - Forced Delivery and Shared Lines
>
> Thanks for the response Bennie.
>
> If I am reading this right, I either need all phones that share the main DN
> number to also utilize the CUBAC software or none of them...there isn't an
> in between like we could do with the old Cisco AC software.  In this
> environment (and several others that I support), there are some phones that
> have an occurrence of the main number so a backup person can answer inbound
> calls to the main number in case the main receptionist is tied up.  Many
> times, these phones do not have PC's attached to them as they might be
> located in common areas.  With CUBAC, I can no longer use these other phones
> to indicate an inbound call because the CTI Route Point sends the call to a
> queue.
>
> Any plans to support shared lines in the future?
>
> Also, is there a way to tweak the overflow timer in CUBAC?  If so, an
> inbound call could ring the one or two operator consoles for X period of
> time then overflow to a hunt pilot which could ring the remainder phones.
>
> Thanks,
> Brian
>
>
> On Thu, Mar 3, 2011 at 10:41 AM, Bennie Grant <Bennie.Grant at mettoni.com>wrote:
>
>> 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>
>> Date: Thu, 3 Mar 2011 15:50:10 +0000
>> To: Cisco-voip <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
>> *************************************************************************
>>
>>
> *************************************************************************
> 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/37a6b212/attachment.html>