unity call handler troubles

[greg.mcbean]

We have a simple call handler that is using a privalte distribution list as the owner in the profile when we enable the owners of the pdl cannot record messages if a routing rule is in place if the routing rule is in place they can record messages but the closed greeting goes to the fail safe recording the standard greeting works fine we are running unity 4.0.3

[lindborg]

First, I assume you mean a public distribution list - you can't assign a private DL as an owner or recipient for a call handler.

Second, I'm confused by your problem report - do you mean members of the PDL cannot record new greetings for the call handler through the "Greetings Administration" conversation? I don't know what you mean by "cannot record messages if a routing rus is in place". I'm not following what you mean...

third, If you're getting failsafe on the closed greeting, look in the application event log - there will be at least one error logged that will give us a clue as to the source of the problem.

[greg.mcbean]

Yes it is a public distribution list

there is a routing rule in place for this call handler our initial problem was when it came time according to the schedule to change to the closed greeting it went to the failsafe when we disabled the routing rule the closed greeting was now accessible but the members of this public distribution list could no longer access the greetings to re record part of my question is is there a requirement in Unity 4.0.3 for a routing rule to be in effect in order for the users of the public distribution list to be able to access the greetings AS this public distribution list is the owner of some other call handlers but they all have routing rules with no problems in being able to access the greetings

[pbarman]

When you got the failsafe message, what event was logged in the windows event viewer application log?

I believe you are using Greeting Administrator (CUGA) to rerecord your closed greeting for the call handler in question. You said "the members of PDL could no longer access the greeting to rerecord....". What happens when a member of the PDL logs into the CUGA using his extension and password, then enters the extension of this call handler???

To my knowledge, there is not any necessity to have a routing rule associated with a call hanler to be able to record/change its greetings via CUGA. You will need an extension on the call handler which is a necessity.

[greg.mcbean]

thank you for your time I have found the at sr1 will take care of my problem with CSCec53192

[lindborg]

No, there's no relationship at all between routing rules, the owner(s) of a call handler and the greetings that play for a call handler - you're dealing with seperate issues here.

The place to start is the error in the event log when you get failsafe.

And a description of what happens when you try to edit the greeting of the call handler via CUGA would be good, too. I don't know what you mean by "no access to the greeting".

[greg.mcbean]

Thank you for your time I have found that sr1 will solve my problem with CSCec53192

[mciarfello]

Can I chime in here a couple months after the original discussion?

I just ran into a situation where a call handler must have an owner assigned or the failsafe greeting will play.

This seems contrary to what the documentation says and what Jeff said about the owner not being related to what greeting plays. As soon as I assigned an owner, the call handler greeting played.

Are my observations correct?

Thanks

Using 4.0.3 SR1.

[lindborg]

the owner is not related to what greeting plays however an owner must be assigned (just as a recipient must be assigned even if it's not used). when the PHGreeting or PHTransfer conversation loads up a call handler, it checks for that and if it's not there it'll error out on you.

[afuller]

Maybe there's no message recipient configured on the callhandler? Back in the day, if there wasn't an owner assigned to a callhandler, there was a very good chance there wasn't a message recipient configured either. That lack of a recipient is what was really causing the failsafe, but I think they've fixed that as of 4.0.1 or 4.0.2...can't remember....

[mciarfello]

Great,

Thanks for the explanation.