cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1183
Views
0
Helpful
8
Replies

Call Waiting on UC540

TWalsh
Level 1
Level 1

I don't know if this is the proper forum for this issue or is better argued through SBSC channels.

Customer Environment:

Doctor's office

UC540

5 x SPA508G

2 x SPA525G

1 x 7921G

CCA3.0 and IOS 15.0(1)XA3a

8-line SIP package from CBeyond through Cisco IAD

1 line pulled as analog line for FAX at IAD

1 line pulled from group to act as DID

remaining 6 lines act as rollover from CBeyond

All extensions not manned at all times

Customer requirements:

DID line (coming in through SIP trunk) to act as direct acces line for family members / other doctor's / specific vendors so as to bypass AA

DID must ring all local phones

Incoming call on DID recognizable as coming from that line via flashing button

Call waiting on that line

Configuration on UC540:

6 rollover lines added under Incoming Dial Plan > Direct Dail to Auto Attendant, Groups, Operator and pointed to AA as destination

Calls routed to several Blast Groups depending on AA option chosen by caller

DID added under Incoming Dial Plan > Direct Dial to Internal User Extensions and pointed to a Shared Extension (201) and labeled BackLine; no VM on shared extension

Shared Extension added as Button 2 on all phones

Problem:

Call waiting doesn't work on Shared extension, i.e. First call on BackLine rings all phones; available User picks up call at whatever phone they are near; second call coming in on BackLine immediately generates busy signal on caller's phone; User already in call on BackLine receives no indication that second call on BackLine is there.

Talked with SBSC about this, and the end answer was that although this feature could be added via command line, is available if 7900 series phones are connected, and is available in full-blown Call Manager, it isn't supported in the UC500 series and CCA 3.0 and with the SPA500 series phones.

NOTE:  according to the customer, call waiting is working on the rollover lines as configured above.

The issues here are that the customer requires call waiting to work regardless of the extension or type of extension, and the Feature Description Guide for CCA 2.2(4) / 2.2(5) (which was in force when the system was purchased) specifically mentions Call Waiting as being an available feature, and doesn't mention any caveats.  Work-arounds suggested by SBSC (create Blast Group of several new extensions; assign one extension from Blast Group to button 2 on each phone; result that phones will ring in series when call comes in on BackLine) won't meet customer requirements, i.e. one user available to pick up phones; call comes in on BackLine and rings all phones; user picks up call in back office; second call coming in on BackLine will ring phone in another office where a user may or may not be available.

Is there anything fundamentally wrong with the way I had this set up to prevent call waiting from working on that BackLine?  Is there another way to configure this to get call waiting to function in a manner that meets the customer's requirements while still showing a call incoming through a specific line?  Please keep in that the fight the customer has with the answer I received from SBSC is that Call Waiting is a feature supported by CCA and the UC500 serieies, and that there were no caveats to this mentioned in the Feature Description Guide.

8 Replies 8

David Trad
VIP Alumni
VIP Alumni

Hi There,

I need to map this out with you as i am certain I have deployed a few systems with similar setup to what you want.

Incoming Call on DID X ----> Call Points to DN-100 (Shared DN: Dual-Line minimum, Octo Preferred) ----> EXT-200 Answers Call (Presses Shared DN button)----> Second Call Arrives on Shared DN-100 ----> Extension 200 Sees the call on the screen and may hear CW Beep, and so does all other handsets (Possible Call Waiting Beep if others are on the call).

Not the best way to map it out, normally I would Visio it up but it is almost time to go home

If the above is correct, then yes it should work and it can be done... And from as I understand it CCA 3 does indeed support this type of setup, well at least I am lead to believe it does.

Admittedly I have never used CCA for this before and only ever did it via Command Line, if I our NFR system arrived already i would have worked this up quickly on the lab system to verify CCA's ability to create this type of scenario.

Let me know if I was way of the mark or if I was at least close, then will see if I can help you out further.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Hi David,

It looks like you have the desired behavior correct.  The key to it all is that the extension that picks up the initial call on DID X be able to tell there is a second call incoming with the CW beep and that the call is coming in on DID x through either the flashing of the Shared DN button or by using a differenet ring tone(which is tied to button configuration as far as I can tell).

Getting the functionality the customer desires is the first major problem.

Staying within what Cisco Small Business Support Center will support with their new CCA-configuration-only support policy is the second problem.

Hi There,

I still have not received our NFR equipment so I am unable to work this up for you on a lab system.. I was kind of hoping someone from Cisco would actually chime in by now and tell you which Draw to open up and do this, CCA/CCA 3 is vague to me as I have not played with it in over 10 months and would be totally rusty with it right now...

But I know 100% that this can be done, if you want it as described then this can be done, and I am certain that CCA does support this type of deployment as well which will keep you within the SBCS guide lines.

*** Whistles out to Dave Harper to give the pointers ***

Hopefully someone from Cisco can tell you where within CCA this is all located, otherwise log a configuration support request and get one of the SMB support guys to help you out over the phone (Assuming they are trained up on how to configure a deployment like this).

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Dave,

There doesn't appear to be anything within CCA as far as configuration for Call Waiting. This would fall in line with other things I've read about Call Waiting being enabled by default.

Also, within the SBCS Feature Description Guide, while there is nothing about configuration of Call Waiting being supported by a particular version of CCA, it is listed under the section titled SBCS Feature Descriptions, where it also mentions that not all items require configuration.

Digging through CCA 3.0, I haven't been able to find anything reference call waiting configuration in any of the help screens, which in my mind says that there are no configuration settings for it within CCA.

The bottom line still remains, that I've now opened two separate SBSC cases, and on the second one was told that what I need is not supported (or is supported via CLI, or is supported with 7900-series phones, or is supported with full Call Manager - all by the same person, within the same conversation).

Perhaps, I just need to keep calling until I wear them down.  Unfortunately, this doesn't help me out as far as the customer is concerned.

By default, this is enabled; the provider should be sending this if you request it.  In fact, I have had to disable this for customers that not desire this.  You can hear call waiting beeps and perform a flashook to retrieve them.  It is not necessary to reinvent the wheel; this is a simple fix.

To turn it off you have to program every ephone-dn with a "no call-waiting  beep accept".  Let STAC do this for you so that you can stay within compliance with support.  Just call them and they will fix this for you via Webex.  You can reach them at 1-866-606-1866 just in case you don't have the number.

All the best,

Robcast

Robert,

Thanks for the reply.

As mentioned in my original post, I am getting Call Waiting from my provider (Cbeyond).  It is in fact working correctly on all the rollover lines from the provider.

As I also mentioned, I've opened two different cases on this.  The original resulted ina half-useful work around that didn't meet customer requirements.  The second resulted in the answeres mentioned in the original post as well as in my reply to Dave in his last post.

The problem exists on only one line which is a DID coming in over a the same SIP trunk.  If I configure the call to go to a specific user extension only, Call Waiting works as advertised.  However, if I configure the DID to point to a shared extension, it does not.  The first call comes in and is answered.  The second call comes in and immediately goes to a busy signal on the callers end.  The person who picked up the original call gets no indication that a second call is there.

I'm probably going to open a third case this morning to argue the position of Call Waiting is supposed to be enabled by default, and that it is mentioned in the Feature Description Guide as an available feature, with no caveats.

I tested call-waiting here in the lab for a shared line.  By default, the call waiting beep is enabled, but "huntstop channel" is applied to the DN.  This is the default configuration for a Shared extension.  There is not a way to change this in CCA, and for that not to be the default setting would have to changed by the CCA team.  (So a feature request would have to be requested.)

To get call-waiting to work on a shared extension, you will need to find the ephone-dn for that extension, and change its behavior:

conf t

ephone-dn 300

no huntstop channel

Thank you,

Darren

Hi Darren,

Thanks for that straight forward answer.  I applied your "fix," and now am getting the behavior I expected before.