Call alerting on Hunt group as shared line

[mar1us_CS]

Hi Gents,

First ,I have  CUCM 10.5.

I was asked to configure a hunt group for 5 users and set it so up ,to make the difference between an inbound call for the Hunt

Group itself and a inbound call for any of the members of the Hunt Group.

I was thinking to put the Hunt Group DN as a shared line on all the members of the group,so every member has a 2nd line on their

phones right now.

I did it like this ,but I have the following behavior :

- call comes to the user itself, the corespondent line button light is signaling the call which is fine,btw

- call comes to the Hunt Group,but instead of the hunt group line button signaling,call appears on the 1st line,although it says

under the Caller ID "For Hunt group..."

So, in case of a missed call, I cannot see if the call was for the Hunt Group or for a member of the Hunt Group.

My question is ,why is the call does not appear on the 2nd line, where the Hunt Group DN is configured as shared line ?

Is it the way it should be or am I doing something wrong ?

Many thanks for your help.

[Aaron Harrison]

Why would you make the hunt group DNs a shared line?

Set them up as non-shared, and the line group as a 'broadcast' type if you want simul ringing.

Aaron

[mar1us_CS]

Hi Aaron,

the members asked me if they are able to recognise based on a missed call if it was a general call for the hunt group or a dedicated call for one of the members of the Hunt Group, in case the Caller do not leave a VM.

P.S. Line group is already as broadcast configured and FWD no answer and FWD busy (for the HG) are set up to go to VM.

Thank you

[Eike Scholz-Janotte]

Hi,

you will see if the missed call was a HG call or a direct call. It may depend on the phone but HG Calls are marked.

Eike

[mar1us_CS]

Hi Eike,

The point is I cannot see...phones are 8945G.

When the call is made ,I can see a "For hunt group..." message (see pics)

As soon as this call becomes missed , there is no sign that would make the difference.

Am I doing something wrong here ?

Thanks !

P.S. I attached pics about the process

[Charles Hill]

The fix we found for the same issue,

go to

-> Hunt Pilot configuration

-> Calling party transformations

-> Prefix digits

-> Enter some identifier/number for prefix digits

When you retrieve your call history, you will still see the external caller-id, but there will be the prefix/identifier at the beginning of the caller-id, which will allow the call takers to verify if the last call was from the hunt group or a direct call.

Hope this helps,

if so, please rate.

[CHRIS CHARLEBOIS]

Changing the Calling Number may allow users to see which missed calls were originally from the hunt group, but I think you are missing a key point.  If you have the DN of the Hunt Group as a shared line on the second line of the phone, you have something misconfigured.  In fact, I don't even think the CUCM allows you to have a DN assigned to a phone that is also a Hunt Group Pilot.  The reason the calls are not coming in on the second line is because the Hunt Group Pilot has priority and it is routing the calls to the hunt group members, which I presume is the DN's on the first line appearance.  From what I see, you have 3 options:

- Using Calling Number Transformation and leave this misconfigured system for the next person to scratch his/her head on.

- Put individual non-DID DN's on the second line of each phone and configure those DN's as the Hunt Group members.

- Scrape the Hunt Group all together and just have the DN only exist as a shared line on the second line appearance of all phones.

Whether you choose the second or the third depends on if you want to allow users to log in/out of the Hunt Group.  If you do, go option 2.  If not, option 3.  For the sake of the next guy, don't use option 1.

[Charles Hill]

Hey Chris,

I completely agree with you concerning the hunt pilot dn not being assigned to a phone.

Your option 2:

its possible if an inbound call was forwarded to one of the non dids, you would still have the same issue as far as not being able to determine if it was from the hunt group or not.  Not likely to happen at least not often.  But still a possibility.

Option 3, you lose the abilities for users to login and logout of the hung group and the control that you have over a hunt group, which we need in our environment.

For our environment,, option 1 works fine.  I don't consider it being a misconfigured system, since only calls coming from the hunt group, has the hunt pilot number prefixed in front of the caller id.  Plus, I like to keep things as simple as possible for the end users.

[CHRIS CHARLEBOIS]

The issue with option 1 is that the fact that there is something assigned to the second line appearance does not matter at all.  It doesn't do anything.  Which is why I called is misconfigured; it *looks* like it is supposed to be doing one thing, but it does something else entirely.

The use would be able to see, in the call logs, which line each call appeared on.  So, yes, if for some reason a call was forwarded to the non-DID that was dedicated for Hunt Group use, the user would not be able to tell that call from a call coming in on the Hunt Group.

Another thing to consider is that your users lose the ability to dial from the call log with the calling party transformation.  Often that isn't possible anyways.

[Charles Hill]

I guess I should address the issue with a hunt group as a shared line, but it had already been addressed by Aaron.

Good point about dialing from the call log.

Our end users are able to call from the call log, only if they press -> more -> edit dial ->

and delte the prefix, then they are able to call from the call log.

[mar1us_CS]

Hi guys,

I really appreciate your ideas and the way you are trying to give me a solution on my issue.
I would like to make some remarks regarding to those spoken above :
- Chris, you are right,CUCM does not allows you to use an extension ,both for DN and also for a Hunt Group.
This is why I did the following : I pickup a DID from my range of DID's and created as a DN . All the calls coming to this DID I forwarded to an internal number(non-DID). This number I made it the HG number.But, as a shared line I put the DID number and not the non-DID.
For e.g. 5555 is the DID , 4444 is the internal number and also the HG number.
1111, 2222 and 3333 are the DN's part of the HG.
So the calls are coming to 5555, which forwards instantly calls to 4444.
Every phone screen looks like this :
1111    2222   3333
5555   5555   5555
-cehill,I would rather not play with any Calling Party Transformation, just for a single Hunt Group configuration.More than that,there is the possibility for the Caller to leave a VM,if the issue is really important.And as I configured the VM right now, MWI appears correctly on every phone, if the call is for one member or for the HG.

The option of log in/out of the HG is not used in my environment,so this cannot be a problem.
Still, making a call from the Call Log seems to be much more important for the business, as it makes the difference between internal and external calls.

I am not sure I understood the workaround in the options 2 and 3.

Many thanks !

[Charles Hill]

Hello mar1us_CS,

Its my understanding that all three recommendations start with not assigning a hunt pilot number to the phones, which I believe was a misunderstanding.  Since 5555 is a DID, which is forwarded to the hunt pilot number.

Option 1: prefix an identifier in front of the caller id on calls coming from the hunt group, which enables the call taker to distinguish between hunt group calls and other calls.

Option 2: Create a non-did DN for each phone in the hunt group, which would reduce the possibility of the DN being called directly from the outside.  Outside calls in the call log should be from the hunt group, internal calls should not. (may not be 100% accurate, since an external call or internal could technically get to the hunt group)

option 3:  Completely remove the hunt group and create a shared dn across the phones, which would replace the hunt group.

Now as far as the returning calls from the call log. 

I have a question concerning the call log and dialing out via the call log to Chris or anyone else that may have the answer.

We are editing all external calls in the call log by adding 9 in front of the caller-id, which enables us to return the missed calls. 

Is there an easy way to allow them to press "dial" from the cal log without editing to make an outbound call? 

Chris, If i misunderstood the options, I apologize and please correct me. 

The more I learn the more I realize I don't know. 

This forum is such a great way to learn, assist and be assisted. 

Hope this helps...

[mar1us_CS]

Hi guys,

cehill,I confirm that in this case ,the 5555 is the DID forwarded to an internal number(which is the HG number). CUCM does not let to have an identical DN and HG number simultaneously .

Back to the options :

1. I tried it and it works . Unfortunately, if the business need requires to call back the missed call from the call log, I am afraid that I have to leave this option out.

2. All the DN's in the cluster are configured from the beginning with Enterprise Alternate Number which allows the numbers to be replicated to other clusters. Also, the team members are changing a lot and doing(just for them) some extra changes for a limited time, would not be pleasant workaround for this situation.

3. I am afraid this out of the question, as their manager may wish to change the distribution algorithm(from broadcast to top down or circular) and the shared line option would not offer this possibility.

So, option 1 would be more closer to the solution ,but needs to be discussed.

Many thanks !

[Charles Hill]

Do you currently have the ability to call external phone numbers from the call log without editing?  If so, how?

I'll do some testing and get back with you on calling from the call log. 

[mar1us_CS]

After some discussion, the team agreed that adding a number identifier would be no issue, when calling back.

They can re-edit the number, so that the call can be dial-able .

Now ,all the external calls from the call log are succesfull...the system adds a digit to get outside and then dials the full E164 number.

Thank you !