Information About Call Coverage Features
Call Coverage Summary
Call coverage features are used to ensure that all incoming calls to Cisco Unified CME are answered by someone, regardless of whether the called number is busy or does not answer.
Some single-dialed-number call coverage features, such as hunt groups, can send incoming calls to a single extension to a pool of phone agents, while other features, such as call hunt, call waiting, and call forwarding increase the chance of a call being answered by giving it another chance for a connection if the dialed number is not available.
Multiple-dialed-number call coverage features, such as call pickup, night service, and overlaid directory numbers, provide different ways for one person to answer incoming calls to multiple numbers.
Any of the call coverage features can be combined with other call coverage features and with shared lines and secondary numbers to design the call coverage plan that is best suited to your needs.
Table 1 summarizes call coverage features.
|
Feature |
Description |
Example |
How Configured |
|---|---|---|---|
|
Call Forwarding |
Calls are automatically diverted to a designated number on busy, no answer, all calls, or only during night-service hours. |
Extension 3444 is configured to send calls to extension 3555 when it is busy or does not answer. |
Enable Call Forwarding for a Directory Number or |
|
Call Hunt |
System automatically searches for an available directory number from a matching group of directory numbers until the call is answered or the hunt is stopped. |
Three ephone-dns have the same extension number, 755. One is on the manager’s phone and the others are on the assistants’ phones. Preference and huntstop are used to make sure that calls always come to the manager’s phone first but if they can’t be answered, they will ring on the first assistant’s phone and if not answered, on the second assistant’s phone. |
Configure Call Hunt on SCCP Phones or |
|
Call Pickup |
Calls to unstaffed phones can be answered by other phone users using a soft key or by dialing a short code. |
Extension 201 and 202 are both in pickup group 22. A call is received by 201, but no one is there to answer. The agent at 202 presses the GPickUp soft key to answer the call. |
|
|
Call Waiting |
Calls to busy numbers are presented to phone users, giving them the option to answer them or let them be forwarded. |
Extension 564 is in conversation when a call-waiting beep is heard. The phone display shows the call is from extension 568 and the phone user decides to let the call go to voice mail. |
Configure Call-Waiting Indicator Tone on SCCP Phone or |
|
Cisco CME B-ACD |
Calls to a pilot number are automatically answered by an interactive application that presents callers with a menu of choices before sending them to a queue for a hunt group. |
The DID number 555-0125 is the pilot number for the XYZ Company. Incoming calls to this pilot number hear a menu of choices; they can press 1 for sales, 2 for service, or 3 to leave a message. The call is forwarded appropriately when callers make a choice. |
See Cisco Unified CME B-ACD and Tcl Call-Handling Applications. |
|
Hunt Groups |
Calls are forwarded through a pool of agents until answered or sent to a final number. |
Extension 200 is a pilot number for the sales department. Extensions 213, 214, and 215 belong to sales agents in the hunt group. When a call to extension 200 is received, it proceeds through the list of agents until one answers. If all the agents are busy or do not answer, the call is sent to voice mail. |
Configure Ephone-Hunt Groups on SCCP Phones or |
|
Night Service |
Calls to ephone-dns and voice register dns that are not staffed during certain hours can be answered by other phones using call pickup. |
Extension 7544 is the cashier’s desk but the cashier only works until 3 p.m. A call is received at 4:30 p.m. and the service manager’s phone is notified. The service manager uses call pickup to answer the call. |
|
|
Overlaid Ephone-dns |
Calls to several numbers can be answered by a single agent or multiple agents. |
Extensions 451, 452, and 453 all appear on button 1 of a phone. A call to any of these numbers can be answered from button 1. |
Out-of- Dialog REFER
Out-of-dialog REFER (OOD-R) allows remote applications to establish calls by sending a REFER message to Cisco Unified CME without an initial INVITE. After the REFER is sent, the remainder of the call setup is independent of the application and the media stream does not flow through the application. The application using OOD-R triggers a call setup request that specifies the Referee address in the Request-URI and the Refer-Target in the Refer-To header. The SIP messaging used to communicate with Cisco Unified CME is independent of the end-user device protocol which can be SIP, SCCP, H.323, or POTS. Click-to-dial is an example of an application that can be created using OOD-R.
A click-to-dial application allows users to combine multiple steps into one click for a call setup. For example, a user can click a web-based directory application from their PC to look up a telephone number, off-hook their desktop phone, and dial the called number. The application initiates the call setup without the user having to out-dial from their own phone. The directory application sends a REFER message to Cisco Unified CME which sets up the call between both parties based on this REFER.
Click-to-Dial Application using Out-of-Dialog REFER shows an example of OOD-R being used by a click-to-dial application. In this scenario, the following events occur (refer to the event numbers in the illustration):
-
Remote user clicks to dial.
-
Application sends out-of-dialog REFER to Cisco Unified CME 1.
-
Cisco Unified CME 1 connects to SIP phone 1 (Referee).
-
Cisco Unified CME 1 sends INVITE to Cisco Unified CME 2.
-
Cisco Unified CME 2 sends INVITE to SIP phone 2 (Refer-Target) and the call is accepted.
-
Voice path is created between the two SIP phones.
The initial OOD-R request can be authenticated and authorized using RFC 2617-based digest authentication. To support authentication, Cisco Unified CME retrieves the credential information from a text file stored in flash. This mechanism is used by Cisco Unified CME in addition to phone-based credentials. The same credential file can be shared by other services that require request-based authentication and authorization such as presence service. Up to five credential files can be configured and loaded into the system. The contents of these five files are mutually exclusive, meaning the username and password pairs must be unique across all the files. The username and password pairs must also be different than those configured for SCCP or SIP phones in a Cisco Unified CME system.
For configuration information, see Enable Out-Of-Dialog REFER.
Call Hunt
Call hunt allows you to use multiple directory numbers to provide coverage for a single called number. You do this by assigning the same number to several primary or secondary ephone-dns or by using wildcards in the number associated with the directory numbers.
Calls are routed based on a match between the number dialed and the destination patterns that are associated with dial peers. Through the use of wildcards in destination patterns, multiple dial peers can match a particular called number. Call hunt is the ability to search through the dial peers that match the called number until the call is answered. Call hunt uses a technique called preference to control the order in which dial peers are matched to an incoming call and a technique called huntstop to determine when the search for another matching peer ends.
In Cisco Unified CME, incoming calls search through the virtual dial peers that are automatically created when you define directory numbers. These virtual dial peers are not directly configurable; you must configure the directory number to control call hunt for virtual dial peers.
Channel huntstop is used to stop the search for the two channels of a dual-line directory number. Channel huntstop keeps incoming calls from hunting to the second channel if the first channel is busy or does not answer. This keeps the second channel free for call transfer, call waiting, or three-way conferencing.
Huntstop prevents hunt-on-busy from redirecting a call from a busy phone into a dial peer that has been setup with a catch-all default destination.
For configuration information, see Configure Call Hunt on SCCP Phones or Configure Call Hunt on SIP Phones.
Call Pickup
Call Pickup allows a phone user to answer a call that is ringing on another phone. Cisco Unified CME 7.1 introduces Call Pickup features for SIP phones. SCCP phones support three types of Call Pickup:
-
Directed Call Pickup—Call pickup, explicit ringing extension. Any local phone user can pick up a ringing call on another phone by pressing a soft key and then dialing the extension. A phone user does not need to belong to a pickup group to use this method. The soft key that the user presses, either GPickUp or PickUp, depends on your configuration.
-
Group Pickup, Different Group—Call pickup, explicit group ringing extension. A phone user can answer a ringing phone in any pickup group by pressing the GPickUp soft key and then dialing the pickup group number. If there is only one pickup group defined in the Cisco Unified CME system, the phone user can pick up the call simply by pressing the GPickUp soft key. A phone user does not need to belong to a pickup group to use this method.
-
Local Group Pickup—Call pickup, local group ringing extension. A phone user can pick up a ringing call on another phone by pressing a soft key and then the asterisk (*) if both phones are in the same pickup group. The soft key that the user presses, either GPickUp or PickUp, depends on your configuration.
 Note |
SIP phones only support local pickup and group pickup. Directed call pickup is not supported. |
The specific soft keys used to access different Call Pickup features on SCCP and SIP phones depends on the configuration in Cisco Unified CME. See the service directed-pickup command in Cisco Unified CME Command Reference for a description.
You can assign each directory number to only one pickup group and a directory number must have a pickup group configured to use Local Group Pickup. There is no limit to the number of directory numbers that can be assigned to a single pickup group, or to the number of pickup groups that can be defined in a Cisco Unified CME system.
If more than one call is ringing on the same number, the calls are picked up in the order in which they were received; the call that has been ringing the longest is the first call picked up from that extension number. Remote call pickup is not supported.
Call Pickup features are enabled globally for all phones through Cisco Unified CME. The PickUp and GpickUp soft keys display on supported SCCP and SIP phones by default and can be modified by using a phone template. For configuration information, see Enable Call Pickup.
Call Pickup shows four call-pickup scenarios.
Call Waiting
Call waiting allows phone users to be alerted when they receive an incoming call while they are on another call. Phone users hear a call-waiting tone when another party is trying to reach them and, on IP phones, see the calling party information on the phone screen.
Call-waiting calls to IP phones with soft keys can be answered using the Answer soft key. Call-waiting calls to analog phones controlled by Cisco Unified CME systems are answered using hookflash. When phone users answer a call-waiting call, their original call is automatically put on hold. If a phone user does not respond to a call-waiting notification, the call is forwarded as specified in the call-forward noan command for that extension.
For an IP phone running SCCP, call waiting for single-line ephone-dns requires two ephone-dns to handle the two calls. Call waiting on a dual-line ephone-dn requires only one ephone-dn because the two channels of the ephone-dn handle the two calls. The audible call-waiting indicator can be either a call-waiting beep or a call-waiting ring. For configuration information, see Configure Call-Waiting Indicator Tone on SCCP Phone.
For a SIP phone, call waiting is automatically enabled when you configure a voice register pool. For SIP phones directly connected to Cisco Unified CME, call waiting can be disabled at the phone-level. For configuration information, see Enable Call Waiting on SIP Phones.
For information on call waiting using Overlaid ephone-dns, see Overlaid Ephone-dns.
Call-Waiting Beep for SCCP Phones
Call-waiting beeps are enabled by default. You can disable the call-waiting beeps that are generated from and accepted by directory numbers. If beep generation is disabled, incoming calls to the directory number do not generate call-waiting beeps. If beep acceptance is disabled, the phone user does not hear beeps when using the directory number for an active call.
Table 1 shows the possible beep behaviors of one ephone-dn calling another ephone-dn that is connected to another caller.
|
Ephone-dn 1 Configuration |
Ephone-dn 2 Configuration |
Active Call on DN |
Incoming Call on DN |
Expected Behavior |
|---|---|---|---|---|
|
— |
|
DN 1 |
DN 2 |
No beep |
|
— |
DN 1 |
DN 2 |
No beep |
|
— |
|
DN 1 |
DN 2 |
No beep |
|
— |
|
DN 1 |
DN 2 |
Beep |
|
— |
|
DN 1 |
DN 2 |
No beep |
|
— |
DN 1 |
DN 1 |
No beep |
|
— |
DN 1 |
DN 1 |
No beep |
|
— |
DN 1 |
DN 1 |
No beep |
|
— |
DN 1 |
DN 1 |
No beep |
|
— |
DN 1 |
DN 2 |
Beep |
|
— |
DN 1 |
DN 2 |
No beep |
|
— |
|
DN 1 |
DN 1 |
Beep |
Call-Waiting Ring for SCCP Phones
Instead of the standard call-waiting beep sound through the handset, you can use a short ring for call-waiting notification. The default is for directory numbers to accept call interruptions, such as call waiting, and to issue a beeping sound for notification.
To use a ring sound, the directory number must accept call-waiting indicator tones. For configuration information, see Configure Call-Waiting Indicator Tone on SCCP Phone or Enable Call Waiting on SIP Phones.
Cancel Call Waiting
Cancel Call Waiting (CCW) enables an SCCP phone user to disable Call Waiting for a call they originate. The user activates CCW, and thereby disables call waiting, by pressing the cancel call waiting (CW Off) soft key or by dialing the feature access code (FAC) before placing a call. Call Waiting is inactive during that call; anyone calling the user receives normal busy treatment and no call waiting tone interrupts the user's active call. CCW automatically deactivates when the user disconnects from the call. CCW is supported on all lines that support the Call Waiting feature, including dual-lines and octo-lines.
This feature is supported in Cisco Unified CME 8.0 and later versions for SCCP IP phones and SCCP analog phones; it is not supported on SIP phones.
For configuration information, see Configure Cancel Call Waiting on SCCP Phone.
Callback Busy Subscriber
This feature allows callers who dial a busy extension number to request a callback from the system when the called number is available. Callers can also request callbacks for extensions that do not answer, and the system will notify them after the called phone is next used.
There can be only one callback request pending against a particular extension number, although a caller can initiate more than one callback to different numbers. If a caller attempts to place a callback request on a number that already has a pending callback request, the caller hears a fast-busy tone. If the called number has call forwarding enabled, the callback request is placed against the final destination number.
No configuration is required for this feature. To display a list of phones that have pending callback requests, use the show ephone-dn callback command.
Hunt Groups
Hunt groups allow incoming calls to a specific number (pilot number) to be directed to a defined group of extension numbers.
Incoming calls are redirected from the pilot number to the first extension number as defined by the configuration. If the first number is busy or does not answer, the call is redirected to the next phone in the list. A call continues to be redirected on busy or no answer from number to number in the list until it is answered or until the call reaches the number that is defined as the final number.
The redirect from one directory number to the next in the list is also known as a hop. You can set the maximum number of redirects for specific peer or longest-idle hunt groups, and for the maximum number of redirects allowed in a Cisco Unified CME system, both inside and outside hunt groups. If a call makes the maximum number of hops or redirects without being answered, the call is dropped.
In Cisco Unified CME 9.0 and later versions, support for call statistics is added for voice hunt groups. To write all the ephone and voice hunt group statistics to a file, the ephone-hunt statistics write-all command is enhanced and renamed to hunt-group statistics write-all command. If applicable, the TFTP statistics report consists of both ephone and voice hunt group statistics.
In Cisco Unified CME 9.5 and later versions, the command hunt-group statistics write-v2 is added to write all ephone hunt group statistics to a file along with total logged in and logged out time for agents. The command was enhanced in Unified CME Release 11.5 to add statistics for total logged in and logged out time for voice hunt group.
The show telephony-service all command is also enhanced to display the total number of ephone and voice hunt groups that have statistics collection turned on.
The statistics collect command under voice hunt-group configuration mode is introduced to enable the collection of call statistics for a voice hunt group.
The show voice hunt-group statistics command is introduced to display call statistics from voice hunt groups.
For Unified CME 11.5 and later versions, the overwrite-dyn-stats (voice hunt-group) command is introduced to overwrite statistics of previously joined dynamic agent with stats of newly joined dynamic agents for voice hunt group. The statistics for a dynamic agent are overwritten only when all the 32 available slots are used. For more information, see Cisco Unified Communications Manager Express Command Reference Guide.
For Unified CME 12.2 and later versions, Sequential, Parallel, Peer, and Longest Idle voice hunt groups support SIP shared line and mixed shared ine (SIP and SCCP Phones) directory numbers. All shared line features such as Hold and Remote resume, Barge, cBarge, Privacy, and calls through B-ACD is supported for calls that are placed through voice hunt groups.
The following are the known behavior patterns for the voice hunt group enhancement with shared line support, introduced in Unified CME Release 12.2:
-
When you press the Decline softkey on one of the shared line DNs (configured across phones) in a voice hunt group for an incoming call, the shared line DNs on the other phones continue ringing. This behavior is typical to shared line DNs in a voice hunt group. For all shared lines that are not part of a voice hunt group, when you press the Decline softkey, all the corresponding shared line DNs stop ringing.
-
Hlog feature is not supported on a shared DN. If a phone configured with Hlog has a shared DN as part of voice hunt group, then the Hlog functionality is supported only for the other lines that are part of voice hunt group on that phone.
For information on displaying statistics for hunt groups, see Cisco Unified CME B-ACD and Tcl Call-Handling Applications.
There are four different types of hunt groups. Each type uses a different strategy to determine the first number that rings for successive calls to the pilot number, as described below.
-
Sequential Hunt Groups—Numbers always ring in the left-to-right order in which they are listed when the hunt group is defined. The first number in the list is always the first number to be tried when the pilot number is called. Maximum number of hops is not a configurable parameter for sequential hunt groups. Sequential hunt Group shows an illustrated example.
-
Peer Hunt Groups—The first number to ring is the number to the right of the directory number that was the last to ring when the pilot number was last called. Ringing proceeds in a circular manner, left to right, for the number of hops specified in the hunt group configuration. Peer hunt Group shows an illustrated example.
-
Longest-idle Hunt Groups—Calls go first to the number that has been idle the longest for the number of hops specified when the hunt group was defined. The longest-idle time is determined from the last time that a phone registered, reregistered, or went on-hook. Longest-idle hunt Group shows an illustrated example.
-
Parallel Hunt Groups (Call Blast)—Calls ring all numbers in the hunt group simultaneously.
Ephone Hunt-group chains can be configured in any length, but the actual number of hops that can be reached in a chain is determined by the max-redirect command configuration. In the following example, a maximum redirect number 15 or greater must be configured for callers to reach the final 5000 number. If a lower number is configured, the call disconnects.
ephone-hunt 1 sequential pilot 8000 list 8001, 8002, 8003, 8004 final 9000 ephone-hunt 2 sequential pilot 9000 list 9001, 9002, 9003, 9004 final 7000 ephone-hunt 3 sequential pilot 7000 list 7001, 7002, 7003, 7004 final 5000 Cisco Unified CME 4.3 and later versions support the following Voice Hunt-Group features:
-
Call Forwarding to a Parallel Voice Hunt-Group (Call Blast)
-
Call Transfer to a Voice Hunt-Group
-
Member of Voice Hunt-Group can be a SIP phone, SCCP phone, FXS analog phone, DS0-group, PRI-group, or SIP trunk.
-
Unified CME supports chaining (nesting) of a voice hunt group with another voice hunt group. The chaining of voice hunt groups is established by configuring the final number of the first voice hunt group as the pilot number of the second voice hunt group.
Note
For Unified CME B-ACD, the final destination for voice hunt groups is determined by the B-ACD service.
-
Unified CME supports the chaining (nesting) of a maximum of two voice hunt groups. The configuration ensures that there is no looping of calls placed to a voice hunt group.
Ephone-Hunt Groups and Voice Hunt-Groups Comparison
SIP phones support Voice Hunt-Groups. SCCP phones support Ephone-Hunt Groups, and in Cisco Unified CME 4.3 and later versions, SCCP phones also support Voice Hunt-Groups. Table 1 compares the features of Ephone-Hunt Groups and Voice Hunt-Groups.
|
Feature |
Ephone Hunt |
Voice Hunt Group |
|---|---|---|
|
Endpoints Supported |
SCCP only |
SIP, SCCP, PSTN, and FXS |
|
Parallel Hunt Groups (Call Blast) |
No (for alternative, see Shared- Line Overlays |
Yes |
|
Hunt Statistics Support |
Yes |
Yes |
|
B-ACD Support |
Yes |
Yes |
|
Shared Line |
Yes |
Yes |
|
Features such as present-call and login/logout |
Yes |
Yes (Only for SIP and SCCP phones) |
Sequential Hunt Groups
In a sequential hunt group, extensions always ring in the order in which they are listed, left to right, when the hunt group is defined. The first number in the list is always the first number to be tried when the pilot number is called. Maximum number of hops is not a configurable parameter for sequential hunt groups.
From Unified CME 12.2 onwards, sequential voice hunt groups support shared lines and mixed shared lines. When calls are placed on a sequential voice hunt group and a shared DN is part of the hunt group, the call is placed sequentially. For the shared DN, the call would ring on all phones part of this shared DN. If none of the phones answer, then call would continue to the next DN in the hunt group.
Note |
Consecutive numbers of the same phone cannot be members of a Sequential Voice Hunt Group when present call idle state (configured using the CLI command present-call idle-phone ) is set to true. The limitation applies to both SIP and SCCP phones. |
Peer Hunt Groups
In a peer hunt group, extensions ring in a round-robin order. The first extension to ring is the number in the list to the right of the last extension to ring when the pilot number was last called. Ringing proceeds in a circular manner, left to right, for the number of hops specified when the hunt group was defined.
From Unified CME 12.2 onwards, peer voice hunt groups support shared and mixed shared lines. When calls are placed on a peer voice hunt group and a shared DN is part of the hunt group, the call is placed in a round-robin order. For the shared DN, the call would ring on all phones part of this shared DN. If none of the phones answer, then call would continue to the next DN in the hunt group.
Peer hunt Group illustrates a peer hunt group.
Longest-Idle Hunt Groups
In a longest-idle hunt group, the algorithm for choosing the next extension to receive a call is based on a comparison of on-hook time stamps. The extension with the smallest on-hook time stamp value is chosen when the next call comes to the hunt group.
The default behavior is that an on-hook time stamp value for an extension is updated only when the agent answers a call. In Cisco Unified CME 4.0 and later versions, you can specify that an on-hook time stamp is updated when a call rings an extension and also when a call is answered by an agent.
From Unified CME 12.2 onwards, longest-idle voice hunt groups support shared lines and mixed shared lines. When calls are placed on a longest-idle voice hunt group and a shared DN is part of the hunt group, the call is placed based on a comparison of on-hook time stamps. For the shared DN, the call would ring on all phones part of this shared DN. If none of the phones answer, then call would continue to the next DN in the hunt group.
Longest-idle hunt Group illustrates a longest-idle hunt group.
Parallel Hunt Groups (Call Blast)
In a parallel hunt group, calls simultaneously ring multiple phones. Using parallel hunt groups is also referred to as application-level forking because it enables the forking of a call to multiple destinations. In versions earlier than Cisco Unified CME 4.3, only SIP phones support parallel hunt groups. In Unified CME 4.3 and later versions, SCCP phones also support voice hunt groups.
You can enable functionality similar to parallel hunt groups on SCCP phones by using the ephone-dn overlay feature for shared lines. See Shared- Line Overlays.
From Unified CME 12.2 onwards, parallel voice hunt groups support shared lines and mixed shared lines. For parallel voice hunt groups, a maximum of 32 call blasts is supported, including shared-line and normal directory numbers. For example, consider a voice hunt group configured with 20 directory numbers, including 3 shared-lines assigned across three different phones. In this scenario, the count of shared line directory numbers is considered as 9 (3*3). Then, the total count of call blasts in this hunt group is 26 directory numbers(17 + 9). When the call blast limit of 32 is exceeded, then call is not placed for those voice hunt group directory numbers that exceed the limit.
In the following parallel hunt group example, when callers dial extension 1000, extension 1001, 1002, and so on ring simultaneously. The first extension to answer is connected. If none of the extensions answers, the call is forwarded to extension 2000, which is the number for the voice-mail service.
voice hunt-group 4 parallel
pilot 1000
list 1001, 1002, 1003, 1004
final 2000
timeout 20
The number of ringing calls that a parallel hunt group can support depends on whether call-waiting is enabled on the SIP phones.
If call-waiting is enabled (the default), parallel hunt groups support multiple calls up to the limit of call-waiting calls supported by a particular SIP phone model. You may not want to use unlimited call-waiting, however, with parallel hunt-groups if agents do not want a large number of waiting calls when they are already handling a call.
If call waiting is disabled, parallel hunt groups support only one call at a time in the ringing state. After a call is answered (by one of the phones in the hunt group), a second call is allowed. The second and subsequent calls ring only the idle phones in the hunt group, and bypass the busy phone that answered the first call (because this phone is connected to the first call). After the second call is answered, a third call is allowed, and so on until all the phones in the parallel hunt group are busy. The hunt group does not accept further calls until at least one phone returns to the idle/on-hook state.
When two or more phones within the same parallel hunt group attempt to answer the same call, only one phone can connect to the call. Phones that fail to connect must return to the on-hook state before they can receive subsequent calls. Calls that arrive before a phone is placed on-hook are not presented to the phone. For example, if a second call arrives after Phone 1 has answered the original call, but before Phone 2 goes back on-hook, the second call bypasses Phone 2 (because it is offhook).
When a phone returns to the idle/on-hook state, it does not automatically re-synchronize to the next call waiting to be answered. For example, in the previous scenario, if the second call is still ringing Phone 3 when Phone 2 goes on-hook, Phone 2 does not ring because it was offhook when the second call arrived.
For configuration information, see Configure Voice-Hunt Groups.
View and Join for Voice Hunt Groups
You can view voice hunt group related information on SIP and SCCP phones using the phone menu. The following information related to hunt groups can be viewed on the phone display:
-
Name
-
Pilot number
-
Status
If voice hunt groups have been configured, the user can view the voice hunt group information using the service button on the phone, by navigating to . On selecting the voice hunt group option, a list of voice hunt groups will be displayed.
A voice hunt group includes the name of the hunt group, the pilot number and also the status of the DN indicating if the DN is a member of the hunt group. This information is displayed in the following method:
-
If DN is a static member of the hunt group, then status is displayed with # (hash) symbol.
-
If DN is dynamic member, the status is displayed with * (asterisk) symbol.
The following operations can be performed on the phone user interface:
-
User can join or unjoin to or from voice hunt groups by selecting the Join or Unjoin softkey which is displayed on the voice hunt group page. The user can select the required voice hunt group using the up and down buttons.
-
User can access the next or previous records of voice hunt groups by selecting the Next/Previous softkey options.
To display voice hunt-group information on the phone, user needs to configure phone-display command under voice hunt-groups.
Restrictions and Limitations
-
A DN can join a maximum of six voice hunt groups.
-
The displayed hunt group information is applicable only for the primary line of the phone.
-
A primary DN can join or unjoin a voice hunt group using the Service button on the phone. If a phone is configured with multiple DNs, then DNs other than the primary DN can join the voice hunt groups by dialing the FAC standards.
-
The voice hunt group information display feature is applicable only on the phones that support My Phone Apps menu. For example, 78xx, 88xx phone families are supported. However, 69xx, 39xx phone families are not supported.
Enable User Interface to View, Join, and Unjoin Voice Hunt Groups on SCCP Phone
This feature enables an SCCP phone user to view information related to the voice hunt groups and join or unjoin voice hunt groups from a menu on their phone. This feature is enabled by default. You must perform this task only if the feature was previously disabled on a phone.
Before you begin
Cisco Unified CME 10.5 or a later version.
SUMMARY STEPS
- enable
- configure terminal
- ephone phone-tag
- phone-ui voice-hunt-groups
- end
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
ephone phone-tag Example: |
Enters ephone configuration mode.
|
|
Step 4 |
phone-ui voice-hunt-groups Example: |
Enables a SCCP phone user to view information related to voice hunt groups and also join or unjoin from voice hunt groups.
|
|
Step 5 |
end Example: |
Exits to privileged EXEC mode. |
Example
The following example shows that the voice-hunt-groups command is enabled on an SCCP phone.
ephone-dn 10 dual-line number 1001 no huntstop huntstop channelephone-dn 11 dual-line Note |
From Cisco Unified CME Release 10.5 onwards, SIP phones will display voice hunt group information, by default. |
Configure Service URL Button On SCCP Phone Line Key
To implement service PLK feature line key buttons on Cisco Unified SCCP Phones, perform the following steps.
SUMMARY STEPS
- enable
- configure terminal
- ephone template template-tag
- url-button index type | url [ name]
- exit
- ephone phone-tag
- ephone-template template-tag
- end
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
ephone template template-tag Example: |
Enters ephone-template configuration mode to create an ephone template.
|
|
Step 4 |
url-button index type | url [ name] Example: |
Configures a service URL feature button on a line key.
|
|
Step 5 |
exit Example: |
Exits ephone-template configuration mode. |
|
Step 6 |
ephone phone-tag Example: |
Enters ephone configuration mode.
|
|
Step 7 |
ephone-template template-tag Example: |
Applies an ephone template to the ephone that is being configured. |
|
Step 8 |
end Example: |
Returns to privileged EXEC mode. |
Example
The following example shows three URL buttons configured for line keys:
!
!
!
ephone-template 5
url-button 1 em
url-button 2 mphoneapp mphoneapp
url-button 3 snr
url-button 4 voicehuntgroups
url-button 5 park-list
!
ephone 36
ephone-template 5What to do next
If you are done configuring the url buttons for phones in Cisco Unified CME, restart the phones.
Configure Service URL Button On SIP Phone Line Key
SUMMARY STEPS
- enable
- configure terminal
- voice register template template-tag
- url-button [ index number] [ url location] [ label]
- exit
- voice register pool phone-tag
- template template-tag
- end
DETAILED STEPS
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
|
Step 3 |
voice register template template-tag Example: |
Enters ephone-template configuration mode to create an ephone template.
|
|
Step 4 |
url-button [ index number] [ url location] [ label] Example: |
Configures a service url feature button on a line key.
|
|
Step 5 |
exit Example: |
Exits ephone-template configuration mode. |
|
Step 6 |
voice register pool phone-tag Example: |
Enters ephone configuration mode.
|
|
Step 7 |
template template-tag Example: |
Applies the ephone template to the phone.
|
|
Step 8 |
end Example: |
Returns to privileged EXEC mode. |
Example
The following example shows URL buttons configured in the voice register template 1:
Router# show run
!
voice register template 1url-button 1 http://x.x.x.x:80/CMEserverForPhone/vhg_root_menu VHG_List
url-button 2 http://x.x.x.x:80/CMEserverForPhone/park_list Park_List
url-button 5 http://www.cisco.com Cisco
!
voice register pool 50
!
What to do next
If you are done configuring the URL buttons for phones in Cisco Unified CME, generate a new configuration file and restart the phones. See Generate Configuration Profiles for SIP Phones.
Display Support for the Name of a Called Voice Hunt-Group
A voice hunt-group is associated with a pilot number. But because there is no association with the name of the voice hunt-group when calls are forwarded from the voice hunt-group to the final number, the forwarding number is sent without the name of the forwarding party. The final number may be in the form of a voice mail, a Basic Automatic Call Distribution (BACD) script, or another extension.
In Cisco Unified CME 9.5, the display of the name of the called voice hunt-group pilot is supported by configuring the following command in voice hunt-group or the ephone-hunt configuration mode:
[no ] name “primary pilot name” [secondary “secondary pilot name” ]
The secondary name is optional and when the secondary pilot name is not explicitly configured, the primary pilot name is applicable to both pilot numbers.
The following example configures the primary pilot name for both the primary and secondary pilot numbers:
name SALES
The following example configures different names for the primary and secondary pilot numbers:
name SALES secondary SALES-SECONDARY
Note |
Use quotes (") when input strings have spaces in between as shown in the next three examples. |
The following example associates a two-word name for the primary pilot number and a one-word name for the secondary pilot number:
name “CUSTOMER SERVICE” secondary CS
The following example associates a one-word name for the primary pilot number and a two-word name for the secondary pilot number:
name FINANCE secondary “INTERNAL ACCOUNTING”
The following example associates two-word names for the primary and secondary pilot numbers:
name “INTERNAL CALLER” secondary “EXTERNAL CALLER”
For configuration information, see Associate a Name with a Called Voice Hunt-Group.
For more configuration examples, see Example for Associating a Name with a Called Voice Hunt-Group.
For configuration information, see Configure Ephone-Hunt Groups on SCCP Phones.
The following show commands are modified to reflect the configured primary and secondary pilot names:
-
show ephone-hunt
-
show voice hunt-group
The information related to the name of the ephone-hunt group and voice hunt-group are sent to the phone and displayed on the phone’s user interface.
Restriction |
|
Support for Voice Hunt Group Descriptions
In Cisco Unified CME 9.5, a description can be specified for a voice hunt group using the description command in voice hunt-group configuration mode.
For a configuration example, see Example for Specifying a Description for a Voice Hunt-Group.
Prevent Local Call Forwarding to the Final Agent in a Voice Hunt-Groups
Local or internal calls are calls originating from a Cisco Unified SIP or Cisco Unified SCCP IP phone in the same Cisco Unified CME system.
Before Cisco Unified CME 9.5, the no forward local-calls command was configured in ephone-hunt group to prevent a local call from being forwarded to the next agent.
In Cisco Unified CME 9.5, local calls are prevented from being forwarded to the final destination using the no forward local-calls to-final command in parallel configuration mode or the sequential voice hunt-group configuration mode.
When the no forward local-calls to-final command is configured in sequential voice hunt-group configuration mode, local calls to the hunt-group pilot number are sent sequentially only to the list of members of the group using the rotary-hunt technique. In case all the group members of the voice hunt group are busy, the caller hears a busy tone. If any of the group members are available but do not answer, the caller hears a ringback tone and is eventually disconnected after the specified timeout. The call is not forwarded to the final number.
When the no forward local-calls to-final command is configured in parallel voice hunt-group configuration mode, local calls to the hunt-group pilot number are sent simultaneously to the list of members of the group using the blast technique. In case all the group members of the voice hunt group are busy, the caller hears a busy tone. If any of the group members are available but do not answer, the caller hears a ringback tone and is eventually disconnected after the specified timeout. The call is not forwarded to the final number.
For configuration information, see Prevent Local Call Forwarding to Final Agent in Voice Hunt-Groups.
For a configuration example, see Example for Preventing Local Call Forwarding in Parallel Voice Hunt-Groups.
Enhancement of Support for Voice Hunt Group Agent Statistics
Before Cisco Unified CME Release 11.5, total logged in and total logged out time statistics were supported only for ephone hunt group agents. In Cisco Unified CME 11.5, support for Total logged in and Total logged out time statistics is added for voice hunt group agents also.
-
The output of the show voice-hunt tag statistics command is modified to display the additional information in the statistics.
For more configuration examples, see Example for Call Statistics From a Voice Hunt Group.
Enhancement of Support for Ephone-Hunt Group Agent Statistics
Before Cisco Unified CME 9.5, statistics were maintained for each ephone hunt group and each ephone-hunt group agent. Some of the statistics included the number of maximum and minimum agents, average time to answer, average time in a call, and average time on hold.
In Cisco Unified CME 9.5, support for hunt group agent statistics of Cisco Unified SCCP IP phones is enhanced to include the following information:
-
Total logged in time—On an hourly basis, displays the duration (in seconds) since a specific agent logged into a hunt group.
-
Total logged out time—On an hourly basis, displays the duration (in seconds) since a specific agent logged out of a hunt group.
The output of the show ephone-hunt tag statistics command is modified to display the additional information in the statistics.
For more configuration examples, see Example for Displaying Total Logged-In Time and Total Logged-Out Time for Each Hunt-Group Agent.
Restriction |
|
Hunt Group Agent Availability Options
Three options increase the flexibility of hunt group agents by allowing them to dynamically join and leave hunt groups or to temporarily enter a not-ready state in which they do not receive calls.
Table 1 compares the following agent availability features:
|
Comparison Factor |
Dynamic Membership |
Agent Status Control |
Automatic Agent Status Not-Ready |
|---|---|---|---|
|
Purpose |
Allows an authorized agent to join and leave hunt groups. |
Allows an agent to manually activate a toggle to temporarily enter a not-ready state, in which hunt-group calls bypass the agent’s phone. |
Automatically puts an agent’s phone in a not-ready state after a specified number of hunt-group calls are unanswered by the agent’s phone. |
|
Example |
Agent A joins a hunt group at 8 a.m. and takes calls until 1 p.m., when he leaves the hunt group. While Agent A is a member of the hunt group, he occupies one of the wildcard slots in the list of numbers configured for the hunt group. At 1 p.m., Agent B joins the hunt group using the same wildcard slot that Agent A relinquished when he left. |
Agent A takes a coffee break at 10 a.m. and puts his phone into a not-ready status while he is on break. When he returns he puts his phone back into the ready status and immediately starts receiving hunt-group calls again. He retained his wildcard slot while he was in the not-ready status. |
Agent B is suddenly called away from her desk before she can manually put her phone into the not-ready status. After a hunt-group call is unanswered at Agent B’s phone, the phone is automatically placed in the not-ready status and it is not presented with further hunt-group calls. When Agent B returns, she manually puts her phone back into the ready status. |
|
Hunt-group slot availability |
An agent joining a hunt group occupies a wildcard slot in the hunt group list. An agent leaving the group relinquishes the slot, which becomes available for another agent. |
An agent who enters the not-ready state does not give up a slot in the hunt group. The agent continues to occupy the slot regardless of whether the agent is in the not-ready status. |
An agent who enters the not-ready does not give up a slot in the hunt group. The agent continues to occupy the slot regardless of whether the agent is in the not-ready status. |
|
Agent activation method |
An authorized agent uses a feature access code (FAC) to join a hunt group and a different FAC to leave the hunt group. |
An agent uses the HLog soft key to toggle agent status between ready and not ready. Agents can also use the HLog FAC to toggle between ready and not-ready if FACs are enabled. If the HLog soft key is not enabled, the DND soft key can be used to put an agent in the not-ready status and the agent will not receive any calls. |
An agent who is a member of a hunt group configured with the auto logout command does not answer the specified number of calls, and the agent’s phone is automatically changed to the not-ready status. The agent uses the HLog soft key or a FAC to return to the ready status. If the HLog soft key or FAC has not been enabled in the configuration, the agent uses the DND soft key to return to the ready status. |
|
Configuration |
The system administrator uses the list command to configure up to 20 wildcard slots in a hunt group and uses the ephone-hunt login command to authorize certain directory numbers to use these wildcard slots. |
The system administrator uses the HLog keyword with the hunt-group logout command to provide an HLog soft key on display phones and uses the fac command to enable standard FACs or create a custom FAC. |
The system administrator uses the auto logout command to enable automatic agent status not-ready for a hunt group. This functionality is disabled by default. |
|
Optional customizations |
The system administrator can establish custom FACs for agents to use to enter or leave a hunt group. |
The system administrator can use the softkeys commands to change the position or prevent the display of the HLog soft key on individual phones. |
The system administrator can use the auto logout command to specify the number of unanswered calls that will trigger an agent status change to not-ready and whether this feature applies to dynamic hunt-group members, static hunt-group members, or both. The system administrator can use the hunt-group logout command to specify whether an automatic change to the not-ready status also places a phone in DND mode. |
Dynamic Ephone Hunt Group Membership
Hunt groups allow you to set up pools of extension numbers to answer incoming calls. Up to 20 wildcard slots can be entered in the list of hunt group extension numbers to allow dynamic group membership, in which authorized phone users can join a hunt group whenever a vacant wildcard slot is available and they can leave when they like. Each phone user who joins a group occupies one slot. If no slots are available, a user who tries to join a group hears a busy signal.
Allowing dynamic membership in a hunt group is a three-step process:
-
Use the list command in ephone-hunt configuration mode to specify up to 20 wildcard slots in the hunt group.
-
Use the ephone-hunt login command under each directory number that should be allowed to dynamically join and leave hunt groups. Directory numbers are disallowed from joining ephone hunt groups by default, so you have to explicitly allow this behavior for each directory number that you want to be able to log in to ephone hunt groups.
-
Use the fac standard command to enable standard FACs or the fac custom command to define custom FACs. FACs must be enabled so that agents can use them to join and leave ephone hunt groups.
To dynamically join an ephone hunt group, a phone user dials a standard or custom FAC for joining an ephone hunt group. The standard FAC to join an ephone hunt group is *3.
If multiple ephone hunt groups have been created that allow dynamic membership, the phone user must also dial the ephone hunt group pilot number. For example, if the following ephone hunt groups are defined, a phone user dials *38000 to join the Sales hunt group:
voice hunt-group 24 sequential
pilot 8000
list 8001, 8002, *, *
description Sales Group
final 9000
voice hunt-group 25 sequential
pilot 7000
list 7001, 7002, *, *
description Service Group
final 9000
To leave an ephone hunt group, a phone user dials the standard or custom FAC. The standard FAC to leave an ephone hunt group is #3. See Customize Softkeys.
Note |
The Dynamic Membership feature is different from the Agent Status Control feature and the Automatic Agent Status Not-Ready feature. Table 1 compares the features. |
Dynamically Join or Unjoin Multiple Voice Hunt Groups
In Cisco Unified CME 10.5 and later versions, support for phones to dynamically join the voice hunt groups is added. This feature is supported on both the SIP and SCCP phones. A single DN can dynamically join and unjoin multiple voice hunt groups. You can perform this action on a maximum of six different voice hunt groups.
A single SCCP or SIP DN can join multiple voice hunt groups dynamically by using the existing FAC standards with pilot number of voice hunt groups. A primary DN of a phone can also join and unjoin the voice hunt group using the Join or Unjoin soft key that are available on the Voice Hunt Group information display page in the My Phone App menu by using the service button.
From Cisco Unified CME Release 10.5 onwards, a status message is displayed on the SCCP phone when a dynamic agent joins a hunt group. The support for status message display for a dynamic agent joining a hunt group on the SIP phone is supported from Cisco Unified CME Release 11.6 onwards.
If a SIP or mixed shared line DN (multi-line) joins multiple voice hunt groups, the phone displays the called number information on the phone's interface for 5 seconds. For SCCP phones, the voice hunt group-related information is displayed for the primary line of the phone.
Hunt groups allow you to set up pools of extension numbers to answer incoming calls. You can enter up to 32 wildcard slots in the list of voice hunt group extension numbers to allow dynamic group membership, in which phone users can join or unjoin a voice hunt group whenever a vacant wildcard slot is available. Each phone user who joins a group occupies one slot. If no slots are available, a user who tries to join a group will fail to join.
Allowing dynamic membership in a voice hunt group is a three-step process:
-
Use the list command in voice-hunt configuration mode to specify up to 32 wildcard slots in the hunt group.
-
Use the voice-hunt-groups login command under each directory number that should be allowed to dynamically join and unjoin hunt groups. Directory numbers are not allowed from joining voice hunt groups by default, so you have to explicitly allow this behavior for each directory number that you want to be able to join or unjoin a voice hunt groups.
-
Use the fac standard command to enable standard FACs or the fac custom command to define custom FACs. FACs must be enabled so that agents can use them to join and unjoin hunt groups.
To dynamically join a voice hunt group, a phone user dials a standard or custom FAC for joining a voice hunt group. The standard FAC to join a voice hunt group is *3.
If multiple voice hunt groups have been configured with dynamic agents, the phone user must also dial the voice hunt group pilot number. If only one voice hunt group is configured with dynamic agent, on SIP phone only FAC is sufficient. Whereas, on SCCP phone, pilot number is mandatory. For example, if the following voice hunt groups are defined, a phone user dials *38000 to join the Sales hunt group:
voice hunt-group 24 sequential
pilot 8000
list 8001, 8002, *, *
description Sales Group
final 9000
voice hunt-group 25 sequential
pilot 7000
list 7001, 7002, *, *
description Service Group
final 9000
To unjoin a voice hunt group, a phone user dials the standard or custom FAC. The standard FAC to unjoin from all the hunt groups is #3. See Customize Softkeys. If a DN joins multiple voice hunt groups, then to unjoin from a specific voice hunt group the user can dial the standard FAC #4 followed by the pilot number.
From Unified CME 12.2 onwards, SIP, SCCP, and mixed (both SIP and SCCP) shared DNs can Join or Unjoin a voice hunt group dynamically.
Agent Status Control for Ephone Hunt Group
The Agent Status Control feature allows ephone hunt group agents to control whether their phones are in the ready or not-ready status. A phone in the ready status is available to receive calls from the hunt group. A phone in the not-ready status blocks calls from the hunt group. Agents should use the not-ready status for short breaks or other temporary interruptions during which they do not want to receive hunt-group calls.
Agents who put their phones into the not-ready status do not relinquish their slots in the hunt group list.
Agents use the HLog soft key or the DND soft key to put a phone into the not-ready status. When the HLog soft key is used to put a phone in the not-ready status, it does not receive hunt group calls but can receive other calls. If the DND soft key is used, the phone does not receive any calls until it is returned to the ready status. The HLog and DND soft keys toggle the feature: if the phone is in the ready status, pressing the key puts the phone in the not-ready status and vice-versa.
The DND soft key is visible on phones by default, but the HLog soft key must be enabled in the configuration using the hunt-group logout command, which has the following options:
-
HLog—Enables both an HLog soft key and a DND soft key on phones in the idle, seized, and connected call states. When you press the HLog soft key, the phone is changed from the ready to not-ready status or from the not-ready to ready status. When the phone is in the not-ready status, it does not receive calls from the hunt group, but it is still able to receive calls that do not come through the hunt group (calls that directly dial its extension). The DND soft key is also available to block all calls to the phone if that is the preferred behavior.
-
DND—Enables only a DND soft key on phones. The DND soft key also changes a phone from the ready to not-ready status or from the not-ready to ready status, but the phone does not receive any incoming calls, including those from outside hunt groups.
Phones without soft-key displays can use a FAC to toggle their status from ready to not-ready and back to ready. The fac command is configured under telephony-service configuration mode to enable the standard set of FACs or to create custom FACs. The standard FAC to toggle the not-ready status at the directory number (extension) level is *4 and the standard FAC to toggle the not-ready status at the ephone level (all directory numbers on the phone) is *5. See Where to Go Next.
Note |
The Agent Status Control feature is different from the Dynamic Membership feature and the Automatic Agent Status Not-Ready feature. Table 1 compares the features. |
Agent Status Control for Voice Hunt Group
The Agent Status Control feature allows voice hunt group agents to control whether their phones are in the ready or not-ready status. A phone in the ready status is available to receive calls from the hunt group. A phone in the not-ready status blocks calls from the hunt group. Agents should use the not-ready status for short breaks or other temporary interruptions during which they do not want to receive hunt-group calls.
Agents who put their phones into the not-ready status do not relinquish their slots in the hunt group list.
Agents use the HLog softkey or the DND softkey to put a phone into the not-ready status. When the HLog softkey is used to put a phone in the not-ready status, it does not receive hunt group calls but can receive other calls. When Agent use DND button, phone will be put into Not-Ready state and Hunt group calls will not be routed. However normal or direct calls are still routed, but without audio notifications.
The DND softkey is visible on phones by default, but the HLog softkey must be enabled in the configuration using the hunt-group logout command, which has the following options:
-
HLog—Enables both an HLog softkey and a DND softkey on phones in the idle, ringing, and connected call states. When you press the HLog softkey, the phone is changed from the ready to not-ready status or from the not-ready to ready status. When the phone is in the not-ready status, it does not receive calls from the hunt group, but it is still able to receive calls that do not come through the hunt group (calls that directly dial its extension). DND softkey suppresses audio notifications for direct calls.
-
DND—Enables only a DND softkey on phones. The DND softkey also changes a phone from the ready to not-ready status or from the not-ready to ready status for voice hunt group calls. Phones receive those calls that directly dial the extension.
Phones without soft-key displays can use a FAC to toggle their status from ready to not-ready and back to ready. The fac command configured under telephony-service configuration mode must be used to enable the standard set of FACs or to create custom FACs. The standard FAC to toggle the not-ready status is *4 and the standard FAC to toggle the not-ready status at the phone level (all directory numbers on the phone) is *5. See Where to Go Next.
From Cisco Unified CME 10.5 onwards, SCCP and SIP phones are supported with Agent Status Control for voice hunt group. SCCP phone can log in or log out to or from voice hunt groups using HLog or DND softkeys, or standard or custom FACs, at line-Level as well as phone level. Whereas, SIP phones can log in or log out to or from voice hunt groups using only standard or custom FACs, only at Line-Level.
From Cisco Unified CME Release 11.6 onwards, SIP phones are also supported with agent status control, for voice hunt groups with HLog softkeys or FAC. Hence, SIP phones can logout or login to voice hunt group using HLog softkey, feature button, or FAC at phone level. If the phone is configured with a single line or multiple lines, and if these lines are members of a voice hunt group, then phone level logout or login results in logout or login of all lines on the phone.
To make HLog functionality work with the SIP or SCCP phones, you need to configure the command hunt-group logout HLog under telephony-service. Once user is logged out from the hunt group, phone displays a message stating that the user is logged out of hunt group. When the user is logged in to hunt group, the agent phone displays a message stating that the user is logged in to hunt group. For Unified CME 12.1 and earlier releases, if any directory number that is part of voice hunt group is shared across phones, then logout is not allowed at the phone level.
For Unified CME 12.2 and later releases, if any directory number that is part of voice hunt group is a shared-line, then logout is allowed for all lines at the phone level, except the shared-line. Shared-line status (always in logged-in state) in a voice hunt group cannot be toggled using agent status control functionality. While SCCP phones with a mixed shared-line only support line level logout of the phone lines (except the shared-line), SIP phones with a mixed shared-line support phone level logout of the phone lines (except the shared-line).
To enable FAC, you need to configure standard or custom FAC under telephony service configuration mode using the command fac standard or fac custom .
-
If phone dn's are not members of a hunt group and phone is configured with an HLog feature button, then phone LED is off for SIP phones and on for SCCP phones.
-
If a SIP phone is already in logged in state, any newly joining dn of that phone (in any voice hunt group) is automatically in logged in state.
-
If a SIP phone is already in logged out state, any newly joining dn of that phone (in any voice hunt group) is automatically in logged out state.
-
Irrespective of whether the SCCP phone is in logged out or logged in state, any dn of that phone joining any voice hunt group retains its previous state (logged out or logged in). For example, if dn 8002 is member of voice hunt group 1 in logged out state, then 8002 remains in logged out state on joining voice hunt group 2. If dn 8001 on the same phone (which was not part of any hunt group) joins any voice hunt group, it is in logged in state.
Note |
From Cisco Unified CME Release 11.6 onwards, line level logout or login using FAC *4 is not supported for SIP phones (only supported on SCCP phones). SIP phones only support phone level logout or login using FAC *5. |
Use hlog-block command under voice hunt-group for Agent Status Control. If you enable this command under voice hunt-group , the logout or login functionality for voice hunt-group is disabled. For example, you can use hlog-block command in voice hunt-groups where logout or login functionality using HLog softkey (or by using FAC) needs to be restricted. By default, hlog-block command is disabled.
Note |
The Agent Status Control feature is different from the Dynamic Membership feature and the Automatic Agent Status Not-Ready feature. Table 1 compares the features. |
Members Logout for Ephone Hunt Group
All members configured under an ephone-hunt are initialized with HLogin by default. The non-shared static members or agents in an ephone hunt group can be configured with the Hlogout initial state using the Members Logout feature. You can use the CLI command members logout configured under ephone-hunt configuration mode to enable the feature. From Cisco Unified CME Release 9.1, members logout is supported for ephone hunt groups.
Members logout cannot be used for shared DNs. Also, this feature is not supported if the CLI commands list and hunt-group logout DND are configured.
Members Logout for Voice Hunt Group
All members configured in a voice hunt group are initialized with HLogin by default. The non-shared static members or agents in a voice hunt group can be configured with the Hlogout initial state using members logout functionality. You can use the CLI command members logout configured under voice hunt group configuration mode to enable the feature. From Cisco Unified CME Release 11.6, members logout is supported in voice hunt groups.
If any member of a hunt group in a SIP phone logs out using the CLI command members logout , all other DN's of that phone in any hunt group are also logged out. This is because SIP phones only support phone level logout. For SCCP phones, only the DN that is configured with the CLI command members logout is logged out from the hunt group. Other member DN's do not logout as SCCP phones support line level logout.
Members logout cannot be used for shared DNs. The feature is not supported if the CLI command hunt-group logout DND is configured. Also, you cannot configure the CLI command members logout if the command list is configured.
Automatic Agent Status Not-Ready for Ephone Hunt Group
Before Cisco Unified CME 4.0, this feature was known as Automatic Hunt Group Logout. If the auto logout command was enabled for a hunt group, a phone was placed in DND mode when a line on the phone did not answer a call for that hunt group within the time limit specified in the timeout command.
In Cisco Unified CME 4.0 and later versions, the name and behavior of this feature has changed, although the Cisco IOS command remains the same. The auto logout command now specifies the number of unanswered hunt group calls after which the agent status of an directory number is automatically changed to not-ready. You can limit Automatic Agent Status Not-Ready to dynamic hunt group members (those who log in using a wildcard slot in the list command) or to static hunt group members (those who are explicitly named in the list command), or you can apply this behavior to all hunt group members.
A related command, hunt-group logout , specifies whether the phones that are automatically changed to the not-ready status should also be placed into DND mode. Phones in the not-ready status do not accept calls from hunt groups, but they do accept calls that directly dial their extensions. Phones in DND mode do not accept any calls. The default if the hunt-group logout command is not used is that the phones that are automatically placed in the not-ready status are also placed in DND mode.
Agents whose phones are automatically placed into the not-ready status do not relinquish their slots in the hunt group list.
Note |
The Automatic Agent Status Not-Ready feature is different from the Dynamic Membership feature and the Agent Status Control feature. Table 1 compares the features. |
Automatic Agent Status Not-Ready for Voice Hunt Group
From Cisco Unified CME Release 11.6, Automatic Hunt Group Logout is supported on voice hunt groups. If the auto logout CLI command is enabled for a hunt group, it specifies the number of successive unanswered hunt group calls after which the agent status of an directory number is automatically changed to not-ready. The range for the number of unanswered rings configured under auto logout command is 1 to 20. If auto logout is not configured with any value, the default value of 1 is applied.
When the auto logout command is enabled under voice hunt group, the auto logout behavior applies to all hunt group members (including static and dynamic members).
A related command, hunt-group logout , specifies whether the phones are automatically changed to the not-ready status. Phones in the not-ready state do not accept calls from hunt groups, but they do accept calls that directly dial their extensions.
If hunt group logout HLog is configured, then the DNs of that hunt group will go to logout state when the number of unanswered rings specified under auto logout command is exceeded. If hunt group logout DND is configured, then phone goes to DND mode and logs out the DND member when the number of unanswered rings specified under auto logout command is exceeded. If any hunt group members are logged out, they can use HLog Softkey, FAC, Feature Button, or DND softkey to login again.
Agents whose phones are automatically placed into the not-ready status do not relinquish their slots in the hunt group list. When an agent returns to ready status, the voice hunt group resumes sending calls to the agent’s DN.
Consider a voice hunt group in sequential, peer, or longest idle configuration mode with call hunt in progress. Then, auto logout count is incremented for agents who do not answer the call. The auto logout count is not incremented for agents who answer the call. In this scenario, the agent can be either an SCCP DN or a SIP DN.
Consider a voice hunt group in parallel configuration mode with call blast in progress to all logged in DN’s in the hunt group. If call is answered by any of the agents, then the remaining agents in that hunt group will not have auto logout count incremented. However, if call is not answered by any of the agents, then the auto logout count will be incremented for all the logged in agents. Here, agent can be either a SCCP DN or SIP DN.
Note |
The Automatic Agent Status Not-Ready feature is different from the Dynamic Membership feature and the Agent Status Control feature. Table 1 compares the features. |
All Agents Logged Out Display on SIP Phones
From Unified CME 12.2 release, All agents logged out status message is displayed on SIP phones. The feature is supported on Cisco 8800 Series IP Phones for Unified CME on Cisco 4000 Series Integrated Services Routers. For example, consider a voice hunt group with three directory numbers (DN) 4002, 4003, and 4004, configured in three different IP phones. When the last member of the voice hunt group is logged out, the message, All agents logged out displays at the line level for all the members in the hunt group. If one of the DNs in the voice hunt group with all members logged out has call forward all enabled as well, then the line level display on the phone toggles between the All agents logged out and the Forwarded to directory number messages. The duration of message display before toggling is 1.5 seconds. Localization is supported for the All Agents Logged Out Display on SIP Phones. For more information, see the figure.
Presentation of Calls for Ephone Hunt Group
For phones configured under ephone hunt group configuration mode, presentation of calls is supported using the CLI command, present-call . When the CLI command is configured, calls from the ephone hunt group are presented only if all lines are on hook or in idle state.
If you configure idle-phone as the sub-mode option of the CLI command present-call , calls from the ephone-hunt group are presented only if all lines are idle on the phone on which the hunt-group line appears. This option does not consider monitored lines that have been configured on the phone using the button m command.
If you configure onhook-phone as the sub-mode option of the CLI command present-call , calls from the ephone-hunt group are presented only if the phone on which the number appears is in onhook state. When this keyword is configured, calls in the ringing or hold state that are unrelated to the hunt group do not prevent the presentation of calls from the ephone-hunt group.
Presentation of Calls for Voice Hunt Group
For phones configured under voice hunt group configuration mode, presentation of calls is supported using the CLI command present-call . The feature is supported from Cisco Unified CME Release 11.6 onwards. When the present-call CLI command is configured, calls from the voice hunt group are presented only if all lines are idle on the phone on which the hunt group line appears.
If the present-call CLI command is not configured, voice hunt group calls are presented without considering the status of other phone lines on the phone. Hence, voice hunt group presents calls to an ephone or voice register pool whenever the phone line (ephone-dn or voice register dn) that corresponds to a number in a voice hunt group list is available. Hence, when you configure the present-call CLI command, you get the additional control to ensure that hunt group calls do not possibly go unanswered.
Night Service
The night-service feature allows you to provide coverage for unstaffed extensions during hours that you designate as “night-service” hours. During the night-service hours, calls to the designated extensions, known as night-service directory numbers or night-service lines, send a special “burst” ring (for SCCP phones and SIP phones) to night-service phones that have been specified to receive this special ring. Phone users at the night-service phones can then use the call-pickup feature to answer the incoming calls from the night-service directory numbers.
For example, the night-service feature can allow an employee working after hours to intercept and answer calls that are presented to an unattended receptionist’s phone. This feature is useful for sites at which all incoming public switched telephone network (PSTN) calls have to be transferred by a receptionist. This is because all the Direct Inward Dialing (DID) calls are not published to PSTN for Cisco Unified CME system. When a call arrives at the unattended receptionist’s phone during hours that are specified as night service, a ring burst notifies a specified set of phones of the incoming call. A phone user at any of the night-service phones can intercept the call using the call-pickup feature. Night-service call notification is sent every 12 seconds until the call is either answered or aborted.
A user can enter a night-service code to manually toggle night-service treatment off and on from any phone that has a line assigned to night service. Before Cisco CME 3.3, using the night-service code turns night service on or off only for directory numbers on the phone at which the code is entered. In Cisco CME 3.3 and later versions, using the night-service code at any phone with a night-service directory number turns night service on or off for all phones with night-service directory numbers. From Unified CME 11.5 onwards, night service feature is supported on SIP phones along with SCCP phones.
Mixed deployment of SIP and SCCP phones is supported from Cisco Unified CME Release 11.6. Any combination of SIP and SCCP phones are supported across incoming call, unstaffed DNs, and agent phones. For DNs in which night service is enabled, notifications are sent to both SIP and SCCP phones that are designated as night service agents in a mixed deployment.
Night Service for SCCP Phones illustrates night service for SCCP phones.
Night Service for SIP Phones illustrates night service for SIP phones.
Overlaid Ephone-dns
Overlaid ephone-dns are directory numbers that share the same button on a phone. Overlaid ephone-dns can be used to receive incoming calls and place outgoing calls. Up to 25 ephone-dns can be assigned to a single phone button. They can have the same extension number or different numbers. The same ephone-dns can appear on more than one phone and more than one phone can have the same set of overlaid ephone-dns.
The order in which overlaid ephone-dns are used by incoming calls can be determined by the call hunt commands, preference and huntstop . For example, ephone-dn 1 to ephone-dn 4 have the same extension number, 1001. Three phones are configured with the button 1o1,2,3,4 command. A call to 1001 will ring on the ephone-dn with the highest preference and display the caller ID on all phones that are on hook. If another incoming call to 1001 is placed while the first call is active (and the first ephone-dn with the highest preference is configured with the no huntstop command), the second call will roll over to the ephone-dn with the next-highest preference, and so forth. For more information, see Call Hunt.
If the ephone-dns in an ephone-dn overlay use different numbers, incoming calls go to the ephone-dn with the highest preference. If no preferences are configured, the dial-peer hunt command setting is used to determine which ephone-dns are used for incoming calls. The default setting for the dial-peer hunt command is to randomly select an ephone-dn that matches the called number.
Note |
To continue or to stop the search for ephone-dns, you must use, respectively, the no huntstop and huntstop commands under the individual ephone-dns. The huntstop setting is applied only to the dial peers affected by the ephone-dn command in telephony-service mode. Dial peers configured in global configuration mode comply with the global configuration huntstop setting. |
Overlaid Ephone-dn (Simple Case) shows an overlay set with two directory numbers and one number that is shared on two phones. Ephone-dn 17 has a default preference value of 0, so it will receive the first call to extension 1001. The phone user at phone 9 answers the call, and a second incoming call to extension 1001 can be answered on phone 10 using directory number 18.
When a call is answered on an ephone-dn, that ephone-dn is no longer available to other phones that share the ephone-dn in overlay mode. For example, if extension 1001 is answered by phone 1, caller ID for extension 1001 displays on phone 1 and is removed from the screens of phone 2 and phone 3. All actions pertaining to the call to extension 1001 (ephone-dn 17) are displayed on phone 1 only. If phone 1 puts extension 1001 on hold, the other phones will not be able to pick up the on-hold call using a simple shared-line pickup. In addition, none of the other four phones will be able to make outgoing calls from the ephone-dn while it is in use. When phone users press button 1, they will be connected to the next available ephone-dn listed in the button command. For example, if phone 1 and phone 2 are using ephone-dn 1 and ephone-dn 2, respectively, phone 3 must pick up ephone-dn 3 for an outgoing call.
If there are more phones than ephone-dns associated with an ephone-dn overlay set, it is possible for some phones to find that all the ephone-dns within their overlay set are in use by other phones. For example, if five phones have a line button configured with the button 1o1, 2, 3 command, there may be times when all three of the ephone-dns in the overlay set are in use. When that occurs, the other two phones will not be able to use an ephone-dn in the overlay set. When all ephone-dns in an overlay set are in use, phones with this overlay set will display the remote-line-in-use icon (a picture of a phone with a flashing X through it) for the corresponding line button. When at least one ephone-dn becomes available within the overlay set (that is, an ephone-dn is either idle or ringing), the phone display reverts to showing the status of the available ephone-dn (idle or ringing).
Shared- Line Overlays
Dual-line ephone-dns can also use overlays. The configuration parameters are the same as for single-line ephone-dns, except that the huntstop channel command must be used to keep calls from hunting to the ephone-dn’s second channel.
The primary ephone-dn in a shared-line overlay set should be unique to the phone to guarantee that the phone has a line available for outgoing calls, and to ensure that the phone user can obtain dial-tone even when there are no idle lines available in the rest of the shared-line overlay set. Use a unique ephone-dn to provide for a unique calling party identity on outbound calls made by the phone so that the called user can see which specific phone is calling.
The following example shows the configuration for a simple shared-line overlay set. The primary ephone-dn that is configured for each phone is unique while the remaining ephone-dns 10, 11, and 12 are shared in the overlay set on both phones.
ephone 1 mac-address 1111.1111.1111 button 1o1,10,11,12!ephone 2 mac-address 2222.2222.2222 button 1o2,10,11,12A more complex directory number configuration mixes overlaid directory numbers with shared directory numbers and plain dual-line directory numbers on the same phones. Overlaid Ephone-dn (Complex Case) illustrates the following example of a manager with two assistants. On the manager’s phone the same number, 2001, appears on button 1 and button 2. The two line appearances of extension 2001 use two single-line directory numbers, so the manager can have two active calls on this number simultaneously, one on each button. The directory numbers are set up so that button 1 will ring first, and if a second call comes in, button 2 will ring. Each assistant has a personal directory number and also shares the manager’s directory numbers. Assistant 1 has all three directory numbers in an overlay set on one button, whereas assistant 2 has one button for the private line and a second button with both of the manager’s lines in an overlay set. A sequence of calls might be as follows.
-
An incoming call is answered by the manager on extension 2001 on button 1 (directory number 20).
-
A second call rings on 2001 and rolls over to the second button on the manager’s phone (directory number 21). It also rings on both assistants’ phones, where it is also directory number 21, a shared directory number.
-
Assistant 2 answers the call. This is a shared overlay line (one directory number, 21, is shared among three phones, and on two of them this directory number is part of an overlay set). Because it is shared with button 2 on the manager’s phone, the manager can see when assistant 2 answers the call.
-
Assistant 1 makes an outgoing call on directory number 22. The button is available because of the additional directory numbers in the overlay set on the assistant 1 phone.
At this point, the manager is in conversation on directory number 20, assistant 1 is in conversation on directory number 22, and assistant 2 is in conversation on directory number 21.
For configuration information, see Configure Overlaid Ephone-dns on SCCP Phones.
Call Waiting for Overlaid Ephone-dns
Call waiting allows phone users to know that another person is calling them while they are talking on the phone. Phone users hear a call-waiting tone indicating that another party is trying to reach them. Calls to IP phones with soft keys can be answered with the Answer soft key. Calls to analog phones are answered using hookflash. When phone users answer a call-waiting call, their original call is automatically put on hold. If phone users ignore a call-waiting call, the caller is forwarded if call-forward no-answer has been configured.
In Cisco CME 3.2.1 and later versions, call waiting is available for overlaid ephone-dns. The difference in configuration between overlaid ephone-dns with call waiting and overlaid ephone-dns without call waiting is that overlaid ephone-dns with call waiting use the c keyword in the button command and overlaid ephone-dns without call waiting use the o keyword. For configuration information, see Configure Overlaid Ephone-dns on SCCP Phones.
The behavior of overlaid ephone-dns with call waiting and overlaid ephone-dns without call waiting is the same, except for the following:
-
Calls to numbers included in overlaid ephone-dns with call waiting will cause inactive phones to ring and active phones connected to other parties to generate auditory call-waiting notification. The default sound is beeping, but you can configure an ephone-dn to use a ringing sound. (See Configure Call-Waiting Indicator Tone on SCCP Phone.) Visual call-waiting notification includes the blinking of handset indicator lights and the display of caller IDs.
For example, if three of four phones are engaged in calls to numbers from the same overlaid ephone-dn with call-waiting and another call comes in, the one inactive phone will ring, and the three active phones will issue auditory and visual call-waiting notification.
-
In Cisco Unified CME 4.0 and later versions, up to six waiting calls can be displayed on Cisco Unified IP Phone 7940G, 7941G, 7941G-GE, 7960G, 7961G, 7961G-GE, 7970G, and 7971G-GE. For all other phones and earlier Cisco Unified CME versions, two calls to numbers in an overlaid ephone-dn set can be announced. Subsequent calls must wait in line until one of the two original calls has ended. The callers who are waiting in the line will hear a ringback tone.
For example, a Cisco Unified IP Phone 7910 (maximum two call-waiting calls) has a button configured with a set of overlaid ephone-dns with call waiting (button 1c1,2,3,4 ). A call to ephone-dn 1 is answered. A call to ephone-dn 2 generates call-waiting notification. Calls to ephone-dn 3 and ephone-dn 4 will wait in line and remain invisible to the phone user until one of the two original calls ends. When the call to ephone-dn 1 ends, the phone user can then talk to the person who called ephone-dn 2. The call to ephone-dn 3 issues call-waiting notification while the call to ephone-dn 4 waits in line. (The Cisco Unified IP Phone 7960 supports six calls waiting.) Phones configured for call waiting do not generate call-waiting notification when they are transferring calls or hosting conference calls.
Note that if an overlaid ephone-dn has call-forward-no-answer configured, calls to the ephone-dn that are unanswered before the no-answer timeout expires are forwarded to the configured destination. If call-forward-no-answer is not configured, incoming calls receive ringback tones until the calls are answered.
More than one phone can use the same set of overlaid ephone-dns. In this case, the call-waiting behavior is slightly different. The following example demonstrates call waiting for overlaid ephone-dns that are shared on two phones:
ephone 1button 1c1,2,3,4!ephone 2button 1c1,2,3,4-
A call to ephone-dn 1 rings on ephone 1 and on ephone 2. Ephone 1 answers, and the call is no longer visible to ephone 2.
-
A call to ephone-dn 2 issues a call-waiting notification to ephone 1 and rings on ephone 2, which answers. The second call is no longer visible to ephone 1.
-
A call to ephone-dn 3 issues a call-waiting notification to ephone 1 and ephone 2. Ephone 1 puts the call to ephone-dn 1 on hold and answers the call to ephone-dn 3. The call to ephone-dn 3 is no longer visible to ephone 2.
-
A call to ephone-dn 4 is issues a call-waiting notification on ephone 2. The call is not visible on ephone 1 because it has met the two-call maximum by handling the calls to ephone-dn 1 and ephone-dn 3. (Note that the call maximum is six for those phones that are able to handle six call-waiting calls, as previously described.)
Note |
Ephone-dns accept call interruptions, such as call waiting, by default. For call waiting to work, the default must be active. For more information, see Configure Call-Waiting Indicator Tone on SCCP Phone. |
Extend Calls for Overlaid Ephone-dns to Other Buttons on the Same Phone
Phones with overlaid ephone-dns can use the button command with the x keyword to dedicate one or more additional buttons to receive overflow calls. If an overlay button is busy, an incoming call to any of the other ephone-dns in the overlay set rings on the first available overflow button on each phone that is configured to receive the overflow. This feature works only for overlaid ephone-dns that are configured with the button command and the o keyword; it is not supported with overlaid ephone-dns that are configured using the button command and the c keyword or other types of ephone-dns that are not overlaid.
Using the button command with the c keyword results in multiple calls on one button (the button is overlaid with multiple ephone-dns that have call waiting), whereas using the button command with the o keyword and the x keyword results in one call per button and calls on multiple buttons.
For example, an ephone has an overlay button with ten numbers assigned to it using the button command and the o keyword. The next two buttons on the phone are configured using the button command and the x keyword. These buttons are reserved to receive additional calls to the overlaid extensions on the first button when the first button is in use.
ephone 276 button 1o24,25,26,27,28,29,30,31,32,33 2x1 3x1For configuration information, see Configure Overlaid Ephone-dns on SCCP Phones.
Feedback