UC560 Intercom Help

[jeremy.hudgeons]

The system I am configuring is replacing an existing phone system. On the existing phone system they utilized an intercom feature button where they pressed intercom and then entered the extension they wanted to intercom with. I am trying to configure this type of functionality in the UC560. From the command line I created ephone-dn intercom using the extension with a star in front of it and then assigned it to the phone with the extension. This worked fine except it appears to break the ability to use the Configuration Assistant (java string error - out of range -1). I don't have enough line buttons on the phones to create an intercom with every person that one may be required. Any Ideas???

[Steven DiStefano · Accepted solution]

Dialable Intercom is not supported with CCA today.

The out of band CLI can be made CCA Compatible with some caveats and restrictions, one being that you can no longer change Dialable Intercom button using the Telephony > Voice configuration

There is a CLI doc being reviewed right now for this.  Would you like to try it?

---
A dialable intercom allows the user to press a button on the phone and then enter the number for the person they wish to intercom (note this may be done using a speeddial or monitor/watch button).  Dialable intercoms are generally used by operators or administrative staff who provide support for many staff, as opposed to secretaries and personal assistants who are generally responsible for one or two people and will have specific intercom buttons on their phone for each person.

Requirements & Caveats
Dialable intercoms should be added last after all other configuration is complete.  Once a single dialable intercom is present, CCA will not longer be able to display or make changes to any phone configuration.

Configuration Details
To create a dialable intercom, it is first necessary to create an additional ephone-dn for each user that may be the target of the intercom, plus a similar ephone-dn for the person who will be initiating the call.  In practice, intercom DNs are usually created for every user in the organisation.
The ephone-dn’s created are assigned a number that is derived from taking the user’s main extension number and prefixing it with an additional digit to ensure uniqueness.

This digit may be a normal dialable digit that is not otherwise used in the configuration, or it may be one of A, B, C, D or *.  When using a CCA-generated configuration, the most commonly available options are 4, 7, 8, A, B, C or D, though this will vary between installations.  The use of a non-dialable option for the prefix prevents accidental dialling of the intercom.

For example, in a site where all extensions are of the form 2xx, the ephone-dn used for intercom on the phone with extension 201 would have the number A201.  The configuration for this ephone-dn would then be as follows:

UC520#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
UC520(config)#ephone-dn  30
UC520(config-ephone-dn)#number A201
UC520(config-ephone-dn)#name DialableIntercomA201
UC520(config-ephone-dn)#intercom A label "Intercom"
UC520(config-ephone-dn)#exit
UC520(config)#ephone 5
UC520(config-ephone)#button 1:10 2:30
UC520(config-ephone)#end

First, and ephone-dn with the number A201 is created.  The name field should be set to be ‘DialableIntercom’ followed by the extension number of this ephone-dn, with no whitespace.  This allows this configuration to be recognised by CCA once the CCA Dialable Intercom feature is available.

Finally, the ephone-dn is defined as an intercom with the ‘intercom A label “Intercom”’ command.  The ‘A’ in this command should match the prefix used in the number assigned.  This allows the user to press the intercom button, and then dial only the digits of the target phone’s extension.

So for this phone to intercom extension 203, the user would press the intercom button and then dial ‘203’.  Similar ephone-dns should be created for all phones requiring intercom capability.
In this example, the ephone-dn is assigned to a button on the phone, allowing the user to initiate intercom calls as well as receive them.  If the user does not need to initiate intercom calls, then the ephone-dn can be configured on the same button as the main extension using an overlay.  This saves the use of a button, and allows single-line phones to receive intercom calls.  The configuration for an overlay for the example above is as follows:

UC520#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
UC520(config)#ephone 5
UC520(config-ephone)#button 1o10,30
UC520(config-ephone)#end
UC520#

[jeremy.hudgeons]

So I assume by reading the answer that support for this in CCA may be on the roadmap? I will most likely be putting this into production. Thanks for the response.

[Steven DiStefano]

Its on the list, but the list is long, only because the UC500 is inheriting new IOS,CME & CUE features from our enterprise offerings, and we move very fast there.. and dominate IMO.  So to allow a Small Business Partner to configure everything offered will always be a game of catch up for the GUI.

Speaking of lists, the fact is that since the days of CCA 1.x we have added so much to CCA, that it is really impressive.

We are at a point now, where we do believe you can support a deployment practice using CCA and the features it supports:

http://www.cisco.com/en/US/partner/prod/collateral/voicesw/ps6882/ps10585/partner_reference_c07-557625-00.html

Keep this in mind.  When you do enter CLI, you are creating a bit of overhead that you will have to consciously decide you (as a Partner) will have to maintain.  This will elevate the skill level required on your team a little, and does mean you are straying off the high use path of deployment models, and so when new features are introduced, you do need to keep one eye open for interoperability.

A nice LAB of your own where you maintain the most typical supported model is the best advise I can give you and try to keep it as cookie cutter as possible, to make it easier and more profitable for you.  The out of band CLI Guide is intended to help you understand what CCA reserves as values and parameters:

https://supportforums.cisco.com/docs/DOC-9809

Steve D

Systems Engineering

US Partner Sales team

[gdamron]

I tried the config you suggested but I having a problem with the prefix.

I have 3 digit extensions in 1xx form and I tried this with 2 of them. If the dn is set to intercom A101 i goes strait to it but with just A it errors

could it be that A needs to be set as a prefix some were or am i missing some thing else?

[gdamron]

I just found that "A" as a prefix doesn't seem to work for me everything else.

[David Harper]

One area where you can have a problem with dialable intercom as compared to regular intercom is when you have an overlapping dialplan.  With a regular intercom, an intercom call to A101 goes through dialplan analysis once with the string A101.  When you use dialable intercom, dialplan analysis is invoked with each digit dialed.  So the strings 'A', 'A1', 'A10', and 'A101' all get tested.  So if you have some other dialable destination that matches 'A1' say, then a diable intercom call will fail where regular intercom succeeds.

One example of possible overlap that springs to mine is if you have any FXO lines assigned to phone buttons as trunk lines (CO Lines in CCA).  The CCA generated configs for CO Lines use A as a prefix in the CO Line config, so you will get strings in the dial plan of 'A1', 'A2' etc for each of the FXO lines.

The way to fix this is to change the prefix used for dialable intercom, since the user doesn't see that at all.  Can I suggest using '*DB' as a prefix, since that is one of the prefixes being used in the internal engineering builds of CCA that support this feature.  While that won't guarantee your config will be recognised by CCA without error, it improves your chances significantly, and the prefix is also unusual enough that it is unlikely to overlap with anything else you have in the dialplan.

Cheers,

Dave.

[jeremy.hudgeons]

Thanks for the info. This is my first UC5XX series system and overall I am pretty impressed. Hopefully that does not change after the unit is in production. I come from the Call Manager/CME side and was concerned the GUI was going to be similar to the web interface to the CME (useless). I don't mind the command line and I do prefer it in most cases but a voice config can begin to stretch out a bit. I enjoy the freedom of having access to all of the interface options and understand there has to be a little downside to that freedom. I like the GUI interface and I want to stay with it as much as possible for the very reasons you speak of. All in all this is the only feature I have come across thus far in the config that has presented an issue. I am going to attempt to guide the end users to utilize consultative trasnfer over the intercom feature they are used to because I believe it is better equipped for their need but in the end if they want the intercom they get the intercom if you know what I mean.